Ministry of Defence

Defence Standard 00-82 Part 0

Issue 1 Publication Date 19th November 2010

Vetronics Infrastructure
for Video Over Ethernet
- Guidance

DEF STAN 00-82 Part 0 Issue 1

Contents
Foreword ................................................................................................................................................... iv
0

Introduction................................................................................................................................... v

0.1

Purpose ...........................................................................................................................................v

0.2

Document Structure.........................................................................................................................v

Scope ............................................................................................................................................. 1

Warning ......................................................................................................................................... 1

Normative References.................................................................................................................. 1

Terms, Definitions and Abbreviations........................................................................................ 3

4.1

Terms and Definitions..................................................................................................................... 3

4.2

Abbreviations .................................................................................................................................. 4

Video Distribution Architecture .................................................................................................. 6

5.1

Introduction ..................................................................................................................................... 6

5.2

Background..................................................................................................................................... 6

5.3

Objective......................................................................................................................................... 6

5.4

Conceptual Architecture ................................................................................................................. 7

5.5

Vetronics Video Architecture .......................................................................................................... 8

Protocol Guidance...................................................................................................................... 10

6.1

Overview....................................................................................................................................... 10

6.2

Physical Layer and Data Link Layer ............................................................................................. 10

6.3

Internet Layer................................................................................................................................ 12

6.4

Transport Layer ............................................................................................................................ 15

6.5

Application Layer .......................................................................................................................... 15

6.6

Video Encoding............................................................................................................................. 21

6.7

Video Compression ...................................................................................................................... 22

6.8

Data Transfer Protocols................................................................................................................ 23

System level guidance ............................................................................................................... 24

7.1

Network Switch Features.............................................................................................................. 24

7.2

Automatic Device Discovery......................................................................................................... 25

7.3

Traffic Shaping.............................................................................................................................. 26

Page ii

DEF STAN 00-82 Part 0 Issue 1

List of Figures
Figure 1 - Conceptual Video Distribution Architecture ................................................................................ 7
Figure 2 - Example Vetronics System Video Network Architecture ............................................................ 8
Figure 3 - Specified Protocols Mapped to the TCP/IP Model.................................................................... 10
Figure 4 - SNMP Control Architecture....................................................................................................... 18
Figure 5 - MIB Structure ............................................................................................................................ 20

List of Tables
Table 1 - Typical Data Rate Requirements ............................................................................................... 11

Page iii

DEF STAN 00-82 Part 0 Issue 1

Foreword
AMENDMENT RECORD
Amd No

Date

Text Affected

Signature and Date

REVISION NOTE
This standard is raised to Issue 1 to update its content.
HISTORICAL RECORD
This standard supersedes the following:
Defence Standard 00-82 Issue 1 Interim
a) This standard provides guidance on the distribution of digital video via an Ethernet based network.
b) This standard has been produced on behalf of the Defence Material Standardization Committee
(DMSC) by QinetiQ on behalf of Cap GM-Sc1 EP (Capability Ground Manoeuvre).
c) This standard has been agreed by the authorities concerned with its use and is intended to be used
whenever relevant in all future designs, contracts, orders etc. and whenever practicable by
amendment to those already in existence. If any difficulty arises which prevents application of the
Defence Standard, the Directorate of Standardization (DStan) shall be informed so that a remedy
may be sought.
d) Any enquiries regarding this standard in relation to an invitation to tender or a contract in which it is
incorporated are to be addressed to the responsible technical or supervising authority named in the
invitation to tender or contract.
e) Compliance with this Defence Standard shall not in itself relieve any person from any legal
obligations imposed upon them.
f)

This standard has been devised solely for the use of the Ministry of Defence (MOD) and its
contractors in the execution of contracts for the MOD. To the extent permitted by law, the MOD
hereby excludes all liability whatsoever and howsoever arising (including, but without limitation,
liability resulting from negligence) for any loss or damage however caused when the standard is
used for any other purpose.

Page iv

DEF STAN 00-82 Part 0 Issue 1

Introduction

0.1

Purpose

The Vetronics Infrastructure for Video Over Ethernet (VIVOE) standard describes the mechanisms and
protocols that shall be employed to implement the distribution of digital video over an Ethernet
infrastructure. This standard also facilitates, as an option, the distribution of other data on the same
network.
The standard includes the provision for multiple service providers (individual video and data sources) to
access the network infrastructure and for multiple service users (displays and data processors) to receive
the information from the network infrastructure. The distribution of video or data from one service
provider to one or many service users is supported.
The fundamental transport protocol used is Real-time Transport Protocol (RTP), which allows numerous
defined video payload formats, including both uncompressed and compressed video formats. The
standard currently supports the distribution of digital video in a number of different formats including
uncompressed video, JPEG 2000 compressed video and MPEG-4 compressed video. The protocols
selected for inclusion in the standard do not restrict it to just these video formats, as other RTP video
payload formats can be adopted and added in future versions. This will allow a VIVOE system to exploit
new digital video formats as they emerge and as RTP payloads profiles are defined for them through the
Request for Comment (RFC) process maintained by the Internet Engineering Task Force (IETF).
The standard also specifies the methods used to incorporate session control using Simple Network
Management Protocol (SNMP) and the distribution of limited metadata within the video stream.

0.2

Document Structure

This standard consists of two parts. Part 1 provides details on the implementation of the standards and
protocols in a VIVOE system.
This document contains Part 0 of the standards and consists of the following sections:
Section 1, Scope.
Section 2, Warning.
Section 3, Normative References.
Section 4, Terms, Definitions and Abbreviations.
Section 5, Video Distribution Architecture.
Section 6, Protocol Guidance.
Section 7, System level guidance.

Page v

DEF STAN 00-82 Part 0 Issue 1

This page is intentionally blank.

Page vi

DEF STAN 00-82 Part 0 Issue 1

Vetronics Infrastructure for Video Over Ethernet - Guidance

1

Scope

The aim of the Vetronics Infrastructure for Video Over Ethernet (VIVOE) standard is to promote the
interoperability of present and future land platform digital video distribution systems. A VIVOE network is
used for the distribution of digital video within a Vetronics system, although, as an option, the
incorporation of limited data (e.g. video metadata) distribution on the same network may be
implemented. However, the standard is not intended to be used to transfer general Vetronics type data
on the network and using it to transfer Vetronics data may impact the real-time performance of the video
system.
The standard describes the mechanisms and protocols that shall be employed to facilitate the distribution
and control of digital video and data. The system specified is based on Ethernet as the network
technology and all the protocols and mechanisms selected are open, widely used network standards.
This standard does not define any new protocols but provides guidance on how the selected protocols
and mechanisms are used. For most protocols, the actual standard documentation will need to be
consulted to obtain additional detailed information to implement the protocol in an actual system. This
Defence Standard should therefore be used as the starting point when designing and implementing a
VIVOE system.
Not all parts of the standard will need to be implemented for every system. The particular features and
functions of the standard that are used for a particular implementation shall be system-defined on a
project by project basis via a valid systems engineering approach.

Warning

The Ministry of Defence (MOD), like its contractors, is subject to both United Kingdom and European
laws regarding Health and Safety at Work, without exemption. All Defence Standards either directly or
indirectly invoke the use of processes and procedures that could be injurious to health if adequate
precautions are not taken. Defence Standards or their use in no way absolves users from complying with
statutory and legal requirements relating to Health and Safety at Work.

Normative References

The publications shown below are referred to in the text of this standard. Reference in this standard to
any related document means that in any Invitation to Tender or contract the edition and all amendments
current at the date of such tender or contract unless a specific edition is indicated.
IEEE Std 802

Local and Metropolitan Area Networks - Architecture and Overview

Specification

IEEE 802.1AX-2008

Local and Metropolitan Area Networks - Link Aggregation

IEEE 802.2-1998

Local and Metropolitan Area Networks - Logical Link Control

IEEE 802.3-2008

Local and Metropolitan Area Networks - Specific Requirements Part 3: Carrier

Sense Multiple Access With Collision Detection (CSMA/CD) Access Method
and Physical Layer Specifications

Page 1

DEF STAN 00-82 Part 0 Issue 1

Internet STD 3
RFC 1122
RFC 1123

Requirements for Internet Hosts - Communication Layers

Requirements for Internet Hosts - Application and Support

Internet STD 5
RFC 791
RFC 792
RFC 950
RFC 1112

Internet Protocol
Internet Control Message Protocol
Internet Standard Subnetting Procedure
Host extensions for IP multicasting

Internet STD 6
RFC 768

User Datagram Protocol

Internet STD 33
RFC 1350

The TFTP Protocol (Revision 2)

Internet STD 37
RFC 826

An Ethernet Address Resolution Protocol

Internet STD 41
RFC 894

A Standard for the Transmission of IP Datagrams over Ethernet Networks

Internet STD 43
RFC 1042

A Standard for the Transmission of IP Datagrams over IEEE 802 Networks

Internet STD 62
RFC 3416

Version 2 of the Protocol Operations for the Simple Network Management

Protocol (SNMP)

Internet STD 64
RFC 3550

RTP: A Transport Protocol for Real-Time Applications

RFC 2236

Internet Group Management Protocol, Version 2

RFC 2365

Administratively Scoped IP Multicast

RFC 2974

Session Announcement Protocol

RFC 4541

Considerations for Internet Group Management Protocol (IGMP)

RFC 4566

SDP: Session Description Protocol

ITU R BT.601

Encoding Parameters of Digital Television for Studios

ITU R BT.656

Interfaces for Digital Component Video Signals in 525 line and 625 line
Television Systems operating at the 4:2:2 level of Recommendation ITU R
BT.601 (Part A)

SMPTE 274M

Television - 1920 x 1080 Image Sample Structure, Digital Representation and

Digital Timing Reference Sequences for Multiple Picture Rates

SMPTE 296M

Television - 1280 x 720 Progressive Image Sample Structure - Analog and

Digital Representation and Analog Interface

Page 2

DEF STAN 00-82 Part 0 Issue 1

ISO/IEC15444

Information technology - JPEG 2000 image coding system

ISO/IEC 14496-2

Information technology - Coding of audio-visual objects - Part 2: Visual

(MPEG-4 Part 2)

ISO/IEC 14496-10

Information technology - Coding of audio-visual objects - Part 10: Advanced

Video Coding (MPEG-4 Part 10)

Reference in this standard to any normative references means in any Invitation to Tender or contract the
edition and all amendments current at the date of such tender or contract unless a specific edition is
indicated.
In consideration of the clause above, users shall be fully aware of the issue and amendment status of all
normative references, particularly when forming part of an Invitation to Tender or contract. Responsibility
for the correct application of standards rests with users.
DStan can advise regarding where to obtain normative referenced documents. Requests for such
information can be made to the DStan Helpdesk. Details of how to contact the helpdesk are shown on
the outside rear cover of Defence Standards.

Terms, Definitions and Abbreviations

For the purposes of this standard, the following terms, definitions and abbreviations apply:

4.1

Terms and Definitions

Use of shall, should and may within the standards observe the following rules:
-

The word 'SHALL' in the text expresses a mandatory requirement of the standard.

The word 'SHOULD' in the text expresses a recommendation or advice on implementing such
a requirement of the standard. It is expected that such recommendations or advice be
followed unless good reasons are stated for not doing so.

The word 'MAY' in the text expresses a permissible practice or action. It does not express a
requirement of the standard.

The following definitions apply throughout the standard:

Channel - a distinct video or data steam transmitted or received on a multicast IP address. A device may
be able to send or receive one or more channels simultaneously.
Primary interface - the Ethernet interface on which all control and configuration communication shall be
undertaken on the device.
Secondary interface - an Ethernet interface on a multi-interface device that shall only be used to stream
out or receive video data (as directed by the SNMP agent on the primary interface).
Service provider - a device that is able to source a stream of information (either data or video).
Service user - a device that is able to sink a stream of information (either data or video).
Jumbo frame - an Ethernet frame with more than the standard 1500 bytes of payload.

Page 3

DEF STAN 00-82 Part 0 Issue 1

4.2

Abbreviations

ARP

Address Resolution Protocol

ASCII

American Standard Code for Information Interchange

ASN.1

Abstract Syntax Notation One

ASP

Advanced Simple Profile

AVC

Advanced Video Coding

BER

Basic Encoding Rules

CSMA/CD

Carrier Sense Multiple Access with Collision Detection

DE&S

Defence Equipment and Support

EMC

Electromagnetic Compatibility

HD

High Definition

IANA

Internet Assigned Numbers Authority

ICMP

Internet Control Message Protocol

ID

Identifier

IEC

International Electrotechnical Commission

IEEE

Institute of Electrical and Electronics Engineers

IETF

Internet Engineering Task Force

IGMP

Internet Group Management Protocol

IP

Internet Protocol

IPD

Inter-Packet Delay

IPv4

Internet Protocol version 4

IR

Infrared

ISO

International Organization for Standardization

ITU

International Telecommunications Union

JPEG

Joint Photographic Experts Group

LLA

Link-Local Address

LLC

Logical Link Control

MAC

Media Access Control

Mbps

Megabits per second

MBps

Megabytes per second

MHF

Main Header Flag

MIB

Management Information Base

Page 4

DEF STAN 00-82 Part 0 Issue 1

MOD

Ministry of Defence

MPEG

Moving Picture Expert Group

MTU

Maximum Transmission Unit

NTSC

National Television System Committee

OID

Object Identifier

PAL

Phase Alternating Line

PEN

Private Enterprise Number

RFC

Request For Comments

RTCP

RTP Control Protocol

RTP

Real-time Transport Protocol

SAP

Session Announcement Protocol

SDP

Session Description Protocol

SMI

Structure of Management Information

SMPTE

Society of Motion Picture and Television Engineers

SNMP

Simple Network Management Protocol

SXGA

Super Extended Graphics Array

TCP

Transmission Control Protocol

TFTP

Trivial File Transfer Protocol

UDP

User Datagram Protocol

VESA

Video Electronics Standards Association

VGA

Video Graphics Array

VIVOE

Vetronics Infrastructure for Video Over Ethernet

VLAN

Virtual Local Area Network

VoIP

Voice over IP (Internet Protocol)

XGA

Extended Graphics Array

Page 5

DEF STAN 00-82 Part 0 Issue 1

Video Distribution Architecture

5.1

Introduction

This VIVOE standard describes the mechanisms and protocols that shall be employed to facilitate the
distribution of digital video over an Ethernet infrastructure. This standard also facilitates, as an option, the
distribution of data on the same network.
The architecture of the system includes the provision for multiple service providers (individual video and
data sources) to access the network infrastructure and for multiple service users (displays and data
processors) to receive information from the network infrastructure. The distribution of video or data from
one service provider to one or many service users is supported.
The fundamental transport protocol used is Real-time Transport Protocol (RTP), which allows numerous
defined video payload formats, including both uncompressed and compressed video formats. The
standard also specifies the methods used to incorporate session control using Simple Network
Management Protocol (SNMP) and metadata within the video stream.

5.2

Background

Analogue video networks, based on proven, mature technologies, have been deployed in a number of
Vetronics systems in the past. Although the technology may continue to be deployed where low cost is
the overwhelming priority, digital video based systems will soon become the technology of choice for
Vetronics systems for a number of reasons:

by selecting suitable protocols, systems constructed using this standard will result in an
integrated network for video and data;

a network based implementation provides a simpler interface for digital output based sensors;

a network based implementation is scalable and extensible, the addition of inputs/ output ports is
easily accommodated by the introduction of further switches, something that is not always
possible with an analogue based video matrix;

digital video technology facilitates the processing of video image data on the platform or in
remote locations. The output of an image processor then becomes a source which can be
distributed to one or more displays within the system

digital signals are easily compressed and encrypted using recognised open standards;

digital signals offer an inherently more robust solution.

digital data distribution via networks is well proven.

5.3

Objective

The objective is to define an architecture that is:

based on open standards and protocols to avoid proprietary solutions and vendor lock-in and
thereby promoting competition;

scalable over the range of platforms to which it may be applied so the same technologies can
used to construct the video network for platforms from low complexity (e.g. utility vehicles) to
platforms of high complexity (e.g. reconnaissance vehicles);

extensible to allow for future addition of sensors, displays and processing resources without the
need to add or change the hardware, software, protocols or standards employed other than the
additional sensors, displays or processing resources being added;

Page 6

DEF STAN 00-82 Part 0 Issue 1

5.4

capable of unicast and multicast video transmission. Unicast is a single video source to a single
display and multicast is a single video source to two or more displays;

capable of accepting and exploiting the full functionality of upgraded sensors and displays
without changes to the protocols or standards employed. This allows sensors and displays to be
added or removed from the network and the functionality added or removed to be discovered
automatically;

capable of transporting a range of video formats and resolutions suitable for military platforms
without impact to the underlying transport protocols e.g. visible band colour and infrared (IR)
monochrome video, standard and high resolutions;

capable of transporting a range of compressed video formats (e.g. MPEG-4 and JPEG 2000)
without impact to the underlying transport protocols;

capable of distributing metadata associated to the source of the image data as part of the video
transmission to convey data pertinent to the sensor from which the video is derived;

flexible in that it employs control mechanisms to select image sources for display or image
processing, to control the routing of these images to the correct display or image processors and
to control the image processing and selection of sensor functionality;

simple to implement, achieved by de-scoping the protocols to a core functionality and excluding
or optioning some of the features and other associated protocols.

Conceptual Architecture

The video and data distribution architecture based on the protocols and mechanisms standardised in this
document interconnects multiple video service providers and service users (e.g. video displays and data
processors) via a Gigabit Ethernet network as shown in Figure 1.

Figure 1 - Conceptual Video Distribution Architecture

Page 7

DEF STAN 00-82 Part 0 Issue 1

The standard is intended to meet the requirements of a range of architectures from simple point to point
links to networks consisting of multiple service providers, service users, network switches and processing
units.
In practice, the architecture is likely to consist of a wide variety of equipment types. For example, the
network may use one or more Gigabit Ethernet or 10G Ethernet switches arranged in a topology to best
meet the distribution of service providers and service users. As the system employs multicast addressing
for all the video and data streams, any switches within the system must be multicast enabled, achieved
either by employing Layer 3 capable switches or by utilising Layer 2 switches that employ Internet Group
Management Protocol (IGMP) snooping.
The video service providers are likely to comprise of a range of video sensors of different resolutions and
capabilities, some of which may have the Ethernet interface incorporated in the sensor hardware and
some of which may need to be connected via interface modules. Likewise, the video service users may
be displays that have the Ethernet interface incorporated in the display hardware or may need to be
connected via interface modules. Service users may also form part of an image processing function,
which could be incorporated into the display or be a separate entity on the network, in which case the
image processing unit would also act as a service provider of video data.

5.5

Vetronics Video Architecture

A more comprehensive and realistic architecture for a video only distribution architecture for a Vetronics
system is shown in Figure 2. An array of image sensors interface to multiple Gigabit Ethernet switches,
which are interconnected using 10G Ethernet to provide a reliable and resilient network infrastructure.
For example, one switch could be located in the hull of the vehicle and one in the turret.

Figure 2 - Example Vetronics System Video Network Architecture

Page 8

DEF STAN 00-82 Part 0 Issue 1

The image sensors could incorporate an image processing function to undertake compression or region
of interest processing etc. Shared image processing resources could be incorporated to undertake image
fusion and image stitching etc. The displays that make up the crewstation display resources are also
connected into the network.
The image control element of the shared image processing resource and each crewstation can
communicate with each other and the image sensors on the network using the control mechanisms in
this standard. However, any control elements will also need to communicate with the Vetronics command
and control system to arbitrate control and priorities. No direct control of the network infrastructure is
required as routing information is provided by the protocols used to send video imagery.

Page 9

DEF STAN 00-82 Part 0 Issue 1

Protocol Guidance

6.1

Overview

The following sections in the document provide a brief overview of the Ethernet standards and the
Internet protocols that are used in a VIVOE system to distribute digital video over the network. Guidance
is also provided on specific areas to facilitate the implementation of the protocols within a VIVOE system.
The standards and protocols are described with reference to the five-layer Transmission Control
Protocol/Internet Protocol (TCP/IP) model, also known as the Internet Reference Model, as shown in
Figure 3 below. The lower four layers of this model are likely to be already implemented in any Vetronics
system employing Ethernet. Only the Application Layer protocols are likely to be unique to a VIVOE
system.

Layer 5
Application Layer

Real-time
Transport Protocol
(RTP)

Layer 4
Transport Layer

Layer 3
Internet Layer

Session
Announcement
Protocol (SAP)

Session
Description
Protocol (SDP)

Simple Network
Management
Protocol (SNMP)

User Datagram Protocol (UDP)

Internet Protocol
(IP)

Internet Group
Management
Protocol (IGMP)

Internet Control
Message Protocol
(ICMP)

Layer 2
Data Link Layer

IEEE 802.3

Layer 1
Physical Layer

Ethernet physical layers

(1000BASE-T, 1000BASE-SX etc.)

Address
Resolution
Protocol (ARP)

Figure 3 - Specified Protocols Mapped to the TCP/IP Model

6.2

Physical Layer and Data Link Layer

The Physical Layer and Data Link Layer of the system is compliant with the IEEE 802.3 set of standards,
which define the Physical Layer (including the electrical signalling, data encoding and connectors etc.)
and the Media Access Control (MAC) sub-layer of the Data Link Layer of Ethernet.
It is likely that the Physical Layer will be predominantly based on Gigabit Ethernet technology in many
implementations of this standard and use the 1000BASE-T specification, which uses four pairs of copper
cables in a full-duplex configuration.
Where data rate requirements or physical media considerations dictate, higher rate Ethernet
technologies such as 10 Gigabit Ethernet should be implemented. For example, it is likely that the data
rate requirements of uncompressed High Definition (HD) video or multiple concurrent video streams will
require 10 Gigabit Ethernet. This is most likely on inter-switch links where the equipment would use the
10GBASE-SR fibre optic, or the 10GBASE-CX4 or 10GBASE-T copper cabling Physical Layers
standard. Other applications may also include backplane interconnects within image processing units.

Page 10

DEF STAN 00-82 Part 0 Issue 1

Where there are special Electromagnetic Compatibility (EMC) considerations and the data rate
requirements can still be met using Gigabit Ethernet, the fibre optic versions of the Physical Layer
standards may be used, providing the chosen fibre optic cable can operate in the specified military
environment. The Gigabit Ethernet fibre options are also specified is the IEEE 802.3 standard. They
include 1000BASE-SX for transmission over multi mode fibre and 1000BASE-LX for transmission over
single mode fibre.
However, the upper layer protocols specified in this standard allow any Ethernet compatible technology
to be used, including wireless Ethernet as specified in the IEEE 802.11 set of standards where the video
streams may need to communicate with off-platform applications.
Table 1 shows the resulting data rates for a number of different video formats supported by the VIVOE
standard and the Physical Layers required to support the data rate. The actual data rates shown in the
table should only be taken as a guide and it should be noted that they are shown in Megabits per second
(Mbps) and Megabytes per second (MBps). It can be seen that the throughput of Gigabit Ethernet may
preclude the transmission of uncompressed 1920 by 1080 HD video data and other high resolution
formats on a single interface. These formats therefore require the use of 10 Gigabit Ethernet interfaces,
compression of the video data or a scheme that implements multiple network interfaces on devices and
link aggregation as defined in IEEE 802.3.
Physical Layer options
Video format

Video data rate

IEEE 802.11

100 Mb

Gigabit

10 G

MPEG-4 Part 2,
576i

~10 Mbps

JPEG 2000, visually

lossless, 576i

~16 Mbps

JPEG 2000,
lossless, 576i

~12 MBps

Uncompressed,
YUV encoded, 576i

~23 MBps

Uncompressed,
RGB, 576i

~35 MBps

Uncompressed,
YUV, 720p

~50 MBps

Uncompressed,
RGB, 1080p

~160 MBps

Table 1 - Typical Data Rate Requirements

6.2.1

Connectors

This standard does not specify the connector requirements or a range of connector types used with each
Physical Layer at this time, as these will be system dependant depending on environmental and EMC
considerations.

6.2.2

Physical Layer and Media Access Control Sub-Layer

The Physical Layer includes definitions of the electrical signalling, data encoding, clocking requirements
and connectors. The exact details of the Physical Layer implemented for a VIVOE system is a system
design issue, although the system shall be compatible with the IEEE 802.3 set of standards. These
standards cover a range of data rates from 10 Mbps to 10 Gbps.

Page 11

DEF STAN 00-82 Part 0 Issue 1

6.2.2.1

Maximum Transmission Unit

The system should support Ethernet Jumbo frames with a maximum payload of 9000 bytes 1 . However,
it should be noted that Jumbo frames can impact the performance and latency of multimedia systems so
the implementation of Jumbo frames shall be system specific after analysis of any impact they may have.
The Maximum Transmission Unit (MTU) for a device should be configurable via an object in the
Management Information Base (MIB), although the standard size Ethernet MTU shall be used as default.
The Internet Protocol (IP) standard mandates that all devices on the same subnet have the same MTU.
As all service providers and service users are on the same subnet in a VIVOE system, they shall all be
configured with the same MTU.

6.2.2.2

Link Aggregation

The overall bandwidth of the interface to a service provider or service user may be increased by
aggregating multiple links into one virtual link using the techniques specified in IEEE 802.1AX-2008, Link
Aggregation.
Most simple Link Aggregation implementations send packets with the same Layer 3 (IP) address on the
same physical link in order to stop packets getting out of order. Some advanced switches can use Layer
4 (TCP/UDP port) numbers as well. However, in this standard, these schemes will prevent Link
Aggregation being able to provide extra bandwidth for the video traffic as a single RTP video stream is
always sent using the same IP address and the same port number. Therefore, traffic balancing across
the multiple links cannot use the standard Link Aggregation mechanisms. When a device can send
multiple video streams (either using multiple service providers or multiple channels), Link Aggregation
can be used, as each stream will use a distinct IP address.

6.2.3

Logical Link Control Sub-Layer

The upper sub-layer of the Data Link Layer is the Logical Link Control (LLC) Layer. This standardises the
interface between the MAC and the Internet Layer and shall be implemented in a VIVOE system as
specified in IEEE 802.2.

6.3

Internet Layer

This standard specifies the use of a number of protocols at the Internet Layer of the TCP/IP model
including Internet Protocol (IP), Internet Group Management Protocol (IGMP) and Address Resolution
Protocol (ARP).
Although these protocols were originally developed for Internet applications, many of the perceived
weaknesses in implementing Internet protocols in a military system, particularly within a land-based
platform, are mitigated by the following factors:

the network they are likely to be employed on will be a closed system (i.e. within the vehicle);

any links to systems outside the vehicle will be via recognised interfaces incorporating the
necessary security considerations;

the Internet protocols specified in this standard have been profiled with some features optional or
excluded to allow the network and protocol behaviour to be well understood.

Jumbo frames are not defined as part of IEEE 802.3 standard although the maximum of 9000 bytes has become
adopted as the conventional limit by standardisation bodies and equipment manufacturers.

Page 12

DEF STAN 00-82 Part 0 Issue 1

6.3.1

Internet Protocol

The standard uses Version 4 of the IP standard, IPv4, as specified in Internet standard STD 5, which
includes RFC 791, RFC 792, RFC 950 and RFC 1112. The standard describes a data-oriented protocol
used for transferring data across a packet switched network. The data to be sent is encapsulated in one
or more packets with a preceding header that includes data length, header checksum and source and
destination addresses.
It is a connectionless protocol that provides an unreliable service (i.e. best effort delivery) and, in terms of
reliability, the only thing IP does is ensure the IP packet's header is error-free through the use of a
checksum. The error checking is also enhanced by the error checking undertaken at other layers of the
protocol stack.

6.3.1.1

IP Address Assignment

Each network host in the system is assigned a unique IP address from the Private Internets allocation as
specified in RFC 1918. From the address a unique identifier (ID) for each service provider and service
user in the system is derived.
There are two options for the range from which the address is chosen defined in the standard, depending
on the number of hosts required in the system, as detailed in Part 1 of this standard. The first option
provides 254 possible addresses, which it is anticipated should be sufficient for the closed networks
implemented in a platform based Vetronics system, especially as all service providers can have up to
255 separate channels to transmitting streams. The second option provides for 254 service providers
(each with up to 255 separate channels) with service users and network switches allocated address from
three different subnets, providing over 1000 addresses in total.
Where the throughput of the streamed video exceeds the data rate of a single Ethernet link, one option is
to have multiple Ethernet interfaces on the device. In this case, one interface shall be designated as the
Primary interface with the other interfaces designated as Secondary. All control and configuration
communication with the device shall be undertaken using the primary interface, as only the primary
interface shall have an SNMP agent, which shall also be responsible for managing the secondary
interfaces. The secondary interfaces shall only be used to stream out or receive the required video
channel as directed by the SNMP agent on the primary interface.
The unique device ID is then derived from the IP address assigned to the primary interface and, if the
device is a service provider, the last byte of the primary IP address shall also be used as the last byte of
the multicast IP address that the device transmits on, i.e. all video channel multicast groups for the
device shall be derived from the primary interface, not the interface it is transmitted from.
For example, a device supports three HD sources and has three Ethernet interfaces with IP addresses
set to 192.168.204.1, 192.168.205.2 and 192.168.205.3. Interface 192.168.204.1 is designated as the
primary interface so other devices communicate with the SNMP agent on 192.168.204.1 and are able to
control all three streams. The device would then stream three HD sources concurrently as follows:

Multicast stream 239.192.1.1 from interface 192.168.204.1;

Multicast stream 239.192.2.1 from interface 192.168.205.2;

Multicast stream 239.192.3.1 from interface 192.168.205.3.

6.3.1.2

IP Address Assignment Schemes

There are three IP address assignment schemes specified in this VIVOE standard to allow flexibility in
the allocation of IP addresses on a VIVOE system. Only the first scheme, static assignment, is
mandatory. The IP address is configured via a software application or operating system running on the
device, or, on simple devices, through an alternative interface, e.g. a serial port. The address is then

Page 13

DEF STAN 00-82 Part 0 Issue 1

stored on the device in non-volatile memory. The system integrator or user is responsible for ensuring
that there are no address conflicts in the system.
The second scheme allows an SNMP manager in the system to subsequently change the IP address by
modifying a read-writable object stored in the MIB, either as a configuration procedure or a maintenance
function. The system integrator or user is again responsible for ensuring that there are no address
conflicts in the system.
The third option uses a modified form of the procedure undertaken by a host when dynamically assigning
itself an IPv4 Link-Local Address (LLA). However, LLA allocates addresses in the range 169.254.x.x,
which may result in duplicate device IDs based on the last byte of the IP address so a device in a VIVOE
system needs to select an unused address by working through the range specified in this standard and
checking that an address is unused using the Address Resolution Protocol (ARP) probe messages. This
will ensure that each device still has a unique ID and the third byte of the address is reserved for multiple
channels on a device. Guidance on the techniques used for LLA are included in RFC 3927, which should
be followed for issues such as the resolution of address conflicts, the generation of an initial, random
addresses and ARP probing timeouts.

6.3.2

Internet Group Management Protocol

The ability to stream video or data from one service provider to multiple service users simultaneously is
important in a VIVOE system. This is accomplished by implementing IP multicasting as defined in
Version 2 of the Internet Group Management Protocol (IGMP) standard, RFC 2236. This RFC describes
how IP hosts join, leave and report their multicast group memberships to any immediately-neighbouring
multicast routers or switches. It only defines the use of IGMP between hosts and routers to determine
group membership.
In practice only service users in this system need to implement IGMPv2, as devices that simply transmit
on a multicast address are not required to join the group they are transmitting on.
To enable multicast messages to be supported, any switches within the system must be multicast
enabled either by using Layer 3 capable switches or by using Layer 2 switches that employ IGMP
snooping. This is discussed in section 7.1.1.

6.3.2.1

IP Multicast Address Assignment

The multicast IP address that each service provider in the system transmits the digitised video data
stream on shall be in a range of predefined multicast addresses from 239.192.1.1 to 239.192.254.254.
This range is defined within the Administratively Scoped IP Multicast standard, RFC 2365, as the
multicast IP address space from which an organization should allocate sub-ranges when defining scopes
for private use. In addition, RFC 2365 describes a simple set of semantics for the implementation of
Administratively Scoped IP Multicast.
The fourth byte in the address specifies the unique host ID of the service provider and the third byte
specifies the channel ID on that service provider if it supports multiple channels. Multiple channels may
be used for different video formats that are transmitted on separated multicast IP addresses from a
single service provider or multiple transmitters in a single service provider unit. However, only one video
or data stream shall be transmitted on each IP address at any one time. The maximum number of host
IDs and channel IDs is 254.
For example, a service provider transmitting on a multicast IP address of 239.192.2.5 would signify that
the video data is being sent from channel 2 on host ID 5. Any device wanting to receive the data would
join that particular multicast group by transmitting the relevant Join group messages as specified by the
IGMPv2 standard. When a receiver is commanded to stop receiving video data it shall transmit the
relevant Leave group messages as specified by the IGMPv2 standard. If only a single service user joins
a particular multicast group, a unicast type connection between the service provider and service user is
established.

Page 14

DEF STAN 00-82 Part 0 Issue 1

6.3.3

Internet Control Message Protocol

The error and control messages defined in the Internet Control Message Protocol (ICMP) standard,
RFC 792, allow devices on the network to send error messages to indicate that a requested service is
not available or that another device could not be reached. Some responses require interaction with or
reporting to higher layers in the network stack. RFC 1122 Requirements for Internet Hosts Communication Layers provides guidance on the use of ICMP
In the VIVOE standard not all the messages defined in ICMP are mandated. Therefore a service provider
or service user shall only be required to implement the messages defined Part 1 of this standard, but
may optionally implement other ICMP messages.

6.3.4

Address Resolution Protocol

Address Resolution Protocol (ARP), as defined in RFC 826, is the standard method for mapping IP
addresses to Ethernet MAC addresses. ARP is implemented by all service providers and users in a
VIVOE system.

6.4

Transport Layer

The VIVOE standard uses the User Datagram Protocol (UDP), as defined in RFC 768 in Layer 4 of the
TCP/IP model, the Transport Layer. UDP specifies a transport protocol that does not guarantee reliable
and in-order delivery of data from sender to receiver, unlike TCP. In a very large network, the datagrams
may arrive out of order, appear to be duplicated or not arrive at all.
For applications that do not need guaranteed delivery UDP can be faster and more efficient than TCP, as
it avoids the overheads of checking whether every packet actually arrived. Time-sensitive applications
often use UDP because dropped packets are preferable to delayed packets. For Vetronics applications
the networks will be well defined and bounded within the vehicle minimising the reliability issue with UDP.
The implementation of Transmission Control Protocol (TCP) shall not be required.
Crucially for this standard, UDP supports packet broadcasts (sending from one node to all nodes on local
network) and multicasting (sending from one node to multiple nodes), which are not supported in TCP.

6.5

Application Layer

In Layer 5 of the TCP/IP model, the Application Layer, the VIVOE standard uses a number of protocols,
which can be broadly split into 3 categories:

The Real-time Transport Protocol (RTP) used to transfer the streaming digital video data;

The Session Announcement Protocol (SAP) and Session Description Protocol (SDP) used for
session announcement and description;

The Simple Network Management Protocol (SNMP) used for session and system configuration
and control.

6.5.1

Real-time Transport Protocol

The VIVOE standard uses the RTP and its associated payload formats to distribute the digitised video
and data streams on the Ethernet network. The standard was developed by the Audio-Video Transport
Working Group of the IETF and published as RFC 3550.
RTP provides end-to-end delivery services for data with real-time characteristics, such as interactive
audio and video. These services include payload and source identification, sequence numbering for
receiver reassembly, timestamping, timing recovery, media synchronisation and delivery monitoring. It is

Page 15

DEF STAN 00-82 Part 0 Issue 1

widely used on the Internet for IP telephony (VoIP) and audio and video streaming for video
conferencing, web casting and on-demand video streaming.
RTP packets are encapsulated in UDP packets to utilize the multiplexing and checksum services of UDP.
UDP is preferred as audio and video applications are more sensitive to the delays incurred by TCP than
the packet loss incurred by UDP.
RTP is usually considered to be an Application Layer protocol as the audio or video application encodes
the data into RTP packets. However, RTP is in reality an application independent transport protocol and,
in combination with UDP, provides the transport protocol functionality. It is probably best described as a
transport protocol that is implemented in the Application Layer.
RTP was originally developed as a lightweight transport protocol over multicast enabled networks so can
support data transfer to multiple destinations using multicast distribution if provided by the underlying
network.
Part 1 of this standard describes how the generic RTP protocol is profiled to provide a simple core
protocol for easy implementation. The aim is to make an RTP compatible header but fix (i.e. make static)
a number of components in the header that are usually negotiated outside of the protocol in a full RTP
implementation. The scheme allows for future expansion or reuse of RTP within the system by any of the
following means:

The equipment may be upgraded to a more comprehensive RTP implementation for use in more
general environments.

Additional static components can be added in private uses of the protocol.

A supporting device or mechanism could be added to the system to provide payload number
resolution for the static payload numbers defined in this standard.

6.5.1.1

RTP UDP Port Numbers

RTP does not have a standard UDP port defined for communication, although the standard specifies that
an even port number is used for RTP with the next higher odd port number used for the corresponding
Real Time Control Protocol (RTCP) messaging. The Internet Assigned Numbers Authority (IANA) has
registered port number 5004 for use by RTP and 5005 for use by RTCP.
Service providers and service users may implement RTCP if the functions supported with RTCP (source
synchronisation, reception quality feedback and current recipient information) are required in the system.

6.5.1.2

RTP Video Payloads Supported

This standard currently supports the distribution of digital video in a number of different formats using
RTP. These include two profiles for MPEG 4 compressed video, uncompressed video and JPEG 2000
compressed video. These payload formats are standardised in the following RFCs.

RFC 3016, RTP Payload Format for MPEG-4 Audio/Visual Streams, describes an RTP payload
format for MPEG-4 Part 2 Advanced Simple Profile (ASP) compressed video.

RFC 3984, RTP Payload Format for H.264 Video, describes an RTP payload format for MPEG-4
Part 10 AVC (Advanced Video Coding) compressed video.

RFC 4175, RTP Payload Format for Uncompressed Video, specifies a packetisation scheme for
encapsulating uncompressed video into a payload format for RTP. It supports a range of
standard- and high-definition video formats, including common television formats such as ITU-R
BT.601, and standards from the Society of Motion Picture and Television Engineers (SMPTE),
such as SMPTE 274M and SMPTE 296M. YCbCr and RGB colour encoding are supported. The
format is designed to be applicable and extensible to new video formats as they are developed.

Page 16

DEF STAN 00-82 Part 0 Issue 1

For this standard the principles outlined in RFC 4175 have been used to support monochrome
encoding and VESA VGA display monitor formats, such as XGA (1024 x 768) and SXGA (1280 x
1024). Other uncompressed video formats can also be supported using the same principles.

RFC 5371, RTP Payload Format for JPEG 2000 Video Streams, describes an RTP payload
format for the ISO/IEC International Standard 15444-1 | ITU-T Rec. T.800, better known as
JPEG 2000 compression. JPEG 2000 features are considered in the design of this payload
format. JPEG 2000 is a truly scalable compression technology allowing applications to encode
once and decode many different ways. A JPEG 2000 video stream is formed by extending from
a single image to a series of JPEG 2000 images.

Appendices B to D in Part 1 of this standard provide worked examples of the RTP main header and the
payload header for these video formats. The protocols selected for inclusion in the standard do not
restrict it to just these video formats, as other RTP video payload formats can be adopted and added in
future versions. This will allow a VIVOE system to exploit new digital video formats as they emerge and
RTP profiles are defined for them.
Appendix E in Part 1 of this standard provides guidance on the format and structure to implement video
metadata using the RTP header extension facility and data streaming using an RTP payload.

6.5.2

Session Announcement Protocols

RTP only provides the mechanisms to transport, reconstruct and label the data streams in this standard.
Service providers require a mechanism to announce sufficient information about the payload along with
the RTP stream to allow service users receiving the RTP data to correctly decode the payload. This is
accomplished by sending a Session Announcement Protocol (SAP) message that incorporates a session
description conforming to the Session Description Protocol (SDP) standard.
SAP is a simple protocol that describes how multimedia sessions can be periodically announced or
advertised on a range of well-known multicast addresses. It is standardised in RFC 2974.
The Session Description Protocol (SDP) is defined in RFC 4566 and is intended for describing
multimedia sessions for the purposes of session announcement, session initiation and session invitation.
The description is formatted as ASCII text as a list of descriptors and parameters. Many of the
descriptors are more relevant to video conferencing etc. so have not been specified in this standard.
However, the scheme is extensible to allow descriptors to be defined and incorporated to describe the
functionality of new sources as they emerge, while still meeting the requirements of this standard.
Appendices B to D in Part 1 of this standard show worked examples of the SDP announcement for the
specific video formats specified in this standard. Appendix E provides guidance and an example on the
format and structure of the SDP announcements to implement raw data streaming using RTP.

6.5.3

Session Control Protocols

RTP is a transport protocol for video data implemented in the Application Layer. When used in
Internet-based systems, other protocols are required to undertake session control and configuration.
RTP is augmented by a control protocol, the Real Time Control Protocol (RTCP), which is used to
provide source synchronisation, reception quality feedback and current recipient information. Service
providers and service users may implement RTCP in a VIVOE system if these additional features are
required in the system.

6.5.3.1

Simple Network Management Protocol

The main session control in a VIVOE system is implemented in-band on the Ethernet network using
Simple Network Management Protocol (SNMP) to monitor and configure all the devices on the network.
SNMP, as defined in IETF STD 62, allows an SNMP manager (or managers) to monitor and manage
devices on a network with a simple set of SNMP messages. An SNMP agent running on a device in the

Page 17

DEF STAN 00-82 Part 0 Issue 1

system uses these messages to configure, report or modify the value of objects in a Management
Information Base (MIB).
To overcome the problems associated with compatibility of SNMP messages across devices based on
different hardware types and software languages, SNMP uses the Basic Encoding Rules (BER) defined
in the OSI's Abstract Syntax Notation One (ASN.1) standard to construct the data units sent with SNMP
messages. This is based on prefixing each data element with a type identifier and a length descriptor,
which allows an agent to decode the data without any prior knowledge of the format of the data. The
modules in a MIB are also written using an adapted subset of ASN.1. The adaptation is defined in
RFC 2578 Structure of Management Information Version 2 (SMIv2).

6.5.3.2

Control Architecture

Each service provider and service user shall implement an SNMP agent unless is it undertaking the role
of the SNMP manager in the VIVOE system. The SNMP agent shall respond to the SNMP messages
that another service provider, service user or the system manager issues to it. The manager is thus able
to monitor, configure and control other devices via the SNMP agent running on that device. Typically the
managers will be crewstations and image processors, which are likely to have the processing
architecture suitable for performing the management functions. However, which devices issue SNMP
commands, and how the arbitration and prioritisation of multiple manager processes is undertaken, is not
defined in this standard as it needs to be considered as part of the complete electronics architecture of
the Vetronics system.
The agent on each service provider and service user shall access its local MIB, which contains the
mandatory objects required to provide minimal information and control functionality for a system. The
SNMP agent may be fairly simple and therefore easily implemented in the device using well-understood
techniques and code. An example implementation of the control architecture is shown in Figure 4.

Figure 4 - SNMP Control Architecture

Page 18

DEF STAN 00-82 Part 0 Issue 1

A crew station hosts the application that is implementing the SNMP manager function and is thus
undertaking the role of the VIVOE system controller. Every service provider and service user in the
system implements an SNMP agent function which accesses the MIB on the device. The manager is
shown populating an optional, central MIB, which holds information on the capabilities and configuration
of all the devices in the system. The manager can also monitor, configure and control the network switch
in the system as most Ethernet switches implement SNMP and a range of standard and vendor specific
MIBs (see section 7.1.2).

6.5.3.3

SNMP Standards

There are three basic versions of SNMP. The initial version (SNMPv1) was enhanced in version 2
(SNMPv2) to include new SNMP message functionality and an enhanced structure for MIBs. However,
neither of these versions included provision for security features. These were added in version 3
(SNMPv3), which defined a set of security capabilities, including the use of four encryption algorithms,
and a framework to allow the capabilities to be used with SNMPv1 and SNMPv2 messages.
To reduce the complexity of the SNMP agent running on a device, a VIVOE system uses the
Community-based SNMPv2 set of standards, usually abbreviated as SNMPv2c. The only security
feature implemented is limited authentication based on the Community parameter in the SNMP
message headers. However, as this value is unencrypted and can be easily be intercepted, the network
should restrict the use of the control features of SNMP (i.e. the SetRequest command) and block SNMP
messages, as required, at any gateways to the network on the platform. The framework for SNMPv2c is
defined in RFC 1901, Introduction to Community-based SNMPv2.
Community-based SNMPv2 consists of three main standardised components:

the structure of the SNMP messages and their Protocol Data Units (PDUs) to provide the
mechanisms for information exchange;

the Structure of Management Information (SMI), which specifies structure, syntax and data types
used to create Management Information Bases (MIBs);

the Management Information Base, a specification of the objects comprising the management
information on a device on the network to allow it to be remotely monitored, configured and
controlled.

6.5.3.4

SNMP Messages

A VIVOE system uses a profiled set of the SNMP message set, defined in SNMPv2 and standardised in
Internet standard STD 62 (RFC 3416), to control service providers and service users. The message
types are summarised below:

GetRequest, GetNextRequest, GetBulkRequest - Read access messages to access

information from a managed device using a polling mechanism;

SetRequest - Write access messages that change management information on a device to

affect the device's operation;

GetResponse - Response messages sent to acknowledge a previous request;

SNMPv2-Trap, InformRequest - Notification messages used by a device to send an interruptlike notification to a manager.

The only mandatory SNMP messages in a VIVOE system are the simplest forms of the basic request
and set object messages and the agent response, as detailed in Table 2 of Part 1 of this standard. As all
the message types may be implemented a VIVOE device, a manager should use the most
comprehensive set of messages that an agent on a particular device responds to.

Page 19

DEF STAN 00-82 Part 0 Issue 1

The SNMP agents also implement the error handling and error message responses as defined in the
SNMPv2c standard, RFC 3416. Section 4.2.5 of RFC 3416 describes the error handling and response
message generation when SNMP agents process the messages.

6.5.3.5

Management Information Base

The MIB is an extensible, hierarchically organised database of individually accessible objects that stores
and records information or parameters about the device on which it resides. The manager can examine
or change the parameters in the MIB via the SNMP agent by specifying the parameters Object Identifier
(OID) within the message. However, the manager cannot modify the structure of the MIB via the agent
and cannot issue commands for a specific action to be performed when a value is changed. The agent
must monitor the object parameter and then initiate an action on the device. The MIB hierarchical
structure is shown in Figure 5.

Figure 5 - MIB Structure

Page 20

DEF STAN 00-82 Part 0 Issue 1

As SNMP is used in a VIVOE system to control service providers and service users, this standard
defines the structure of a MIB and the mandatory objects it contains to allow a management station to
fully configure, control or monitor any VIVOE device on the network. All VIVOE service providers and
service users implement the VIVOE MIB specified in this standard as a minimum, unless they are
undertaking the role of a system manager. The VIVOE MIB is compliant with the version 2 of the
Structure of Management Information (SMI) standard, Internet Standard STD 58, which comprises
RFC 2578, RFC 2579 and RFC 2580.
Each branch and leaf in the MIB is assigned an OID. For example, the deviceManufacturer object
at the bottom of Figure 5 can be accessed by using an OID of 1.3.6.1.4.1.35990.3.1.1.2, which can be
broken down as follows. The OID of 1.3.6.1.4.1 denotes that the MIB is a private enterprise Internet MIB,
as used by organisations or vendors to provide additional objects and functionality to the range of MIBs
defined by the standardisation bodies. Each enterprise is assigned a unique Private Enterprise
Number (PEN) by IANA. The MOD Defence Equipment and Support group (DE&S), as custodians of this
standard, have been assigned a PEN of 35990.
Below this additional sub-trees are defined, as recommended in the SNMP and MIB standards. The
sub-trees are:

desleReg (1) - The "Registration" sub-tree allows MIBs and objects to be registered, if required,
for use in additional MIBs;

desleGen (2) - The "Generic" sub-tree can be used for objects that are common to multiple
MIBs;

desleProducts (3) - The "Products" sub-tree is where the MIBs are located, e.g. the VIVOE MIB;

desleExperimental (6) - The "Experimental" sub-tree can be used while MIBs are under
development without conflicting with other MIBs. It denotes that the MIB is likely to change.

There are many standard MIBs defined in various RFCs and a service provider or service user may
include one or more of these MIBs as appropriate to increase functionality. The most likely MIB to include
is RFC 1213, the MIB for Network Management of TCP/IP-based internets (MIB-II), part of which is
included in Figure 5. It should be noted that although MIB-II is an SNMPv1 MIB, it is fully compatible with
SNMPv2.
In addition to any standards-based MIBs, a service provider or service user may also incorporate an
additional private enterprise MIB to include vendor specific features in the device. Vendors can include
their own private MIBs in a device by including another branch in the hierarchical structure under the
private subtree as an additional enterprises subtree, as shown in Figure 5 using their own PEN
number. The private MIB is then addressed by the PEN of the organisation or vendor, obtainable from
IANA, and subcategorised as required. This allows managers or controllers in the system to discover and
utilise any unique or enhanced feature on a vendors device by interrogating the additional MIB. Any
MIBs incorporated should be compliant with the version 2 of the SMI standard, Internet Standard
STD 58.

6.5.3.6

VIVOE Management Information Base

Appendix A in Part 1 of this standard provides the definition of the VIVOE MIB modules (compliant with
SMIv2) using the adapted subset of ASN.1, as defined in RFC 2578. The text can be used as an input to
a MIB compiler to generate images and code (e.g. C code and header files) that can be integrated during
the development of VIVOE system interfaces and controllers.

6.6

Video Encoding

A VIVOE network is used for the distribution of digital video within a Vetronics system. Therefore, there is
a requirement to encode the video signal into a digital format. There are a number of recognised
standards for digital video encoding, all of which are supported by this standard:

Page 21

DEF STAN 00-82 Part 0 Issue 1

ITU-R BT.601, Encoding Parameters of Digital Television for Studios, specifies the sampling
scheme to be used for digital representation of 625/525 line video for broadcast quality.

ITU-R BT.656, Interfaces for Digital Component Video Signals in 525-line and 625-line
Television Systems operating at the 4:2:2 level of Recommendation ITU-R BT.601 (Part A),
describes a simple digital video protocol for streaming uncompressed PAL or NTSC standard
definition TV (525 or 625 lines) signals. The protocol builds upon the 4:2:2 digital video encoding
parameters defined in ITU-R BT.601, which provides interlaced video data, streaming each field
separately, and uses the YCbCr colour space and a 13.5 MHz sampling frequency for pixels.

SMPTE 274M, 1920 x 1080 Image sample Structure, Digital Representation and Digital Timing
Sequences for Multiple Picture Rates, specifies the sampling scheme to be used for digital
representation of 1920 x 1080 video.

SMPTE 296M, 1280 x 720 Progressive Image Sample Structure - Analog and Digital
Representation and Analog Interface, specifies the sampling scheme to be used for digital
representation of 1280 x 720 video.

6.7

Video Compression

A VIVOE network can be used for the distribution of compressed digital video within a Vetronics system.
There are a number of video compression standards supported:

ISO/IEC15444, JPEG 2000 image coding system, defines a set of lossless (bit-preserving) and
lossy compression methods for coding bi-level, continuous-tone grey-scale, palletized colour, or
continuous-tone colour digital still images. It specifies the decoding processes for converting
compressed image data to reconstructed image data, specifies a code stream syntax containing
information for interpreting the compressed image data and a file format. It provides guidance on
encoding processes for converting source image data to compressed image data and guidance
on how to implement these processes in practice. JPEG 2000 is a wavelet-based image
compression that does not generate the characteristic 'blocky and blurry' artefacts of JPEG and
MPEG-2. When used for video, each frame is processed individually, without requiring intra
(reference) or predicted frames as in various MPEG schemes, which results in errors being
confined to the frame they occur in.

ISO/IEC 14496, commonly termed MPEG4, specifies techniques suitable for heavy compression
of moving images and is typically used for compression of video and audio down to data rates
ranging from 150 to 400 Kbps. Two version of MPEG-4 are supported by this standard:

Page 22

ISO/IEC 14496-2, MPEG-4 Part 2 provides over 20 different profiles. It is widely adopted
for video conferencing, CCTV and internet streaming applications. Disadvantages of
MPEG-4 Part 2 from the Vetronics viewpoint are that the encoding process discards
video data, incurs signal latency, and may produce images of lower quality. This
standard is preferred because it is international, open, will be in widespread use in the
commercial arena and is suitable for a limited range of Vetronics applications.

ISO/IEC 14496-10, MPEG-4 Part 10 is also known as MPEG-4 AVC (Advanced Video
Coding) and ITU-T H.264 and can support high quality video with large formats and high
compression rates. It has been widely adopted for low data rate Internet video
streaming, HDTV broadcast, Blu-ray video discs and CCTV applications including video
recording or archiving. However, it is still a block-oriented, motion-compensation-based
codec which can cause visible artefacts if the data is corrupted or missing.

DEF STAN 00-82 Part 0 Issue 1

6.8

Data Transfer Protocols

There are three main functions that may be undertaken by data transfers in the system:
1) File transfer (e.g. for downloading new firmware or software to a device) using Trivial File
Transfer Protocol (TFTP);
2) Metadata associated with a video stream using the extension headers in the RTP header;
3) Raw streamed data in format that does not have an RTP payload defined for it or a format that
does not required a payload format by packetising the data into RTP packets with RTP headers
and SDP descriptors.
The schemes are not intended to be used to transfer general Vetronics type data on the network. A
VIVOE network is used for the distribution of digital video within a Vetronics system and using it to
transfer other Vetronics data may impact the real-time performance of the video.

Page 23

DEF STAN 00-82 Part 0 Issue 1

System level guidance

7.1

Network Switch Features

A key component in a VIVOE system is the Ethernet switch, or switches, which interconnect the service
providers and service users. It is likely that the network switch will be procured or developed as a
separate item from the other devices. Careful selection of the switch is important to ensure that all the
features and mechanisms required in a VIVOE system are provided and that its performance is adequate
to ensure the overall performance targets for the system are met.
Not all network switches are the same and there will usually be a correlation between the features and
performance of a switch and its cost. However, some implementations of a VIVOE system may not
require the performance provided by the most expensive switches, although the system designer must
still ensure that the mechanisms required by the system are correctly implemented in the network switch.
Selection of the switch hardware will need to be based on a thorough investigation of the switches
capabilities and performance. Many of the performance criteria may be difficult to establish from the
vendors standard datasheets and manuals, and dialogue may be required to establish that the hardware
will be suitable for the VIVOE system being implemented.
This section provides some guidance on some of the areas that need to be considered and some of the
factors to be aware of when selecting the network switches.

7.1.1

Internet Group Management Protocol

Multicasting is a key requirement of even the simplest VIVOE system. This requires that any switches
within the system must be multicast enabled, achieved either by employing Layer 3 capable switches or
by utilizing Layer 2 switches that implement Internet Group Management Protocol (IGMP) snooping. This
means that generally only managed switches can be used in a VIVOE system and, although virtually all
Layer 3 switches are managed, some low-end Layer 2 switches may not be managed and will simply act
as a repeater hub when dealing with multicast traffic and therefore broadcast the traffic on every port. It
is unlikely that this scenario will be acceptable in a VIVOE system.
If Layer 2 switches employing IGMP snooping are used, there must be at least one Layer 3 capable
device in the network to issue the IGMP queries for IP multicast and IGMP snooping to work. Layer 2
switches by themselves cannot fully support IP multicast service unless they have the capability to act as
the IGMP querier. However, an increasing number of Layer 2 IGMP snooping switches now implement
the IGMP querier function.
There are also a number of configuration settings that deal with IGMP and IGMP snooping on a switch,
including numerous timer setting and timeout values, which need to be accessed to set switches in the
system up correctly. The maximum and minimum values need to be analysed against the VIVOE system
requirements.
There are a few IGMP performance issues that need consideration. For example, the amount of time that
is needed to accomplish IGMP querier election between multiple switches when they are initialised. A
switch should also stop sending multicast traffic to a multicast group immediately after the final member
of that multicast group leaves, although some switches take a finite time to stop the stream which may
overload a particular Ethernet link by sending multiple streams over it.
There may also be issues using IGMP snooping with high volumes of traffic. This may depend on how
the switch manufacturer has implemented the IGMP snooping function as to whether it is an issue or not.
For example, if the processor on the switch that manages the address table cannot handle the high rate
of multicast traffic likely with a video stream, it may not be able to manage the routing of multicast
packets and may cause to switch to fail in extreme cases. This is something that needs to be considered
during the selection of a suitable switch when using low-end hardware.

Page 24

DEF STAN 00-82 Part 0 Issue 1

The IETF has published a memo, RFC 4541, Considerations for Internet Group Management Protocol,
which provides guidance and information covering this area, as well as other factors to be aware of when
implementing IGMP in a system.

7.1.2

SNMP Configuration

Most managed switches implement SNMP and provide access to numerous MIBs on the switch. The
MIBs usually consist of those covering the standard IP networks (e.g. RFC 1213), Ethernet interfaces,
bridges and switches. There are also usually vendor specific MIBs providing access to a vast array of
statistics about the switch and any configurable parameter on the switch.
As SNMP is used in a VIVOE system to implement configuration and control, it may be useful to ensure
that the switches considered implement a sufficient range of MIBs to allow adequate configuration of the
switch.
One feature that may be useful is the implementation of link up/down SNMP Trap messages so that
whenever an Ethernet link goes up or down, i.e. whenever a device is connected to or disconnected from
the network, the switch sends an SNMP Trap message to an SNMP Manager. Therefore, whenever a
device is replaced or added a switch can send a Trap to the system supervisor. The supervisor accesses
the switch MIB using SNMP to get the IP address of the new device and then accesses the MIB on the
new device to find out what it is and what capabilities it has.

7.1.3

Other Switch Features

There are also a number of general features and functions that may be required on the switch. Some of
these are listed below and although most of them are not critical for a VIVOE system they may allow the
implementation of more capable architectures and facilitate integration with other elements of the
Vetronics system.

The switch should implement 10/100/1000 Mbps auto sensing on all ports;

The switch should implement MDI/MDI-X crossover detection on all ports;

The switch should implement the Virtual Local Area Network (VLAN) schemes specified in
IEEE 802.1Q;

The switch should be able to support Jumbo frames;

The switch should implement the three-bit user priority scheme specified in IEEE 802.1Q or the
Internet Layer DiffServ priority scheme and be able to manage the priority of packets using the
3-bit priority field included in the Tag Control Information defined by the VLAN IEEE standard;

A switch should be able to configure packet priorities on a port-by-port basis.

7.2

Automatic Device Discovery

7.2.1

Overview

When a new device, either a service provider or a service user, is connected to the VIVOE network it
may be useful for other devices on the network to automatically detect that it has been connected. This
would allow, in particular, video sensors to be added or replaced without having to manually configure
the rest of the system.

7.2.2

Switch Link Status

A system controller may achieve device discovery by enabling and monitoring the link status traps
provided on most managed Ethernet switches. When enabled, this function sends an SNMP Trap
message from the switch whenever the Ethernet link on an individual port on the switch is established or
detached. The destination for the SNMP Trap messages can be configured to be any other device or

Page 25

DEF STAN 00-82 Part 0 Issue 1

devices in the system. The new device can then be allocated a new IP address and, if necessary, a
manager, controller or service user may interrogate the new devices MIB to discover its capabilities.

7.2.3

Device Polling and MIB Walk

If a controller or service user has not been sent the Ethernet link up/down Trap message it may still poll
for any new devices by sending an ARP message to poll all the IP addresses in the range defined by this
standard, to update its ARP table to determine if a new device has been added to the system.
The manager can then use the GetRequest, GetNextRequest or GetBulkRequest SNMP operations to
traverse the entire MIB on the device (called a MIB walk) without any prior knowledge of the MIB. The
manager can therefore identify the device and acquire a full list of the capabilities and status of the
device.

7.2.4

Initialisation SAP/SDP Announcement

A service provider may also send a SAP/SDP announcement message when it completes its initialisation
after powering up or rebooting. The data within the announcement may describe the generic or main
capabilities of the service provider. These SAP/SDP announcement messages may be used to notify any
service user in the system currently processing SAP/SDP announcements that a new service provider
has been connected into the VIVOE network. If the service provider supports more than one video format
(e.g. uncompressed and JPEG 2000) then the service provider may send multiple SAP/SDP
announcement messages to describe the main features of each format.

7.3

Traffic Shaping

A simple but effective method to overcome potential problems with non-uniformly distributed or bursty
network traffic is to have a programmable Inter-Packet Delay (IPD) for each streamed packet. The IPD is
measured from the end of the previous packet to the beginning to the next packet of the same stream.
The IPD is specified in this way to match the definition of the Interframe Gap in an Ethernet network.
A service provider may implement a programmable IPD for each of its video services, programmed via
the MIB. A manager or service user may then request a service provider to use a specified IPD. Multiple
service users may exchange information to determine an optimum IPD for a service provider, although
the mechanism to do this is outside the scope of this standard.

Page 26

This page is intentionally blank.

 Crown Copyright 2010

Copying Only as Agreed with DStan

Defence Standards are Published by and Obtainable from:

Defence Equipment & Support

UK Defence Standardization
Kentigern House
65 Brown Street
GLASGOW G2 8EX

DStan Helpdesk
Tel 0141 224 2531/2
Fax 0141 224 2503
Internet e-mail enquiries@dstan.mod.uk

File Reference
The DStan file reference relating to work on this standard is D/DSTAN/21/82.
Contract Requirements
When Defence Standards are incorporated into contracts users are responsible for their correct
application and for complying with contractual and statutory requirements. Compliance with a Defence
Standard does not in itself confer immunity from legal obligations.
Revision of Defence Standards
Defence Standards are revised as necessary by an up issue or amendment. It is important that users
of Defence Standards should ascertain that they are in possession of the latest issue or amendment.
Information on all Defence Standards can be found on the DStan Website www.dstan.mod.uk,
updated weekly and supplemented regularly by Standards in Defence News (SID News). Any person
who, when making use of a Defence Standard encounters an inaccuracy or ambiguity is requested to
notify UK Defence Standardization (DStan) without delay on order that the matter may be investigated
and appropriate action taken.