One document matched: draft-lee-pce-ted-alternatives-00.txt
PCE Y. Lee
Internet Draft Huawei
G. Bernstein
Grotto Networking
D. Li
Huawei
Intended status: Informational September 26, 2008
Expires: March 2009
Alternative Approaches to Traffic Engineering Database Creation and
Maintenance for Path Computation Elements
draft-lee-pce-ted-alternatives-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any 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 aware will be disclosed, in accordance with Section 6 of
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
This Internet-Draft will expire on March 26, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Lee Expires March 26, 2009 [Page 1]
Internet-Draft PCE TED Alternatives September 2008
Abstract
Path Computation Elements (PCEs) require an accurate and timely
Traffic Engineering Database (TED). Traditionally this TED has been
obtained from a link state routing protocol supporting traffic
engineering extensions. This document discusses possible alternatives
and enhancements to such an approach and their potential impacts on
network nodes, routing protocols, and PCEs.
Table of Contents
1. Introduction...................................................2
1.1. TED Creation and Maintenance via IGPs.....................3
2. Alternative TED Creation & Maintenance for a PCE...............5
2.1. Architecture Options......................................6
2.1.1. Nodes Send TE Info to all PCEs......................10
2.1.2. Nodes Send TE Info via an Intermediate System.......10
2.1.3. Nodes Send TE Info to Only One PCE..................10
2.2. Nodes Finding PCEs.......................................11
2.3. Node TE Information Update Procedures....................11
2.4. PCE TED Maintenance Procedures...........................12
3. Standardization and Protocol Considerations...................12
3.1. Architecture Specific Standardization Aspects............13
3.2. Protocols and Data Formats...............................14
3.2.1. Data Formats........................................14
3.2.2. Communication Protocols.............................14
4. Security Considerations.......................................15
5. IANA Considerations...........................................15
6. Conclusions...................................................16
7. Acknowledgments...............................................16
APPENDIX A: LDAP and Directory Services..........................16
8. References....................................................18
8.1. Normative References.....................................18
8.2. Informative References...................................18
Author's Addresses...............................................19
Intellectual Property Statement..................................20
Disclaimer of Validity...........................................20
1. Introduction
In Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS),
a traffic engineering database (TED) is used in computing paths for
connection oriented packet services and for circuits. The TED
contains all relevant information that a Path Computation Element
(PCE) needs to perform its computations. It is important that the TED
be complete and accurate at the time of the computation.
Lee Expires March 26, 2009 [Page 2]
Internet-Draft PCE TED Alternatives September 2008
In MPLS and GMPLS, interior gateway routing protocols (IGPs) have
been used to create and maintain a copy of the TED at each node
running the IGP. One of the benefits of the PCE architecture
[RFC4655] is the advantages of computationally more sophisticated
path computation algorithms and the realization that these may need
enhanced processing power not necessarily available at each node
participating in an IGP.
Section 4.3 [RFC4655] describes the potential load of the TED on a
network node and proposes an architecture where the TED is maintained
by the PCE rather than the network nodes. What isn't discussed is how
a PCE would obtain the information needed to populate its TED. In
this document we propose approaches for creating and maintaining the
TED on a PCE and look at the impacts from the PCE, IGP, and node
perspective.
New application areas for GMPLS and PCE include wavelength switched
optical networking (WSON). WSON scenarios can be divided into routing
wavelength assignment (RWA) problems where no consideration is made
of optical impairments, and optical impairment-aware deployments.
Even in the non-impairment case WSON requires detailed information
about switching node asymmetries and wavelength constraints as well
as detailed up to date information on wavelength usage per link
[WSON-Frame]. This is significantly more information to be held in
the TED than is required for other traffic engineering networks.
There is a concern that such additional information could "bog down"
the IGP on the nodes from a data processing, a storage, or
communications perspective. In a network where PCEs are external to
the nodes running the IGP, and where the information in the TED is
not used by the switching nodes it makes sense to investigate
alternative methods to create and maintain the TED at its place of
use, the PCE.
1.1. TED Creation and Maintenance via IGPs
Routing protocols, in particular, IGPs such as OSPF and IS-IS, take
on a number of roles with respect to the control and data planes for
IP, MPLS, and GMPLS. In all three technology families the underlying
control plane communications technology is IP and hence all utilize
the IGPs ability to control and run the IP data plane.
For the IP layer, the IGP directly establishes data plane
connectivity. In the MPLS and GMPLS cases separate signaling
protocols are used to directly control the data plane connectivity
Lee Expires March 26, 2009 [Page 3]
Internet-Draft PCE TED Alternatives September 2008
and in these cases the prime purpose of the routing protocol is to
furnish network topology and resource status information used by path
computation algorithms on the nodes or PCEs. Hence in the IP case the
IGP is directly service impacting, while in the MPLS/GMPLS case it is
only indirectly service impacting.
The IP layer information and the MPLS/GMPLS data plane layer
information may be kept by the IGPs in two different information
stores. These are referred to as databases but are not necessarily
relational databases. In OSPF the information directly related to IP
connectivity (and hence the control communications plane for all
three technologies) is kept in the link state database (LSDB), while
additional information related to traffic engineering used by MPLS
and GMPLS is kept in a (conceptually) separate traffic engineering
database (TED) and distributed in a different data structure (Opaque
LSA [RFC5250]). When we talk about adding additional technology-
specific GMPLS information used for path computation we are only
talking about adding to the TED and not the IP LSDB.
There are three main functions performed by an IGP: (a) hello
protocol, (b) database synchronization (with neighbors), (c) database
updates.
Data Plane | Hello Protocol | Database Sync
Technologies | | & Updates
--------------------------------------------------------------
IP | Establish Control & Data | LSDB
| Plane Adjacencies |
--------------------------------------------------------------
MPLS | Establish Control & Data | LSDB & TED
| Plane Adjacencies |
--------------------------------------------------------------
GMPLS | Establish Control Plane | LSDB & TED
| Adjacencies (only) |
--------------------------------------------------------------
Table 1 Main Functions of an IGP for various technologies
The procedures for maintaining LSDBs and TEDs in IGPs have been very
successful and well proven over time. These consist of:
1. Ageing the individual pieces of information in the TED
(including discarding them when the information gets too old) to
remove stale information from the TED.
2. Originator of the information being required to periodically
resend TED information to prevent it from being discarded.
Lee Expires March 26, 2009 [Page 4]
Internet-Draft PCE TED Alternatives September 2008
3. Originator of the information sending updates of information as
needed, but subject to limits on how many/often these can be
sent to keep the TED up-to-date, but to avoid swamping the
network.
4. Reliable method for getting this information to other peers
(flooding) to ensure that the information is delivered to all
participants.
5. An efficient database synchronization mechanism for sharing info
with a newly established peer.
2. Alternative TED Creation & Maintenance for a PCE
Given that nodes, by their position and role in the network, have
accurate traffic engineering information concerning their local link
ends and switching properties, it seems natural that, if other nodes
in the network cannot make use of this information or do not want it,
the information only be conveyed to interested PCEs. In addition, one
could potentially choose to have some traffic engineering information
distributed via an IGP while other more specialized traffic
information is only conveyed to the PCEs.
The benefits of such an approach include:
o Node: reduced storage demands (doesn't keep the entire TED)
o Node: reduced processing demands for TED updates and
synchronization
o Control Plane: reduced overall communication demands since the TED
is not being updated and maintained on all nodes in the network.
o PCE: More timely TED updates are possible.
To quantify the previous advantages requires a bit more detail on how
such an approach could actually be accomplished. The key pieces
needed to implement such an approach include:
o Multiple PCEs must be supported for robustness and load sharing.
o Nodes must be able to find a PCE to which to send their traffic
engineering information.
Lee Expires March 26, 2009 [Page 5]
Internet-Draft PCE TED Alternatives September 2008
o Nodes must have procedures and a mechanism (protocols) with which
to communicate their TE information to a PCE. PCEs must have
procedures and a mechanism (protocols) with which to receive this
TE information from nodes.
o Efficient mechanisms must exist in the multi-PCE case to ensure
all PCEs have the same TED.
2.1. Architecture Options
There are three general architectural alternatives based on how nodes
get their local TED information to the PCEs: (1) Nodes send local
information to all PCEs; (2) Nodes send local information to an
intermediate server that will send to all PCEs; (3) Nodes send local
information to only one PCE and have the PCEs share this information
with each other. An important functionality that needs to be
addressed in each of these approaches is how a new PCE gets
initialized in a reasonably timely fashion.
Figures 1-3 show examples of three options for nodes to share local
TED information with multiple PCEs. As in the IGP case we assume that
switching nodes know their local properties and state including the
state of all their local links. In these figures the data plane links
are shown with the character "o"; TE information flow from nodes to
PCE by the characters "|", "-", "/", or "\"; and PCE to PCE TE
information, if any, by the character "i".
Lee Expires March 26, 2009 [Page 6]
Internet-Draft PCE TED Alternatives September 2008
---- ----
// \\ // \\
/ \ / \
| PCE \ | PCE |
| |\ / |
| X \ / \ /
|\\ // \ \ / /|\ /X
| --+-\ \ \ /// | -+-- \
| | \\ \ \\ // | | \
| | \\ \ // | | \
| | \\ \ / | | \
| | \ \\ \// | | \
| | \ \\ /\/ | | \
| | \ /X\/\ | | \
| | \ / /\ \ | | \
| | X/ / \\\ | | \
| | / \ / \\ | | \
| | // \ / \\| | \
| | / X \\\ | \
| | // /\ |\\\\| \
| +----+-/-+ / \ |+-\-|----+ \
| | | / \ || | \
| | N1 ooooooooooooooooooo N2 oo \
| | ooooooooooooooooooo ooo \
| | | / \ | | |ooo \
| +---oo---+/ \ | +------\-+ ooo \
| ooo / \ | \ ooo \
| ooo / \ | \ ooo \
| oo / * \ | \ ooo \
| oo / \ | \ ooo \
| ooo / \ | \\ ooo \
| oo / * \ \ ooo \
| ooo / \ \ ooo \
| oo / |\ \ ooo\
++--oo-/-+ |\ * \+---oo-\-+
| | | \ \ |
| oooo | \ oooo Nn |
| N3 ooooooooo +-+---\--+ ooooooooo |
| | ooooooooo | | oooooooooo | |
+--------+ oooooooo N4 oooooooo +--------+
oooo oooo
| |
+--------+
Figure 1 . Nodes send local TE information directly to all PCEs
Lee Expires March 26, 2009 [Page 7]
Internet-Draft PCE TED Alternatives September 2008
---- ---- ----
// \\ // \\ // \\
/ \ / \ / \
| PCE | | PCE | | PCE |
| | | | | |
\ -- \ / \ /
\\ // -- \\ // --\\ //
---- --- /--- ---- ----
-- / ----
--- / ---
-- --/- ----
--/ \\ ----
/ --
| Pub/ |
-+ Sub |
--- X ---
-- / \\ // ----
+--- / -+--\ ----+
+-----+--+ / | \ +--+-----+
| | / | \\ | |
| N1 ooooooooooooooooooooooooo N2 oooo
| ooooooooooooooooooooooooo oooo
| | / | \\ | | oo
+---oo---+ / | \+--------+ oo
oo / | \ oo
oo / | \ oo
oo / | \\ oo
oo / | \ oo
oo / * | \ oo
oo / | \ oo
oo / | \\ oo
oo / *| \ oo
oo / | \ oo
oo / | \\ oo
+---oo-/-+ | * \+---oo---+
| | | \ |
| oooo | oooo Nn |
| N3 oooooooo +---+----+ ooooooooo |
| | oooooo | | ooooooooooo | |
+--------+ oooooooo N4 ooooooooo +--------+
ooooo oooo
| |
+--------+
Figure 2 . Nodes send local TE information to PCEs via an
intermediary (publish/subscribe)server
Lee Expires March 26, 2009 [Page 8]
Internet-Draft PCE TED Alternatives September 2008
iiiiiiiiiiiiiiiiii
iiiiii ---- iii iiiii ----
ii ii// \\i iiiiiiii/ \\
ii / \ / \
i | PCE1 | | PCE2 |
i | | | |ii
i \ / X / ii
i \\ // // \\ // ii
i -//- / --+- i
i // // | i
i +-----/--+ +----/---+ | i
i | | | | | i
i | N1 ooooooooooooooooooooooooo N2 oooo | i
i | ooooooooooooooooooooooooo oooo | i
i | | | | oo | i
i +---oo---+ +--------+ oo | i
i oo oo | i
i oo oo | i
i oo * oo | i
i oo oo | i
i oo oo | i
i oo * oo | i
i oo oo | i
i +---oo---+ * +---oo-+-+ i
i | | | | i
i | oooo oooo Nn | i
i | N3 oooooooo +--------+ ooooooooo | i
ii | | oooooo | | ooooooooooo | | ii
i +---\----+ oooooooo N4 ooooooooo +--------+ i
i \ ooooo oooo i
ii \ | | i
i \\ +--------+ ii
ii \ --- i
ii \ ---- --- i
ii \// \-- i
ii / \ ii
ii | PCE3 | iiii
iiiii| | iiiii
\ / iii
\\ // iiiiiiiii iii
---- iiiiiiiiiiiiiiiiiii
Figure 3 . Nodes send local TE information to only one PCE and have
the PCEs share TED information
Lee Expires March 26, 2009 [Page 9]
Internet-Draft PCE TED Alternatives September 2008
2.1.1. Nodes Send TE Info to all PCEs
Architectural alternative 1 shown in Figure 1, illustrates nodes
sending their local TE information to all PCEs within there domain.
As the number of PCEs grow we have scaling concerns. In particular
each node needs to keep track of which PCE it has sent information to
and update that information periodically.
If a new PCE is added to the domain the node must send all its local
TED information to that PCE rather than just sending status updates.
2.1.2. Nodes Send TE Info via an Intermediate System
Architecture alternative 2 is shown in Figure 2. This architecture
reduces the burden on switching nodes by having the nodes send TE
information to an intermediate system. This general approach is
typically described in the software literature as a publish/subscribe
paradigm. Here the nodes send their local TED information to an
intermediate entity whose job is to insure that all PCEs receive this
information. The nodes in this case being the publishers of the
information and the PCEs the subscribers of the information.
Publish/subscribe functionality can be found in general messaging
oriented middleware such as the Java Messaging Service [JMS] and many
others. A routing specific example of this approach is seen in BGP
route reflectors [RFC4456].
Note that the publish/subscribe entity can be collocated with a PCE.
This would then looks like a master/slave type system architecture.
If a new PCE is added then the intermediate server will need to work
with this new PCE to initialize its TED. Hence the publish/subscribe
entity will need to also keep a copy of the entire TED and for
reliability purposes a redundant server would be required.
2.1.3. Nodes Send TE Info to Only One PCE
In this architectural alternative, shown in Figure 3, each node would
be associated with only one PCE. This implies that each PCE will only
have partial TED information directly from the nodes. It would be
the responsibility of a node to get its local TED information to its
associated PCE, then the PCEs within a domain would then need to
share the partial TED information they learned from their associated
nodes with each other so that they can create and maintain the
complete TED. As we have seen in section 1.1. this is very similar to
part of the functionality provided by a link state protocol, but in
this case the protocol would be used between PCEs so that they can
Lee Expires March 26, 2009 [Page 10]
Internet-Draft PCE TED Alternatives September 2008
share the information they have obtained from their associated
switching nodes (rather than from attached links as in a regular link
state protocol). To allow for this sharing of information PCEs would
need to peer with each other. PCE discovery extensions [RFC4674]
could be used to allow PCEs to find other PCEs. If a new PCE is added
to the domain it would need to peer with at least one other PCE and
then link state protocol procedures for TED synchronization could
then be used to initialize the new PCEs TED.
2.2. Nodes Finding PCEs
In cases 1 and 3 nodes need to send TE information directly to PCEs.
Path Computation Clients (PCCs) and network nodes participating in an
IGP (with or without TE extensions) have a mechanism to discover a
PCE and its capabilities. [RFC4674] outlines the general
requirements for this mechanism and extensions have been defined to
provide information so that PCCs can obtain key details about
available PCEs in OSPF [RFC5088] and in IS-IS [RFC5089].
After finding candidate PCEs, a node would need to see which if any
of the PCEs actually want to receive TE information directly from
this node.
In architectural alternative 2 (publish/subscribe) the location of
intermediate system would either need to be configured or PCE
discovery could be extended so that a when a node asks a PCE if it
wants to hear TE info the PCE points it to the intermediate
publish/subscribe system.
2.3. Node TE Information Update Procedures
First a node must establish an association between itself and a PCE
or intermediate system that will be maintaining a TED. It is the
responsibility of the node to share PCE TE information concerning its
local environment, e.g., links and node properties. General and
technology specific information models would specify the content of
this information while the specific protocols would determine the
format. Note that a node would not be sending to the PCE information
it might be passed from neighbor nodes. Note that data plane neighbor
information would be passed to the PCE embedded in TE link
information.
There will be cases where the node would have to send the PCE only a
subset of TE link information depending on the path computation
option. For instance, if the node is responsible for routing while
the PCE is responsible for wavelength assignment for the route, the
node would only need to send the PCE the WSON link usage information.
Lee Expires March 26, 2009 [Page 11]
Internet-Draft PCE TED Alternatives September 2008
This path computation option is referred to as separate routing (R)
and wavelength assignment (WA) option in [PCE-WSON].
2.4. PCE TED Maintenance Procedures
The PCE is responsible for creating and maintaining the TED that it
will use. One key function is to ensure that the network information
obtained from nodes or elsewhere is relatively timely, or not stale.
By analogy with similar functionality provided by IGPs this can be
done via a process where discrete "chunks" of TED information are
"aged" and discard when expired. This combined with nodes
periodically resending their local TE information leads to a timely
TED.
3. Standardization and Protocol Considerations
In the previous section we examined a number of architectural
alternatives for TED creation and maintenance on a PCE. Here we
examine aspects of these alternatives that could be suitable for
standardization. First there are a number of items and functions that
can be independent of the particular architectural alternatives used,
these include:
o An information model for the TED
o Basic PCE TED creation and maintenance procedures
o Information packaging for use in TED creation, maintenance and
exchange
o NE to PCE (or Pub/Sub) communication of TED information ---
interface and protocol (e.g. PCEP)
o NEs discovering PCE (or Pub/Sub) for TED creation and maintenance
purposes
By the "information model" for the TED we mean the raw information
that a path computation algorithm would work with somewhat
independent of how it might be packaged for TED maintenance and
creation. Initial efforts along these lines have started at CCAMP for
wavelength switched optical networks [WSON-Info].
Given a TED information model if we can agree on basic PCE TED
creation and maintenance procedures we can then come up with a
standardized way to package the information for use in such
procedures. The analogy here is with an IGPs database maintenance
procedures such as aging and the packaging of link state information
Lee Expires March 26, 2009 [Page 12]
Internet-Draft PCE TED Alternatives September 2008
information into LSA (link state advertisements). LSAs form the basic
chunks of an IGP's database. OSPF LSAs include an age field to assist
in the ageing procedure and also has an advertising router field that
aids in redistribution decisions, i.e., flooding. However the
detailed TE information is encoded in LSAs via type length value
(TLV) structures and it is this information that is used in path
computation.
From there we could standardize the interface between a NE and a PCE
for communication of TE information. This interface includes NE and
PCE behaviors as well as a communications protocol.
Finally for the common behaviors we need a way for the NEs to find
the PCEs or an intermediate publish/subscribe system to which they
will send their TE information. As was previously pointed out this
could be based on small enhancements to existing PCE discovery
mechanisms.
3.1. Architecture Specific Standardization Aspects
Case 1: NEs send to all PCEs
This case has commonalities with both cases 2 and 3 and does not
appear to have unique standardization aspects. As pointed out in
section 2.1. we do need to consider when a new PCE comes online.
Case 2: Publish/Subscribe Server
In this case we would need to additionally standardize
1. how a new PCE coming online synchronizes with the
publish/subscribe server
2. how PCEs and publish subscribe server communicate
Case 3: PCE to PCE sharing TE information learned from NEs
Here we would need the following additional mechanisms standardized:
1. The PCE to PCE interface and protocol
2. The method for PCEs to discover PCEs for the purpose of TE
information sharing
3. PCE to PCE association for information sharing, in particular
sharing update information.
Lee Expires March 26, 2009 [Page 13]
Internet-Draft PCE TED Alternatives September 2008
3.2. Protocols and Data Formats
In selecting protocols and data formats to implement any of these
alternative architectures the main deciding factor will most likely
be architectural fit. However another deciding factor may be which
protocols and data formats a NE or PCE would tend to already
implement or understand in order to reduce implementation complexity.
3.2.1. Data Formats
Since NEs use IGPs at a minimum to establish the control plane
communications, they must understand some type of link state
advertisement packaging of topology information (in IS-IS these are
called link state protocol data units). Similarly since most PCEs
currently get their TEDs via IGPs they too would understand LSA based
information packaging.
Both IS-IS [RFC3784] and OSPF [RFC3630] utilize TLVs and sub-TLVs to
encode traffic engineering information. Hence there is strong
motivation to use a TLV format for encoding TE information and some
type of "LSA like" packaging of the TE information from the NEs.
3.2.2. Communication Protocols
For the communication of TE information between NEs and PCEs either
datagram protocols such as UDP or DCCP [RFC4340] could be used as
well as stream protocols such as TCP. The advantages and
disadvantages of such approaches have been extensively discussed in
the literature.
Nodes, however, may already be acting as PCCs and hence may already
know how to speak PCEP [PCEP]. From a scaling point of view a TCP
based protocol such as PCEP could limit the number of nodes that
could communicate TE information to a PCE, however the number of
simultaneous TCP connections can be quite high and networks are
typically partitioned into smaller groupings before such limits are
reached. The multiple PCE options considered in Section 2 will help
PCEP to scale.
The PCE Architecture [RFC4655] allows the Notify Message to flow in
both directions and therefore it could be used for the PCC (node) to
send the TED information to the PCE. Since now multiple PCEs are
involved, the burden for one PCE to keep a session open with NEs is
lessened compared to single PCE solution. If the keeping TCP sessions
Lee Expires March 26, 2009 [Page 14]
Internet-Draft PCE TED Alternatives September 2008
still burden the NE and the PCE, a more sophisticated option could be
to allow "sessionless" PCEP Notify message sent over UDP or DCCP.
The most critical TED information the PCE should be updated with is
the information concerning changes in availability due to LSP
setup/teardown. It is possible for the head-end node (which is likely
a PCC) to provide the RRO in PCEP Notify Message to update the PCE
with the dynamic changes occurred in the network. Note that the RRO
can provide with all of the information about the network resources
used along the path of the LSP.
That would make the information flow as follows:
PCC PCE
--- ---
PC Request -------------.
(Please compute a path)
.---------------_ PC Reply
(Here is a path)
PC Notify -------------->
(This is the path I set up)
4.
5. Security Considerations
This draft discusses an alternative technique for PCEs to build and
maintain a traffic engineering database. In this approach network
nodes would directly send traffic engineering information to a PCE.
It may be desirable to protect such information from disclosure to
unauthorized parties in addition it may be desirable to protect such
communications from interference since they can be critical to the
operation of the network. In particular, this information is the same
or similar to that which would be disseminated via a link state
routing protocol with traffic engineering extensions.
6. IANA Considerations
This version of this document does not introduce any items for IANA
to consider.
Lee Expires March 26, 2009 [Page 15]
Internet-Draft PCE TED Alternatives September 2008
7. Conclusions
This document introduced several alternative architectures for PCEs
to create and maintain a traffic engineering database (TED) via
information directly or indirectly received from network elements and
identified common aspects of these approaches. The TED is a critical
piece of the overall PCE architecture since without it path
computations cannot proceed. Though not explicitly out of scope the
PCE working group does not have a work item or study item devoted to
TED creation and maintenance. Such a work item can lead to enhanced
interoperability and simplicity of PCE implementations. This document
identified several common areas within these alternatives that could
be standardized. In addition, the alternative approaches to TED
creation and maintenance discussed here offloads both the network
nodes and routing protocols from either some or all TED creation and
maintenance duties at the same time it does not add significant new
processing to a PCE that has already been participating in IGP based
TED creation and maintenance.
8. Acknowledgments
We would like to thank Adrian Farrel for his useful comments and
suggestions.
Lee Expires March 26, 2009 [Page 16]
Internet-Draft PCE TED Alternatives September 2008
APPENDIX A: LDAP and Directory Services
Directory services and their accompanying protocols such as LDAP
[RFC4510] are fairly close to the architectural alternative of
section 2.1.2. In this case both the NEs and the PCEs would be
clients of a separate directory services system. The NEs would use
the LDAP protocol [RFC4511] to publish current NE TE information to
the directory server, the PCEs would then query the directory server
for information about NEs and changes to a NE's TE information.
Note that a directory server is not a publish/subscribe system in
that it does not keep track of which subsystems want to be notified
of changes. Due to this the PCEs would need to poll the directory
server periodically with appropriate queries.
Lee Expires March 26, 2009 [Page 17]
Internet-Draft PCE TED Alternatives September 2008
9. References
9.1. Normative References
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September
2003.
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)",
RFC 3784, June 2004.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion
Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", RFC 4510, June
2006.
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4674] Le Roux, J., Ed., "Requirements for Path Computation
Element (PCE) Discovery", RFC 4674, October 2006.
[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
Zhang, "OSPF Protocol Extensions for Path Computation
Element (PCE) Discovery", RFC 5088, January 2008.
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
Zhang, "IS-IS Protocol Extensions for Path Computation
Element (PCE) Discovery", RFC 5089, January 2008.
[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
OSPF Opaque LSA Option", RFC 5250, July 2008.
[PCEP] JP. Vasseur, Ed., JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", draft-ietf-
pce-pcep-15.txt, August 2008.
9.2. Informative References
[JMS] Java Message Service, Version 1.1, April 2002, Sun
Microsystems.
Lee Expires March 26, 2009 [Page 18]
Internet-Draft PCE TED Alternatives September 2008
[PCE-WSON] Y. Lee, G. Bernstein, "PCEP Requirements and Extensions
for the support of Wavelength Switched Optical Networks
(WSON)", work in progress, draft-lee-pce-wson-routing-
wavelength-02.txt, July 2008.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection:
An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456,
April 2006.
[WSON-Frame] G. Bernstein, Y. Lee, W. Imajuku, "Framework for GMPLS
and PCE Control of Wavelength Switched Optical Networks",
work in progress: draft-ietf-ccamp-wavelength-switched-
framework-00.txt, July 2008.
[WSON-Info] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and
Wavelength Assignment Information Model for Wavelength
Switched Optical Networks", work in progress: draft-ietf-
ccamp-rwa-info-00.txt, August 2008.
Author's Addresses
Greg Bernstein
Grotto Networking
Fremont, CA, USA
Phone: (510) 573-2237
Email: gregb@grotto-networking.com
Young Lee
Huawei Technologies
1700 Alma Drive, Suite 100
Plano, TX 75075, USA
Phone: (972) 509-5599 (x2240)
Email: ylee@huawei.com
Lee Expires March 26, 2009 [Page 19]
Internet-Draft PCE TED Alternatives September 2008
Dan Li
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base,
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28973237
Email: danli@huawei.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
Lee Expires March 26, 2009 [Page 20]
Internet-Draft PCE TED Alternatives September 2008
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lee Expires March 26, 2009 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-24 01:56:13 |