VLBI Standard Interface – Electronic
(VSI-E)
Protocol Fundamentals
Chet Ruszczyk
MIT Haystack Observatory
Agenda
•
•
•
•
•
•
•
•
•
•
VLBI Standard Interface (VSI) – Why?
VSI’s Model
VSI-E’s Primary Objective
VSI-E’s Goals
RTP Summary
RTP Extensions for e-VLBI
Open Source Linux Libraries
SC05: Kashima – Haystack using VSI-E
Documentation
Conclusion
VLBI Standard Interface (VSI)
• VSI defines
– A standard interface to and from a VLBI Data
Transmission System (DTS)
– Allows heterogeneous DTS’s to be interfaced to both
data-acquisition and correlator systems with a
minimum of effort.
• VSI is defined to be compatible with:
– tradition recording/playback systems,
– network data transmission, and
– direct-connect systems.
VSI (Cont)
• VSI is designed to:
– Hides the detailed characteristics of the DTS
– Allows the data to be transferred from
acquisition to correlator
• in transparent manner
– Relieve existing incompatibilities
• between various VLBI data systems.
VSI (cont)
• Three VSI specifications developed
– VSI-Hardware
– VSI-Software
– VSI-Electronic
• VSI-H defines the electrical and interfaces
– To / from a DTS
– Also specifies a control philosophy.
VSI (cont)
• VSI-S defines the software component of
the VSI-H specification
– Specifies communications protocol,
– Control a VSI-H-compliant DTS.
• VSI-H and VSI-S explicitly refrain from
– specifying the format of data
• from the Data Input Module (DIM)
• to the Data Output Module (DOM).
VSI (cont)
• VSI-E primary objective
– A media independent data format
• Transmitted “on the wire”
– from source to destination
» DIM to DOM
– Is compatible between heterogeneous DTSs
VSI’s Model
VSI-E
•
Goals
–
–
–
–
–
Efficient transport mechanism
Standard protocols
Internet-friendly transport
Scalable Implementation
Ability to transport individual data-channel streams
as individual packet streams
– Ability to make use of multicasting to transport data
and/or control information in an efficient manner
• could be used in the future for support of distributed
correlation
Network Topologies
VSI-E (cont)
• The following assumptions were made in the
development of the VSI-E specification:
– The DTS is compliant with the VSI-H specification
– All active bit streams, associated relevant parameters must be
derivable from the information arriving at the DOM, in particular:
•
•
•
•
•
•
•
Primary data stream (i.e. active bit-stream data)
Active bit-stream mask
DOT time-tagging
Bit-stream information rate (BSIR)
Valid-data indicator
TVG-data indicator
PDATA messages
– Underlying network structure is IP-based
VSI-E (cont)
•
Critical Definitions:
–
–
–
A channel is an exclusive subset of 2n of the active
bit streams. The intent of the channel abstraction is
that it carry the digitized data from a single analog
data source.
A channel sample is 2n bits collected from a single
‘channel’ on a single DIM CLOCK cycle. The DIM
collects channel samples at the Bit-Stream
Information Rate (BSIR).
A channel stream is a contiguous set of channel
samples collected over some period of time.
VSI-E Proposal
• Real-time Transport Protocol (RTP) / RTP
Control Protocol (RTCP)
– Proposed as the basis for the VSI-E Standard
– IETF Standards RFC3550, RFC3551,
RFC3605
RTP Philosophy
• Build a mechanism for robust, real-time
media delivery above an unreliable and
unpredictable transport layer
• Without changing the transport layer
VSI-E Proposal (cont)
• Why RTP/RTCP
–
–
–
–
–
–
–
–
RTP is the standard for real-time transport over IP
Transmission of sampled analog data
Dissemination of session information
Monitoring of network and end system performance
(by participants and third parties)
Adaptation to varying network capability /
performance
Appropriate reliability / repair model
Message Sequencing / un-reordering
Multi-cast distribution of statistics, control and data
RTP Summary
• A wealth of implementation and operational experience
• Seen as internet-friendly by the network community
– RTP pays attention to:
• efficiency
• resource constraints,
• scaling issues.
• Framework for transporting real-time data
– Transport layer independent
• Timing and synchronization
• Merging, bridging, and translation support
• Application-specific control data
– e.g. PDATA, time, data collection parameters, antenna pointing,
system temperature
Protocol Components
RTP Extensions for e-VLBI
• RTP Profile for e-VLBI
– defines the structure and semantics of the RTP
packets used to transport VLBI data.
• Six packet types
–
–
–
–
–
–
RTP Data Packet
RTCP Sender Report Packet
RTCP Receiver Report Packet
RTCP Source DEScription Packet
RTCP BYE Packet
Application Defined RTCP Packet
RTP Data Packet
• Used to encapsulate and
transport e-VLBI data.
• Payload type (PT)
– # bits per channel sample
•
•
•
•
Sequence number
RTP timestamp
Source identifier
Data Payload
– data samples
Data Payload
• Channel-stream encapsulated
into an integer number of 32bit words in format.
• DIM input => 32 individual bit
streams
• A subset of 2n is chosen to be
‘active bit streams’.
• The ‘active bit streams’ are
further subdivided into some
number of mutually exclusive
channels
• each sample of which is a
channel sample
• A sequential set of channel
samples from a single channel
is encapsulated into each RTP
RTCP Sender Report Packet
• Provides 3 functions:
– Transmission statistics
– Defines the relationship
between UT and RTP
packet sequence
number.
– Reception statistics for
all of the sources that
have sent packets to this
source since the time of
the last Sender Report
RTCP Receiver Report
• Informs other session
members of the quality of
their reception
• Statistics:
– Fraction of packets lost
– Cumulative number of
packets lost
– Approximation of the interarrival jitter for RTP data
packets
• received at the receiver
from a particular source
RTCP Source DEScription Packet (SDES)
• Describes the source of a
particular packet stream
– CNAME: Canonical endpoint
Name Identifier.
– NAME: User Name
– EMAIL: contact person.
– PHONE: contact person.
– LOC: Geographical Location
– TOOL: Application generating the
stream.
– NOTE: Notice/Status SDES item.
Transient packets describing the
state of the source during a
session.
– PRIV: A mechanism to enable
users to define application specific
SDES packets
RTCP-SDES Priv Extensions
• Add VLBI specific extensions to the
SDES packet.
• Four additional message types are
added, identified by their prefix string
– Evlbi-abm: Active Bitstream Mask
• indicates which bits in a channel
stream are active.
– Evlbi-cid: Channel Identifier
• which channel was the source of this
stream of samples.
– Evlbi-sfr: Sampling FRequency
• sampling frequency of the channel
samples.
– Evlbi-spp: Samples Per Packet
• how many channel samples are
contained in a single RTP data packet.
– Evlbi-tsf: Timestamp Scaling Factor
• Communicate the Timestamp Scaling
Factor
RTCP Bye Packet
• Indicates
– A source is leaving a
session and is no longer
active.
• It is distributed to all
session participants
– to allow them to update
their internal tables
appropriately.
• Allows session
participants to track the
number of active sources
– Important for the
calculation of RTCP
bandwidth.
RTCP Application Defined Packet
• Communicates other
VLBI control
information between
DIMs/DOMs
– subtype of (1)
• the PDATA packet.
RTP Open Source Libraries
• Libraries (RTP / RTCP extensions for e-VLBI)
– Vsocket
– Application – VLBI Transport Protocol (vtp)
• Libraries (RTP-only and H.323)
–
–
–
–
–
–
–
–
–
–
–
–
ccRTP
Bell Labs/Columbia/UMass library
EDM Media over IP libray
JVOIPLIB
Java Media Framework (JMF)
jrtplib
LIVE.COM Streaming Media
NetLab Java library
RADVision H.323
WebCanal
UCL RTP library
Vovida
RTP Tools
• Tools
– MultiMON
• a monitor that collects, organises and displays all the IP
multicast traffic that is detected at the location of the
MultiMON Server
– Rtpdump
• display, decode and generate RTP packet
– Rtpmon
• Monitors RTP transmissions by displaying RTCP
– rtpplay
• Play back RTP packet stream recorded with rtpdump.
– rtpsend
• Send RTP packet stream with configurable parameters.
– RTP MIB
• Real-Time Transport Protocol Management Information Base
Documentation
•
•
•
•
•
VSI-H:
VSI-S:
VSI-E:
RTP – RFC3550
RTCP – RFC3605
SC05: VSI-E Experiment
• During SC05 Issues:
– Onsala, Jodrell Bank, Westerbork
• Jumbo Frame Support
– Kashima
• Lack of jumbo frame support
• RTT made TCP not feasible
• UDP was the only option
– Data format miss-match
• K5 – M4 data format
– Deployed VSI-E between Kashima – Haystack
SC05 - Kashima-Haystack
• Local Network – TCP
• Long haul network – VSI-E
• Results
– Sustained 540Mbps during show
– 8% packet loss
– Failed to incorporate the data in correlation process
Conclusion
• VSI-E
– A media independent data format
• Transmitted “on the wire”
–
–
–
–
–
–
Is compatible between heterogeneous DTSs
Efficient transport mechanism
Using Standard protocols
Internet-friendly transport
Scalable Implementation
Ability to transport individual data-channel streams as
individual packet streams
– Multicasting to transport data and/or control
information in an efficient manner