Jump to: navigation, search

Topology Processing Framework:Main

Topology Processing Framework Facts

Project Creation Date: December 18th, 2014
Lifecycle State: Incubation
Type: Service
Primary Contact: Andrej Zan <andrej.zan@pantheon.tech>
Project Lead: Andrej Zan <andrej.zan@pantheon.tech>
Committers:

  • Andrej Zan <andrej.zan@pantheon.tech>
  • Carlo Perocchio <carlo.perocchio@ericsson.com>
  • Giorgio Garziano <giorgio.garziano@ericsson.com>
  • Matej Perina <mperina@cisco.com>
  • Martin Dindoffer <martin.dindoffer@pantheon.tech>

Emeritus Committers:

  • Michal Polkorab <michal.polkorab@pantheon.tech>
    IRC: freenode.net #opendaylight

Mailing List: topoprocessing-dev@lists.opendaylight.org
    Archives: mailing list archives
Meetings:
Repository: git clone https://git.opendaylight.org/gerrit/p/topoprocessing
Jenkins: jenkins silo
Gerrit Patches: code patches/reviews
Bugs:

Introduction

Topology Processing Framework Presentation
YouTube video introduction

Links

List of possible correlations

  • Node ID's
    Same node with multiple uncoordinated mgmt-protocol (different plugins for the same node) produces:
    Different nodes in inventory
    nodes with different ids in uncorrelated network topology plane or planes (for example ospf and isis topologies)
    In this cases id’s are different, but in common they can have
    - an attribute (for example te-router-id is unique, an administrative name or label, system-id, mac address, bridge id, part number…)
    - a value in a set (for example router-id can be multiple for a node)
  • Termination-points
    represented in different topology planes that are on the same node-connector in order to identify client server relationship.
  • Customer edge ports
    as termination-point in network-topology
  • Functionality / feature
    e.g. node supporting special actions, matches, features

MLMT Module

The aim of the Multi-Layer and Multi-Technology (MLMT) module in TPF project is to augment the network topology model currently in use inside OpenDaylight architecture in order to represent all technologies and layers managed by the SDN Controller in a single topological plane providing a normalized view.

Developer Guide