Directionality

Table of Contents

Scope

This page describes the different "directionality" types which can be used in a topology.

The property "directionality" supports different values depending on the object class.

Topology and Edge

The object classes "Topology" and "Edge" share the same definition and values of the property "directionality".

directionality : =

• bidirectional
  
  

  • A bidirectional "Topology" contains unidirectional and/or bidirectional nodes and edges

  • A bidirectional "Edge" service in a telecommunication context can support traffic in both directions.

• unidirectional

  • A unidirectional "Topology" contains  only unidirectional nodes and edge

  • A unidirectional "Edge" service in a telecommunication context supports traffic in one direction only.

Node

Also nodes can be divided into "unidirectional" and "bidirectional" nodes. However, for unidirectional nodes it is important to know whether the nodes is the source or the sink of the related "Edge". 

directionality : =

• bidirectional
  
  

  • A bidirectional "Node" can act as "sink" and/or as "source"

• sink

  • A unidirectional "Node" with directionality "sink" is in context of telecommunication the receiver of a signal. Sometimes also the label "out" is applied. 

• source 

  • A unidirectional "Node" with directionality "sink" is in context of telecommunication the transmitter of a signal. Sometimes also the label "out" is applied. 

Combination of Nodes and Edges with certain directionalities

This chapter discusses the different combinations of Nodes and Edges depending on their directionality.

bidi Nodes and bidi Edge

Add text here ...

bidi Nodes and uni Edges

Add text here ...

uni Nodes and uni Edges

Add text here ... including grouping of nodes...

uni and bidi nodes

Add text here ....

uni Nodes and bidi Edge

Add text here ... possible but inefficient ...

uni Node and contradicting edges

Add text here ... should not be possible ...

Creating a protected unidirectional server for a TV signal

The following example is already an extreme  case. An abstract topology model may not support it by default and needs to add rules for simplification purposes. 

However, such cases should be possible with "small" extensions. 

Explanations

Analog signal protection often comes with the concept of "broadcast and select". The transmitter sends the same signal towards different paths. On the receiver side both could be processed but often just one is selected. In case no signal is detected the receiver switches to the other input signal. (This here is just an example, to explain the potential need of a directionality also per edges. There are several more clever technical solutions at the receiver).

Examples how to represent a protected unidirectional service 

For the TV Broadcast in a ring topology the network capacity is optimized, when protected channel uses the "free" capacity of the "working" direction. 

It is basically the combination of protected add-and-drop cross connections and drop-and-continue cross connections. 

All nodes and edges represented as unidirectional

This representation of the use case looks quite complex - at least for humans. But maybe even machines have limitations in terms of CPU, memory and bandwidth.

The nodes filled with blue are "source" nodes, while the white nodes are "sink".

Open

All nodes are bidirectional but edges are still unidirectional

Due to the unidirectional representation of the edges it is still possible to distinguish between the "Protecting" and the "Working" path.

Open

All bidirectional

This representation of the service has its conflicts, because it is not possible any more to distinguish the "Working" path from the "Protecting" path.

Several feedback loops are created. A path computation element would not have the chance to calculate an efficient path.