CTM Solutions

Voici enfin un document (en Anglais) résumant la position d' Avid face à l'activation ou non du firewall sur des workgroups basés sur Avid ISIS et/ou Avid Interplay :

1.0 Overview

Many people ask the question about which firewalls are recommended or qualified for use with ISIS. The short answer is NONE, this is an issue to do with ISIS and not Interplay.

NONE is a bit blunt for most customers so we have to help them understand why.

To the authors knowledge there are no customer successfully using a firewall for ISIS traffic. There are some who have tried and failed, and other tat are trying alternative products. Also alternative approaches such as mezzanine networks of the Avid Product Border switch, either direct or via MPLS tunnels.

1.2 Next understand Latency

ISIS client applications are latency sensitive. An editing application needs to be responsive, ISIS was designed for high speed LAN environment. When latency gets to 5ms it becomes noticeable, at 10ms it become intrusive, and at 20ms it is unpleasant to use

Some testing with NewsCutter has been done previously as part of a different products but this was based on Gigabit Ethernet MAN connection.

*Given that the speed of light constant in a vacuum, 'c' is exactly 299,792,458 metres per second, the figure of 1 millisecond per 300km might be an accurate estimate for the purpose of latency calculation over distance However, propagation speed in media is significantly lower than c, for glass roughly 1/2 - 2/3 of light speed in vacuum, depending on the refraction index of the media., so a figure of 1 millisecond per 200km is more appropriate .

Based on the tests performed with A NewsCutter editing client date 5ms is an acceptable latency; this translates to a distance of a connection of approx. 1000-1500km* where it would be acceptable to the operator.

1.3 Firewall process

When a firewall encounters a fragmented packet it wants to re-assemble all the fragments into a complete datagram and inspect the content from the inbound interface, when it is satisfied this is not a threat it will send the content via the outbound interface.

The first challenge for the firewall is to assemble the datagram which will be 256KB in size, this is approx 2mS on the wire, then it has to process is, then if satisfied it has to re-fragment and send on its way, so that is another 2ms, so lets call this 5ms of additional latency

The second challenge for the firewall is to re-fragment datagram in exactly the same way, which it should do under normal circumstances.

Add to this the quantity of 256 burst per second per client, which is dependant on video resolution. DV 25 = approx 4MB/S do that is 16 x 256KB bursts per second DV 50 = approx 8MB/S do that is 32 x 256KB Burst per second MPEG II Browse uncompressed audio is approx 1MB/S do that is 4 x 256KB bursts per second

Then multiply that by the number of clients, so 10 clients need 2.5MB of high speed memory available to the firewall, remember to process at high speed this need to be executed in hard ware not software which would add huge amounts of latency.

This becomes an onerous task for most firewalls so the general recommendation is not to firewall ISIS video traffic. I.E. set up rules to exclude the ISIS traffic based on four criteria:

• ISIS source networks
• Client destination network
• UDP
• Ports 4000-4399 up to ISIS V1.3
• Ports 4200 – 4599 ISIS V1.4 onward

But firewall everything else!

But this may not work for all firewalls because even when rules for exclusion are set, the firmware in the firewall device may still complain about the number of fragments and identify this is a risk, or even continue to clock the traffic.

Another challenge is for the firewall to re-fragment in the right order, some testing proved that with a load on 1-2 clients the firewall under test could cope, but when this was increased to 10 clients the firewall under test began to change the way it applied fragmentation outgoing stream from ISIS toward the client and send packet out of order, hence corrupting the data!

Note - The port numbers for data transfer between client and ISB as well as those for incoming message traffic from the index server or ISB's are all chosen from the range 4000-4399 on a dynamic basis. That is, not all 400 ports are in use at any time, but the ports in use will vary over time over this entire range. The wide range of ports (400 UDP ports) is used by ISIS as a tracking mechanism of the UDP segments that are exchanged between the ISIS server blade and the ISIS client.

"Note -The reason for port number changes in ISIS 1.4 refers to a conflict between Interplay requirements and ISIS. The Interplay AIF Lookup Service, the LUS (Jini/Apache River) uses port 4160 for its discovery mechanism

Prior to version 1.4 the ISIS client cycled through ports 4000 - 4400 by default even though it has only a handful of these ports open at once, it pokes holes in the firewall for all of them at boot time. Since 4160 is required for Jini then the ISIS team had to make a decision to move the ISIS ports to 4200 - 4599 to avoid any conflict."

1.5 What ports are used?

The TCP and UDP ports used but ISIS, Interplay and WG4 are available from

http://www.avid.com/onlineSupport/supportcontent.asp?contentID=8269

Partager cette page