1. AIMS Workshop Heidelberg, 10 March 1998 ATM/IP in P613 End-to-End Service Testing Paola PARISE (CSELT) E-mail: paola.parise@cselt.it

2. AIMS Workshop Heidelberg, 10 March 1998 Background 1994: Memorandum of Understanding (MoU) for the availability of a European ATM Pilot PVC service Specification of Benchmark Services (Frame Relay, CBR, SMDS) 1996: James (Joint ATM Experiment on European Service) is responsible of the maintenance of the platform that was the ATM Pilot James and national ATM networks usable for international end-to-end service experimentation 1995: European ATM Pilot available for non commercial use P410 P613 End-to-End Service Testing for Pan-European ATM Networks Methods and Tools for B-ISDN and N-ISDN Integration Testing

3. AIMS Workshop Heidelberg, 10 March 1998 Methods and Tools for B-ISDN and N-ISDN Network Integration Testing Project Leader Marco Vecchiato CSELT P613

4. AIMS Workshop Heidelberg, 10 March 1998 Project Structure AU Post und Telekom Austria AG CH Swiss Telecom PTT DTDeutsche Telekom AG, Germany HTMatav HTC Ltd. ITCSELT/STET, Italy PTPortugal Telecom S.A., Portugal RBBelgacom, S.A. de Droit Public TETelefonica de Espana S.A., Spain Project budget: 18 MM Project start date: 10/9/96 Project completion date:30/9/98

5. AIMS Workshop Heidelberg, 10 March 1998 Node-to-Node and End-to-End Test Suites T1T2A B transit network Network Under Test access protocol network protocol T1T2A B M

6. AIMS Workshop Heidelberg, 10 March 1998 Main objectives of EURESCOM P613 ATM service testing –B-ISDN end-to-end (including interworking with N-ISDN) –B-ISUP node-to-node (including interworking with N-ISUP ) –IP over ATM –FR interworking Narrowband service interworking testing –GSM –N-ISDN –POTS Validation through a test execution experiment

7. AIMS Workshop Heidelberg, 10 March 1998 Test methodology The project develops for each type of service a well defined set of documents: Test Suite Structure and Test Purposes ( TSS&TP ), Implementation Conformance Statement and Implementation eXtra Information for Testing ( ICS&IXIT ), Abstract Test Suite ( ATS ). The ATS (the main technical document) can be written in TTCN or described by other means. Several test sessions will be performed to validate the project results in a real environment (e.g. international networks or experimental contexts)

8. AIMS Workshop Heidelberg, 10 March 1998 IP over ATM Service Specification Classical IP over ATM (IETF RFC 1577) Tag Switching (IETF RFC 2105 Informational) I-PNNI (ATM Forum) NHRP (IETF) IP switching (IETF RFC 1953, 1954, 1987Informational) MPOA (ATM Forum) Somebody knows how IP has to be transported over an ATM SVC Network... MPOA Almost stable specification issued by ATM Forum Support of MPOA is foreseen in 1997 by many manufacturers Incorporates NHRP Project results will be baselines for testing specification on other service configuration

9. AIMS Workshop Heidelberg, 10 March 1998 P613 IP over ATM End-to-End Service Testing Following ATM Forum MPOA (Multiprotocol over ATM) Specification, the project will issue Functional Abstract Test Suite –(Is the IP datagram delivered?) Performance Abstract test Suite –(How fast, reliable the IP datagram delivery is?)

10. AIMS Workshop Heidelberg, 10 March 1998 Service reference configuration MPOA Server MPOA Client PCO 3 PCO 1 PCO 2 ATM PCO: Point of Control and Observation MPOA: MultiProtocol Over ATM

11. AIMS Workshop Heidelberg, 10 March 1998 How QoS Measurement is Approached in P613: Performance Testing (1) Benchmark methodology issued by IETF BMWG (Benchmark Methodology Working Group) in Request for Comment RFC 1944 Throughput ( Maximum rate at which none of the offered frames are dropped by the network) Packet Loss Ratio ( Maximum rate at which none of the offered frames are dropped by the network) Latency ( The one-way network latency is the time interval starting when the last bit of the input frame reaches the input port and ending when the first bit of the output frame is seen on the output port of the network) Back to Back capacity( The back-to-back capacity measurement uses fixed length frames presented at a rate such that there is the minimum legal separation for a given medium between frames over a short to medium period of time, starting from an idle state)

12. AIMS Workshop Heidelberg, 10 March 1998 Benchmark Applications : Ping FTP Spray Videoconferencing How QoS Measurement is Approached in P613: Performance Testing (2) Server Specific Performance Measurement: ATM address resolution is always achieved by means of Servers that could be the bottlenecks of service performance. It is therefore useful to measure time needed to reply to a query number of simultaneously active shortcuts...

13. AIMS Workshop Heidelberg, 10 March 1998 Performance Testing (3) Other Parameters % Service Unavailability due to ATM impairment % outages due to Server unavailability... New! IETF BMWG is working on IPPM (IP Provider Performance Metrics) for the definition of Benchmark tools to measure service outages and other relevant parameters.

14. AIMS Workshop Heidelberg, 10 March 1998 IETF Issll (Integrated services over specific lower layer) is defining the modalities of mapping an IP service class into an ATM SVC. Empirical approach could help: Analytical approach could help Thr, Flr, Lat =f(CLR, CER, CDT,CDV, T set-up, T release ) Mapping ATM QoS into IP QoS CLRCER CDV T set-up T release CTD THR FLR LAT

15. AIMS Workshop Heidelberg, 10 March 1998 Open Issues and Future Work on Performance Testing Difficulties in testing phase automation Only few testing equipment implement the needed protocol stack Simultaneous monitoring of underlying ATM layer is considered useful Research Communities and Labs are working on distributed service monitoring and testing

16. AIMS Workshop Heidelberg, 10 March 1998 Conclusions P613 perceives the need of performance measurement and is proceeding with the description of methodology to assess the QoS given to users. Commercial offerings should be based on guarantees of QoS to a customer. In this case a Resource Reservation Set-up mechanism (RSVP) that acts on Network Elements could be the only applicable solution. MPOA and other architectures that base QoS provision on the ATM/IP integration constitute a technological improvement. Once IP services become differentiated on a QoS basis other effort on service provisioning aspects should be done (i.e. accounting, acceptance policies,...)