Page History

...

Model architecture and abstraction

NOTE! The model architecture and abstraction presented below is the draft version. The new architecture using core ONOS abstractions and Route subsystem is in progress. However, the most important component (XmppController being responsible for XMPP protocol handling) will remain unchanged.The eXtensible Messaging and Presence Protocol (XMPP) is a general-purpose, universal protocol. The main feature of XMPP is its extensibility and payload-agnosticism, what makes XMPP very powerful and high-level protocol that may carry various information such as routing, configuration or monitoring.

The main assumption of XMPP protocol implementation design for ONOS was to provide extensibility of XMPP protocol, as Publish/Subscribe extension is not the only use case for XMPP. The current implementation allows to re-use the core implementation of basic XMPP mechanisms (such as stream establishment or handling of basic XML stanzas) and based on that develop the new XEPs that are needed for particular use case.

Image RemovedImage Added

The XMPP Stanza is composed of header, extension-specific (XEP-specific) part and optionally payload. In order to make our implementation architecture extensible and make possible to add new XMPP extensions seamlessly we made a decision to divide XMPP parsing process into three parts. The basic part is implemented in Protocols layer (XmppController) and handles core XMPP functionalities (such as Stream negotiation). It is also responsible for recognizing XMPP messages and parsing XMPP Stanza headers. The handling of the XEP-specific part is moved to Providers layer. We assume that for the each XEP the new XMPP Provider will be created. We have already created XmppPubSubProvider being responsible for XMPP Publish/Subscribe message handling. Additionally, the XmppDeviceProvider is common for all XEP-specific Providers. The payload of the XMPP messages (if exists) is handled by XmppDriver, which is responsible for translating XML payload into Java abstractions. These objects returned by XmppDriver are passed to the PubSub Subsystem. Then, they are encapsulated in PubSub Event and all PubSub listeners are notified about new incoming PubSub message. Each future XEP implementation should follow this architecture. The payload parsing logic should be moved to Driver subsystem. Moreover, the new subsystem, which will provide XEP-specific abstractions for ONOS applications, should be created for every new XEP.

...

• Establishing XMPP stream
• Stream errors handling
• Decoding/encoding XMPP Stanzas
• Maintaining the state of connected XMPP devices

The XmppPubSubProvider XmppPubSubController listens to IQ stanzas based on that:

...

In order to run a simple demo you have to set tup three VMs. We use VirtualBox to provide three VMs on local laptop. It's preferred to create two separate networks between VMs (we use VBox Host-Only Adapter networks):  management network for control plane operations and data network for connecting emulated compute nodes. The lab architecture is presented below:

Image Modified

Controller node

...

• Download ONOS sources:

  Code Block
  mkdir onos/ cd onos/ git init git pull https://gerrit.onosproject.orggithub.com/osinstom/onos refs/changes/81/16781/1.git git checkout xmpp-bgpvpn

  
  

• Start ONOS:

  Code Block
  export ONOS_ROOT=<your-path-to-onos>/onos tools/build/onos-buck run onos-local -- clean debug

  
  

• Activate XMPP Provider and PoC Application:

  Code Block
  cd tools/test/bin ./onos localhost app activate org.onosproject.protocolsproviders.xmpp.evpn org.onosproject.xmppapps.devicerouteserver

  
  

• You should have XMPP server listening on 5269 TCP port
  

...