Minutes of the 4th TF-NGN meeting 18-19 June 2001 University of Tromsø, Tromsø, Norway

Valentino Cavalli, John Dyer, Issue 1
 

Table of Contents

•  Attendees
•  Apologies
• 1. The Status of the GÉANT Procurement
• 2. Premium IP service
• 3. Over-provisioned network performance analysis
• 4. Towards the specification of an IP+ service
• 5. Available testbeds
• 6. IPv6
• 7. Optical Networking
• 8. Juniper R&E specific programme
• 9. MPLS testing on PlaGE
• 10. Measurement
• 11. Improved Multicast
• 12. Review of Geant Technical roadmap
• 13. Date of Next Meeting
• 14. Any other business
• 15. Actions from last meeting
• 16. Open actions

Attendees

Apologies

Online presentations: http://www.terena.nl/task-forces/tf-ngn/presentations4.html
 

1. The Status of the GÉANT Procurement,

Howard reported that DANTE haven't yet got to the end of the procurement process, although they are close. DANTE have selected three suppliers that will share the GEANT topology and made a recommendation to the Policy Committee, which endorsed the decisions. DANTE are now in the process of agreeing the fine detail of the contracts with the chosen network suppliers. There are some issues regarding the exact locations of some of the POPs in central Europe that need to be resolved. On the commercial side, the DANTE board asked DANTE to harden the clauses regarding the future competitiveness of the prices. Howard went on to say that DANTE expect connections to be installed by September this year.

DANTE are negotiating to provide a single Network Operations Centre (NOC) for all services on GEANT but some of the details are dependent on connectivity decisions still to be reached. It is expected that the chosen provider of the NOC will begin work in August 2001, So as to be part of the standard operation of the Geant circuits as and when they become avaialble and to assist in the migration from TEN-155 to Geant. DANTE have been deeply involved in the router procurement over the last few weeks, using the standard European procurement procedures. Sixteen expressions of interest were received resulting in four solid tenders. The tender called for the supply, delivery, installation and configuration of the equipment. The evaluation criteria will include the total cost of ownership over a three-year period, including software maintenance support and upgrade. It is expected that the delivery of the equipment will take place in August 2001.
 

2. Premium IP service

Mauro began his presentation on the IP Premium Service by mentioning the basic principle of avoiding heavy control and minimizing the number of actions undertaken on the data-stream. Mauro explained that in making decisions regarding the definition of premium service, a number of assumptions have to be made:

• 1. When using DiffServ, micro-flows are not policed individually, but are aggregated and policed together.
• 2. As much of the processing as possible should be carried out close to the end-points (preferably on the PC NIC) and as little as possible should be undertaken in the DiffServ core. It was recognized that some NRENs might no agree with DiffServ parameters being set on distant networks.
• 3. The sending host is expected to shape traffic. The expectation is that at least initially, the core network will be effectively over-provisioned and thus no additional shaping will be needed in the core.
• 4. The network is not responsible for the fair sharing of premium capacity between the micro-flows.
• 5. Filter EF traffic at the boarder, do not shape in the core network. Dimitrios and Wilfried raised a discussion leading to the need for clarification on the user requirements. Mauro said that they have been studied by SEQUIN, the deliverble should be made available to the group

• 6. Policing will be performed by means of a token bucket.
• 7. Admission to the IP Premium Service will be based on the Internet address pair for source and destination addresses. The packets will be policed according to the agreed capacity.
• 8. There will be no policing and shaping at the egress from the domain. Application of the above points should ensure that egress IP Premium traffic would not exceed a pre-determined safety value.
• 9. A common marking scheme across DiffServ domains is not essential, although uniformity is strongly recommended.
• 10. In the case of an end-to-end connection between domains the inter-domain link is required to behave according to the EF-PHB.
• 11.  The IP Premium service is aimed at providing end-to-end QoS.

In order to implement a premium IP service the following elements will be needed:

• A detailed specification of the monitoring system (which will be dependent on what parameters are going to be used). It was agreed that Simon and Victor would work on this specification.

• Draft SLA/SLS specifying the necessary procedures. This is still an open action item, but it was agreed that initially the experimental work could start based on MBS, which could subsequently be modified.
• A translation of the parameters into a practical router configuration. This will come out of the experimental work.
• More experimental data from traffic shaping to better understand how to implement and manage such a service. Tiziana's group has been producing data from CISCO 7000 series routers. This work will now need to be repeated on the candidate GÉANT routers on the testbed networks available to TF-NGN.

Mauro opened a general discussion on the issues of traffic shaping, which resulted in some disagreement on whether it should take place in the core of the network. It was agreed that the discussion on this topic should be continued on the TF-NGN email distribution list. Victor Reijs thought that the mechanism by which end users can obtain bandwidth should be explicitly addressed.

ACTION Mauro to continue the discussion about the issues of traffic shaping on the TF-NGN email distribution list.

Wilfred Woeber suggested that the Task Force should take a tactical approach to the work item description. In particular, the issue he had in mind is his local situation in which ATM will remain in service for some months. Mauro suggested that using the ATM for the first hop would be a great way of offering an EF policed stream.

ACTION Mauro to take into account comments from people doing experimental work on shaping in his draft report to be distributed in 2-3 weeks to the email distribution list.
 
 

3. Over-provisioned network performance analysis

Dimitrios reported that he could not yet find an exact definition of over provisioning, although he had some useful discussions at Antalya. The rough consensus seems that if one works with a network that is 10% or less loaded on core links, then that could be considered over-provisioned. The only jitter related delays with this level of loading would be related to processing delay of the routers. It was agreed that experimentation should take place on the core.

It was agreed that there is a need for some good instrumentation with the capability of synchronized packet generation of at least 1 Gbps, probably using a hardware-generating platform. It was noted that although a Linux PC could probably generate 900 Mbps of outgoing traffic, reading at this speed would be unlikely. The issue of synchronization of time stamps could be difficult as Dimitrios stated the resolution requirement to be of the order of microseconds. In previous tests distributed NTP was capable of only 10-20 milliseconds. Tiziana expressed her concern that using traffic generators can only mimic user traffic and can never exactly reproduce the effects of real applications running in a production environment and suggested that the only way of getting true results is to experiment on a production core.

Dimitrios proposed two experiments to be carried out stepwise :

1. Measuring and empty network with one flow, measuring packet loss as a function of network load, delay and jitter
2. Background noise measuring one flow plus production like traffic, measuring delay and jitter

ACTION GARR and GRnet to start performing the baseline tests.
 
 

4. Towards the specification of an IP+ service

Octavio discussed the potential problems of using AF and TCP together, focusing on how can the Quality of Service of TCP flows be increased by using AF. He went on to explain that even if the SLS is defined at the aggregate level, the improvement in QoS should be seen on each of the individual micro-flows. ENST have undertaken simulations running 24 TCP flows concurrently with 8 UDP flows. They tested several different marking strategies using first same parameters for both UDP and TCP, but later giving the TCP higher values in a system where the source and destination where connected by a 10Mbps bottleneck link.

The simulations show that if the UDP packets and TCP packets are marked equally then the UDP flows can achieve rates nearly as high as the source-sending rate. Only when the TCP packets are marked 35% higher do the UDP and TCP packets fairly share the bottleneck link (with a higher proportion of the UDP packets being dropped).

Octavio reported that in looking at the effects of RTT marking with the same parameters does NOT assure the same bandwidth for all TCP flows. Throughput depends on the RTT and in the case of an AF link the utilization is penalized with a drop down to 68%.   There was some discussion on the validity of this experiment. It was explained that the performance changes seen are the inherent behavior of TCP rather than any problem that could be fixed by adjusting parameters.

There had been further simulations undertaken looking at flow aggregation in which micro-flows are aggregated and then remarked as single flow. The marking performed well resulting in a similar TCP flow throughput to that of UDP flows, demonstrating that generally there is fairness amongst the aggregates. Mauro suggested it would also be useful to include information on the packet losses.

ACTION Octavio to provide charts about packet loss.

The list of work completed so far includes:

1. Calibration of CISCO WRED
2. Testing of Juniper AF capabilities
3. Bandwidth sharing amongst UDP flows

ACTION Simon discuss his ideas about limitation and restriction in the use of AF.
 
 

5. Available testbeds

Atrium is a testbed of terabit IP routers running MPLS over DWDM, which started on 1 January 2001 and will be running for 30 months until June 2003. The major objective of ATRIUM is to develop an advanced testbed for experiments and provide a validation platform for the Advanced Terabit Router (ATR) the A7770 RCP. The project will look at:

• Installation and Integration issues,
• Test and evaluate MPLS in a DiffServ Autonomous System,
• Research Intra domain issues,
• Research Inter domain issues.

Currently, access can only be gained by coming to one of the ATRIUM laboratories and working there. In future it will be possible to interconnect other networks. Plans are to connect France Telecom R&D VTHD testbed in month seven. In month 19 ATRIUM plans to be interconnected to Renater, Belnet and perhaps GEANT. Discussions are taking place with island testbeds in Italy, Greece, Hungary and Poland. ATRIUM is very interested in proposals from TF-NGN for further interconnections and experiments.

ACTION Wim Barbaix to collect proposals from TF-NGN for further interconnections and experiments with ATRIUM.

PlaGE Testbed - Alain Bidaud

PlaGE (Plate-forme Gigabit Expérimentale) is currently running in a laboratory in Paris with plans to deploy in POPs at the beginning of July 2001 using routers with Engine2 cards. TF-NGN was told that access to the testbed is possible.

Graça from CISCO stressed the importance of using the same levels of hardware/software on the experimental equipment as will be deployed in the production network. If this is not done, the experimental results may not reflect the production performance. PlaGE personnel agreed to send a description of their situation and requirements to Graça so she can resolve any problem hardware/software level problems they may have.

ACTION Alain and Mauro to follow up with Graça about hardware/software requirements in setting up the PlaGE and Garr-G testbeds.

PlaGE also said they do not currently have any supporting instrumentation (such as a traffic generator). Roberto asked PlaGE to send him details of their requirements so he might try and arrange the loan of a Smartbits.

ACTION Roberto, Alain to define the configuration and request the Smartbit testkit.
 

Italian GARR-G Testbed -  Mauro Campanella

Mauro reported that two of the three lines have been installed and the third link, completing the triangle should be installed during July. The CISCO 12000 routers have been delivered with line cards. The line cards are a mixture of engine 0, 1 and 2. Graça offered the following summary of engine capabilities:

• Engine 2 Is OK for core testing
• Engine 3  Has Edge feature capabilities
• Engine 4 Core Engine

ACTION Graça to mail details of capabilities of Cisco engines to the TF-NGN email distribution list.

Mauro said the Italian testbed could be used for some TF-NGN testing but he needs to schedule these requests into the Italian testing schedule. A first experiment with Ovnet phase 1 could start immediately. If Task Force members have some experiments they would like to undertake they should send details of what they want to do, for how long and the manpower requirements. Jean Marc said he might provide information about support for shaping in Juniper routers.

ACTION Task Force members to send Mauro requirements for experiments on the Garr-G testbed.

ACTION Jean Marc to provide information about support for shaping in Juniper routers.

Roberto said he would like to get some baseline measurements from Engine 2 cards without using MPLS.
 

Polish Pioneer testbed -  Artur Binczewski, PSNC/Pol-34

The Pioneer testbed has network instrumentation equipment available including Ericsson traffic generators and some codecs. It was reported that Pioneer has sufficient dark fibre in the city to simulate most distances. The routing equipment of Pioneer consists of a combination of CISCO 8500 CSR (Campus Switch Routers) and CISCO 12000 GSR (Gigabit Switch Routers), which it is hoped, will remain in place for testing until at least September. TF-NGN members are encouraged to use Pioneer for testing as it is already installed and connected. Tiziana agreed to evaluate the facilities of Pioneer to ascertain if it would be suitable for some of the shaping experiments. An uncertainty is the need for Engine 3 cards, which are not installed and will not be available from CISCO until October.

ACTION Tiziana to evaluate the suitability of Pioneer facilities for shaping experiments.
 
 

6. IPv6

Tim Chown informed the Task Force that it is possible to have Ipv6 reverse lookup entries put into the DNS by sending a request to David Harmelin at DANTE. He also said that there is still some opportunity to obtain Ipv6 connectivity to the US through the 6TAP project or through UCL, UK.

Tim reported that we could do with some more diagnostic tools and monitoring equipment around the networks. It was suggested that people running the RIPE boxes should be IPv6 enabled so as to allow the same statistics to be collected on IPv6 as are already collected for IPv4.

Tim reported that he has added some new pages to the web sever NREN IPv6 Projects. In particular he suggested looking at new member projects page at http://www.ipv6.ac.uk/gtpv6/. In this connection, Tim asked Task Force members to submit any further URLs that should be added. János Mohácsi of Hungarnet reported that he is currently putting together a database of IPv6 applications. Available at: http://tipster6.ik.bme.hu/ipv6port/index.cgi?lang=en  Access is via a simple web interface that will be developed into something more users friendly as time allows.

Tim said work on the IPv6 Work items is progressing and the group should make sure that the results are reported in the GEANT deliverables D13.1.

ACTION Tim to collect items on the IPv6 deliverable and to draft a paper in the first two weeks of July.

6NET Status - Graça Carvalho, Cisco Systems

Graça was unable to report any official news regarding the outcome of the 6NET project proposal, submitted to the European Commission IST programme in April this year. There will however be a management level partners meeting taking place on 2nd July 2001. It is understood that the project was evaluated by external experts a couple of weeks ago. Howard Davies reported that DANTE is giving priority to their GEANT work, but are very interested in 6NET.

Juniper Proposal from Juniper Networks to TF-NGN -  Jean-Marc-Uze

Jean-Marc discussed the possible loan of Juniper M5 routers for the GEANT and 6TAP projects and for running a link between them. He pointed out the host site should ideally be near a Juniper Networks engineering site and that the host will have sufficient hosting resources. Details of these routers can be found on the web page http://www.juniper.net/products/dsheet/100017.html

It was agreed that representatives of organizations interested in these loans should meet after the main TF-NGN meeting with Jean-Marc and Roberto.

Other Ipv6 News

It was reported that Hitachi have also indicated that a GR2000 router might be made available to the group as they Hitachi want to market more aggressively into the European region. Details of the Hitachi GR2000 can be found at URL: http://www.v6.hitachi.co.jp/GR2000/

Forthcoming European Commission Ipv6 related meetings:

• IPv6, 21 June concertation meeting
• NGNI Project meeting 22 June
• IPv6 Task Force 25 June : see URL: http://www.ipv6-taskforce.org/

János Mohácsi BME/HUNGARNET talked about TAHI and Tipster6. TAHI shows results of tests about IPv6 implementations with the goal of contributing to their quality improvement. The project provides suggestions to avoid certain pitfalls in configuration and recommendations about selection of which IPv6 implementation sould be used for their servers. János said they have tested FreeBSD 4.2 and 4.3. There were problems with 4.2, some due to the implementation, more to do with the configuration. He said one must be sure to specify which is the default interface if more than autoconfigured interface exist. FreeBSD4.3 is quite good even though sometimes it accepts erroneous ND packets. On SOLARIS 8, there were some problems, many cured by patch 108528-6, however malformed messages are not handled properly. With Linux 2.2.19/2.4.3 they found problem with IPv6 implementation in earlier versions that have been fixed in 2.4.3 . Fragmentation is not working very well even in 2.4.3. With AIX 4.3.4 patchkit9 they had many problems. The conclusions were that TAHI is very picky, quite KAME specific and sometimes misuses packets. However the implementations are safe and useable. János plans to continue testing other platforms including Windows-2000. The 6bone statistical tools are available at TIPSTER6 and monitoring 6bone and IPv6 Internet and the new Trout6 is in operation. The Trout6 statistics are available at http://tipster6.ik.bme.hu/trout6/. Some strange results found that sometimes IPv6 RTT is lower than IPv4 RTT.
 
 

7. Optical Networking

Victor is working on service specification from the user/provider viewpoint. The service could either be a managed fibre /lambda service or dark fibre to be self managed. Dark fibre is defined by the fact that there is no equipment in the path except the fibre itself. Victor is going to specify some co-location for small equipment like repeaters in the path to get to the required total distance. He wants to know what the maximum distance of the segment will be and he needs to specify what wavelengths (colours) will be used. It is also needed to specify the window that is going to be used over the panel, to ensure the characteristic of the glass is OK. The choice of connectors is also important, one needs to decide between SC/APC (now the standard) and E-2000, which is not yet used in the US but many suppliers are now using in Europe.

G.652 is the type of fibres put in the ground by most carriers. Victor said it is OK even for DWDM supporting 10G over each lambda. G.655 is better, but its costs is 50% more expensive. The issue is really one of trading loss with dispersion. Some of the branded fibres exceed the specifications and perform better. For long distance, the usual modality is single mode.

The main optical characteristics that need to be known are attenuation, chromatic dispersion, and polarization mode dispersion. The attenuation can be compensated. The optical return loss is caused by reflections at the connector panels, so results in a loss. The chromatic dispersion is the relative shift between the different wavelengths measured in picoseconds per nanometer (ps/nm), but can be compensated by a corrector. Victor said fibres of 652 type have more chromatic dispersion than 655. Polarization mode dispersion is caused by non-circular section of the cable among the other things but can be caused by bends, temperature or even proximity to energy distribution networks.

Victor is looking for tools to compare the expected and actually measured values of the above parameters, some of them are OTDR, LTS, CD, PMD, but they are all very expensive, and he is not sure that the suppliers have them. The expected MTBF and MTTR also need to be measured. He said on trains it is maybe 300 years per km, in towns it is maybe only 10 year per km. This means that for a 10 km length in a town it could get dug up once every year !! The routing of the fibre therefore has a high impact on the MTBF.

On the Managed Fibre / Lambda Service side one need to define frequencies (black and white - as used in SDH  - or colours) and bit rate. Most equipment can easily handle 2.5 Gbps, but over 2.5 there might be a need to be more specific. This means that there is less flexibility in case the fibre is owned by others. One needs to make sure that the power is delivered in the right range, not too much or too little . Optical return losses and dispersion are the same for Dark Fibres. Assuming that multiple coulors are sent, then one need to discuss the cross talk between colours. If there is more power in one colour one might get into big problems. One need to get the BER (not in a dark fibre though) on 10-12. MTBF and MTTR path diversity are good to know, but be careful that you are not traversing the same back plane. A final note was that if the fibre gets cut and spliced, then this will introduce poorer performance, so one needs to allow for this in calculations. If the drop gets too big then one will need to insist on a new fibre.

Artur Binczewski, PSNC/Pol-34, has made loop backs on STM-16, 12 hours#20 hours# 0 BER for both - 10e-12. During the months that they have been running the DWDM they have had no problems with them. He said that every DWDM system can be tuned after inserting and removing some cards. Their Alcatel system has one special lambda for inband management system. The amplifier has always the same power on entry, can measure the output and adjust accordingly.
 
 

8. Juniper R&E specific programme

Jean Marc presented a a program that Juniper are developing to support the Research and Education community in Europe, which includes a number of measures like equipment loan, training, seminars etc. For equipment loan the idea is to overcome the current procedure that goes through the dealers, and to create a pool of equipment that can be used directly. Jean Marc invited people to send him requests for equipment. Juniper also have labs in UK and  Amsterdam that can be used by customers.

Training is independent from a specific loan, can be tailored to specific requirements and is open to all of the NRENs. Jean Marc would like to get feedback from TF-NGN on training requirements. The training facility can normally accommodate 16 seats, the size being limited due to the inclusion of hads-on lab sessions. In addition to that, Juniper will participate in workshops or seminars if that would be helpful. Finally, the package includes special price discounts and sponsorhip for R&E customers.

In the following discussion Roberto said it would be helpful to install some routers on the Polish and Italian testbeds. For the people that are operating the equipment in the testbeds, it would also be appropriate to organise some training. Dimitrios suggested that it would be useful for problem isolation and advanced feature testing to have two examples of the Juniper equipment on each network. The training, instruction and material will be FREE to NREN attendees. The first goal of the training is to train the operational part of the networks that are new to Juniper equipment. It was suggested that Juniper might like to give a tutorial for ½ day at the Athens TF-NGN meeting. Jean Marc said VPNs and Optical GMPLS would be suitable options, TF-NGN will choose a topic and communicate that to Juniper.
 
 

9. MPLS testing on PlaGE

The PlaGE testbed validates network services for RENATER 3 on  2.5 Gbps links between Paris, Nancy and Strasbourg. Currently all equipment is in a lab in Paris awaiting line card from CISCO. It is the intention to install during July. They hope to have three CISCO and 2 Juniper routers as planned.

The testbed operation was delayed due to problems with forwarding marked traffic in Diffserv queues when MPLS was activated. It turned out to be a known bug in the CISCO IoS and the problems are now solved.

The service validation on PlaGE would regard interoperability test, coordination with premium IP service and MPLS specific tests. Alain said they would request another M20 or M10 router to Jean Marc for one month. They also need to translate the IP premium and IP+ services into working configurations for the Juniper and CISCO equipment, and finally need to do work on the SLA including interdomain tests. They plan to connect other testbeds to PlaGE, Germany being the first canditate. Test could be done on PlaGE to validate these functions and services and then, if found beneficial, could be transferred to GEANT.
 
 

10. Measurement

Simon began by saying that there has not been much activity in Flow based management and accounting. Some people in the group have been at the Passive and Active Measurement (PAM) workshop. In the IETF the standardization effort for something like netflow is starting up. There are two different opinions in the IETF group. Some people have a very broad view of what a flow is, other have a more traditional view that it must be a full formed packet of information containing source/destination address etc. The people for NED hydrobad have agreed to write a requirement draft for the next IETF meeting. There will be a Bof in London and probably a working group will be formed.

On the implementation front, Foundry are already implementing whole netflow in hardware. People have solved the problem of high bandwidth in two ways, either sampling or looking at just a limited set of the parameters leaving out things like port number. Full netflow is very nice, but it would be recommended to limit the amount of data that is exported. Some newer protocols do not use well-known port numbers. Indeed some negotiate a port number at connection time. However Simon said that to be able to collect data about protocol use, it is necessary to also look at the control data, so the collection can only be derived from very detailed statistics.

Simon informed that he has added many references to the FLOMA pages including refs from PAM and USENIX meetings. The discussion followed with some talk about tools, Simon mentioned a free tool called SKPING which can be found at http://www.caimis.com which he finds very useful. He also mentioned that Victor had sent information about the possibility of using the New Zealand cards in Europe. Many do passive measurement, there are only a few projects doing active measurement, RIPE NCC, Surveyor are some of them. How many cards are available is still an issue, Victor asked for 7-8 cards, but they would probably like to provide 3-4. Cost is not known.

The relevant Geant deliverable was due end June, it was decided to shift it to end July.

ACTION Simon to coordinate with Victor and collecting information for the Geant report due end of July.
 

QOS MONITORING and SLS auditing - Victor Reijs, SURFnet, The Netherlands & HEAnet, Ireland

Victor is working with the QoS WG of Internet2. They take a very high level look at the issues. They have different boundaries, but they are doing comparable things, so there is scope for collaboration.There is a call for tender for Fellowship to work on some of these issues. Victor will forward a pointer to this information to the list. It is about defining what applications need from networks. Another intiative from the Internet2 people regard putting test boxes in Europe. Victor has said tentatively we could use about 7 boxes.

Victor reported about the metrics that should be used:

• One way delay (OWD) is one of the most difficult matrics because it need accurate timing. Victor thinks gPS is needed,but other people in the group were not sure about that.
• IP delay variance (ipdv) is not that difficult to measure, but it is difficult to define what is statistically important for the application. This metric is already supported in many tools.
• One way packet loss is not difficult and there is a lot of experience. It is supported both in  RIPE and Surveyor boxes.
• Burstiness of the loss still needs to be defined, but Victor remarked that he still did not see many applications that need it.
• Available bandwidth. The main problem is to define the meaning of this metric. Many tools only measure the capacity of links. It is the white space on the link. Simon thinks this is not true, it is only interesting if you can make a reservation of that white space. What Victor would like to know is the equivalent leased line capacity that is left on a link.

• Accurate Time available - GPS, PPS
• Distribution structure
• Mutli management domain
• End-to-End edge-to-end-edge-to-edge

• SSL access (secure access - measurement can hinder network)
• Measurement script
• OS Indpendent
• Database (RRD)

ACTION Victor to send the list an English version of the Polish document on Bandwidth Measurement.
 
 

11. Improved Multicast

Lada updated about the progress regarding two items, MPLS and Multicast on the one hand and the Beacon multicast monitoring service on the other hand. Lada said there is no native support for multicast in MPLS (draft-ietf-mpls-multicast-05.txt). Multicast travels as plain IP packets. He discussed several options on how to handle this: a). provide P routers with standard unicast IGP routing data introduces flapping and is not a good solution, b) use GRE tunnels between PE routers so that P routers don't see any multicast traffic, c) the best solution seems to be to use MBGP on P routers and that is what CESNET are going to do when they will switch off ATM. Traffic Engineering has similar problems, although the RPF interface may be the TE tunnel.  Future activity carried out by CESNET would be to configure and test MBGP on P routers, and following to test the MPLS-TE and multicast interaction. The latter activity might take place on the PlaGE testbed.

An experimental beacon server has been setup at http://zma.ten.cz:8378. The current status is that all serious problems have been solved. Lada said that Roman Lapaz, from PSNC, has been patching the Beacon server (http://noc.man.poznan.pl) which now works under Java 1.3. In Java 1.4 the built-in server also supports IPv6. Roman has also added a nice feature that allows the user to save the server data collected from the agents to a file, previously it was only possible to look at it on the screen. Robert Stoy has also done some work on multicast statistics based on this data. Lada assumes there will be one workstation at each GEANT pop. He is looking at installing the multicast beacon at each POP on Solaris workstations. Sun has released Java 1.3.1 and the original version of Beacon now runs fine. Future activity for the group includes the use of Beacon on Geant from the very beginning of operation, select GLOP address based on the GEANT A5 number, install agents in all POPS to be used by the Geant NOC for multicast monitoring. Additional improvements to Beacon should be consolidation of history and statistics to provide long-term reports, rewrite the agent in C and provide some sort of authentication. There was concern about the choice of C rather than Java. It was suggested that since Linux boxes don't have Java installed as default, they would have to download and install it specially.

Information is updated on the multicast home page http://www.cesnet.cz/tf-ngn/multicast/ containing user support pages.

Simon remarked that  it is good to have Beacons on Geant, but in addition there should be one in each NREN as well, even though this might be done later on. Although it is difficult to view large matrix, there are a couple of tools for extracting subsets of data from the global matrix and presenting them as a personalised view.

Artur briefed the group on the Multicast Research in Poznan and provided some detail about the new feature of history to the Beacon application - originally created and published by NLANR. The Polish network runs four beacon, in the next few months they will go to7 beacons.
 
 

12. Review of Geant Technical roadmap

The transport activity included IPv4 testing of IPv6, premium IP, improved multicast and MPLS TE. The Geant PC discussed DANTE participation in 6net. It was said that national networks must be free to introduce ther suppliers equipment. Any other network not part of the project but having IPv6 test facilities will be free to connect to GEANT. The VPN topic for year 1 included continuation of TEN155 MBS, testing of MPLS support for VPNs and AAA. The traffic Measurement work item included equipment of new POPs with Traffic Measuremeant capability and study MPLS VPN measurement.

Roberto asked if the roadmap was complete, and mentioned possible additional items like the study carried out by Victor on optical networking. Dimitrios said that management of lambda services should be taken on board but it was  generally felt it is still too early. One topic that the group agreed to discuss further was the Less-than-Best-Effort service being studied at Internet2. LBE makes BE traffic to perform better. Ukerna SURF, SWITCH, DFN, CESNET and HEANET are considering it. It was recommended to perform a study of how LBE is implemented in various networks and getting feedback from users. The appropriate context forthe study would be in the QoS IP group. There was some discussion on QoS, particularly the Scavanger service. Roberto asked also about other multicast topics that might be added  and remarked that  nothing is happening about BGMP. There were no firm views about drop the item from year 2, but at the end it was decided to remove it  as an experimental item.
 

Agnes said that VPNs can be provided in other ways than MPLS, like for instance using IPsec, and suggested to try other technologies in year 2 Lada asked what is the user requirement for VPNs in Geant and remarked that  Layer 3 VPNs are not very interesting. Howard said that the only requirement users of TEN155 MBS care about is performance. People felt that VPN is an important item, but it was concluded after a long discussion that the group needs to have a much clearer idea of what they are trying to do. The action item for year 2+ was review requirements for VPN facilities.

ACTION - DANTE to prepare the revised Geant road map.
 
 

	Year 1	Following years
Transport	IPv4 testing of IPv6  Spec of Premiunm IP service  Improvement of Multicast service    MPLS TE study being carried out on the PlaGE and GarrG testbeds	Spec of IPv6 service / pilot services continuing the pilot activity study of MPLS support for multicast: Video distribution continuing the pilot activity
VPNs	Continue TEN155  Testing of MPLS support  AAA	review requirements for VPN facilities pilot MPLS VPNs Study/test directory support for VPN provisioning, bandwdith brokers, user interfaces, tools for user control of VPN provisioning
Traffic Measurement	Equip new POPs with Traf Measuremeant capability Study MPLS VPN measurement	?   ?

 

13. Date of Next Meeting

The following meeting would be held in January 2001, a suitable venue was being investigated, the first option was at CERN in Geneva.
 
 

14. Any other business

15. Actions from last meeting

1.17 bernard to send to mailing list a format being used to distribute IPv6 addresses to customers.
 - ongoing

1.18 Tiziana. Mauro, Roberto, Herve to finalise discussion about loan of  equipment. RIPE boxes will be installed on Garr-G
 - ongoing

2.1 the MPLS group to check whether MPLS traffic should be tested in  isolation or mixed with BE.
- ongoing

3.1 Howard, Mauro to follow up on the definition of service specification for the premium IP service.
- Done

3.2 Michal to stimulate investigation on usage of Linux or OpenBSD platforms for traffic shaping.
- Done

3.3 Valentino to set up listing of TF-NGN test beds.
- Done

3.4 Tijany to report on the usage of the new generation RIPE measurement boxes.
- Ongoing
 

16. Open actions

1.17 bernard to send to mailing list a format being used to distribute IPv6 addresses to customers.
 - ongoing

1.18 Tiziana. Mauro, Roberto, Herve to finalise discussion about loan of  equipment. RIPE boxes will be installed on Garr-G
 - ongoing

2.1 the MPLS group to check whether MPLS traffic should be tested in  isolation or mixed with BE.
- ongoing

3.4 Tijany to report on the usage of the new generation RIPE measurement boxes.
- Ongoing

4.1 Roberto to post SEQUIN deliverable D2.1 to the email distribution list.

4.2 Simon and Victor to work on specification  of the monitoring system for premium IP service.

4.3 GRNET to produce initial thoughts on SLA/SLSs.

4.4 Mauro to continue the discussion about the issues of traffic shaping on the TF-NGN email distribution list.

4.5 Mauro to take into account comments from people doing experimental work on shaping in his draft report to be distributed in 2-3 weeks to the email distribution list.

4.6 GARR and GRnet to start performing the baseline tests.

4.7 Octavio to provide charts about packet loss.

4.8 Simon discuss his ideas about limitation and restriction in the use of AF.

4.9 Wim Barbaix to collect proposals from TF-NGN for further interconnections and experiments with ATRIUM.

4.10 Alain and Mauro to follow up with Graça about hardware/software requirements in setting up the Plage and Garr-G testbeds.

4.11 Roberto, Alain to define the configuration and request the Smartbit testkit.

4.12 Graça to mail details of capabilities of Cisco engines to the TF-NGN email distribution list.

4.13 Task Force members to send Mauro requirements for experiments on the Garr-G testbed.

4.14 Jean Marc to provide information about support for shaping in Juniper routers.

4.15 Tiziana to evaluate the suitability of Pioneer facilities for shaping experiments.

4.16 Tim to collect items on the IPv6 deliverable and to draft a paper in the first two weeks of July.

4.17 Simon to coordinate with Victor and collecting information for the Geant report due end of July.

4.18 Victor to send the list an English version of the Polish document on Bandwidth Measurement.

4.19 DANTE to prepare the revised Geant road map.

| Home | Information | Conferences | Innovation | Technical | Library | News |