Actions

Difference between revisions of "Network layer"

From Zenitel Wiki

(→‎Message Format)
m (1 revision imported)
 
(32 intermediate revisions by 3 users not shown)
Line 3: Line 3:
 
Note that the header contains an <options> field, which need not be processed but your data receiver must advance the correct number of bytes.
 
Note that the header contains an <options> field, which need not be processed but your data receiver must advance the correct number of bytes.
  
−
= Message Format =
+
= AlphaCom Dataprotocol Networklayer header Format =
 
The network layer message has the following format:  
 
The network layer message has the following format:  
−
  '''<source> <destination> <hop­count­byte> <options> data……>'''  
+
  '''<source> <destination> <hop­count­byte> <[[#Netlayer options|options]]> <[[Application Layer (AlphaCom Data Protocol)|application data....]]>'''  
 
where:
 
where:
  
−
<source> UINT2. 
+
*'''<source>''': [[UINT1]] [[UINT1]]
−
The Device Address for the sender of the message. See below.
+
**The [[Node]] + [[Device]] Address for the sender of the message.
−
<destination> UINT2.  
+
 
−
The Device Address for the receiver of the message. See below.
+
* '''<destination>''': [[UINT1]] [[UINT1]]  
−
<hop­count­byte> UINT1.   <options size> <hop counter>
+
**The [[Node]] + [[Device]] Address for the receiver of the message.
−
<option size>  3 bits  
+
 
−
The number of optional bytes in the following <options> field. External applications can normally set this byte to zero. External applications may receive messages with options from AlphaCom, so the option length field must be handled when parsing messages, but the contents of the <options> can normally be ignored.  
+
*'''<hop­count­byte>''': [[UINT1]]   <options size> <hop counter>
−
For backward compatibility reasons AMC always removes the <options> field when sending on a ISO­1745 link.  The hop-count/options fields are removed all together when sent on port 0 to AlphaPro.
+
** External applications can normally set this byte to zero.
−
(AMC 06.xx does not support the <options> field, and ignores these three bits.)
+
** '''<option size>''' 3 upper bits (mask: 0xE0)
−
<hop counter>  5 bits
+
***The number (0 - 7) of optional bytes in the following <options> field. '''External applications may receive messages with options from AlphaCom, so the option length field must be handled when parsing messages''', but the contents of the <options> can normally be ignored.
−
A hop counter, counting the number of links that the message has traveled. The hop count (initially 0) is used for graceful handling of data routing configuration errors, by increasing it for every hop and discarding looping messages after 31 hops.  
+
*** For backward compatibility reasons AMC always removes the <options> field when sending on a ISO­1745 link.  The hop-count/options fields are removed all together when sent on port 0 to AlphaPro.
−
<options> The number of bytes is given by <hop­count­byte>.  
+
*** (AMC 06.xx does not support the <options> field, and ignores these three bits.)
−
Currently only one option is defined: A UINT1 which is a message sequence number. The sequence number is chosen by the sender, and must follow the message to the destination. The sequence number is used in order to handle broadcast messages between exchanges in AlphaNet. Sequence number set to zero means “no sequence number”.  
+
** '''<hop counter>''' 5 lower bits (mask: 0x1F)
−
+
***A hop counter, counting the number of links that the message has traveled. The hop count (initially 0) is used for graceful handling of data routing configuration errors, by increasing it for every hop and discarding looping messages after 31 hops.  
−
is described in a later chapter.
+
* '''<options>''' The number of bytes is given by <hop­count­byte>. 0-7 bytes. [[#Netlayer options|See below]].
 +
 
 +
* '''<[[Application Layer (AlphaCom Data Protocol)|application data]]>'''
 +
 
The maximum size of a network layer message handled by AlphaCom is 64 bytes.
 
The maximum size of a network layer message handled by AlphaCom is 64 bytes.
  
−
= Handling of Broadcast messages =
+
==Netlayer options ==
 +
The netlayer options are only used for inter-exchange routing, and can be ignored by external devices. If present, netlayer options start at byte 5 (counting from 0) of the binary message.
 +
 +
Two optional bytes are defined:
 +
 
 +
First UINT1 is a message sequence number. The sequence number is chosen by the sender, and must follow the message to the destination. The sequence number is used in order to handle broadcast messages between exchanges in AlphaNet. Sequence number set to zero means “no sequence number”.
 +
 
 +
Second UINT1 (if present) is used as options flags:
 +
 
 +
{| border="1"
 +
!| Flagvalue
 +
!| Description
 +
|-
 +
| 0x01 || Message is Node broadcast message expanded to unicast
 +
|-
 +
| 0x02 || Force old-style node broadcast flooding, do not expand to multiple unicasts
 +
|-
 +
| 0x10 || Message is backtracking towards source from failed transit
 +
|-
 +
| 0x20 || Message has been rerouted to an alternative route at least once, diagnostics only
 +
|-
 +
|}
  
−
== Sequence numbers ==
+
= Handling of Node Broadcast messages =
 +
Node broadcast (destination node = 255) is handled in two different ways.
 +
* Before AMC 10.55 node broadcasts was done with "Flooding". A node node receiving a broadcast message, forwards the message to all links to neighbor nodes (except to the incomming link). The neighbor nodes in turn does the same. Looping messages was dropped by the sequence number check described below.
 +
* From AMC 10.55 AlphaCom multiplies a node-broadcast message by sending one unicast message addressed to every known node. (This change was done because with AlphaNet-over-IP, it is very common to routing-wise connect every node directly to every other node in the AlphaNet, making the flooding algorithm very inefficient.)
 +
** From AMC 10.61.1.5 such expanded messages are tagged with the "Message is Node broadcast message expanded to unicast " optional flag.
 +
** From AMC 10.61.1.5 it is possible to force Flooded Broadcast by setting "Force old-style node broadcast flooding" optional flag.
 +
 
 +
 
 +
 
 +
== Sequence numbers used for "Flooding Broadcast" ==
 
When the AlphaCom message router receives a message addressed to a broadcast address, and the message does not have a sequence number, the router adds a non­zero sequence number to the message.  Then the sequence number and the source address are stored in a message reference ring buffer with 20 elements, and the message is forwarded to all neighbour nodes.  
 
When the AlphaCom message router receives a message addressed to a broadcast address, and the message does not have a sequence number, the router adds a non­zero sequence number to the message.  Then the sequence number and the source address are stored in a message reference ring buffer with 20 elements, and the message is forwarded to all neighbour nodes.  
  
 
When the AlphaCom message router receives a message addressed to a broadcast address, and the message does have a sequence number, the router searches the ring buffer in order find if the message is already forwarded. If the message reference is found, the message is discarded. Otherwise, the sequence number and the source address are stored in the ring buffer, and the message is forwarded to all neighbor nodes.
 
When the AlphaCom message router receives a message addressed to a broadcast address, and the message does have a sequence number, the router searches the ring buffer in order find if the message is already forwarded. If the message reference is found, the message is discarded. Otherwise, the sequence number and the source address are stored in the ring buffer, and the message is forwarded to all neighbor nodes.
  
−
== Alternative Routing Effect ==
+
 
−
The AlphaCom does not support alternative routing of signalling in cases where the configured routes are broken.  Note that Broadcast messages are delivered through all possible links in a network, so a message will be delivered via an alternative route if the network has several connections throughout.  The DP messages will then be received and processed by all transit nodes, but only the node that recognizes the A subscriber will act on it.
+
[[Category:Protocols]]
−
 
+
[[Category:AlphaNet]]
−
This effect should be used with some caution, though.  If the audio link is broken at the same time, the human operator must set up alternative audio paths manually by using area codes.  But as a backup procedure where the alternative is no communication at all, the customer may accept it!
 

Latest revision as of 13:46, 5 February 2018

The network layer is responsible for message transport from a source device to a destination device, possibly via one or more transit nodes. It will also monitor broadcasts and discard messages that have been forwarded too many times (possibly going in loop). The network layer’s message header must always be included independent of which data link layer is used. Note that the header contains an <options> field, which need not be processed but your data receiver must advance the correct number of bytes.

AlphaCom Dataprotocol Networklayer header Format

The network layer message has the following format: 

<source> <destination> <hop­count­byte> <options> <application data....>

where:

  • <hop­count­byte>: UINT1 <options size> <hop counter>
    • External applications can normally set this byte to zero.
    • <option size> 3 upper bits (mask: 0xE0)
      • The number (0 - 7) of optional bytes in the following <options> field. External applications may receive messages with options from AlphaCom, so the option length field must be handled when parsing messages, but the contents of the <options> can normally be ignored.
      • For backward compatibility reasons AMC always removes the <options> field when sending on a ISO­1745 link. The hop-count/options fields are removed all together when sent on port 0 to AlphaPro.
      • (AMC 06.xx does not support the <options> field, and ignores these three bits.)
    • <hop counter> 5 lower bits (mask: 0x1F)
      • A hop counter, counting the number of links that the message has traveled. The hop count (initially 0) is used for graceful handling of data routing configuration errors, by increasing it for every hop and discarding looping messages after 31 hops.
  • <options> The number of bytes is given by <hop­count­byte>. 0-7 bytes. See below.

The maximum size of a network layer message handled by AlphaCom is 64 bytes.

Netlayer options

The netlayer options are only used for inter-exchange routing, and can be ignored by external devices. If present, netlayer options start at byte 5 (counting from 0) of the binary message.

Two optional bytes are defined:

First UINT1 is a message sequence number. The sequence number is chosen by the sender, and must follow the message to the destination. The sequence number is used in order to handle broadcast messages between exchanges in AlphaNet. Sequence number set to zero means “no sequence number”.

Second UINT1 (if present) is used as options flags:

Flagvalue Description
0x01 Message is Node broadcast message expanded to unicast
0x02 Force old-style node broadcast flooding, do not expand to multiple unicasts
0x10 Message is backtracking towards source from failed transit
0x20 Message has been rerouted to an alternative route at least once, diagnostics only

Handling of Node Broadcast messages

Node broadcast (destination node = 255) is handled in two different ways.

  • Before AMC 10.55 node broadcasts was done with "Flooding". A node node receiving a broadcast message, forwards the message to all links to neighbor nodes (except to the incomming link). The neighbor nodes in turn does the same. Looping messages was dropped by the sequence number check described below.
  • From AMC 10.55 AlphaCom multiplies a node-broadcast message by sending one unicast message addressed to every known node. (This change was done because with AlphaNet-over-IP, it is very common to routing-wise connect every node directly to every other node in the AlphaNet, making the flooding algorithm very inefficient.)
    • From AMC 10.61.1.5 such expanded messages are tagged with the "Message is Node broadcast message expanded to unicast " optional flag.
    • From AMC 10.61.1.5 it is possible to force Flooded Broadcast by setting "Force old-style node broadcast flooding" optional flag.


Sequence numbers used for "Flooding Broadcast"

When the AlphaCom message router receives a message addressed to a broadcast address, and the message does not have a sequence number, the router adds a non­zero sequence number to the message. Then the sequence number and the source address are stored in a message reference ring buffer with 20 elements, and the message is forwarded to all neighbour nodes.

When the AlphaCom message router receives a message addressed to a broadcast address, and the message does have a sequence number, the router searches the ring buffer in order find if the message is already forwarded. If the message reference is found, the message is discarded. Otherwise, the sequence number and the source address are stored in the ring buffer, and the message is forwarded to all neighbor nodes.

Retrieved from "https://wiki.zenitel.com/w/index.php?title=Network_layer&oldid=2461"