Internet DRAFT - draft-grampin-pce-mgmnt-if
draft-grampin-pce-mgmnt-if
PCE Working Group
Internet Draft Eduardo Grampin
Document: draft-grampin-pce-mgmnt-if-00.txt UdelaR
Expires: January 2006 July 2005
PCE Management Interface
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.
Abstract
The Path Computation Element (PCE) Architecture provide a framework
to support the Constraint-Based Routing (CBR) functionality for
traffic engineering systems in Multiprotocol Label Switching (MPLS)
and Generalized Multiprotocol Label Switching (GMPLS) networks.
The model define the PCC and PCE entities at the Control Plane, which
communicate using a Request/Reply protocol.
The PCE architecture enable network operators a tight control of the
resource assignment by means of the administrative constraints that
are included in the Traffic Enginnering Database (TED), and used in
the path computation process. Moreover, appropriate objective
funtions assist operators in the fulfillment of the overall network
objectives.
This document present a system architecture for the PCE, namely
Routing and Management Agent (RMA), with a standard management
interface, which permit established management frameworks to rely on
Grampin Expires - January 2006 [Page 1]
PCE Management Interface July 2005
the PCE for the CBR functionality and inject network-wide policies
into the PCE path computation process. Some reliability issues of the
PCE Architecture are addressed in the document.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [i].
Table of Contents
1. Introduction................................................2
2. RMA Functional Components....................................3
2.1 Signalling Interface....................................4
2.2 IGP Interface...........................................4
2.3 CBR Computation Component................................4
2.4 Traffic Engineering DataBase Component...................4
2.5 Management Plane Interface...............................4
3. Two Tier RMA Architecture....................................5
3.1 RMA availability and fault-tolerance.....................5
3.2 Traffic Engineering Database (TE-DB).....................6
3.3 The CBR process.........................................7
4. Autodiscovery of RMAs.......................................7
5. Security Considerations.....................................7
6. Acknowledgments.............................................7
7. References..................................................7
8. Author's Addresses..........................................8
9. Full Copyright Statement....................................8
1. Introduction
The Routing and Management Agent (RMA), interacts with both the
Control Plane and the Management Plane, assuming the PCE role in the
PCE Architecture [PCE-ARCH], as shown in Figure 1.
This entity, while enabling a Control Plane-based provisioning, can
be used as a traffic engineering tool by management applications,
using its interface towards the Management Plane. This interface can
be used to establish cooperative relationship with other RMAs in the
"multi-PCE path computation with PCE-intercommunication model" , as
specified in [PCE-ARCH].
The RMA management interface is reachable in the management DCN,
therefore integrating the RMA into a distributed management
framework.
Grampin Expires - January 2006 [Page 2]
PCE Management Interface July 2005
+------------------------+
| Management Framework |
+------------------------+
|
Management Interface
|
|
+------------------------------+
| Routing and Management Agent |
+------------------------------+
|
Control Plane Interface
|
|
+------------------+
| Network Elements |
+------------------+
Figure 1. Routing and Management Agent (RMA)
2. RMA Functional Components
The RMA is built asuming a component-based framework, with basic
scheduling and other supporting modules needed to build the described
functionality. The interfaces and "core" components shown in Figure 2
are described below:
+-------------------------------------------+
| +----------------------+ |
| | Management Interface | |
| +----------------------+ |
| +-----------+ +--------------------+ |
| |CBR | |Traffic Engineering | |
| |Component | |Data Base | |
| +-----------+ +--------------------+ |
| +-----------+ +--------------------+ |
| |Signalling | |IGP +---+ | |
| |Interface | |Interface |TDB| | |
| | | | +---+ | |
| +-----------+ +--------------------+ |
+-------------------------------------------+
Figure 2. RMA Functional Components
Grampin Expires - January 2006 [Page 3]
PCE Management Interface July 2005
2.1 Signalling Interface
This component interfaces with PCCs via a suitable Request/Reply
protocol, as required by [PCE-COMM-REQ], and is out of the scope of
this document.
2.2 IGP Interface
The RMA gathers network topology running an instance of the network
TE IGP (OSPF-TE [RFC3630] or ISIS-TE [RFC3784]), communicating
through this interface. The RMA is like any node in the routing
graph, usually without forwarding capabilities, even though the PCE
functionality is orthogonal to packet forwarding, as defined in [PCE-
ARCH]. The goal of this component is to maintain the Topology
DataBase (TDB), which in turn is used to feed the Traffic Engineering
DataBase (TE-DB), the basic information source for CBR computation.
2.3 CBR Computation Component
This is the core of the RMA, which provides the intended
functionality: a computation engine for Constraint-Based Routing. The
component implements the needed algorithms to solve the Path
Computation problem with multiple restrictions. Well-known algorithms
and heuristics can be used to accomplish the intended goal, making
sure that route computation time is limited (i.e. by the usage of
polynomial-time CBR algorithms).
The two tier architecture with a computation cluster is presented in
Section 3 is able to fulfill this objective.
2.4 Traffic Engineering DataBase Component
The TE-DB contains the up-to-date information regarding link states
in the network, gathered by the IGP Interface. Additional
information, like constraints and administrative policies can also be
made persistent in the TE-DB. This information, which defines the TE
objectives of the network, will typically come from Policy-Based
Management applications.
2.5 Management Plane Interface
This component implements the interaction with management
applications, which enables the RMA to be used as a traffic
engineering component for high-level applications. Other
possibilities of this interface include the usage of the RMA as a
network-wide monitoring agent.
Grampin Expires - January 2006 [Page 4]
PCE Management Interface July 2005
This interface may be based in well-known distributed component
frameworks like CORBA, widely used by telecommunication operators,
and/or J2EE, .NET or other usual packages in use in the enterprise
and Internet environments.
The information model used in this interfaces, as well as object
access granularity issues (coarse or fine grain) are out of the scope
of this document, and may be further standardized.
3. Two Tier RMA Architecture
The RMA is designed as a component-based system, as detailed in the
previous section. As described in other documents of the PCE WG,
several issues arise regarding the design and implementation of a PCE
Architecture; in particular availability and fault tolerance are of
major impact in network operation. This section review some of these
problems and propose some implementation guidelines.
3.1 RMA availability and fault-tolerance
A PCE centralized solution may suffer potential bottleneck problems
and is a single point of failure is not careful designed.
A Two Tier Architecture comprises a reliable communication front-end
with a computation back-end cluster, where the well-known High
Performance Computing paradigm may be of use. This architecture is
shown in Figure 3. This is a proven architecture used by Service and
Content Providers for high-availability services such as web-server
farms, VoD headends, E-Mail distributed servers. In the figure there
are two front-end sets, one to handle Control Plane communication,
and the other for the Management Plane. This separation, while not
mandatory, is advisable given that very different kind of protocols
need to be supported.
High availavility is given by two factors:
a) arbitrary large set of front-end (i.e. signaling) processors and,
b) arbitrary large set of computation nodes in the back-end cluster.
The remaining point of failure is network connectivity (both internal
and external). Internal connectivity (i.e. between front and back-
ends) can be protected by redundant LAN switches, while different
options exist to overcome potential external connectivity failure. A
straightforward (and expensive) solution is to place disjoint RMA
clusters in the network, while an acceptable solution would be to
have a multi-homed approach, i.e. use multiple load-sharing links.
Other useful techniques include VRRP [RFC3768] and DNS Round-Robin,
among others.
Grampin Expires - January 2006 [Page 5]
PCE Management Interface July 2005
+----------------------+
| Management Framework |
+---------|------------+
+------------+--------------------------------------------+
| | |
| +---------+---------+ +----------------------+ |
| | Management Plane | | Computation Cluster | |
| | Comm. Front-End | | | |
| +-------------------+ +----------------------+ |
| | Internal bus | |
| ''''''''''''''''''''''''''''''''''|''''''''''''''''''' |
| +-----------------+ |
| | Control Plane | |
| | Comm. Front-End | |
| +-------+---------+ |
+------------------------------------+--------------------+
|
+--------+-----------+
| Netwkork Elements |
+--------------------+
Figure 3 - Two Tier RMA Architecture
3.2 Traffic Engineering Database (TE-DB)
The construction of the TE-DB involves two asynchronous process:
a) update of Topology Database (TDB) by the IGP
b) policy and administrative information insertion from management
applications.
The topology database (TDB) suffer intrinsic innacuracies, due to the
update mechanisms of the IGPs and the hierarchical routing approach
with information summarization. Some form of inaccuracy reduction
shall be implemented to reduced the gap between the gathered TDB and
the actual network state. This, consequently, will reduce the
blocking probability and the need for cranckback procedures in
provisioning time.
Policy and administrative information is inserted in the TE-DB by
management processes. Policy-Based Network Management enable network
administrators to manage network behaviour using high-level
definitions, or policies, which shall be expressed unambiguously.
These policies, associated with an abstract model of the managed
objects and accurate network status information permit to trigger or
refrain certain actions on network elements, resulting in an
enforcement of the high level policies. The policy language and
information model is out of the scope of this proposal.
Grampin Expires - January 2006 [Page 6]
PCE Management Interface July 2005
Typical administrative information comprises link resource class
(colour), SRLGs, etc, while a simple routing policy is to deny the
establishment of LSPs with bandwith grater than a certain value, to
tune the load sharing of traffic demands and minimize blocking
probability.
3.3 The CBR process
There are a number of heuristics and a few exact algorithms to solve
the CBR process in near real time. The implementation shall evaluate
the applicable approaches to the RMA, taking into account the
objective functions, the system of demands, network and
administrative constraints that need to be satisfied.
4. Autodiscovery of RMAs
Autodiscovery requirements are defined in [PCE-DISC-REQ]. The RMA
architecture could implement a very basic static strategy, relying on
LSRs' local configuration; since the RMA architecture is redundant
and fault-tolerant, this may be considered a minor drawback.
5. Security Considerations
A potential security issue is raised by the fact that the proposed
architecture has connections to the network elements via the Control
Plane interface, and to the management applications via the
Management Plane interface. Specially crafted packets in the Control
Plane could eventually be used to gain access to the RMA with
potential incidence in network management applications. This is for
further study.
6. Acknowledgments
The author would like to express his warmest thanks to Joan Serrat,
Javier Baliosian, and the networking team at UdelaR for their
support, review and valuable suggestions.
7. References
i Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
Grampin Expires - January 2006 [Page 7]
PCE Management Interface July 2005
[PCE-ARCH] Farrel, A., Vasseur, JP, Ash, J., "Path Computation
Element (PCE) Architecture", work in progress.
[PCE-COMM-REQ] Ash, J., Le Roux JL, "Path Communication Protocol
Generic Requirements", work in progress.
[RFC3630] Katz D., Kompella K., Yeung D., "Traffic Engineering (TE)
Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3784] Smit H., Li T., "Intermediate System to Intermediate System
(IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June
2004.
[RFC3768] Hinden R. et al., "Virtual Router Redundancy Protocol
(VRRP)", RFC 3768, April 2004.
[PCE-DISC-REQ] Le Roux, JL, et. al., "Requirements for Path
Computation Element (PCE) Discovery," work in progress.
8. Author's Addresses
Eduardo Grampin
Universidad de la Republica - UdelaR
J.H. Reissig 565
11300 Montevideo - Uruguay
Email: grampin@fing.edu.uy
9. Full Copyright Statement
Copyright (C) The Internet Society (2005).
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.
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 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.
Grampin Expires - January 2006 [Page 8]
