Frequently Asked Questions about VITA 49 VITA Radio Transport

We are implementing a piece of software that interacts with a network utilizing the VITA 49.2 standard and are considering purchasing the standard document.  I see that the VITA 49.0 standard has been updated twice with 49.1 and 49.2.  It looks like 49.1 is more of an amendment to 49.0 and probably doesn’t contain all the VRT information that 49.0 does.  I need to find out if the 49.2 document does include the information from 49.0 and 49.1, or does it only contain the new additions?

The VITA 49 standards build on each other. They are what VITA refers to as "dot" standards and are not amendments or revisions to each other.

ANSI/VITA 49.0 - is the original receive only standard defining signal data packets + context packets.

ANSI/VITA 49.1 – was released at the same time as VITA 49.0, it is an optional “framing” wrapper for VITA 49.0 that has a unique code to define begin and end of container. Multiple VITA 49.0 or VITA 49.2 packets can be placed in a VITA 49.1 container. One application is for stored data on a disk to indicate the beginning of packet.

ANSI/VITA 49.2 – Is a significant enhancement to VITA 49.0, it is backward compatible and thus completely replaces it. New features:

Bottom line: Order 49.1 and 49.2 or join VITA

What is the purpose of Rule 10.1.2-2?

Rule 10.1.2-2: Once paired with a Data Packet Stream, a Context Packet Stream shall not be associated with other Context Packet Streams, either within the Information Stream or within other Information Streams, such that its Stream ID appears in a Context Association List of another Context packet.

I think I must be misunderstanding the rule, because it appears to outlaw the most obvious and common use of context association. For example, in Figure B-62, Context Stream 100 violates this rule. It is paired with Data Stream 100 ("Once paired with a Data Packet Stream") and it appears in the context association lists of streams 201 through 264 (violating "shall not be associated with other Context Packet Streams … such that its Stream ID appears in a Context Association List of another Context packet.").

Another example of the violation of the rule is found in figures 3.8.6-1 and 3.8.6-2. In these figures, context streams for DDC1 and DDC2 are paired with data streams for DDC1 and DDC2 (figure 3.8.6-1) and also appear in the source context association list for the adaptive combiner context packet stream (figure 3.8.6-2). Both these examples represent the kind of context association that seems most natural for the types of systems I work with: context that is paired with an upstream data stream shows up in context association lists of a downstream data stream that represents the data after it has undergone further processing. But Rule 10.1.2-2 says I'm not allowed to do that.  Why is it in the specification?

I have a project where we need some kind of Streaming and Control Package Format. It should possibly be a standard protocol and should work at high speed (from PC to target). Since we use a PC source which contains an Intel Processor (little endian format!) and we cannot afford to lose performance by converting to big endian data, we’ll have to use little endian payload. Can we do that using the standard data package format or will we have to define some own proprietary format using the extension data packages?

The VITA 49 standard calls for packets to be transmitted in big-endian byte order. This transmission order is consistent with other transport layers, such as TCP, UDP, and Real-Time Protocol (RTP). It may require software reordering of bytes or half-words on some systems to convert the packet to or from the format desirable for processing.

If we have to change the endianness at the Tx side manually, we would lose about 2/3 of our data throughput bandwidth for 10GbE. Are we the only customer using an Intel PC on the Tx side and who is not willing to slow down the Tx rate by getting the processor into a bulky endianness change? Isn't there a more applicable solution? (e.g. signaling to the receiver that he has to change parts of the protocol into big endian by himself – at least such layers where the Tx application cannot avoid little endian transmission)

You are not wrong. We have had the same problem and have chosen to implement little-endian transmission as an option in some of our FPGA implementations.  We document this as an “out-of-band” configuration option – in other words, it is not controllable or reportable within VITA 49.

If you are controlling both sides of the link then there is obviously no problem doing this.  If he is making a standard product that he expects to be received by a range of VITA 49 receiver implementations then he will have to figure out a way to send big-endian data if he wants the data that he sends to be understood. If his data is “at rest” in the PC then he can pre-process all of it before transmission.  If his data is being created by a piece of hardware in the PC then that hardware could potentially change the endian-ness – unless it can’t.

I have a question about the maximum size packet that can be used. The VITA standards limit the size to 65,535 words of 32-bit length. Below I copy the rule from the standard. That would be 262,140 bytes. But if this is used in an Internet Protocol (IP) packet for UDP using IPv4, the maximum packet is 65,535 bytes.  That would limit the packet to 16,383 words of 32-bit length. I see some reference to using IPv6 jumbograms to have UDP datagrams larger than 65,535 bytes.  Was that standard the assumption for the VITA 49.0 maximum? I would think that the VITA 49.0 packet maximum and UDP/IP packet maximum would be the same, because VITA 49.0/2 packets would most often be used inside UDP/IP packets. Is it possible that I am missing a correction that was published after the documentation that I have?

From VITA 49.0

Rule 6.1.6-1: The maximum number of data payload words shall be 2^16-1 minus the number of words required for the header and any optional fields (i.e. Stream ID, Class ID, Timestamps, and trailer).

Two part answer:

1. VITA 49 was designed to be agnostic to the communication protocol. In addition to Ethernet some have used it with  Aurora, S-FPDP and other protocols.
2. In the design of the header there was some trade-offs on maximizing efficiency and number of bits in header that need to be used for other items and reserved.