draft-ietf-pce-p2mp-app-02.txt   rfc5671.txt 
Network Working Group S. Yasukawa Network Working Group S. Yasukawa
Internet Draft NTT Request for Comments: 5671 NTT
Category: Informational A. Farrel (Editor) Category: Informational A. Farrel, Ed.
Created: August 17, 2009 Old Dog Consulting Old Dog Consulting
Expires: February 17, 2010 October 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) MPLS and GMPLS Traffic Engineering (TE)
and Generalized MPLS (GMPLS) Traffic Engineering (TE)
draft-ietf-pce-p2mp-app-02.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract Abstract
The Path Computation Element (PCE) provides path computation The Path Computation Element (PCE) provides path computation
functions in support of traffic engineering in Multiprotocol Label functions in support of traffic engineering in Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) networks. Switching (MPLS) and Generalized MPLS (GMPLS) networks.
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.
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
RFC 5671 PCE for P2MP MPLS and GMPLS TE October 2009
Table of Contents Table of Contents
1. Introduction ................................................... 3 1. Introduction ....................................................2
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 Overload ............................................... 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 ...............................11
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
8.6. Impact on Network Operation ................................. 13 Components ................................................12
9. Security Considerations ....................................... 13 8.6. Impact on Network Operation ...............................13
10. IANA Considerations .......................................... 13 9. Security Considerations ........................................13
11. Acknowledgments .............................................. 13 10. Acknowledgments ...............................................13
12. References ................................................... 14 11. References ....................................................13
12.1. Normative Reference ........................................ 14 11.1. Normative References .....................................13
12.2. Informative Reference ...................................... 14 11.2. Informative References ...................................13
13. Authors' Addresses ........................................... 15
14. Full Copyright Statement ..................................... 15
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 of applying computational constraints. The
is that the PCE is used to compute the path of Traffic Engineered intention is that the PCE is used to compute the path of Traffic
Label Switched Paths (TE LSPs) within Multiprotocol Label Switching Engineered Label Switched Paths (TE LSPs) within Multiprotocol Label
(MPLS) and Generalized MPLS (GMPLS) networks. Switching (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 collocated 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]. In this
networks are considered in support of various features including
layer 3 multicast VPNs [RFC4834], video distribution, etc. RFC 5671 PCE for P2MP MPLS and GMPLS TE October 2009
document, P2MP MPLS TE networks are considered in support of various
features including 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
constrained by the network topology and available network resources, selection constrained by the network topology and available network
but it is determined by the objective functions that may be applied resources, but it is determined by the objective functions that may
to path computation. For example, one standard objective is to be applied to path computation. For example, one standard objective
minimize the total cost of the tree (that is, to minimize the sum of is to minimize the total cost of the tree (that is, to minimize the
the costs of each link traversed by the tree) to produce what is sum of the costs of each link traversed by the tree) to produce what
known as a Steiner Tree. Another common objective function requires is known as a Steiner tree. Another common objective function
that the cost to reach each leaf of the P2MP tree is minimized. requires that the cost to reach each leaf of the P2MP tree be
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
information may be recorded in the Traffic Engineering Database (TED) information may be recorded in the Traffic Engineering Database (TED)
that the PCE uses to perform its computations, and may have been that the PCE uses to perform its computations, and may have been
distributed using extensions to the Interior Gateway Protocol (IGP) distributed using extensions to the Interior Gateway Protocol (IGP)
operating within the network [RFC5073]. operating within the network [RFC5073].
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 LSPs in certain types of networks, 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 multicast 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 resiliency 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
act of path computation might interfere with the control and act of path computation might interfere with the control and
management plane operation necessary to maintain existing LSPs. The
RFC 5671 PCE for P2MP MPLS and GMPLS TE October 2009
management plane operation necessary to maintain existing LSPs. The
PCE architecture offers a way to offload such path computations from PCE architecture offers a way to offload such path computations from
LSRs. LSRs.
2. Architectural Considerations 2. Architectural Considerations
2.1. Offline Computation 2.1. Offline Computation
Offline path computation is performed ahead of time, before the LSP Offline path computation is performed ahead of time, before the LSP
setup is requested. That means that it is requested by, or performed setup is requested. That means that it is requested by, or performed
as part of, a management application. This model can be seen in as part of, a management application. This model can be seen in
Section 5.5 of [RFC4655]. Section 5.5 of [RFC4655].
The offline model is particularly appropriate to long-lived LSPs The offline model is particularly appropriate to long-lived LSPs
(such as those present in a transport network) or for planned (such as those present in a transport network) or for planned
responses to network failures. In these scenarios, more planning is responses to network failures. In these scenarios, more planning is
normally a feature of LSP provisioning. normally a feature of LSP provisioning.
This model may also be used where the network operator wishes to This model may also be used where the network operator wishes to
retain full manual control of the placement of LSPs, using the PCE retain full manual control of the placement of LSPs, using the PCE
only as a computation tool to assist the operator, not as part of an only as a computation tool to assist the operator, not as part of an
automated network. automated network.
Offline path computation may be applied as a background activity for Offline path computation may be applied as a background activity for
network reoptimization to determine whether and when the current LSP network reoptimization to determine whether and when the current LSP
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 collocated 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 it 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 a Network Management
the computation is not necessarily achieved by a single PCE operating System (NMS). Furthermore, the computation is not necessarily
on its own, but may be the result of cooperation between several achieved by a single PCE operating on its own, but may be the result
PCEs. of cooperation between several 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.
2.2.1. LSR Loading RFC 5671 PCE for P2MP MPLS and GMPLS TE October 2009
2.2.1. LSR Loading
An important feature of P2MP path computation is the processing load An important feature of P2MP path computation is the processing load
that it places on the network element that is determining the path. that it places on the network element that is determining the path.
Roughly speaking, the load to compute a least-cost-to-leaf tree is Roughly speaking, the load to compute a least-cost-to-leaf tree is
the same as the cost to compute a single optimal path to each leaf in the same as the cost to compute a single optimal path to each leaf in
turn. The load to compute a Steiner tree is approximately an order of turn. The load to compute a Steiner tree is approximately an order
magnitude greater although there exist algorithms to approximate of magnitude greater, although algorithms exist to approximate
Steiner trees in roughly the same order of magnitude of time as for a Steiner trees in roughly the same order of magnitude of time as for a
least-cost-to-leaf tree. least-cost-to-leaf tree.
Whereas many LSRs are capable of simple Constrained Shortest Path Whereas many LSRs are capable of simple Constrained Shortest Path
First (CSPF) computations to determine a path for a single point-to- First (CSPF) computations to determine a path for a single point-to-
point (P2P) LSP, they rapidly become swamped if called on to perform point (P2P) LSP, they rapidly become swamped if called on to perform
multiple such computations such as when recovering from a network multiple such computations, such as when recovering from a network
failure. Thus, it is reasonable to expect that an LSR would struggle failure. Thus, it is reasonable to expect that an LSR would struggle
to handle a P2MP path computation for a tree with many destinations. to handle a P2MP path computation for a tree with many destinations.
The result of an LSR becoming overloaded by a P2MP path computation The result of an LSR becoming overloaded by a P2MP path computation
may be two-fold. First, the LSR may be unable to provide timely may be two-fold. First, the LSR may be unable to provide timely
computations of paths for P2P LSPs: this may impact LSP setup times computations of paths for P2P LSPs; this may impact LSP setup times
for simple demand-based services, and could damage the LSR's ability for simple demand-based services and could damage the LSR's ability
to recover services after network faults. Secondly, the LSR's to recover services after network faults. Secondly, the LSR's
processing capabilities may be diverted from other important tasks processing capabilities may be diverted from other important tasks,
not the least of which is maintaining the control plane protocols not the least of which is maintaining the control plane protocols
that are necessary to the support of existing LSPs and forwarding that are necessary to the support of existing LSPs and forwarding
state within the network. It is obviously critically important that state within the network. It is obviously critically important that
existing traffic should not be disrupted by the computation of a path existing traffic should not be disrupted by the computation of a path
for a new LSP. for a new LSP.
It also not reasonable to expect the ingress LSRs of P2MP LSRs to be It is also not reasonable to expect the ingress LSRs of P2MP LSRs to
specially powerful and capable of P2MP computations. Although a be specially powerful and capable of P2MP computations. Although a
solution to the overloading problem would be to require that all LSRs solution to the overloading problem would be to require that all LSRs
that form the ingresses to P2MP LSPs should be sufficiently that form the ingresses to P2MP LSPs be sufficiently high-capacity to
high-capacity to perform P2MP computations, this is not an acceptable perform P2MP computations, this is not an acceptable solution
solution because in all other senses, the ingress to a P2MP LSP is because, in all other senses, the ingress to a P2MP LSP is just a
just a normal ingress LSR. normal ingress LSR.
Thus, there is an obvious solution which is to off-load P2MP path Thus, there is an obvious solution: off-load P2MP path computations
computations from LSRs to remotely located PCEs. Such PCE function from LSRs to remotely located PCEs. Such PCE function can be
can be provided on dedicated or high-capacity network elements (such provided on dedicated or high-capacity network elements (such as
as dedicated servers, or high-end routers that might be located 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 Overload RFC 5671 PCE for P2MP MPLS and GMPLS TE October 2009
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 overload at the PCEs. That is, the P2MP computations may block cause overload at the PCEs. That is, the P2MP computations may 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,
computation requests can be assigned priorities by the LSRs that path 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 overload notification may choose between them and may use overload notification information
information supplied by the PCEs to spot which PCEs are currently supplied by the PCEs to spot which PCEs are currently over-loaded.
over-loaded. Additionally, a PCE that is becoming over-loaded may Additionally, a PCE that is becoming over-loaded may redistribute its
redistribute its queue of computation requests to other less-burdened queue of computation requests (using the PCE cooperation model
PCEs within the network using the PCE cooperation model described in described in [RFC4655]) to other, less burdened PCEs within the
[RFC4655]. network.
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 overload notifications from the PCEs, but could also may be based on overload notifications from the PCEs, but could 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 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. This exchange of can be made directly between the PCEs and the LSRs. This exchange of
PCE capabilities information allows a Path Computation Client (PCC) PCE capabilities information allows a Path Computation Client (PCC)
to select thePCE that can best answer its computation requests. to select the PCE that can best answer its computation requests.
3. Fragmenting the P2MP Tree RFC 5671 PCE for P2MP MPLS and GMPLS TE October 2009
A way to reduce the computational burden on a single PCE of computing 3. Fragmenting the P2MP Tree
a large P2MP tree is to fragment or partition the tree. This may be
particularly obvious in a multi-domain network (such as multiple A way to reduce the computational burden of computing a large P2MP
tree on a single PCE is to fragment or partition the tree. This may
be 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
single PCE model, LSR A may request the entire path of the tree and a 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
x, and from M to s, y, and z. and 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
in a single computation response to PCE A. The mechanisms for both of 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 A--b--c--d--g--i--L--p--w
/ \ \
/ \ \
A--b--c--d--g--i--L--p--w 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
RFC 5671 PCE for P2MP MPLS and GMPLS TE October 2009
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 [RFC5441]. Backward Recursive Path Computation (BRPC) mechanism [RFC5441].
Indeed, if the LSRs K, L, and M were ASBRs or Area Border Routers Indeed, if LSRs K, L, and M were ASBRs or Area Border Routers (ABRs),
(ABRs) the BRPC technique would be particularly applicable. 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, or 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.
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 as well
between replication point and each leaf so as to achieve a P2MP as 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 scope 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
consult a PCE in its turn and determine the P2P LSPs to egress LSRs will consult a PCE in its turn and determine the P2P LSPs to egress
m and p, and the P2P LSP to the next replication point, LSR J. LSRs m and p as well as the P2P LSP to the next replication point,
Finally, LSR J will use a PCE to determine P2P LSPs to egresses n and LSR J. Finally, LSR J will use a PCE to determine P2P LSPs to
o. egresses n and o.
f--i--m RFC 5671 PCE for P2MP MPLS and GMPLS TE October 2009
/
/
a--b--c--D--g--J--n
\ \
\ \
E h K o
\
\
l--p
Figure 2 : Using Centralized Replication Points f--i--m
/
/
a--b--c--D--g--J--n
\ \
\ \
E h K o
\
\
l--p
In this model of operation it is quite likely that the PCE function Figure 2: Using Centralized Replication Points
is located at the replication points which will be high-capacity
LSRs. One of the main features of the computation activity is the In this model of operation, it is quite likely that the PCE function
is located at the replication points, which will be high-capacity
LSRs. One of the main features of the computation activity is the
selection of the replication 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 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
Once established, P2MP LSPs are more sensitive to modification than Once established, P2MP LSPs are more sensitive to modification than
their P2P counterparts. If an egress is removed from a P2P LSP, the their P2P counterparts. If an egress is removed from a P2P LSP, the
whole LSP is torn down. But egresses may be added to and removed from whole LSP is torn down. But egresses may be added to and removed
active P2MP LSPs as receivers come and go. from active P2MP LSPs as receivers come and go.
The removal of an egress from a P2MP LSP does not require any new The removal of an egress from a P2MP LSP does not require any new
path computation since the tree can be automatically pruned. path computation since the tree can be automatically pruned.
The addition of a new egress to a P2MP LSP can be handled as the The addition of a new egress to a P2MP LSP can be handled as the
computation of an appropriate branch point and the determination of a computation of an appropriate branch point and the determination of a
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 sub-optimal 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.
RFC 5671 PCE for P2MP MPLS and GMPLS TE October 2009
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 brought 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
administrator so that only subsets of the egresses (or subtrees of network administrator so that only subsets of the egresses (or
the P2MP tree) are optimized at any time. In these cases, the subtrees of the P2MP tree) are optimized at any time. In these
computational load of reoptimization may be considerable, but cases, the computational load of reoptimization may be considerable,
fortunately reoptimization computations may be performed as but 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 [RFC5557] can achieve Network-wide reoptimization of multiple LSPs [RFC5557] can achieve
far greater improvements in optimality within overloaded networks far greater improvements in optimality within overloaded networks
than can be achieved by reoptimizing LSPs sequentially. Such than can be achieved by reoptimizing LSPs sequentially. Such
computation would typically be performed offline and would usually computation would typically be performed offline and would usually
require a dedicated 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
is (statistically) likely to only impact a small subset of the total fault is (statistically) likely to only impact a small subset of the
set of egresses. Repair activity, therefore, does not need to total 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.
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
sophisticated reoptimization computations can be deferred until the sophisticated reoptimization computations can be deferred until the
network is stable and the load on the PCEs has been reduced. Those network is stable and the load on the PCEs has been reduced. Those
reoptimizations can be computed as described in Section 5. reoptimizations can be computed as described in Section 5.
7. Disjoint Paths RFC 5671 PCE for P2MP MPLS and GMPLS TE October 2009
7. Disjoint Paths
Disjoint paths are required for end-to-end protection services and Disjoint paths are required for end-to-end protection services and
sometimes for load balancing. They may require to be fully disjoint sometimes for load balancing. They may require to be fully disjoint
(except at the ingress and egress!), link disjoint (allowing common (except at the ingress and egress!), link disjoint (allowing common
nodes on the paths), or best-effort disjoint (allowing sharing of nodes on the paths), or best-effort disjoint (allowing shared links
links or nodes when no other path can be found). or nodes when no other path can be found).
It is possible to compute disjoint paths sequentially, but this can It is possible to compute disjoint paths sequentially, but this can
lead to blocking problems where the second path cannot be placed. lead to blocking problems where the second path cannot be placed.
Such issues are more readily avoided if the paths are computed in Such issues are more readily avoided if the paths are computed in
parallel. parallel.
The computation of link disjoint P2P paths may be non-trivial and may The computation of link disjoint P2P paths may be non-trivial and may
be the sort of task that an LSR offloads to a PCE because of its be the sort of task that an LSR offloads to a PCE because of its
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 manageability considerations as when it is used for P2P LSPs
[RFC5440]. There may be additional manageability implications for the [RFC5440]. There may be additional manageability implications for
size of P2MP computation requests and the additional loading exerted the size of P2MP computation requests and the additional loading
on the PCEs. 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. Care needs to be taken in the data models, such as MIB modules. Care needs to be taken in the
RFC 5671 PCE for P2MP MPLS and GMPLS TE October 2009
design of such data models, and the use of other management protocols design of such data models, and the use of other management protocols
and data modelling structures, such as NETCONF / NETMOD [RFC4741] and data modeling structures, such as NETCONF [RFC4741] and the
could be considered. NETCONF Data Modeling Language (NETMOD), 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 LSRs that are concerned that PCE algorithms PCEs is out of scope, but LSRs that are concerned that PCE algorithms
might not be operating correctly may make identical requests to might not be operating correctly may make identical requests to
separate PCEs and compare the responses. 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]. The PCE Communication Protocol (PCEP) is defined in
[RFC5440], but extensions will be necessary to support P2MP [RFC5440], but extensions will be necessary to support P2MP
computation 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 [RFC5440], ([RFC5088] and [RFC5089]) and can also be exchanged in PCEP
but extensions will be required to describe P2MP capabilities. ([RFC5440]), 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 RFC 5671 PCE for P2MP MPLS and GMPLS TE October 2009
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
LSRs freeing them up to handle protocol operations. LSRs, freeing them up to handle protocol operations.
Furthermore, the use of a PCE may enable more dynamic behavior in Furthermore, the use of a PCE may enable more dynamic behavior in
P2MP LSPs (such as addition of new egresses, reoptimization, and P2MP LSPs (such as the addition of new egresses, reoptimization, and
failure recovery) than is possible using more traditional management- failure recovery) than is possible using more traditional
based planning techniques. management-based planning techniques.
9. Security Considerations 9. Security Considerations
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.
Thus, the use of message integrity and authentication mechanisms Thus, the use of message integrity and authentication mechanisms
within the PCE protocol should be used to mitigate attacks from within the PCE protocol should be used to mitigate attacks from
devices that are not authorized to send requests to the PCE. It would devices that are not authorized to send requests to the PCE. It
be possible to consider applying different authorization policies for would be possible to consider applying different authorization
P2MP path computation requests compared to other requests. policies for P2MP path computation requests compared to other
requests.
10. IANA Considerations
This document makes no requests for IANA action.
11. Acknowledgments 10. 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. Lars Eggert, Dan Romascanu, and Tim Polk their thoughtful comments. Lars Eggert, Dan Romascanu, and Tim Polk
provided useful comments during IESG review. provided useful comments during IESG review.
12. References 11. References
12.1. Normative Reference 11.1. Normative References
[RFC4655] Farrel, A., Vasseur, J.P., and Ash, G., "A Path [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", Computation Element (PCE)-Based Architecture", RFC 4655,
RFC 4655, August 2006. August 2006.
12.2. Informative Reference 11.2. Informative References
[RFC4461] S. Yasukawa, Editor, "Signaling Requirements for [RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to-
Point-to-Multipoint Traffic Engineered MPLS LSPs", Multipoint Traffic-Engineered MPLS Label Switched Paths
RFC4461, April 2006. (LSPs)", RFC 4461, April 2006.
[RFC4657] Ash, J., and Le Roux, J.L., "Path Computation Element RFC 5671 PCE for P2MP MPLS and GMPLS TE October 2009
(PCE) Communication Protocol Generic Requirements",
RFC 4657, September 2006.
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, [RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation
December 2006. Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, September 2006.
[RFC4834] Morin, T., "Requirements for Multicast in Layer 3 [RFC4741] Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4741,
Provider-Provisioned Virtual Private Networks December 2006.
(PPVPNs)", RFC 4834, April 2007.
[RFC4875] Aggarwal, R., Papadimitriou, D., and Yasukawa, S., [RFC4834] Morin, T., Ed., "Requirements for Multicast in Layer 3
"Extensions to Resource Reservation Protocol - Traffic Provider-Provisioned Virtual Private Networks (PPVPNs)",
Engineering (RSVP-TE) for Point-to-Multipoint TE Label RFC 4834, April 2007.
Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC5073] Vasseur, J.P, and Le Roux, J.L., Editors, "IGP Routing [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Protocol Extensions for Discovery of Traffic Yasukawa, Ed., "Extensions to Resource Reservation
Engineering Node Capabilities", RFC 5073, December Protocol - Traffic Engineering (RSVP-TE) for Point-to-
2007. Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May
2007.
[RFC5088] Le Roux, J.L., and Vasseur, J.P., Editors, "OSPF [RFC5073] Vasseur, J., Ed., and J. Le Roux, Ed., "IGP Routing
Protocol Extensions for Path Computation Element (PCE) Protocol Extensions for Discovery of Traffic Engineering
Discovery", RFC 5088, January 2008. Node Capabilities", RFC 5073, December 2007.
[RFC5089] Le Roux, J.L., and Vasseur, J.P., Editors, "IS-IS [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
Protocol Extensions for Path Computation Element (PCE) Zhang, "OSPF Protocol Extensions for Path Computation
Discovery", RFC 5089, January 2008. Element (PCE) Discovery", RFC 5088, January 2008.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and Ash, [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
J., "Policy-Enabled Path Computation Framework", Zhang, "IS-IS Protocol Extensions for Path Computation
RFC 5394, December 2008. Element (PCE) Discovery", RFC 5089, January 2008.
[RFC5440] Vasseur, J.P, and Le Roux, J.L., Editors, "Path [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
Computation Element (PCE) Communication Protocol "Policy-Enabled Path Computation Framework", RFC 5394,
(PCEP)", RFC 5440, March 2009. December 2008.
[RFC5441] J.P. Vasseur, Editor, "A Backward-Recursive PCE-Based [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation
Computation (BRPC) Procedure to Compute Shortest Element (PCE) Communication Protocol (PCEP)", RFC 5440,
Constrained Inter-Domain Traffic Engineering Label March 2009.
Switched Paths", RFC 5441, April 2009.
[RFC5557] Lee, Y., Le Roux, JL., King, D., and Oki, E., "Path [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
Computation Element Communication Protocol (PCEP) "A Backward-Recursive PCE-Based Computation (BRPC)
Requirements and Protocol Extensions in Support of Procedure to Compute Shortest Constrained Inter-Domain
Global Concurrent Optimization", RFC 5557, July 2009. Traffic Engineering Label Switched Paths", RFC 5441, April
2009.
[PCE-P2MP-REQ] Yasukawa, S., and Farrel, A., "PCC-PCE Communication [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
Requirements for Point to Multipoint Multiprotocol Computation Element Communication Protocol (PCEP)
Label Switching Traffic Engineering (MPLS-TE)", Requirements and Protocol Extensions in Support of Global
draft-yasukawa-pce-p2mp-req, work in progress. Concurrent Optimization", RFC 5557, July 2009.
13. Authors' Addresses RFC 5671 PCE for P2MP MPLS and GMPLS TE October 2009
[PCE-P2MP] Yasukawa, S., and Farrel, A., "PCC-PCE Communication
Requirements for Point to Multipoint Multiprotocol Label
Switching Traffic Engineering (MPLS-TE)", Work in
Progress, May 2008.
Authors' Addresses
Seisho Yasukawa Seisho Yasukawa
NTT Corporation NTT Corporation
9-11, Midori-Cho 3-Chome 9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585, Musashino-Shi, Tokyo 180-8585,
Japan Japan
Email: yasukawa.seisho@lab.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
14. Full Copyright Statement EMail: adrian@olddog.co.uk
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
 End of changes. 126 change blocks. 
325 lines changed or deleted 352 lines changed or added

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