[ippm] Implementation report

["Yves Cognet" <[e-mail]>]

Hi all
I'm not sure this is the right channel, but we do have an iplementation of
IPPM and you will find some more detail herafter. We are working closely
with FT R&D Emile Stephan on several subjects including the IPPM MIB.
Feel free to contact me or us
regards
Yves Cognet
President
[e-mail]


General
=======

Name of Implementation:       NetWarrior

Organization:                       QoSmetrics, SA.

Contact details:                   QoSmetrics, Inc.
                             Joe Ovanesian VP Engineering
                              802 Calle Plano
                              Camarillo, CA 93012 USA
                              [e-mail]
                              www.qosmetrics.com


Origin of code:        Written from scratch.

Platform:                Last release run on Linux 2.4.22
                             Hardware time stamping engine TSE (tx and rx)
with built-in GPS and TXC0

                             This platform is running IPv4 and IPv6, PPPoE
with both static, dynamic and Nated IP address.
                             The platform has been tested in both ipv4 and
ipv6 environment  (except PPPoE)


Metrics considered
----------------------------
RFC2330   IPPM sync method
RFC2678   Connectivity
RFC2679   One way delay
RFC2680   Packet Loss
RFC2681   Round trip Delay


RFC2678/Type-P-Instantaneous-Bidirectional-Connectivity
-------------------------------------------------------
Parameters:                                 Implemented?
 + Src, the IP address of a host            Yes
 + Dst, the IP address of a host            Yes
 + T, a time                                         Yes
 + TTL                                                 Yes
 + payload length                                 Yes
 + TOS/DSCP                                      Yes
+ VLAN                                               Yes

Units:
 + dT                                                   Yes

Methodology:
 + According to section 3.1 of RFC 2678
 + Synchronization via TSE card
 + Timestamping in hardware via TSE card

Comments (Type-P):
 + TCP packets are being used over ipv4 and ipv6.
 + TCP checksum is over written when the frame is sent and when the TSE is
appending the time stamp
 + The port numbers for test traffic can be specified
 + User data length is user defined
 + access to special IP bits ( TOS/DSCP values )
 + If a packet is duplicated, any duplicates are counted (the delay of
    the first packet to arrives is used).
 + Corrupted packets are counted as lost; they will
    fail either a hardware CRC check, or IP or UDP checksum verification.

Features included:
 + path variation (TTL variation)

Features not implemented:

Reporting the metric:
 + all results are recorded in an SQL database, good and bad records (lost
of synchronization)
 + all timestamps are reported in UTC
 + local aggregation can be done
 + TTL variation are being recorded


RFC2679/Type-P-One-way-Delay
----------------------------

Parameters:                                 Implemented?
 + Src, the IP address of a host            Yes
 + Dst, the IP address of a host            Yes
 + T, a time                                        Yes
+ Payload                                           yes
+ VLAN ID                                          Yes

Units:
 + dT                                                  Yes

Methodology:
 + According to section 3.6 of RFC 2679
 + Synchronization via TSE card
 + Timestamping in hardware via TSE card

Comments (Type-P):
 + UDP and TCP packets are being used over ipv4 and ipv6.
 + TCP checksum is over written when the frame is sent and when the TSE is
appending the time stamp
 + The port numbers for test traffic can be specified
    among sessions, although for any given session port numbers were fixed
 + User data length was 12 bytes (32 bit sequence number, 64 bit time value)
 + access to special IP bits ( TOS/DSCP values )
 + If a packet is duplicated, any duplicates are counted (the delay of
    the first packet to arrives is used).
 + Corrupted packets are counted as lost; they will
    fail either a hardware CRC check, or IP or UDP checksum verification.

Features included:
 + If either end lost synchronization (as reported by the TSE
    timing card) the session is kept but results are marked invalid.
 + path variation (TTL variation)

Features not implemented:

Reporting the metric:
 + all results are recorded in an SQL database, good and bad records (lost
of synchronization)
 + The loss threshold is 1 received packets for UPD traffic.
 + all timestamps are reported in UTC
 + local aggregation can be done
 + TTL variation are being recorded

Tests performed:
 + calibration, measured time uncertainty is in the 450 ns range end to end
once TSE cards are in sync


RFC2679/Type-P-One-way-Delay-Poisson-Stream
-------------------------------------------
not implemented

RFC2679/Type-P-One-way-Delay-Percentile
---------------------------------------
By default, the 50th percentile (median) and 90th percentile are calculated
and reported for x minute intervals.(user setup)

RFC2679/Type-P-One-way-Delay-Median
-----------------------------------
This value can be calculated and reported from the database


RFC2679/Type-P-One-way-Delay-Minimum
------------------------------------
This value is reported for x minute intervals (user setup)


RFC2679/Type-P-One-way-Delay-Inverse-Percentile
-----------------------------------------------
Not implemented.


RFC2680/Type-P-One-way-Packet-Loss
----------------------------------

Metric Parameters:                                  Implemented
 +  Src, the IP address of a host                    Yes
 +  Dst, the IP address of a host                    Yes
 +  T, a time                                        Yes

Metric Units:
 + Type-P-One-way-Packet-Loss                         Yes

Comments:
 + The time is the time the packet was sent, (40 nano second ticks).
 + Packets that arrive at the machine corrupted are dropped (CRC failure or
by IP or UDP checksum failure)
 + If a packet is duplicated, any duplicates are ignored.


RFC2680/Type-P-One-way-Packet-Loss-Poisson-Stream
-------------------------------------------------
Not implemented

RFC2680/Type-P-One-way-Packet-Loss-Average
------------------------------------------
Not implemented

RFC2681   Round trip Delay
--------------------------
Not implemented , comuted - (we make use of One Way Delay)


Other features implemented
--------------------------
Our system is implementing the E Model as defined by ITU for accumulated
loss and jitter over period of time
IPPM MIB (experimental) - the test has been done with FT R&D Lannion and San
Francisco: contact name Emile Stephan
IPFIX (passive monitoring)

_______________________________________________
ippm mailing list
[e-mail] 
https://www1.ietf.org/mailman/listinfo/ippm