41
INST
ALLA
TION
CONFIGURA
TION
OPERA
TION
fur
ther
inform
A
tion
INDEX
APPendiX e -
Glossary
Internet Group Management Protocol
Where an ALIF transmitter is required to stream video to
two or more receivers, multicasting is the method used.
Multicasting involves the delivery of identical data to
multiple receivers simultaneously without the need to
maintain individual links. When multicast data packets enter
a subnet, the natural reaction of the switches that bind
all the hosts together within the subnet, is to spread the
multicast data to all of their ports. This is referred to as
Multicast flooding and means that the hosts (or at least
their network interfaces) are required to process plenty of
data that they didn’t request. IGMP offers a partial solution.
The Internet Group Management Protocol (IGMP) is
designed to prevent multicast flooding by allowing
Layer
3
switches to check whether host computers within
their care are interested in receiving particular multicast
transmissions. They can then direct multicast data only to
those points that require it and can shut off a multicast
stream if the subnet has no recipients.
There are currently three IGMP versions: 1, 2 and 3, with
each version building upon the capabilities of the previous
one:
• IGMPv1 allows host computers to opt into a multicast
transmission using a Join Group message, it is then
incumbent on the router to discover when they no
longer wish to receive; this is achieved by polling them
(see IGMP Querier below) until they no longer respond.
• IGMPv2 includes the means for hosts to opt out as well
as in, using a Leave Group message.
• IGMPv3 encompasses the abilities of versions 1 and 2
but also adds the ability for hosts to specify particular
sources of multicast data.
AdderLink Infinity units make use of IGMPv2 when
performing multicasts to ensure that no unnecessary
congestion is caused.
igmP
Snooping
The IGMP messages are effective but only operate at
layer 2
- intended for routers to determine whether
multicast data should enter a subnet. A relatively recent
development has taken place within the switches that
glue together all of the hosts within each subnet: IGMP
Snooping. IGMP snooping means these layer 2 devices now
have the ability to take a peek at the IGMP messages. As a
result, the switches can then determine exactly which of
their own hosts have requested to receive a multicast –
and only pass on multicast data to those hosts.
igmP
Querier
When IGMP is used, each subnet requires one
Layer 3
switch to act as a Querier. In this lead role, the switch
periodically sends out IGMP Query messages and in
response all hosts report which multicast streams they
wish to receive. The Querier device and all snooping Layer
2 switches, then update their lists accordingly (the lists are
also updated when Join Group and Leave Group (IGMPv2)
messages are received).
igmP
Fast-Leave (aka Immediate Leave)
When a device/host no longer wishes to receive a
multicast transmission, it can issue an IGMP Leave Group
message as mentioned above. This causes the switch to
issue an IGMP Group-Specific Query message on the port
(that the Leave Group was received on) to check no other
receivers exist on that connection that wish to remain a
part of the multicast. This process has a cost in terms of
switch processor activity and time.
Where ALIF units are connected directly to the switch
(with no other devices on the same port) then enabling
IGMP Fast-Leave mode means that switches can
immediately remove receivers without going through
a full checking procedure. Where multiple units are
regularly joining and leaving multicasts, this can speed up
performance considerably.
Jumbo frames (Jumbo packets)
Since its commercial introduction in 1980, the Ethernet
standard has been successfully extended and adapted to
keep pace with the ever improving capabilities of computer
systems. The achievable data rates, for instance, have risen
in ten-fold leaps from the original 10Mbit/s to a current
maximum of 100Gbit/s.
While data speeds have increased massively, the standard
defining the number of bytes (known as the Payload)
placed into each data packet has remained resolutely stuck
at its original level of 1500 bytes. This standard was set
during the original speed era (10Mbits/s) and offered the
best compromise at that speed between the time taken to
process each packet and the time required to resend faulty
packets due to transmission errors.
But now networks are much faster and files/data streams
are much larger; so time for a change? Unfortunately, a
wholesale change to the packet size is not straightforward
as it is a fundamental standard and changing it would mean
a loss of backward compatibility with older systems.
Larger payload options have been around for a while,
however, they have often been vendor specific and at
present they remain outside the official standard. There
is, however, increased consensus on an optional ‘Jumbo’
payload size of 9000 bytes and this is fully supported by
the AdderLink Infinity (ALIF) units.
Jumbo frames (or Jumbo packets) offer advantages for
ALIF units when transmitting certain high resolution video
signals across a network. This is because the increased data
in each packet reduces the number of packets that need to
be transferred and dealt with - thus reducing latency times.
The main problem is that for jumbo frames to be possible
on a network, all of the devices on the network must
support them.