INTERNATIONAL TELECOMMUNICATION UNION

COM 4 – LS 13 – E

TELECOMMUNICATION
STANDARDIZATION SECTOR

STUDY PERIOD 2001-2004

 

Original: English

Question(s):

4/4

5 - 14 February 2003

Ref. : TD 53 (Rev.2) (PLEN)

Source:

ITU-T Study Group 4

Title:

Framework of new Recommendation O.iptest

LIAISON STATEMENT

To:

IETF ippm WG chairs (Merike Kaeo, Matthew Zehauskas)

IETF Area Directors for Operations and Management (Scott Bradner, Allison Mankin)

IETF email address for liaison statements

Approval:

ITU-T SG4 meeting, Geneva, 5 – 14 February 2003

For:

Information/Action

Deadline:

1 June 2003

Contact:

Wolfgang Miller

Acterna

Germany

Tel: +49 7121 861328

Fax: +49 7121 862029

Email:wolfgang.miller@acterna.com

 

ITU-T SG4 is pleased to inform the IETF that a new topic is discussed with regard to performance measurements of IP networks and services.

Question 4 of Study Group 4 is standardizing test and measurement equipment. In February 2003 SG4 discussed a new draft Recommendation, O.iptest , focusing on the standardization of a test packet format to perform tests of IP based networks and services.

Regarding this topic, ITU-T  SG4 would like to cooperate with the related WG of the IETF, such as the IPPM WG.

The framework of the draft Recommendation is described below:

 

1 – Scope

In order to support provisioning and maintenance of IP-based networks, in order to measure the performance of IPv4 and IPv6 networks and services for different Type-P [RFC2330], a common standard IP Test Packet format is desirable such that interoperability between heterogeneous test equipment and comparison of measurement results can be achieved.

 


2 – Requirements

A standard IP test packet should meet the following requirements:

v Network level: It is necessary to define a test packet suitable for performing the measurement of existing IP performance metrics and flexible enough to permit proprietary extension and new format definition in the future. The format should be compatible with all SUB-IP media on IP versions and should allow accurate measurements in the Gbit range.

 

v Application level: The concern is not only the performance measurement of IP networks, but of numerous application services. To permit IP test packets to be transported in the same manner as regular application packets, it is necessary to use test packets with the same behaviour as regular packets of the tested IP service. The IP test packet format defined should accept the header of any regular IP application.

 

v Interoperability: There is a need for interoperability between instruments of different manufacturers to monitor consistently network performance and QoS. That will offer measurement results comparison against SLAs and correlation between measurement points and instruments.

 

v Inter-domain interoperability: This is motivated by the need to perform end-to-end tests across administrative areas and composite networks.

It is necessary to increase operational interoperability by promoting the sharing of the same measurement identification mechanism in the test packet to permit the managers of the measurement systems to exchange results among administrative domains.

 

 

3 – Test packet format

It is proposed to adopt a standard format for IP test packets. The currently proposed test packet consists of Sub-IP header and trailer, IP header, data block and an IP measurement signature (IMS).

 

 

 

 

Signature format

The signature block is explained below, showing the various fields of IMS.

 

 

 

 


ID:         Identifier to differentiate test packets from regular packets

Ver:       Version number

Type:     permits to categorize measurement packet types

Ext:        Proprietary extension size

SN:        Sequence number

Timestamp:   Wire time the packet was sent

Measure ID: Identifier of the measure in the initiator scope

Owner ID:    Initiator of the measure

Specific:       Proprietary extension

 

The signature is flexible enough to define several classes of measurement packets, mainly transport and application classes.

 

 

Signature classes

Some examples of signature classes are given hereafter, for illustration purpose only:

 

 

Classes

Length data

Extension

Type

Signature length (bytes)

Applications

VoIP

RTP SDU- Signature

0

1

20

HTTP

variable

1

1

28

Transport

UDP

variable

0

1

20

TCP

variable

1

1

28

Network

IPv4

variable

0

1

20

IPv6

variable

0

1

20

 

 

We would appreciate any comments or remarks on the framework of this new Recommendation O.iptest.

_______________________________