Piccola presentazioni sulla mia tesi, quello che ho fatto e quello che farò

1. IP – FLOW
IP FLows over Optical and Wireless
FL
Milan testbed – Politecnico di Milano
Milano - Fri. 18 may 2007
Università degli studi di Trento Politecnico di Torino

2. Introduction - The need of QoS
IP-FLOW project
Nowadays the need of real-time sessions is growing more and more.
The current data network are divided in two categories:
• Circuit – switched
Well suited for transporting CBR real-time traffic. They may be
highly inefficient for carrying bursty data traffic.
• Packet – switched
Designed for high resource utilization exploiting the
statistical-multiplexing capability.
Trade off between efficiency and capacity
Politecnico di Milano
01 Dipartimento di Elettronica ed Informazione

3. How it works - properties
IP-FLOW project
TDP: Time Driven Priority
The TDP packet – scheduling technique combines the statistical
multiplexing and the predictability. How does it works?
It gives higher priority to real time traffic in a periodic fashion, only to
packets arrived in the previous time interval.
It leads to these properties:
• Bounded delay
• Constant bound on the jitter
• Deterministic loss-free
And all these properties are guaranteed even if there is a congestion
inside the network and de-allocating reserved resources when it isn’t
necessary.
Politecnico di Milano
02 Dipartimento di Elettronica ed Informazione

4. How it works - principles
IP-FLOW project
All the TDP network elements must be synchronized (ex. with a
common reference like GPS) in order to switch the packets
correctly.
The global time is divided in Time Frame (TF), usually derived as a
fraction of UTC. A certain number of TF is grouped in Time Cycle
(TC).
TFs are partially or totally reserved during the resource reservation
procedure.
TFs are also used for implementing switching time-based.
Politecnico di Milano
03 Dipartimento di Elettronica ed Informazione

5. How it works - principles
IP-FLOW project
Periodic Forwarding
The basic TDP operation is regulated by two simple rules:
I. All packets that must be sent in TF t by a node must be in its
output ports’ buffers by the end of TF t-1
II. A packet p transmitted in TF t by a node n must be transmitted in
TF t + dp by node n+1, where dp is an integer constant called
forwarding delay that must be large enough to satisfy (1)
Best effort traffic can be transmitted during any unused portion of a
TF.
Politecnico di Milano
04 Dipartimento di Elettronica ed Informazione

6. How it works - network elements – TDP Router
IP-FLOW project
In a real network not any element could be synchronized with a
common reference time.
We need some devices that can interface the synchronized TDP
network with the asynchronous world, this device is the TDP Router.
No signaling protocol implemented, at the moment, between any TDP
Router.
The implementation needs:
• Ethernet NICs, optical and CAT-5
• GPS - Symmetricomm PCI card that generates an interrupt
every n us (n could be ≈ 125-250 us) in order to divide the TFs
Politecnico di Milano
05 Dipartimento di Elettronica ed Informazione

7. How it works - network elements – TDP Router
IP-FLOW project
Router Input Processing
Each router must know in which TF is the incoming packet. This
could be achieved in different ways:
I. Attaching a sort of timestamp to each packet
II. Including a TF delimiter
III. Precisely measuring propagation delay and arrival time
Router Output Processing
Considering d as the maximum forwarding delay (in TFs) there are
nbuf = d + 1 queues at each output interface, each having capacity Tf x
C, where Tf is the TF duration.
Pakets arriving at the output interface are enqueued in a buffer
determined as a function of forwarding TF (TFout), current TF (TFcurr),
the number of TFs per TC (nTF) and the buffer currently in use (bufcurr)
The buffers are simply FIFO queues.
Politecnico di Milano
06 Dipartimento di Elettronica ed Informazione

8. How it works - network elements – TDP Switch
IP-FLOW project
Another network element is the TDP Switch (TDS) that is also
synchronized as the TDP Router.
The functionality of the switch is simple.
It’s a time-division commutating matrix.
In the testbed is implemented as an optic / electric switch, that
change is matrix depending on the current TF
Politecnico di Milano
07 Dipartimento di Elettronica ed Informazione

9. Milan Testbed
IP-FLOW project
The testbed is at the Lambrate laboratory:
Politecnico di Milano
08 Dipartimento di Elettronica ed Informazione

10. Milan Testbed – Local Area Tests (LAT)
IP-FLOW project
Till now the studies about the IP-FLOW project were only theoretical
without any practical application in the real world.
So the next step was to make real what was only theory, the born of
the Milan test bed.
We decided some local test in order to prove the implementation
issues of this system.
The local environment is necessary to prove the system in the ideal
condition: no jitter, no packet loss, short propagation delay and high
bit-rate capacity
Politecnico di Milano
09 Dipartimento di Elettronica ed Informazione

11. Milan Testbed – Local Area Tests (LAT)
IP-FLOW project
twelve Local Area test to implement
Name depend
A Single Loop -
B Single Destination -
C Loop + Different Destination A-B
D Fork A-B
E Fork + 1_Loop D-C
F Source + Destination B
G Source + Destination + 1_Loop C
H Source + Destination + Back_Loop D
I Source + Destination + Forward_Loop E
J Source + Double Destination H
K Src + Double Dest + 1_Loop (after Fork) H-E
L Src + Double Dest + 1_Loop (befor Fork) H-E
Politecnico di Milano
10 Dipartimento di Elettronica ed Informazione

12. Milan Testbed – Wide Area Tests (WAT)
IP-FLOW project
Another type of test must be the so called Wide Area Tests.
These tests are oriented to prove the system connecting the three
local testbeds (Trento, Torino and Milano) through the Internet
network
WAT has different aims:
• Test the system with the maximum possible jitter.
• The Interconnection of the common asynchronous network to
the IP-FLOW (synchronous) system.
• Test the system in the case of very huge delay.
Politecnico di Milano
11 Dipartimento di Elettronica ed Informazione

13. Milan Testbed – Wide Area Tests (WAT)
IP-FLOW project
Nowadays we had some test only to prove the configuration of the
routers and to test the interconnectivity of the three testbeds through
the establishment of VPN.
No TDP Switch were used in order
to simplify the WAT tests.
Problems found:
• Configuration
• Sending of TF delimiter the
now needs to use virtual IF
• Synchronization between TDP
Routers.
Politecnico di Milano
12 Dipartimento di Elettronica ed Informazione

14. Milan Testbed – Wide Area Tests (WAT)
IP-FLOW project
Nowadays we implemented four WAT tests:
Session Aim Results
Multimedia session TN to MI Test the first WAT Not good: wireshark
configuration analysis: BAD UDP LENGTH
28 feb 2007
1324 (later we discovered
that gif1 and gif2 had mtu at
1350).
Multimedia session MI to TO First test with two TDP TDPs not working when both
Router synchronized syn.
01 mar 2007
Delimgen unavailable
because of the use of virtual
interfaces.
Synchronization MI and TO Use of new Delimigen The two TDP were
synchronized but no traffic
22 mar 2007
flow initialized.
Multimedia session TO to MI Multimedia session with two Packets trunk by the virtual
TDP synchronized Interface in Milan.
29 mar 2007
Politecnico di Milano
13 Dipartimento di Elettronica ed Informazione

15. Milan Testbed – Wide Area Tests (WAT)
IP-FLOW project
Next step: Introducing TDP Switch
Problems of introducing TDP Switch:
• We have more complex topology of the network
• Different problems due to the propagation of delimiter packets
throughout the switch: we cannot use null packets in order to
maintain synchronized the TDP Routers.
• Multiple destinations allowed and enhanced switching
required in order to implement the more complex networks
Politecnico di Milano
14 Dipartimento di Elettronica ed Informazione

16. Critical issues
IP-FLOW project
Doing the implementation of the IP-FLOW system some critical issues
appears:
• Problems in Delimiters receiving
• Efficiency of mono-processor PC
• Signaling protocol
• Synchronization to the reference time
Of course, the major problem is the last one. GPS-based
synchronization is a point of weakness:
• Need of a system for receiving the GPS signal (antenna + card)
• Dependency from the GPS system
Politecnico di Milano
15 Dipartimento di Elettronica ed Informazione

17. Synchronization Issues
IP-FLOW project
Another fact is that we don’t need to know the perfect time in every
moment.
It’s only necessary that the difference of phase between the clocks of
the network elements remains constant.
it could be interesting to use a local clock that generates interrupts
every n usec. With a PLL (software) device that can adjust it.
The local clock shouldn’t be the PC clock because it’s difficult to
generate interrupts in sw mode, it’s surely simpler generating them
with an hardware PCI card or similar.
Next Step: It’s to evaluate synchronization errors
Politecnico di Milano
16 Dipartimento di Elettronica ed Informazione

18. Synchronization Issues
IP-FLOW project
The evaluation of synchronization errors can be done in different
ways:
• Through a theoretical analysis and models.
• Simulation tool written using Omnetpp libraries.
• Experiments on the real system.
I found three aim for this issue:
• How synchronization errors can affect the system.
• Which is the maximum jitter allowed in the syn network.
• How to design a new Common Time Reference Network-
distribution.
a) Externally distributed reference
b) Network-distributed
Politecnico di Milano
17 Dipartimento di Elettronica ed Informazione

19. Synchronization Issues – The Simulator
IP-FLOW project
Simulating the real network is essential in understanding the
functionality of the system.
The simulator is designed in order to
have a simple way to introduce
statistical error in the common
(simulated) time reference.
A node represent the GPS device the
distributes the reference.
In the ideal case the syn message reaches all the TDP Router at the
same simulated time.
We can add statistical phase delay simply changing the sending time of
the syn message or the propagation delay of the syn link.
Politecnico di Milano
18 Dipartimento di Elettronica ed Informazione

20. Synchronization Issues – The Simulator
IP-FLOW project
Next steps for the Simulator:
• Finding the network topology we want to simulate.
• Understanding what happens if the TF are not aligned: some
documents say that at the current TF the buffer used is
completely flushed and the incoming packets must be queued
to the next reserved buffer available (at maximum the time-
delay is one TC).
• Implementing the synchronization error delays in the
simulated network.
• Evaluating the effects of synchronization in the network
throughput.
• Evaluating the maximum jitter allowed.
Politecnico di Milano
19 Dipartimento di Elettronica ed Informazione

21. Summary
IP-FLOW project
What is done:
• Study of the system IP-FLOW
• Implementing the testbed in Milan
• First phase of WAT tests
• First release of the TDP simultator
Which are the next steps:
• LAT tests
• Second step of WAT tests:
• Introducing the switch
• Different topology and routing
• Multiple clients and server media flow during each test
• Study about the introduction of synchronization errors
• Simulation of synchronization errors
• Implementation of a sustainable network-based
synchronization system
Politecnico di Milano
20 Dipartimento di Elettronica ed Informazione

22. References
IP-FLOW project
References:
• http://dit.unitn.it/ip-flow/index.html Project Website
• http://netgroup.polito.it/TDP/ FreeBSD TDP kernel sources
Politecnico di Milano
21 Dipartimento di Elettronica ed Informazione