User guide

 




28
Appendix C
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Innity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-Specic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.