Ring Chaining

Glossary

  • UUID - Universally Unique IDentifier 1

Introduction

In short, the Ring Chaining (RiCh) protocol is designed to construct a chain of networks, and to distribute the information about that chain, across all of the constituent networks. The protocol is designed to work in a “chain” topology, most commonly achieved by connecting multiple ring networks into a one-dimensional chain. The chain is constituted by an ordered list of networks (termed rings, see below), where each ring has an orientation.

Overview

RiCh is a distributed protocol running on at least one coupling node in a ring network as well as an extension of RiCo. A coupling node is part of the ring and has a ring coupling that can connect to a coupling node in another ring.

Ring couplings

RiCh rings are built on FRNTv2 rings that are connected using the ring coupling protocol RiCov3. Each end-node runs two RiCo instances that are used to connect to other rings and to distribute connection information within the ring.

Discovery of topology

With RiCh, nodes will discover other nodes present on the network and exchange information. This RiCh signalling in turn allows each node to gather information about:

  • UUID: The identity of present ring(Universally Unique Identifier, or simply UUID)
  • CRC: A checksum calculated over the chain of rings that a node has collected
  • Inauguration state: indicates if all ring information collected have the same CRC value

Redundancy

RiCh (mode active) has to run on at least one node in the ring. Additional RiCh instances (mode active) can be configured to run on other node in the network to work as backup instances. At start up, all active instances will send out topology messages. The node with the numerically smallest IP will be selected as master to continue sending topology messages. The remaining nodes will act as backup nodes. The backup nodes stop sending topology messages but continue to collect the incoming message and build the connectivity table so that they are prepared to quickly takeover as master in case the master node fails.

        .-------.    .-------.
        |       |    |       |
<-dir1--+ RICH1 +----+ RICO1 +--dir2->
        |       |    |       |
        '---+---'    '---+---'
            |            |
        .---+---.    .---+---.
        |       |    |       |
<-dir1--+ RICO2 +----+ RICH2 +--dir2->
        |       |    |       |
        '-------'    '-------'

Figure 1: A ring with four nodes. All nodes are running FRNTv2 and RiCov3. In this example there is a redundant setup of active RiCh running on the nodes RICH1 and RICH2.

Configuration

RiCh can be activated from the top-level configuration context in the CLI.

example:/#> configure
example:/config/#> ring chaining
Activating RiCh with default settings.
example:/config/ring/chaining/#>

Note

RiCh will be enabled by default when entering the configuration context.

For configuration examples, see

Syntax

[no] enable

Enable RiCh.

Note

Simply entering the RiCh config context will enable RiCh when leaving the RiCh context or config context.

no

Disable RiCh. The current configuration is saved, for when you re-enable the service again.

Note

The RiCh configuration can be completely removed from the ring config context using no chaining.

[no] uuid <UUID-STRING>

Set the ring UUID. Each node belonging to the same ring must use the exact same UUID, and no two rings may have the same UUIDs. Thus, the UUID is what defines individual rings.

UUID-STRING
A literal UUID string, in the RFC 4122 format. 
example:/config/ring/chaining/#> uuid 11111111-1111-1111-1111-111111111111
no
Reset UUID to all zeros.
[no] iface <INTERFACE>

Specify the interface on which RiCh should distribute topology messages.

INTERFACE
Name of the interface that RiCh will send messages on.
no
Reset to default (not set).
[no] address <ADDRESS>

Specify the multicast group address on which RiCh should distribute topology messages.

ADDRESS
Multicast group address that RiCh will distribute topology messages on.
no
Reset to default (not set).
[no] trigger <always|master>

Specify under which conditions RiCh should trigger an SNMP trap at coupling/decoupling.

always
The RiCh instance will always generate a SNMP trap at coupling/decoupling.
master
The RiCh instance will generate a SNMP trap at coupling/decoupling if it is acting as master.
no
Reset to default (master).
[no] mode <active|passive>

Specify the mode for running RiCh.

active
Run the full RiCh features with the ability to become the RiCh master node.
passive
Run only the Rico extension for RiCh.
no
Reset to default (active).
[no] dir1 <RICO-ID>

Specify which RiCo instance is connected to direction 1.

RICO-ID
Id of the RiCo instance associated with direction 1.
no
Resets to (not set).
[no] dir2 <RICO-ID>

Specify which RiCo instance is connected to direction 2.

RICO-ID
Id of the RiCo instance associated with direction 2.
no
Resets to (not set).
show
Show a summary of RiCh settings.

Status

To see the current status of RiCh, run the show chaining command in Admin context.

example:/#> show chaining
RICH NODE                                                              
Own UUID     : 11111111-1111-1111-1111-111111111111
Chain state  : Inaugurated
Chain CRC    : 32cca232
Node state   : Master (sending)

UUID                                  ORIENTATION                      
22222222-2222-2222-2222-222222222222  DIFFERENT
11111111-1111-1111-1111-111111111111  DIFFERENT
33333333-3333-3333-3333-333333333333  SAME

example:/#>

  1. See RFC 4122 ↩