Minutes of the 2nd TF-NGN meeting 8-9 February 2001 University of Münster, Germany

Valentino Cavalli, Kostas Anagnostakis, Issue 1
 

Table of Contents

•     Attendees
•     Apologies
• 1.  Welcome
• 2. TEN155/Geant Update
• 3. Premium IP
• 4. Over-provisioned network performance analysis
• 5. AF-based Services
• 6. Support of Delay and Jitter Requirements
• 7. Hardware discussion
• 8. Improved Multicast
• 9. GCS and MPLS
• 10. IPv6
• 11. QoS and Multicast
• 12. Measurement
• 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/presentations2.html
 

1. Welcome

The minutes of the 1st TF-NGN Meeting were approved without further comments.

Actions from previous meeting: 4,5,7,9 DONE. In the others, there has been more or less progress, but they cannot be considered done.
 

2. TEN155/Geant Update

Howard Davies provided an update on the Geant tender process. The closing date for bids was September of 2000. 17 bids for Gbit/s speeds were received and 14 for non-Gbit/s speeds. Out of the 17 gbit/s tenders 11 were put aside but not rejected. 6 bids are still being considered, 3 of which characterised as possible and 3 as probable. DANTE targets at making recommendations to the Geant Policy Commitee meeting in March, with a short list of 3 bids. The selection of principal supplier(s) should be complete by April. The evaluation issues were the following: who owns the infrastructure, dependencies on third parties, financial stability, location of POPs and local loops and whether the options exists for starting at 10Gbit/s speeds. Participants asked Howard Davies whether there are plans for providing access to the new infrastructure for experimentation on the TF-NGN workitems. The response was that additional capacity might be offered, but is not part of the tender discussed. Also, there is a requirement for experiments to take place on a physically seperate infrastructure.

Anges Pouele presented an update on a meeting between TF-NGN participants and Internet2/Abilene, during the 49th IETF in San Diego, USA. The goal of this meeting was to investigate engineering options for a IP Premium Service peering with Geant and common QoS/IP Premium Service tests. The conclusion was that there exists such a possibility and 5 Mbit/s could be made available on the transatlantic link into frankfurt for this specific purpose. A mailing list is set-up to continue discussion and make further plans.
 

3. Premium IP

1. MBS
2. GCS,
3. IP premium, and finally
4. BE

The definition of IP premium follows the classical definition by Jacobson of Virtual Wire - considered as providing the same service as a leased line. The functionality will be provided by EF PHB marking, strict policing at the Diffserv domain ingress, priority queuing and possibly shaping. The latter may be  needed due to localised traffic aggregation that can create burst,  even if plenty of bandwidth is available.

Roberto asked how much bandwidth was feasable to be reserved to the Premium IP service, as in Ten-155 a limit of 20% was set and proved to be suitable. The result of a discussion involving Simon and others was that how the service will be provisioned is a subject for research by the IP premium TF-NGN group. The rationale for bandwidth limitation in the MBS was mostly of administrative nature, technically it was possible to allow customers to use more. Mauro had prepared a slide showing some estimates and would talk about it later on.

The following discussion focused on open issues regarding IP premium. Mauro asked whether the service should only be provided point to point or independently of the destination address (undetermined metric). This question also involves the problem of asymmetric SLAs. To clarify he discussed what happens when, for example, in a four-nodes configuration one node receives flows from three nodes, each of 10 Mbps IP premium packets. It will have 30 Mbps at ingress and 10 at egress. Mauro was arguing for only policing at the ingress and not having to police at the egress.

Olav asked if it was considered to provide several classes of IP premium service. Mauro said the service can be provided in different classes to the customers, but there is aggregation of traffic in the network core, so one will always end up with one class in the network. Simon said one can provide different bandwidth but he does not think one can differentiate by quality because of the use of EF and of a single queue. Klaus remarked that providing point-to-point IP premium would be simpler than providing it to unknown destination, but Simon argued in favor of both, he said the first is not really simpler, it is just more expensive.

Another remark, from Rüdiger, was that ATM is a connection oriented service, whereas IP is connectionless so in principle one does not know the destination. In this case it is possible to police on some destinations at the edge, but this affects the performance of the router. At present this is mostly a technical problem and not just a limitation due to performance costs. Jürgen said he was not only interested in providing IP premium service point-to-point between specific nodes in the backbone, he was mostly interested in providing end-to-end QoS.

After the discussion Mauro defined the (temporarily) so-called Guaranteed Capacity Service (GCS). He said this service can be defined as a transport of at least a nominal bandwidth and provide loose or no guarantee on delay and ipdv. A proposed way to obtain that, though still needing some discussion, was to build the GCS service using the AF per hop behaviour (PHB), having separate queues (WFQ) for GCS and BE, policing with token bucket algorithm. Shaping was an open issue, but it should not be needed. There was a discussion related to the number of colours in AF PHB. Octavio said reordering of packets when the SLA is exceeded was no needed.

Roberto asked what kind of support is provided for having different colours in the same queue by the hardware platforms currently available. Octavio said he would also address this point in his presentation later on. Simon argued that the service would be useful even in the case of using the same queue although in this case one cannot get perfect isolation. He remarked that it is the same case today, when we have only BE traffic - and no isolation - but a still useful service. He said by limiting the service to one single queue one can still have differentiation, and the fact that there is no real guarantee differentiates it service from the real GCS.

There was general consensus that having AF and BE packets on the same queue is a good approach, also in terms of cost. Octavio said there is no fundamental difference with respect to having two queues. But he warned to be careful on the amount of traffic that would be let in because one may have starvation and/or provisioning problems.

A marginal issue was to provide TCP friendlyness but found to be more a problem of the customer than of the network. Mauro said the service is for layer 3 not for layer 4 protocols (TCP. UDP), what happen with the mixture of protocols is up to the customer.

Mauro recapped the work points, which include

• static provisioning,
• mapping the service functionality to the features supported by hardware platforms, e.g. at least 3 HW queues (IP, GCS, BE) are needed,
• depending on the capacity of the core links, computing the maximum amount of bandwidth for each ingress that can be allocated to the QoS services;
• measuring the values of the agreed QoS parameters in an empty  (but working) network;
• defining how to extend policies to multiple domains;
• monitoring.

Roberto and Mauro wrapped up the whole discussion with the following result: over-provisioning would be leveraged, the Diffserv model would be used and MBS would be collapsed to IP premium but GCS is going to be given another name (no matter which one) and will be provided as a subset of the premium IP because it does not address the problem of isolation of protocols.

A discussion followed on the need for such a separation before testing Ipv4 - Ipv6. Tim said in the long term it is needed, but the majority of Ipv6 features can be tested over tunnels. Mauro observed that the same problem of isolation might also concern MPLS. The discussion continued with the attempt to define a timetable: the critical date would be November 2001, when the TEN 155 ATM network will be replaced by GEANT, but when Ipv6 will be needed as a production service, i.e. when the technology and the user requirements will be there was up to group to find out. On the issue of separate MPLS there was a discussion between Simon and Lada, which led to the need for the MPLS group to check whether MPLS traffic should be tested in isolation or mixed with BE traffic.

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

4. Over-provisioned network performance analysis

5. AF-based Services

Mauro Campanella suggested that the useful direction to proceed would be to use feedback-based traffic such as TCP, since that's what WRED is basically intented for as a QoS mechanism.
 

6. Support of Delay and Jitter Requirements

7. Hardware discussion

Roberto asked if this testbed is usable by TF-NGN, and in that case if it is useful. The result of the discussion was that it was advisable to interconnect the nodes, hopefully Strasbourg to the DFN network and also the INFN network in Italy. Octavio said this issue is also important to find out in which part of the network to implement Diffserv for carrying out the tests.

ACTION 2.2 Octavio to make plans for using PlaGE for AF-based testing.

Mauro presented the GARR-G pilot. He showed that Milan, Bologna and Rome will be connected at 2.5 Gbps links provided by Telecom Italia. The links were already tested and would be operational at the beginning of March. The equipment was Alcatel WDM 1690 and Cisco GSR 12016. Juniper M20 was also going to be in place, but they were not yet there. INFN have been approached by RiverStone Network, who wants to provide three switches plus one-two PCs at each site. Mauro added that the current line Milan-Rome is not a single fiber, it appears like a Lambda, but has many hops. For measurement they plan to use the RIPE NCC boxes.

ACTION 2.3 Octavio, Tryfon, what equipment is needed to interconnect the PlaGE and the GARR-G testbeds and to take into account impact of ATM connection for testing the queueing techniques which may not work on ATM interfaces on high-end routers.

Howard mentioned the ATRIUM project, a IST project which started in January and is coordinated by France Telecom, with partners like Alcatel, the University of Pisa and two more universities in Belgium. He said the project is setting up a testbed by installing three Alcatel 7070 routers, and is offering it to DANTE. Howard will talk to them next week, there is a possibility to provide further interconnection to GEANT.

Tryfon recalled that he expects to have operational Lambdas in Greece in September.

Tim, mentioned that SuperJANET4 have GSR at four POPs with extra capacity at 2.5 Gbps, but he did not know much detail.

ACTION 2.4 Tim, to gather information on the UK testbed and post it to the list.

Klaus showed the topology of the Finn testbed were they are building 2.5 Gbps POS, but not yet in production. He said they have the boxes and the links, and the connection to NORDUNet had been tested. They expect to be ready at mid March.

Simon described the Swiss topology. Between Geneva and Zürich SWITCH has ATM and STM-16 link with Foundry Networks boxes where they are doing some production tests. They bought two dark fibers between the two towns that will be managed by SWITCH and should be ready in Summer. A lot of universities should be connected. Simon said were the infrastructure is ready it is available for testing. CERN in Geneva is connected via STM-1 to TEN-155, both Geneva and Zürich are connected to the US with three nodes in NYC, Simon said they have complete link redundancy right now and the load is not so high, so it would be an interesting opportunity to carry out some international testing. Simon would like Abilene to be involved, but Roberto was afraid that the time frame would not match. Rüdiger said he will investigate about making international testing with Internet2.

ACTION 2.5 Rüdiger to investigate what traffic testing kit is available from Abilene in 60 Hudson and how they can be used with SWITCH; Simon to verify the options from SWITCH's point of view in Geneva or Zurich.

Simon, Tryfon and Mauro would work together in making a time schedule and define actions for carrying out international tests with over provisioned Networks. Part of this can be done even now. The tests could initially focus on Ipv6 and multicast.

ACTION, 2.6 Simon, Tryfon and Mauro to make plans for international tests.
 

8. Improved Multicast

Lada proposed to install server/viewer in Prague for Beacon and MM and to test them, he then he will ask people to test the agents locally. After the testing period the tools should be offered to the general public.
 

9. GCS and MPLS

During the MPLS session the following presentations were made :

• a presentation from Ennovate about their view and implementions of  VPNs;
• a report about the last tests done on the EFT image on the European test bed and the following tests planned to do on diffserv & MPLS;
• a presentation from Renater of the  PlaGE testbed and the experimentations they intend to do on it - part of their work will focus on the transport of IPV6 over MPLS.

10. IPv6

Tim briefed the participants about the 6INIT network services. They have introduced successfully DNS, QoS, IPsec, BGP v4, and have NAT PT device for IPv4-IPv6 interoperability in place in the 6INIT clusters (UK, France, Germany and Scandinavia run native Ipv6, in addition there are Ipv6 tunnels between Germany and Scandinavia).

Tim also recalled the GEANT test programme which contains having IPv4-IPv6 backbone, getting some operational experience and study the impact down to the site level. The programme also entails IPv6 deployment, encourage additional NRENs to join, seek collaboration with other networks and projects. The first report is due in July 2001 on the primary work items. In October 2001 a end-of-year report is due.

The meeting went on with discussion new GTPv6 IPv6 infrastructure after the QTPv6 ATM PVC star network will be phased out. This was based on Ericsson Telebit boxes - some of the better working on the market at the time- and now it was needed to investigate also into other products. Tim`s draft proposal to implement the programme includes providing dedicated Ipv6 routers and having links tunneled following the IPv4 infrastructure. Acquiring hardware is an issue, maybe by loan-donation. Probably Cisco 7000 series or higher. Tim said a model for the loans is requested at this stage, and it should run for about two years. Six or seven routers are required, one per main participant: Ukerna, DFN/JOIN, RENATER, Uninett, SWITCH, ACONET and maybe Amsterdam Exchange. Tim proposed RedIRIS to tunnel to Paris using their ATM link, but in a following discussion later on RedIRIS expressed the willingness of running a dedicated IPv6 router. Tim presented two possible topology, with and without AMS IX.

Some open issues are related to tension between production like and low-bandwidth, to going beyond tunnels - run commercial code on dual-stack routers - the possible routers to be used - Cisco IOS 12.3,12.4, others, from Juniper, Hitachi - having a parallel native fiber infrastructure and possible funding from EU 5th FP current CFP. On the latter issue Pascal announced that the EC is organizing a workshop on wireless IP underlining some IPv6 components on 12 March. He encouraged people from the group to participate in the meeting. On the issue of peering/transit to other networks Tim mentioned possibilities with Japan, - using the 45 Mbps link from UCL in the UK - 6TAP - PVC with CERN and RENATER -, AMS IX, Abilene, vBNS, WIDE and CA*Net3.

Christian Schild, depicted the German IPv6 backbone and said they moved from ATM-based B-WIN project to the SDH-based G-WIN. Ten cities are now connected at level one, each of them has level two routers for connecting the universities - Christian explained how address space is split at the various levels. There were comments from Simon comment and a lively discussion. Christian argued for having dedicated routers for provisioning of IPv6 infrastructure.

Bernard described the RENATER2 IPv6 pilot - 1Mbps PVC capacity -, and discussed RIPE IPv6 allocation issues. Address allocation was defined in RFC 2450, modified in RIPE 196 and in RFC 2928, in addition it was addressed in the IAB & IESG Recommendation. A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-iesg-ipv6-addressing-recommendations-00.txt.

Bernard has set up a small group of people to rewrite the RIPE 196 document. There was a discussion between Bernard, Tim, Simon, Jürgen, then Bernard invited people to subscribe to the RIPE IPv6 working group list, he would send his document to the gtp mailing list.

ACTION 2.7 Bernard to send his revision of the RIPE 196 document.

Tim briefly updated on the status of the work items. Platforms, routing and interoperability was going to be led by Christian Schild. Open issues included router platforms, there would be no interoperability to be tested if only Cisco boxes are used, Christian said JOIN will try to get an Hitachi. The DNS item is going to be led by David Harmelin, who already started a discussion on benefits and pitfalls of A6/DNAME. Bernad said he would send slides of presentation from Randy Busch at RIPE meeting ad IETF San Diego. For the secondary areas there was an issue on IPsec because Jürgen was not going to coordinate it. Tim proposed Yves, but he did not seem to accept immediately. Janos would lead the work on Firewalls and presented his plan. It was announced that a tutorial on IPv6 was going to be held at the next RIPE NCC meeting in Bologna.
 

11. QoS and Multicast

The presentation continued with some ideas on how to support QoS and multicast. QoS packets addressed to a multicast group can be marked so that multicast traffic is differentiated. Identify multicast streams is easy by source/destination addresses. One can not assign QoS to a specific session with the current available sessions, one can only do it to a range of multicast groups, because the group is not known when you start/join a session.

Simon commented that People who designs differentiated services in GEANT should keep multicast in their mind. Agnes asked if what is the QoS requirement for multicast. LADA raised a duiscussion on the issue of multicast speaking against exploiting MPLS in the backbone.
 

12. Measurement

Simon Leinen/SWITCH briefly presented the Flow-based Measurement and Analysis activity. No concrete plans have been made at this time. However, Simon is going to present a poster in PAM2001 on his measurement based work in SWITCH and TF-NGN. PAM2001 is the Workshop on Passive and Active Measurements hosted by RIPE-NCC in Amsterdam, on April 23-24. More information is available on http://www.ripe.net/pam2001/.

Simon suggested also to pursue work in monitoring multicast tools, especially for debugging purposes. Roberto added that he would make available software and documenmtation for the tool developed at DANTE last year, so that others could add extensions (and robustness) to it.

ACTION 2.8, Roberto to distribute SW and documenmtation (DONE!)
 

13. Date of Next Meeting

14. Any other business

Howard mentioned a conversation with Fernando Liello. GEANT should be available by the Summer 2001, TEN-155 will end in November, so there is a window of a few months for carrying out experiments on the GEANT infrastructure. Howard said some time at the next meeting should be allocated to discuss ideas about exploitation of the GEANT very high speed network as a test-bed for TF-NGN experiments. Victor asked if the network is going to be SDH or Lambda. Howard said it is a lambda with SDH presentation, i.e. black and white, you do not see the colours of the lambda.
 

15. Actions from last meeting

1.2 GRnet to clarify plans for the OvpN activity within two weeks, + define network and resources requirements.
- ongoing

1.3 Tiziana and Mauro to provide support to GRnet in the definition of tasks and test plan for the OvpN activity.
- ongoing

1.4 Tijani to provide pointer to EURESCOM document with metrics for defining QoS services.
- DONE

1.6 Octavio, Tiziana, Tryfon and Mauro to coordinate testing with deadlines for the premium IP deliverable.
- ongoing

1.7 Lada to start collecting information about info-sources for end users from people providing multicast services to end users; to host web site; to send pointer to the multicast list.
- DONE

1.8 Robert to provide information about LAN set-up; Dimitrios to provide pointer to Multicast information collected by Patrick de Muynck (formerly from BELNET).
- DONE by Robert: following the pointer to the Multicast SW and documentation repository at UCL,  which evolved during
the MICE, MERCI and MECCANO projects.  http://www-mice.cs.ucl.ac.uk/multimedia/software/ For those who are
interested in the projects:  http://www-mice.cs.ucl.ac.uk/multimedia/projects/meccano/

1.9 Roberto to change prefix of mailing lists at DANTE from qtp- to ngn-
- DONE

1.10 Victor to incorporate active network measurement in the QoS measurement plan.
- DONE

1.11 Victor to find partners and make plans for the practical experience with optical networking.
- DONE

1.12 Victor to investigate the Chariot monitoring tool support for multicast, and see if it can be provided for free to the TF-NGN group.
- DONE. It is not free, but for our environment the costing is 50% of the normal costs

1.13 Robert, Tiziana and Lada to refine the workplan for QoS & Multicast, which has relations with both premium IP and multicast services but was decided to be kept separate from them.
- ongoing

1.14 Dimitrios to work out a more specific proposal about IP VPN service and see what can be related to the premium IP service.
- ongoing

1.15 Tim to fix the priority areas and responsibility.
- ongoing

1.16 Tim and Bernard to work out a draft plan for set-up of the IPv6 testbed before the next TF-NGN meeting; RedIRIS will participate by installing an IPv6 router with ATM card.
- ongoing

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.
- ongoing
 

16. Open actions

1.2 GRnet to clarify plans for the OvpN activity within two weeks, + define network and resources requirements.
- ongoing

1.3 Tiziana and Mauro to provide support to GRnet in the definition of tasks and test plan for the OvpN activity.
- ongoing

1.6 Octavio, Tiziana, Tryfon and Mauro to coordinate testing with deadlines for the premium IP deliverable.
- ongoing

1.13 Robert, Tiziana and Lada to refine the workplan for QoS & Multicast, which has relations with both premium IP and multicast services but was decided to be kept separate from them.
- ongoing

1.14 Dimitrios to work out a more specific proposal about IP VPN service and see what can be related to the premium IP service.
- ongoing

1.15 Tim to fix the priority areas and responsibility.
- ongoing

1.16 Tim and Bernard to work out a draft plan for set-up of the IPv6 testbed before the next TF-NGN meeting; RedIRIS will participate by installing an IPv6 router with ATM card.
- ongoing

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.
- ongoing

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

2.2 Octavio to make plans for using PlaGE for AF-based testing.

2.3 Octavio, Tryfon, what equipment is needed to interconnect the PlaGE and the GARR-G testbeds and to take into account impact of ATM connection for testing the queueing techniques which may not work on ATM interfaces on high-end routers.

2.4 Tim, to gather information on the UK testbed and post it to the list.

2.5 Rüdiger to investigate what traffic testing kit is available from Abilene in 60 Hudson and how they can be used with SWITCH; Simon to verify the options from SWITCH's point of view in Geneva or Zurich.

2.6 Simon, Tryfon and Mauro to make plans for international tests.

2.7 Bernard to send his revision of the RIPE 196 document.

2.8, Roberto to distribute SW and documenmtation - DONE 

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