< draft-ietf-pce-architecture-04.txt   draft-ietf-pce-architecture-05.txt >
Network Working Group Adrian Farrel Network Working Group Adrian Farrel
IETF Internet Draft Old Dog Consulting IETF Internet Draft Old Dog Consulting
Proposed Status: Informational Jean-Philippe Vasseur Proposed Status: Informational Jean-Philippe Vasseur
Expires: July 2006 Cisco Systems, Inc. Expires: October 2006 Cisco Systems, Inc.
Jerry Ash Jerry Ash
AT&T AT&T
January 2006 April 2006
draft-ietf-pce-architecture-04.txt draft-ietf-pce-architecture-05.txt
A Path Computation Element (PCE) Based Architecture A Path Computation Element (PCE) Based Architecture
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 3, line 28 skipping to change at page 3, line 28
in different domains. This document specifies the architecture for a in different domains. This document specifies the architecture for a
Path Computation Element (PCE)-based model to address this problem Path Computation Element (PCE)-based model to address this problem
space. space.
This document describes a set of building blocks for the PCE This document describes a set of building blocks for the PCE
architecture from which solutions may be constructed. For example, it architecture from which solutions may be constructed. For example, it
discusses PCE-based implementations including composite, external, discusses PCE-based implementations including composite, external,
and multiple PCE path computation. Furthermore, it discusses and multiple PCE path computation. Furthermore, it discusses
architectural considerations including centralized computation, architectural considerations including centralized computation,
distributed computation, synchronization, PCE discovery and load distributed computation, synchronization, PCE discovery and load
balancing, detection of PCE liveness, PCC-PCE and PCE-PCE balancing, detection of PCE liveness, communication between Path
communication, TED synchronization, stateful and stateless PCEs, Computation Clients (PCCs) and the PCE (PCC-PCE communication) and
monitoring, policy and confidentiality, and evaluation metrics. PCE-PCE communication, Traffic Engineering Database (TED)
synchronization, stateful and stateless PCEs, monitoring, policy and
confidentiality, and evaluation metrics.
The model of the Internet is to distribute network functionality The model of the Internet is to distribute network functionality
(e.g., routing) within the network. PCE functionality is not intended (e.g., routing) within the network. PCE functionality is not intended
to contradict this model, and can be used to exactly match the model, to contradict this model, and can be used to exactly match the model,
for example, when the PCE functionality co-exists with each LSR in for example, when the PCE functionality co-exists with each Label
the network. PCE is also able to augment functionality in the network Switching Router (LSR) in the network. PCE is also able to augment
where the Internet model cannot supply adequate solutions, for functionality in the network where the Internet model cannot supply
example, where traffic engineering information is not exchanged adequate solutions, for example, where traffic engineering
between network domains. information is not exchanged between network domains.
2. Terminology 2. Terminology
CSPF: Constraint-based Shortest Path First. CSPF: Constraint-based Shortest Path First.
LER: Label Edge Router. LER: Label Edge Router.
LSDB: Link State Database. LSDB: Link State Database.
LSP: Label Switched Path. LSP: Label Switched Path.
skipping to change at page 8, line 13 skipping to change at page 8, line 13
computation. computation.
4.4. Node Outside the Routing Domain 4.4. Node Outside the Routing Domain
An LER might not be part of the routing domain for administrative An LER might not be part of the routing domain for administrative
reasons (for example, a customer-edge (CE) router connected to the reasons (for example, a customer-edge (CE) router connected to the
provider-edge (PE) router in the context of MPLS VPN [RFC2547] and provider-edge (PE) router in the context of MPLS VPN [RFC2547] and
for which it is desired to provide a CE to CE TE LSP path). for which it is desired to provide a CE to CE TE LSP path).
This scenario suggests a solution that does not involve doing This scenario suggests a solution that does not involve doing
computation on the ingress (TE LSP head-end) router, and that does computation on the ingress (TE LSP head-end, CE) router, and that
not rely on static loose hops configuration in which case optimal does not rely on the configuration of static loose hops. In this
shortest paths could not be achieved. A distinct PCE-based solution case, optimal shortest paths can not be guaranteed. A solution that
can help here. Note that the PCE in this case may, itself, provide a a distinct PCE can help here. Note that the PCE in this case may,
path that includes loose hops. itself, provide a path that includes loose hops.
4.5. Network Element Lacks Control Plane or Routing Capability 4.5. Network Element Lacks Control Plane or Routing Capability
It is common in legacy optical networks for the network elements not It is common in legacy optical networks for the network elements not
to have a control plane or routing capability. Such network elements to have a control plane or routing capability. Such network elements
only have a data plane and a management plane, and all only have a data plane and a management plane, and all
cross-connections are made from the management plane. It is cross-connections are made from the management plane. It is
desirable in this case to run the path computation on the PCE, and desirable in this case to run the path computation on the PCE, and
send the cross-connection commands to each node on the computed path. send the cross-connection commands to each node on the computed path.
That is, the PCC would be an element of the management plane, perhaps That is, the PCC would be an element of the management plane, perhaps
residing in the NMS or OSS. residing in the Network Management System (NMS) or Operations Support
System (OSS).
This scenario is important for ASON-capable networks, and may also be This scenario is important for Automatically Switched Optical Network
used for interworking between GMPLS-capable and GMPLS-incapable (ASON)-capable networks, and may also be used for interworking
networks. between GMPLS-capable and GMPLS-incapable networks.
4.6. Backup Path Computation for Bandwidth Protection 4.6. Backup Path Computation for Bandwidth Protection
A PCE can be used to compute backup paths in the context of fast A PCE can be used to compute backup paths in the context of fast
reroute protection of TE LSPs. In this model all backup TE LSPs reroute protection of TE LSPs. In this model all backup TE LSPs
protecting a given facility are computed in a coordinated manner by a protecting a given facility are computed in a coordinated manner by a
PCE. This allows complete bandwidth sharing between backup tunnels PCE. This allows complete bandwidth sharing between backup tunnels
protecting independent elements, while avoiding any extensions to TE protecting independent elements, while avoiding any extensions to TE
LSP signaling. Both centralized and distributed computation models LSP signaling. Both centralized and distributed computation models
are applicable. In the distributed case each LSR can be a PCE to are applicable. In the distributed case each LSR can be a PCE to
compute the paths of backup tunnels to protect against the failure of compute the paths of backup tunnels to protect against the failure of
adjacent network links or nodes. adjacent network links or nodes.
4.7. Multi-Layer Networks 4.7. Multi-Layer Networks
A server-layer network of one switching capability may support A server-layer network of one switching capability may support
multiple networks of another (more granular) switching capability. multiple networks of another (more granular) switching capability.
For example, a TDM network may provide connectivity for client-layer For example, a TDM network may provide connectivity for client-layer
networks such as IP, MPLS or Layer 2 [MRN]. networks such as IP, MPLS or Layer 2 [MLN].
The server-layer network is unlikely to provide the same connectivity The server-layer network is unlikely to provide the same connectivity
paradigm as the client networks so that bandwidth granularity in the paradigm as the client networks so that bandwidth granularity in the
server-layer network may be much coarser than in the client-layer server-layer network may be much coarser than in the client-layer
network. Similarly, there is likely to be a management separation network. Similarly, there is likely to be a management separation
between the two networks providing independent address spaces. between the two networks providing independent address spaces.
Further, where multiple client-layer networks make use of the same Further, where multiple client-layer networks make use of the same
server-layer network, those client-layer networks may have server-layer network, those client-layer networks may have
independent policies, control parameters, address spaces and routing independent policies, control parameters, address spaces and routing
preferences. preferences.
skipping to change at page 10, line 5 skipping to change at page 9, line 48
application of policy within the path computation/selection process. application of policy within the path computation/selection process.
Similarly, a PCC may apply local policy to the selection of a PCE to Similarly, a PCC may apply local policy to the selection of a PCE to
compute a specific path, and to the constraints that are requested. compute a specific path, and to the constraints that are requested.
In a PCE context, the policy may be sensitive to the type of path In a PCE context, the policy may be sensitive to the type of path
that is being computed. For example, a different set of policies may that is being computed. For example, a different set of policies may
be applied for an intra-area or single-layer path, than would be be applied for an intra-area or single-layer path, than would be
provided for an inter-area or multi-layer path. provided for an inter-area or multi-layer path.
Note that synchronization of policy between PCEs or between PCCs and
PCEs may be necessary. Such issues are outside the scope of the PCE
architecture, but within scope for the PCE policy framework and
application which is described in a separate document.
4.9. Non-Motivations 4.9. Non-Motivations
4.9.1. The Whole Internet 4.9.1. The Whole Internet
PCE is not considered to be a solution that is applicable to the PCE is not considered to be a solution that is applicable to the
entire Internet. That is, the applicability of PCE is limited to a entire Internet. That is, the applicability of PCE is limited to a
set of domains with known relationships. The scale of this limitation set of domains with known relationships. The scale of this limitation
is similar to the peering relationships between Service Providers. is similar to the peering relationships between Service Providers.
4.9.2. Guaranteed TE LSP Establishment 4.9.2. Guaranteed TE LSP Establishment
skipping to change at page 14, line 31 skipping to change at page 14, line 31
PCE based on computation information passed from the previous PCE. PCE based on computation information passed from the previous PCE.
Alternatively, there may be explicit communication of policy Alternatively, there may be explicit communication of policy
information between PCEs. information between PCEs.
5.5 Management-Based PCE Usage 5.5 Management-Based PCE Usage
It must be observed that the PCC is not necessarily an LSR. For It must be observed that the PCC is not necessarily an LSR. For
example, in Figure 5 the NMS supplies the head-end LSR with a fully example, in Figure 5 the NMS supplies the head-end LSR with a fully
computed explicit path for the TE LSP that it is to establish through computed explicit path for the TE LSP that it is to establish through
signaling. The NMS uses a management plane mechanism to send this signaling. The NMS uses a management plane mechanism to send this
request such as the TE MIB module [RFC3812]. request, and encodes the data using a representation such as the TE
MIB module [RFC3812].
The NMS constructs the explicit path that it supplies to the head-end The NMS constructs the explicit path that it supplies to the head-end
LSR using information provided by the operator. It consults the PCE LSR using information provided by the operator. It consults the PCE
which returns a path for the NMS to use. which returns a path for the NMS to use.
Although Figure 5 shows the PCE as remote from the NMS it could, of Although Figure 5 shows the PCE as remote from the NMS it could, of
course, be collocated with the NMS. course, be collocated with the NMS.
----------- -----------
| ----- | | ----- |
skipping to change at page 15, line 34 skipping to change at page 15, line 34
Figure 5. Management-based PCE Usage Figure 5. Management-based PCE Usage
5.6 Areas for Standardization 5.6 Areas for Standardization
The following areas require standardization within the PCE The following areas require standardization within the PCE
architecture. architecture.
- communication between PCCs and PCEs, and between cooperating PCEs, - communication between PCCs and PCEs, and between cooperating PCEs,
including the communication of policy related information including the communication of policy related information
- requirements for extening existing routing and signaling protocols - requirements for extending existing routing and signaling protocols
in support of PCE discovery and signaling of inter-domain paths in support of PCE discovery and signaling of inter-domain paths
- definition of metrics to evaluate path quality, scalability, - definition of metrics to evaluate path quality, scalability,
responsiveness, robustness and policy support of path computation responsiveness, robustness and policy support of path computation
models models
- MIB modules related to communication protocols, routing and - MIB modules related to communication protocols, routing and
signaling extensions and metrics. signaling extensions, metrics, and PCE monitoring information.
6. PCE Architectural Considerations 6. PCE Architectural Considerations
This section provides a list of the PCE architectural components. This section provides a list of the PCE architectural components.
Specific realizations and implementation details (state machines or Specific realizations and implementation details (state machines or
algorithms, etc.) of PCE-based solutions are out of the scope of this algorithms, etc.) of PCE-based solutions are out of the scope of this
document. document.
Note also that PCE-based path computation does not affect in any way Note also that PCE-based path computation does not affect in any way
the use of the computed paths. For example, the use of PCE does not the use of the computed paths. For example, the use of PCE does not
skipping to change at page 18, line 35 skipping to change at page 18, line 35
Proxy PCE advertisement whereby the existence of a PCE is advertised Proxy PCE advertisement whereby the existence of a PCE is advertised
via a proxy PCE is a viable alternative, should the PCE be incapable via a proxy PCE is a viable alternative, should the PCE be incapable
of such advertisement itself. In this case, it is a requirement for of such advertisement itself. In this case, it is a requirement for
the proxy to adequately advertise the PCE status and capability in a the proxy to adequately advertise the PCE status and capability in a
timely and synchronized fashion. timely and synchronized fashion.
In the event that multiple PCEs are available to serve a particular In the event that multiple PCEs are available to serve a particular
path computation request, the PCC must select a PCE to satisfy the path computation request, the PCC must select a PCE to satisfy the
request. The details of such a selection, in order for instance to request. The details of such a selection, in order for instance to
efficiently share the computation load across multiple PCEs, is local efficiently share the computation load across multiple PCEs, or to
to the PCC, may be based on policy and out of the scope of this request secondary computations after partial or failed computations,
document. is local to the PCC, may be based on policy and out of the scope of
this document.
PCE capabilities that may be advertised or configured could include PCE capabilities that may be advertised or configured could include
(and not be limited to): (and not be limited to):
- set of constraints that it can account for (diversity, SRLGs, - set of constraints that it can account for (diversity, SRLGs,
Optical impairments, wavelength continuity, etc.) Optical impairments, wavelength continuity, etc.)
- computational capacity (for example, the number of computations it - computational capacity (for example, the number of computations it
can perform per second) can perform per second)
- number of switching capability layers (and which ones) - number of switching capability layers (and which ones)
- number of path selection criteria (and which ones) - number of path selection criteria (and which ones)
skipping to change at page 19, line 41 skipping to change at page 19, line 43
protocol timers to determine the liveness of the PCE. This is protocol timers to determine the liveness of the PCE. This is
particularly important in the case of inter-domain path computation particularly important in the case of inter-domain path computation
where the PCE liveness may not be detected by means of the IGP that where the PCE liveness may not be detected by means of the IGP that
runs in the PCC's domain. runs in the PCC's domain.
6.6. PCC-PCE & PCE-PCE Communication 6.6. PCC-PCE & PCE-PCE Communication
Once the PCC has selected a PCE, and provided that the PCE is not Once the PCC has selected a PCE, and provided that the PCE is not
local to the PCC, a request/response protocol is required for the PCC local to the PCC, a request/response protocol is required for the PCC
to communicate the path computation requests to the PCE and for the to communicate the path computation requests to the PCE and for the
PCE to return the path computation response. PCE to return the path computation response. Discussion of the
security requirements and implications for this protocol is provided
in Section 10 of this document.
The path computation request may include a significant set of The path computation request may include a significant set of
requirements including: requirements including:
- the source and destination of the path - the source and destination of the path
- the bandwidth and other QoS parameters desired - the bandwidth and other QoS parameters desired
- resources, resource affinities and shared risk link groups (SRLGs) - resources, resource affinities and shared risk link groups (SRLGs)
to use/avoid to use/avoid
- the number of disjoint paths required and if near-disjoint paths - the number of disjoint paths required and if near-disjoint paths
are acceptable are acceptable
skipping to change at page 21, line 54 skipping to change at page 22, line 6
usage policies can be configured by the operator. Path computation usage policies can be configured by the operator. Path computation
can also act on a far wider set of information that includes data can also act on a far wider set of information that includes data
about the TE LSPs provisioned within the network. This information about the TE LSPs provisioned within the network. This information
can include TE LSP routes, reserved bandwidth, and measured can include TE LSP routes, reserved bandwidth, and measured
traffic volume passing through the TE LSP. traffic volume passing through the TE LSP.
Such TE LSP information can enhance TE LSP (re)optimization to Such TE LSP information can enhance TE LSP (re)optimization to
provide "full network" (re)optimization, and can allow traffic provide "full network" (re)optimization, and can allow traffic
fluctuations to be taken into account. Detailed TE LSP information fluctuations to be taken into account. Detailed TE LSP information
may also facilitate reconfiguration of the Virtual Network may also facilitate reconfiguration of the Virtual Network
Topology (VNT) [MRN], in which lower layer TE LSPs such as optical Topology (VNT) [MLN], in which lower layer TE LSPs such as optical
paths provide TE links for use by the higher layer, since this paths provide TE links for use by the higher layer, since this
reconfiguration is also a "full network" problem. reconfiguration is also a "full network" problem.
Note that synchronization techniques may apply to both intra- and Note that synchronization techniques may apply to both intra- and
inter-domain TEDs. Further, the techniques can be mixed for use in inter-domain TEDs. Further, the techniques can be mixed for use in
different domains. The degree of synchronization between the PCE and different domains. The degree of synchronization between the PCE and
the network is subject to implementation and/or policy. However, the network is subject to implementation and/or policy. However,
better synchronization generally leads to paths that are more likely better synchronization generally leads to paths that are more likely
to succeed. to succeed.
skipping to change at page 23, line 19 skipping to change at page 23, line 22
synchronization and race condition avoidance become larger and more synchronization and race condition avoidance become larger and more
complex. complex.
There is benefit in knowing which TE LSPs exist, and their routing, There is benefit in knowing which TE LSPs exist, and their routing,
to support such applications as placing a high priority TE LSP in a to support such applications as placing a high priority TE LSP in a
crowded network such that it preempts as few other TE LSPs as crowded network such that it preempts as few other TE LSPs as
possible (also known as the "minimal perturbation" problem). Note possible (also known as the "minimal perturbation" problem). Note
that preempting based on the minimum number of links might not result that preempting based on the minimum number of links might not result
in the smallest number of TE LSPs being disrupted. Another in the smallest number of TE LSPs being disrupted. Another
application concerns the construction and maintenance of a Virtual application concerns the construction and maintenance of a Virtual
Network Topology [MRN]. It is also helpful to understand which other Network Topology [MLN]. It is also helpful to understand which other
TE LSPs exist in the network in order to decide how to manage the TE LSPs exist in the network in order to decide how to manage the
forward adjacencies that exist or need to be set up. The cost-benefit forward adjacencies that exist or need to be set up. The cost-benefit
of stateful PCE computation would be helpful to determine if the of stateful PCE computation would be helpful to determine if the
benefit in path computation is sufficient to offset the additional benefit in path computation is sufficient to offset the additional
drain on the network and computational resources. drain on the network and computational resources.
Conversely, stateless PCEs do not have to remember any computed path Conversely, stateless PCEs do not have to remember any computed path
and each set of request(s) is processed independently of each other. and each set of request(s) is processed independently of each other.
For example, stateless PCEs may compute paths based on current TED For example, stateless PCEs may compute paths based on current TED
information, which could be out of sync with actual network state information, which could be out of sync with actual network state
skipping to change at page 24, line 19 skipping to change at page 24, line 19
to the PCE status and operation. For example, it will be necessary to to the PCE status and operation. For example, it will be necessary to
understand the way in which the TED is being kept synchronized, the understand the way in which the TED is being kept synchronized, the
rate of arrival of new requests and the computation times, the range rate of arrival of new requests and the computation times, the range
of PCCs that are using the PCE, and the operation of any PCC-PCE of PCCs that are using the PCE, and the operation of any PCC-PCE
protocol. protocol.
6.10. Confidentiality 6.10. Confidentiality
As stated in [RFC4216], the case of inter-provider TE LSP As stated in [RFC4216], the case of inter-provider TE LSP
computation requires the ability to compute a path while preserving computation requires the ability to compute a path while preserving
confidentiality across multiple Service Providers cores. Thus any PCE confidentiality across multiple Service Providers cores. That is, one
architecture solution must support the ability to return partial Service Provider must not be required to divulge any information
paths by means of loose hops (for example, where each loose hops about its resources or topology in order to support inter-provider
would for instance identify a boundary LSR). Confidentiality and TE LSP path computation. Thus any PCE architecture solution
security of PCC-PCE and PCE-PCE messages must also be ensured. must support the ability to return partial paths by means of loose
hops (for example, where each loose hops would for instance
identify a boundary LSR).
This requirement is not a security issue, but relates to Service
Provider policy. Confidentiality, integrity, and authentication of
PCC-PCE and PCE-PCE messages must also be ensured and is described in
Section 10.
The ability to compute a path at the request of the head end PCC, but The ability to compute a path at the request of the head end PCC, but
to supply the path in segments to the domain boundary PCCs may also to supply the path in segments to the domain boundary PCCs may also
be desirable. be desirable.
6.11. Policy 6.11. Policy
Policy impacts multiple aspects of the PCE architecture. There are Policy impacts multiple aspects of the PCE architecture. There are
two applications of policy for consideration: two applications of policy for consideration:
- application of policy within an architectural entity (PCC or PCE) - application of policy within an architectural entity (PCC or PCE)
skipping to change at page 25, line 22 skipping to change at page 25, line 26
PCC/PCE that receives the response. PCC/PCE that receives the response.
A PCE may have a local policy that impacts the paths selected to A PCE may have a local policy that impacts the paths selected to
satisfy a particular PCE request. A policy may be applied based on satisfy a particular PCE request. A policy may be applied based on
any information provided from a PCC. any information provided from a PCC.
In Figure 6 the policy component is shown providing input to the PCE In Figure 6 the policy component is shown providing input to the PCE
component. This policy component may consult an external policy component. This policy component may consult an external policy
database, but this is outside the scope of this document. database, but this is outside the scope of this document.
Note that policy information may be conveyed on the internal
interfaces, and on the external protocol interfaces.
------------------------------ ------------------------------
| --------- | Routing ---------- | --------- | Routing ----------
| | | | Protocol | | | | | | Protocol | |
| | TED |<-+----------+-> | | | TED |<-+----------+-> |
| | | | | | | | | | | |
| --------- | | | | --------- | | |
| | | | | | | | | |
| | Input | | | | | Input | | |
| v | | | | v | | |
| --------- --------- | | | | --------- --------- | | |
skipping to change at page 26, line 5 skipping to change at page 26, line 5
| --------- | | | | --------- | | |
Service | | | | Signaling| | Service | | | | Signaling| |
Request | |Signaling| | Protocol | | Request | |Signaling| | Protocol | |
------+---------------->| Engine |<-+----------+-> | ------+---------------->| Engine |<-+----------+-> |
| | | | | | | | | | | |
| --------- | ---------- | --------- | ----------
------------------------------ ------------------------------
Figure 6. Policy Component in the Composite PCE Node Figure 6. Policy Component in the Composite PCE Node
Note that policy information may be conveyed on the internal
interfaces, and on the external protocol interfaces.
Figure 7 displays the case of a distinct PCE function through the Figure 7 displays the case of a distinct PCE function through the
example of the multiple PCE with inter-PCE communication example example of the multiple PCE with inter-PCE communication example
(compare with figure 4). Each PCE takes input from local policy as (compare with figure 4). Each PCE takes input from local policy as
part of the router computation/determination process. The local part of the router computation/determination process. The local
policy components may consult external policy components or policy components may consult external policy components or
databases, but that is out of scope of this document. databases, but that is out of scope of this document.
Note that policy information may be conveyed on the external Note that policy information may be conveyed on the external
protocol interfaces, including the inter-PCE interface. protocol interfaces, including the inter-PCE interface.
skipping to change at page 32, line 28 skipping to change at page 32, line 28
amount of the load. It will also be important to be able to record amount of the load. It will also be important to be able to record
and inspect statistics about the communications between the PCC and and inspect statistics about the communications between the PCC and
PCE, including issues such as malformed messages, unauthorized PCE, including issues such as malformed messages, unauthorized
messages and messages discarded owing to congestion. In this respect messages and messages discarded owing to congestion. In this respect
there is clearly an overlap between manageability and security. there is clearly an overlap between manageability and security.
Statistics for the PCE architecture can be made available through Statistics for the PCE architecture can be made available through
appropriate tables in the new MIB modules. appropriate tables in the new MIB modules.
The new MIB modules should also be used to provide notifications The new MIB modules should also be used to provide notifications when
(formerly known as traps) when key thresholds are crossed or when key thresholds are crossed or when important events occur. Great care
important events occur. Great care must be exercised to ensure that must be exercised to ensure that the network is not flooded with SNMP
the network is not flooded with SNMP notifications. Thus it might be notifications. Thus it might be inappropriate to issue a notification
inappropriate to issue a notification every time that a PCE receives every time that a PCE receives a request to compute a path. In any
a request to compute a path. In any case, full control must be case, full control must be provided to allow notifications to be
provided through the MIB modules to allow notifications to be disabled using, for example, the mechanisms defined in the
disabled. SNMP-NOTIFICATION-MIB module in [RFC3413].
9.3. Liveness Detection and Monitoring 9.3. Liveness Detection and Monitoring
Section 6.5 discusses the importance of a PCC being able to detect Section 6.5 discusses the importance of a PCC being able to detect
the liveness of a PCE. PCE-PCC communications techniques must enable the liveness of a PCE. PCE-PCC communications techniques must enable
a PCC to determine the liveness of a PCE both before it sends a a PCC to determine the liveness of a PCE both before it sends a
request and in the period between sending a request and receiving a request and in the period between sending a request and receiving a
response. response.
It is less important for a PCE to know about the liveness of PCCs, It is less important for a PCE to know about the liveness of PCCs,
skipping to change at page 34, line 42 skipping to change at page 34, line 42
It is important that network congestion be managed proactively It is important that network congestion be managed proactively
because it may be impossible to manage it reactively once the network because it may be impossible to manage it reactively once the network
is congested. It should be possible for an operator to rate limit the is congested. It should be possible for an operator to rate limit the
requests that a PCC sends to a PCE, and a PCE should be able to requests that a PCC sends to a PCE, and a PCE should be able to
report impending congestion (according to a configured threshold) report impending congestion (according to a configured threshold)
both to the operator and to its PCCs. both to the operator and to its PCCs.
9.7. Other Considerations 9.7. Other Considerations
No other management considerations arise. No other management considerations have been identified.
10. Security Considerations 10. Security Considerations
The impact of the use of a PCE-based architecture must be considered The impact of the use of a PCE-based architecture must be considered
in the light of the impact that it has on the security of the in the light of the impact that it has on the security of the
existing routing and signaling protocols and techniques in use within existing routing and signaling protocols and techniques in use within
the network. There is unlikely to be any impact on intra-domain the network. There is unlikely to be any impact on intra-domain
security, but an increase in inter-domain information flows and the security, but an increase in inter-domain information flows and the
facilitation of inter-domain path establishment may increase the facilitation of inter-domain path establishment may increase the
vulnerability to security attacks. vulnerability to security attacks.
skipping to change at page 35, line 45 skipping to change at page 35, line 45
12. Acknowledgements 12. Acknowledgements
The authors would like to extend their warmest thanks to (in The authors would like to extend their warmest thanks to (in
alphabetical order) Arthi Ayyangar, Zafar Ali, Lou Berger, Mohamed alphabetical order) Arthi Ayyangar, Zafar Ali, Lou Berger, Mohamed
Boucadair, Igor Bryskin, Dean Cheng, Vivek Dubey, Kireeti Kompella, Boucadair, Igor Bryskin, Dean Cheng, Vivek Dubey, Kireeti Kompella,
Jean-Louis Le Roux, Stephen Morris, Eiji Oki, Dimitri Papadimitriou, Jean-Louis Le Roux, Stephen Morris, Eiji Oki, Dimitri Papadimitriou,
Richard Rabbat, Payam Torab, Takao Shimizu, and Raymond Zhang for Richard Rabbat, Payam Torab, Takao Shimizu, and Raymond Zhang for
their review and suggestions. Lou Berger provided valuable and their review and suggestions. Lou Berger provided valuable and
detailed contributions to the discussion of policy in this document. detailed contributions to the discussion of policy in this document.
Thanks also to Pekka Savola, Russ Housley and Dave Kessens for review
and constructive discussions during the final stages of publication.
13. Intellectual Property Considerations 13. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 36, line 33 skipping to change at page 36, line 36
[RFC2547] Rosen, E. and Rekhter, Y. "BGP/MPLS VPNs", RFC 2547, [RFC2547] Rosen, E. and Rekhter, Y. "BGP/MPLS VPNs", RFC 2547,
March 1999. March 1999.
[RFC3209] Awduche, D., et. all, "Extensions to RSVP for LSP [RFC3209] Awduche, D., et. all, "Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3630] Katz et al., "Traffic Engineering (TE) Extensions to [RFC3630] Katz et al., "Traffic Engineering (TE) Extensions to
OSPF Version 2", RFC 3630, September 2003. OSPF Version 2", RFC 3630, September 2003.
[RFC3413] Levi, D., Meyer, P. and B. Stewart, "Simple Network
Management Protocol (SNMP) Applications", STD 62, RFC
3413, December 2002.
[RFC3473] Berger, L., et. al., "Generalized Multi-Protocol Label [RFC3473] Berger, L., et. al., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling - Resource ReserVation Switching (GMPLS) Signaling - Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003. RFC 3473, January 2003.
[RFC3748] Smit, H. and Li, T., "Intermediate System to [RFC3748] Smit, H. and Li, T., "Intermediate System to
Intermediate System (IS-IS) - Extensions for Traffic Intermediate System (IS-IS) - Extensions for Traffic
Engineering (TE)", RFC 3784, June 2004. Engineering (TE)", RFC 3784, June 2004.
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau,
skipping to change at page 37, line 5 skipping to change at page 37, line 12
Engineering (TE) Management Information Base (MIB)", Engineering (TE) Management Information Base (MIB)",
RFC 3812, June 2004. RFC 3812, June 2004.
[RFC4105] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements for [RFC4105] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements for
Support of Inter-Area and Inter-AS MPLS Traffic Support of Inter-Area and Inter-AS MPLS Traffic
Engineering", RFC 4105, June 2005. Engineering", RFC 4105, June 2005.
[RFC4216] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic [RFC4216] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic
Engineering requirements", RFC 4216, November 2005. Engineering requirements", RFC 4216, November 2005.
[MRN] Shiomoto, K., et. al., "Requirements for GMPLS-based [MLN] Shiomoto, K., et. al., "Requirements for GMPLS-based
multi-region and multi-layer networks", multi-region and multi-layer networks",
draft-ietf-ccamp-gmpls-mln-reqs, work in progress. draft-ietf-ccamp-gmpls-mln-reqs, work in progress.
15. Contact Information 15. Contact Information
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
Jean-Philippe Vasseur Jean-Philippe Vasseur
 End of changes. 25 change blocks. 
48 lines changed or deleted 74 lines changed or added

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