Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
...
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.
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.
Our implementation design of XMPP functionality for ONOS controller is depicted below. It is composed of two main parts: the XMPP Providers and Route Server application. The XMPP Providers implement XMPP SBI, while Route Server application realizes BGP-VPN system using data abstractions provided by XMPP Providers.The XMPP Providers translates XMPP objects into three ONOS abstractions: Device, Route and Flow.
XMPP Providers
We have made decision to divide Protocols layer into two components: XMPP Controller and XMPP PubSub Controller. Such a decision is due to the nature of XMPP protocol. XMPP may be extended by new XEPs, so that we provide a possibility to build new extensions in future without modyfing already existing implementation. The implementation of core XMPP is provided by XMPP ControllerThe core part of the implementation architecture is XmppController, which is responsible for:
- Establishing XMPP stream
- Stream errors handling
- Decoding/encoding XMPP Stanzas
- Maintaining the state of connected XMPP devices
The XmppPubSubController Based on core XMPP implementation we have developed XMPP PubSub Controller implementing Publish/Subscribe (XEP-0060) extension. The XMPP PubSub Controller listens to IQ stanzas based on thatand:
- parses XMPP messages into PubSub abstractions. The Subscribe and Unsubscribe XMPP messages are passed directly, while the Publish/Retract XMPP messages are parsed using methods provided by XmppDriver. For BGP-signaled End System IP VPNs use case, XmppDriver translates XML data carried in XMPP body into BgpInfo ONOS Java object.ONOS abstractions.
- handles PubSub errors
- constructs XMPP Event Notification messages and sends them to underlaying XMPP devices
The PubSub Subsystem is newly created ONOS subsystem, which provides Publish/Subscribe abstractions. It provides interface between Providers and Apps layer and is responsible for notifying listeners observing the PubSub Events. The Device Subsystem is the standard ONOS core subsystem storing status of connected devices. The abstractions provides by both PubSub and Device Subsystems may be used by ONOS applicationsXMPP PubSub Controller produces notifications, that can be handled by higher layers. The Providers layer includes the XMPP Device Provider and XMPP EVPN Provider. The XMPP Device Provider listens to notification from XMPP Controller and creates a new Device object, when a XMPP session is established. The XMPP EVPN Provider is implemented based on XMPP PubSub Controller. It listens to XMPP PubSub events (SUBSCRIBE, UNSUBSCRIBE, PUBLISH, RETRACT). These messages are handled by Route Provider, which translates PubSub attributes and payload into BGP EVPN constructs, which are provided by RouteService subsystem. The PubSub messages are handled, so that:
- According to IETF spec 2, SUBSCRIBE and UNSUBSCRIBE messages are translated into BGP RouteTarget configuration. Moreover, when a SUBSCRIBE/UNSUBSCRIBE message is received the XMPP Route Provider associates/deassociates Device to/from VPN instance.
- According to IETF spec 2, PUBLISH/RETRACT messages are translated into BGP Route objects and are stored in distributed RouteStore. Moreover, a BGP Route Update or BGP Route Delete event is generated.
The events generated by RouteService are handled by Route Server application. When new event is handled, the Route Server may install a Flow, which is constructed based on BGP Route object and translated into XMPP Event Notification (Message stanza).
Key implementation pieces of code
...
- Tinder, which provides XMPP abstractions. It is also used in open source XMPP server implementations such as Openfire
- Aalto-XML, which provides asynchronous, non-blocking XML parsing mechanism
- Netty, which provides multi-threaded and efficient TCP Java-based server
Interfaces and classes
XmppController.java interface implemented by XmppControllerImpl.java tracks all connected XMPP devices, provides interface to obtain XMPP device and register/unregister listeners.
XmppDevice.java interface implemented by AbstractXmppDevice.java represents underlaying XMPP devices and allows to perform operations on them. With each XmppDevice.java object there is a Netty channel associated.
XmppDeviceId.java class implements identifier representation based on XMPP JID address.
XmppServer.java and XmppChannelInitializer.java implements Netty TCP server listening on XMPP connection on TCP 5269 port and configures Netty channel pipeline.
XMPP encoding and decoding is implemented by several classes in order to provide efficient XML stream parsing. XmlStreamDecoder.java class reads asynchronously incoming XML data using Aalto-XML library. XmlMerger.java class accumulates incoming XML events from XmlStreamDecoder.java and creates XML document. The XmppDecoder.java class translates XML document into XMPP stanzas. The XmppEncoder.java class translates Tinder objects into bytes ready to send over a network socket.
The XmppChannelHandler.java class implements XMPP protocol state machine.
The XmppPubSubProvider.java implements XMPP Publish/Subscribe mechanism for parsing XMPP PubSub messages and sending XMPP Event Notifications.
The XmppMessageListener.java, XmppIqListener.java and XmppPresenceListener.java interfaces informs providers in the ONOS core about incoming XMPP stanzas. Currently, only the XmppIqListener is implemented by InternalXmppIqListener.java in XmppPubSubProvider, because XMPP Publish/Subscribe does not operate on the other XMPP stanzas.
The XmppDeviceProvider.java manages any XMPP device and its interactions with the ONOS core. It notifies ONOS Device Subsystem about already connected/disconnected devices.
The XmppDeviceListener.java notifies the provider in ONOS core that XMPP device is connected/disconnected.
...