Transcript 10Paola

ATM/IP
in
P613 End-to-End Service Testing
Paola PARISE (CSELT)
E-mail: [email protected]
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)
1995: European ATM Pilot available for non commercial use
P410
End-to-End Service Testing for
Pan-European ATM Networks
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
P613
Methods and Tools for B-ISDN
and N-ISDN Integration Testing
AIMS Workshop
Heidelberg, 10 March 1998
P613
Methods and Tools for B-ISDN and N-ISDN
Network Integration Testing
Project Leader Marco Vecchiato CSELT
AIMS Workshop
Heidelberg, 10 March 1998
Project Structure
PT
RB
HT
DT
CH
TE
AU
CH
DT
HT
IT
PT
RB
TE
Post und Telekom Austria AG
Swiss Telecom PTT
Deutsche Telekom AG, Germany
Matav HTC Ltd.
CSELT/STET, Italy
Portugal Telecom S.A., Portugal
Belgacom, S.A. de Droit Public
Telefonica de Espana S.A., Spain
IT
AU
Participants
AIMS Workshop
Heidelberg, 10 March 1998
Project budget:
18 MM
Project start date:
10/9/96
Project completion date: 30/9/98
Node-to-Node and End-to-End
Test Suites
M
T1
T1
A
A
transit
network
Network Under Test
AIMS Workshop
Heidelberg, 10 March 1998
B
T2
B
T2
access protocol
network protocol
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
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)
AIMS Workshop
Heidelberg, 10 March 1998
IP over ATM Service
Specification
Classical IP over ATM
(IETF RFC 1577)
I-PNNI
(ATM Forum)
Somebody knows how IP
has to be transported over
an ATM SVC Network ...
NHRP
(IETF)
IP switching
(IETF RFC 1953, 1954,
1987Informational)
Tag Switching
(IETF RFC 2105
Informational)
MPOA
(ATM Forum)
MPOA
Almost stable specification issued by ATM Forum
Support of MPOA is foreseen in 1997 by many
manufacturers
Incorporates NHRP
AIMS Workshop
Heidelberg, 10 March 1998
Project results will be baselines for testing
specification on other service configuration
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?)
AIMS Workshop
Heidelberg, 10 March 1998
Service reference configuration
MPOA Server
PCO 2
PCO 3
PCO 1
MPOA Client
ATM
MPOA Client
PCO: Point of Control and Observation
MPOA: MultiProtocol Over ATM
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)
AIMS Workshop
Heidelberg, 10 March 1998
How QoS Measurement is Approached in
P613: Performance Testing (2)
Benchmark Applications:
Ping
FTP
Spray
Videoconferencing
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
...
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.
AIMS Workshop
Heidelberg, 10 March 1998
Mapping ATM QoS into IP QoS
• 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:
CLR
CER
CTD
CDV
Tset-up Trelease
THR
FLR
LAT
• Analytical approach could help
Thr, Flr, Lat =f(CLR, CER, CDT,CDV, Tset-up, Trelease)
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
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.
MPOA and other architectures that base QoS provision on the
ATM/IP integration constitute a technological improvement.
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.
Once IP services become differentiated on a QoS basis other effort
on service provisioning aspects should be done (i.e. accounting,
acceptance policies, ...)
AIMS Workshop
Heidelberg, 10 March 1998