[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
  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]