Zodiac FX review

What is Zodiac FX

Zodiac FX is an OpenFlow enabled switch, developed by Northbound Networks. They promote it on their kickstarter project as:

The OpenFlow switch that is powerful enough to develop world changing SDN applications yet small enough to sit on your desk.

I've played with Openflow during Nick Feamster's course Software Defined Networking and I've decided that owning such device is a good opportunity to run Openflow controllers in a real network. I can't say how powerful the switch is, because all I have done up to now is to get it out of the box and start it up, but it is definitely small! Its dimensions are 10 x 8 cm, so expect something as big as Raspberry Pi, for example.

Read more…

SCTP Multi-homing in Linux

Introduction

After exploring how SCTP multi-homing works, it's time to see how to use this feature in Linux. This post will show how to implement multi-homing for the client-server application, used up to now. Baseline code for the development will be the 'one-to-many_advanced' branch, used in SCTP specific socket functions in Linux post. It already uses SCTP's advanced interface so only a few modifications are required to get the job done.

Implementing multi-homing means that the server should bind to more than one IP address and the client - to connect to more than one destination IP address. Both applications can also operate on single IP address. Mixed scenario is also possible, e.g. multi-homed server can communicate with non multi-homed client.

The code in this post uses one-to-many styles sockets, however the approach is the same for one-to-one sockets. I am pretty sure that you will be able to handle the latter case by yourself, so I will not discuss it. Anyway do not hesitate to leave a comment, in case you have got any questions.

Read more…

Multi-homing in SCTP

What is multihoming

In the previous posts about the SCTP protocol, I promised a separate article about multi-homing. I think we have covered most of the basic topics and now it is time to review this killer feature. The behaviour of a multi-homed SCTP node is scattered around RFC 4960 and in this post I will present the most important aspects.

I think Section 6.4 has got the best definition for multi-homing:

An SCTP endpoint is considered multi-homed if there are more than one transport address that can be used as a destination address to reach that endpoint.

Read more…

SCTP specific socket functions in Linux

Preface

In the previous posts we have used socket related functions common for protocols other than SCTP. For example with connect() you can connect to a remote peer with either TCP or SCTP socket. recvmsg() and sendmsg() can also be used with UDP and SCTP. This is normal, because SCTP has features similar to TCP (connection oriented) and UDP (message based). However SCTP's unique features deserve specific API. In this post we will review some SCTP only functions for sending and receiving messages, establishing associations and extracting local and peer IP addresses from the association.

Read more…

SCTP notifications in Linux

Introduction

In the previous post we have discussed the ancillary data - one of the ways to access SCTP specific protocol parameters and events. Today we will review another similar topic - the SCTP notifications. They are also received with recvmsg(), but you receive different kind of information. Ancillary data allowed us to get some SCTP specific parameters for the DATA chunk containing the payload, like stream number, association id, etc. With notifications you can access more general information about the association - e.g. receive event when it is established, when it is teared down, remote errors, etc.

SCTP notifications are described in Section 6 of RFC 6458. The implementation of Linux has got some really small differences from the specification, but they are in terms of structure/parameter names. I will try to list them, but even if I forget something you will easily notice them by yourself.

Read more…

Working with SCTP ancillary data in FreeBSD

Introduction

The socket interface provides good generalized interface for the underlying networking protocol, which is exactly what one programmer needs in most of the time. However for some more specific use cases someone might want to exploit specific protocol features, which can't present in the generalized interface. Ancillary data allows the socket interface to handle such specific protocol parameters/features, otherwise unaccessible from the socket API. Today we will add some ancillary data support to the one-to-many style application from the previous post.

Before digging right into the ancillary data I believe I owe you an explanation. My initial intention was to demonstrate the SCTP interface in Linux and as you have probably noticed, up to now I wrote only for Linux. However it turned out that not all ancillary data control messages are supported out of the box in the Linux distribution I currently use (Ubuntu 14.04.2 LTS with kernel version 3.16.0-36). Because the SCTP stack in Linux was ported from FreeBSD I decided to see what is supported there. Luckily all control messages described in Section 5.3 from RFC 6458 were supported in FreeBSD. That's why for this post I will use this operating system.

If you need to use some SCTP specific features in your Linux powered project I suggest you to use sctp_sendmsg, sctp_connectx, etc.

Read more…

SCTP Linux API: One-to-many style interface

Introduction

In the previous post we saw one very simple example of SCTP client-server application with the one-to-one style API. Here I will reimplement it with the one-to-many interface and we will see different approach to the same application. Again all the code used in this post is available for you on this GitHub project. Switch to 'one-to-many_basic' branch before you continue. This and the following posts will heavily use information from RFC 6458 Sockets API Extensions for the Stream Control Transmission Protocol (SCTP). As usual I will provide links to the relative sections for your convenience. If you are serious about using Linux's SCTP socket API I highly recommend you to read the entire specification. You will find tons of interesting information there.

Read more…

Introduction to the SCTP socket API in Linux

Sockets introduction

In Linux, you deal with the network stack via sockets. I assume you are familiar how they work and you have got some basic network programming knowledge in C. What I mean is that you know what functions like socket(), bind(), listen() do, how you should call them and how to implement a simple client-server application. For the purposes of this and the following posts I have created a project in GitHub. You will find there all the code mentioned here. Please check the one-to-one_basic branch now and make sure you understand the code there. It is nothing fancy - client and server application exchanging few messages over SCTP. Anyway if you need a refreshment or you are new to Linux socket programing check some other tutorial on this topic. There are a lot of good ones out there so just pick one you like. My personal best is Beej's Guide to Network Programming.

Disclaimer about the code

Please note that the code is not at all intended to be used on production systems. It is created as a demonstration for the interfaces that I shall write about. It has got some basic checks, but it is far from production ready. If you plan to use it in your project please take some time and add proper error handling. You have been warned.

Read more…

SCTP failure detection and association teardown

Overview

In the previous post we reviewed how the essence of the SCTP protocol works - the user data transfer. Now it's time to see some failure detection procedures and finally how an SCTP association is closed. Both topics will be discussed in this post. Error detection procedures are specified in Section 8, titled 'Fault management', but in this post I will mainly discuss heartbeating. The other failure detection mechanisms will be described in brief, so if you wish to know more about the specific mechanism - read the corresponding Section of the specification (hyperlinks are provided in each section). Association teardown is specified in Section 9 - 'Termination of association'.

Read more…

SCTP Data Transfer

Overview

Up to now I have reviewed message encoding and association initialisation. Now it's time to see how SCTP does some real work - user data transfer. It is implemented via DATA and SACK chunks. Two peers can exchange user data only when the association is established, which means it should be in ESTABLISHED, SHUTDOWN-PENDING or SHUTDOWN_SENT state. SCTP receiver must be able to receive at least 1500 bytes in a single packet, which means its initial a_rwnd value (in the INIT or INIT ACK chunk) must not be set to a lower value. Similar to TCP, SCTP supports fragmentation of user data, when it exceed the MTU of the link. The receiver of the segmented data will reassemble all chunks, before passing it to the user. On the other side, more than one DATA chunk can be bundled in a single message. Data fragmentation will be discussed in more details later.

Read more…