Fusion Performance Monitoring (PM)

MA API Guide
Virtual Performance Monitoring Measurement
Agents for TWAMP

Version 4.1

Confidential
Viavi Solutions
1-844-GO-VIAVI / 1-844- 468-4284
www.viavisolutions.com
Notice

Every effort was made to ensure that the information in this manual was accurate at the time of printing.
However, information is subject to change without notice, and Viavi reserves the right to provide an
addendum to this manual with information not available at the time that this manual was created.
Copyright

© Copyright 9 December 2018 Viavi Solutions Inc. All rights reserved. Viavi and the Viavi logo are
trademarks of Viavi Solutions Inc. (“Viavi”). All other trademarks and registered trademarks are the
property of their respective owners. No part of this guide may be reproduced or transmitted, electronically
or otherwise, without written permission of the publisher.
Trademarks

VIAVI is a trademark or registered trademark of VIAVI in the United States and/or other countries.

Specifications, terms, and conditions are subject to change without notice. All trademarks and registered
trademarks are the property of their respective companies.
Terms and conditions

Specifications, terms, and conditions are subject to change without notice.

Fusion PM MA APIs
Page 3 Confidential 9 December 2018
ContentsReferences .................................................................................................................................. 7

Overview 8

Device Information APIs .......................................................................................................................... 11

LMAP State API ........................................................................................................................ 11

Viavi Custom Capabilities API ................................................................................................... 12

Device Configuration API ........................................................................................................................ 16

Settings task .............................................................................................................................. 16

Test-Specific Data .................................................................................................................................... 19

TWAMP Configuration Submission................................................................................ 19

Functionality Common to TWAMP Initiator and Reflector Configuration .................................... 19

TWAMP Initiator Test Submission ............................................................................................. 20

TWAMP Reflector Submission .................................................................................................. 32

TWAMP Light Reflector Submission ......................................................................................... 34

TWAMP Results ............................................................................................................ 36

TWAMP Initiator Results ........................................................................................................... 36

TWAMP Reflector Status .......................................................................................................... 40

Fusion PM MA APIs
Page 5 Confidential 9 December 2018
 Contents

Document Change History

Date Revision Author Description of Changes
Oct 11, 2016 1.0 Ron Stana Initial Draft

Jun 20, 2018 2.0 Cathy Addition of twamp light

Cunningham
Oct 1 2018 2.0.1 Ron Stana Addition of twamp-keep-alive-interval for reflectors such as Huawei

Oct 3, 2.1 Cathy Document changes in support of Fusion PM

2018 Cunningham
Dec 4, 2018 4.1 Ron Stana Added support of QT-600-10

Fusion PM MA APIs
Page 6 Confidential 9 December 2018
 References

A. A Framework for Large-Scale Measurement of Broadband Performance

https://tools.ietf.org/html/rfc7594 (RFC-7594 September 2015)

B. Information Model for Large-Scale Measurement Platforms

https://tools.ietf.org/html/draft-ietf-lmap-information-model-09 (Draft version 9)

C. YANG Data Model for LMAP

https://tools.ietf.org/html/draft-ietf-lmap-yang-04 (Draft version 4)

D. YANG Modeling Language

https://tools.ietf.org/html/rfc6020

E. Viavi Controller/Collector APIs (version 1.0)

Available upon request from Viavi

F. TWAMP Data Model

https://tools.ietf.org/html/draft-cmzrjp-ippm-twamp-yang-02 (Draft version 2)

G. Data Model for Twamp light

https://tools.ietf.org/html/draft-mirsky-ippm-twamp-light-yang-03

Fusion PM MA APIs
Page 7 Confidential 9 December 2018
 1
Overview

The Fusion application supports the following Performance Monitoring (PM) tests:

• TWAMP and TWAMP Light initiator

• TWAMP Reflector
• TWAMP Light Reflector

These tests are supported by these Measurement Agents (MA):

• vPMA
• QT-600-10

The purpose of this document is to explain the APIs used in executing tests and obtaining results that are
specific to these MAs and these tests.

This document contains the following chapters:

1. Device Information APIs

• describes APIs that provide information about the capabilities of the device

2. Test Specific APIs

• describes test parameters and results for each test type

The APIs follow the LMAP documentation [References A,B,C]. LMAP defines common APIs for test
submission, test termination, test status retrieval and result reporting. See the Viavi Controller/Collector API
document (Reference E) for an explanation of these APIs. LMAP is a delivery mechanism for test-specific
information. Since the delivery is the same for all device types it is only explained in the Viavi
Controller/Collector API document. Therefore the Controller/Collector API document and this document
together explain the API.

LMAP is still an evolving specification at the time of this writing. Every effort has been made to follow the
LMAP specification in the areas that support the functionality of this measurement agent. Not all functionality
defined by LMAP is needed and some extensions are required. These differences will be identified in this
document and in the Viavi Controller/Collector API document.

Similarly, this test uses an existing TWAMP model for test configuration. Functionality not supported in that
model and functionality that extends beyond that model will be identified.

Statements common across all APIs supported by this measurement agent:

Fusion PM MA APIs
9 December 2018 Confidential Page 8
 Chapter 1

1. The APIs will be implemented using RESTCONF

2. The APIs will accept and return only JSON formatted data.
3. The communication between the Controller, Collector and MA will not be authenticated or encrypted
in this release.

Fusion PM MA APIs

9 December 2018 Confidential Page 9

 3

Device Information APIs

The following APIs are used to learn identity, capability and predefined information on the MA:

• LMAP state
• Viavi custom capabilities
LMAP State API

LMAP state refers to an HTTP GET request for /restconf/data/ietf-lmap-control:lmap-state. This API
returns the MA’s id, device id, software version and a list of supported tests.

The following is a response from a vPMA:

{
"ietf-lmap-control:lmap-state": {
"tasks": {
"task": [
{
"version": "1.0",
"name": "twamp-initiator"
},
{
"version": "1.0",
"name": "twamp-reflector"
},
{
“version”: “1.0”,
“name”: “twamp-light-reflector”
},
{
"version": "1.0",
"name": "results"
}
]
},
"agent": {
"last-started": "2016-10-10T17:42:52+00:00",
"firmware": "",
"device-id": "urn:viavisolutions:model:vPMA:mac:%52%54%00%EA%81%39",
"agent-id": "3a9846f6-8681-11e6-8c56-525400ea8139",
"hardware": "",
"version": "1.0"
},
"schedules": {
"schedule": [

Fusion PM MA APIs
9 December 2018 Confidential Page 11
Chapter 2

...
],
}
}
}

The list of task names include ‘twamp-initiator’, ‘twamp-reflector’ and ‘twamp-light-reflector’ for vPMA. The
‘results’ task is common across Viavi measurement agents so it is described in the Viavi Controller/Collector
API document.

The device-id contains the vendor (Viavi Solutions), model (vPMA or QT600-10) and MAC address of the
management interface.

The agent-id is an unique identifier for the device and is generated when the measurement agent is booted
up for the first time. The agent-id remains the same value for the life of the measurement agent.

For additional information about this LMAP API see the Viavi Controller/Collector API document.

Viavi Custom Capabilities API

Information beyond what can be provided by the LMAP State API is returned through an HTTP GET request
for /restconf/data/capabilities. This API returns information such as the number of simultaneous tests and
maximum number of TWAMP control sessions and flows that are supported.

The following is a response from a vPMA:

{
"capabilities": {
"phy": {
"link-speed": "1G",
"virtualization": "VIRTIO",
"tagging": "UNTAGGED",
"dpdk": "no"
},
"software": {
"agent-upgrade": "1.0.14-r0",
"ma-python-executor": "1.1.0.0-3-g2470720-r2",
"maf-portal": "1.1.0.0-2-g6e087ff-r1",
"vpma-maf": "1.1.0.0-127-g4203943-r0"
},
"properties": {
"max-concurrent-commands": "2",
"max-concurrent-tests": "5"
},
"timers": {
"heartbeat_interval_mins": "5"
},
"upgrade": {
"max-concurrent-commands": "1"
},
"diagnostics": {
"max-concurrent-commands": "1"
},
"twamp-reflector": {

Fusion PM MA APIs

Page 12 Confidential 9 December 2018

 "max-control-sessions-per-test": 500,
"max-frame-size": 1518,
"max-flows-per-test": 500,
"max-concurrent-tests": 1
},
“twamp-light-reflector”: {
“max-flows-per-test”: 500
“max-concurrent-tests”: 1
“max-frame-size”: 1518
},
"twamp-initiator": {
"max-control-sessions-per-test": 500,
"max-frame-size": 1518,
"max-flows-per-test": 500,
"max-concurrent-tests": 4
},
"system": {
"hostname": "myVPMA",
"ram": 493,
"os": "Linux i686",
"num-cores": 1
}
}
}

Fusion PM MA APIs

9 December 2018 Confidential Page 13

Chapter 2

The following is a response from a QT-600-10:

{
"capabilities":{
"phy-list":[
{
"default-test-gateway":"192.168.57.1",
"default-test-ip":"192.168.57.219",
"default-test-mask":"255.255.255.0",
"external-test-ip":"192.168.57.219",
"link-speed":"10G",
"max-frame-size":1500,
"name":"QT600-10_61_133_P1",
"phy-id":"p1",
"tagging":"UNTAGGED",
"test-mac-address":""
},
{
"default-test-gateway":"192.168.58.1",
"default-test-ip":"192.168.58.219",
"default-test-mask":"255.255.255.0",
"external-test-ip":"192.168.58.219",
"link-speed":"10G",
"max-frame-size":1500,
"name":"QT600-10_61_133_P2",
"phy-id":"p2",
"tagging":"UNTAGGED",
"test-mac-address":"00:10:4e:0a:05:20"
}
],
"system":{
"hostname":"QT600-10_61_133",
"num-cores":2,
"os":"Linux 4.4.55",
"ram":1851
},
"truespeed-list":[
{
"max-bandwidth":10000,
"max-concurrent-tests":1,
"phy-id":"p1",
"public-access":false,
"tcp-ports":[
8080
]
},
{
"max-bandwidth":10000,
"max-concurrent-tests":1,
"phy-id":"p2",
"public-access":true,
"public-access-ip":"192.168.58.219",
"public-access-port":80,
"tcp-ports":[
8081
]
}
],
"twamp-initiator-list":[
{
"max-concurrent-tests":1,
"max-control-sessions-per-test":4000,
"max-flows-per-test":8000,
Fusion PM MA APIs
"max-frame-size":1518,
Page 14 "phy-id":"p1" Confidential 9 December 2018
},
 {
"max-concurrent-tests":1,
"max-control-sessions-per-test":4000,
"max-flows-per-test":8000,
"max-frame-size":1518,
"phy-id":"p2"
}
],
"twamp-light-reflector-list":[
{
"max-concurrent-tests":1,
"max-flows-per-test":8000,
"max-frame-size":1518,
"phy-id":"p1"
},
{
"max-concurrent-tests":1,
"max-flows-per-test":8000,
"max-frame-size":1518,
"phy-id":"p2"
}
],
"twamp-reflector-list":[
{
"max-concurrent-tests":1,
"max-control-sessions-per-test":4000,
"max-flows-per-test":8000,
"max-frame-size":1518,
"phy-id":"p1"
},
{
"max-concurrent-tests":1,
"max-control-sessions-per-test":4000,
"max-flows-per-test":8000,
"max-frame-size":1518,
"phy-id":"p2"
}
]
}
}

Fusion PM MA APIs

9 December 2018 Confidential Page 15

 3
Device Configuration API
The system configuration API enables customization of certain device-wide values. In particular, the
vPMA allows configuration of two items related to overlays: tasks and flows.

• overlayflows – determines how many (f) twamp initiator flows are reserved for use in overlays.
The remaining flows (500-f) are then available for “ad-hoc” testing.
• overlaytasks – determines how many tasks (t) are reserved for us in overlays. The remaining
tasks (5-t) are available for “ad-hoc”testing.

Settings task
A task with the name 'settings' is processed by the MAF portal specially. It supports the POST and
GET verbs. It is used to update and read device configuration values.
Use GET to read all attributes (GET /restconf/data/ietf-lmap-control:lmap). Here is an example re-
sponse:

Response
{
"ietf-lmap-control:lmap":{
"agent":{
"agent-id":"11111111-1111-1111-1111-111111111117"
},
"tasks":{
"task":[
{
"name":"settings",
"option":[
{
"id":"LMAP.controller_addr",
"value":"dev.observer.live"
},
{
"id":"LMAP.controller_port",
"value":"443"
},
{
"id":"LMAP.heartbeat_sec",
"value":"180"
},
{
"id":"LMAP.heartbeat_url",
"value":""
},

Fusion PM MA APIs
9 December 2018 Confidential Page 16
 {
"id":"LMAP.test_status_post_sec",
"value":"14"
},
{
"id":"LMAP.test_status_url",
"value":""
},
{
"id":"LMAP.request_poll_sec",
"value":"30"
},
{
"id":"LMAP.msg_queue_request_url",
"value":""
},
{
"id":"LMAP.msg_queue_reply_url",
"value":""
},
{
"id":"LMAP.upload_url",
"value":""
},
{
"id":"LMAP.logging_url",
"value":""
},
{
"id":"LMAP.alt_controller_addr",
"value":""
},
{
"id":"LMAP.alt_controller_port",
"value":"443"
},
{
"id":"LMAP.alt_registration_url",
"value":"/registration/v2/call-home"
}, {
"id":"overlay.overlaytasks”,
"value":"2"
}, {
"id":"overlay.overlayflows”,
"value":"80"
}
]
}
]
}
}
}

Use POST to update one or more attributes (POST /restconf/data/ietf-lmap-control:lmap). Here is an

example:

Request

Fusion PM MA APIs

9 December 2018 Confidential Page 17

Chapter 2

{
"ietf-lmap-control:lmap":{
"tasks":{
"task":[
{
"name":"settings",
"option":[
{
"id":"overlay.overlaytasks",
"value":"3"
},
{
"id":"overlay.overlayflows,
"value":"100"
}
]
}
]
}
}
}

Fusion PM MA APIs

Page 18 Confidential 9 December 2018

 4

Test-Specific Data

The following tests are supported by these measurement agents:

• TWAMP Initiator (supports connections to both standard Twamp Reflectors, and Twamp Light
Reflectors)
• TWAMP Reflector (referred to in this document as standard TWAMP)
• TWAMP Light Reflector

Test submission, status retrieval and result posting follow the LMAP document. These interfaces use a
combination of the LMAP data model and test-specific data. For additional information about the LMAP data
models see the Viavi Controller/Collector API document.

The parameters to start the test will be placed in the ietf-lmap-control:lmap/schedules/schedule/action/options

object as a JSON structured value for a parameter with a specific id: ‘twamp’. The structured value shall be in
string format per the LMAP model. The content of the structured value will follow the TWAMP YANG model
specified by Reference F. Additional parameters needed for the test that are not defined by the TWAMP YANG
model are specified in additional id/value pairs. All of these test specific parameters are defined in the chapter.

The results from the TWAMP Initiator test will be sent in a table format following the LMAP model. The unique
set of statistics that make up each table are defined in this chapter.

The TWAMP Reflector tests do not send a formal set of results; instead the LMAP State response will include
information such as how many TWAMP control sessions and flows are being reflected. This information is
defined in this chapter.

TWAMP Configuration Submission

Functionality Common to TWAMP Initiator and Reflector Configuration

1. Each MA supports execution of multiple tests simultaneously. The limit is specified by the value of ‘max-
concurrent-tests’ in the Custom Capabilities API.
a. For the vPMA this is a maximum of 4 TWAMP initiator tests or 3 TWAMP Initiator tests plus one
TWAMP reflector (either standard or Light) configuration. Tests submitted after the limit has
been reached will be rejected.

Fusion PM MA APIs
9 December 2018 Confidential Page 19
 b. For the QT-600-10 this is a maximum of one TWAMP initiator test and one TWAMP reflector test
per test port.
2. Each MA will initiate/respond to a maximum number of standard TWAMP control sessions (Session-
Requests per the TWAMP YANG model). The limit is specified by the value of ‘max-control-sessions’ in
the Custom Capabilities API.
a. For the vPMA this is a maximum of 500. This is a total value across all tests so once it has been
reached additional TWAMP sessions will stop being requested/accepted.
b. For the QT-600-10 this is a maximum of 4000 per test port, however due to a limitation of the
NETCONF API, the maximum is 500 sessions per test port.
3. Each MA will initiate/respond to a maximum amount of TWAMP flows (Session-Senders and Session-
Reflectors per the YANG model). The limit is specified by the value of ‘max-flows’ in the Custom
Capabilities API.
a. For the vPMA this is a maximum of 500. This is a total value across all tests so once it has been
reached additional TWAMP flows will stop being requested/accepted. An exception to this is the
TWAMP Light Reflector, as there is no connection establishment; a TWMAP Light Reflector will
reflect all traffic that matches its IP and port configuration.
b. For the QT-600-10 this is a maximum of 8000 per test port, however due to a limitation of the
NETCONF API, the maximum is 500 flows per test port.
4. Test schedules will support being started immediately. They will start immediately and run until they are
manually terminated.
5. If a schedule is sent to the MA using HTTP PUT and the MA already has a schedule with the same
name, the HTTP PUT will be rejected. The current test schedule will need to be manually terminated
(using HTTP DELETE) before the updated test schedule can be started (using HTTP POST).
6. Updates to a test can be done using HTTP PATCH. The only changes supported on updates are the
addition or deletion of flows, and the specification of a time to stop posting realtime results.
7. An attempt to start a new test schedule (HTTP POST of LMAP config to MA) that contains the same
schedule name as an existing schedule on the MA will be rejected by the MA. LMAP requires each
schedule to have a unique name.
8. Upon MA reboot previously running tests will be restarted automatically.

TWAMP Initiator Test Submission

Separate MAs are used to execute the TWAMP Initiator and TWAMP Reflector functionality. Upon startup the
MA waits for requests to start a test. Using the IETF TWAMP YANG model definitions, the TWAMP Initiator
represents the TWAMP Client and Session-Senders portions of the TWAMP Test.

Simultaneous TWAMP initiator tests will be required to have unique source IP addresses. The Initiator supports
sessions with both standard TWAMP destinations and TWAMP Light destinations in the same test request.
They are discussed separately in the following text, with a final example that shows both being used together.

TWAMP Initiator test overview, for standard destinations

1. For each Control-Client-Connection act as a TWAMP Client and create a TCP connection to the Server-
IP/Server-Tcp-Port specified in the message

Fusion PM MA APIs

Page 20 Confidential 9 December 2018

 2. Once the connection is established, send the Session-Request messages contained in the Control-
Client-Connection portion of the RESTConf POST message to the TWAMP Server.
3. Upon successful acknowledgement of the Session-Requests, create a TWAMP Session for each of the
Session-Senders specified in the test configuration.
4. For each TWAMP Session, transmit UDP packets to SessionRequest.Reflector-IP/Reflector-UDP-Port at
the Sender-Test-Session.Periodic-Interval. In this implementation, the Sender-Test-Session.Periodic-
Interval must be specified in Sender-Test-Session.Periodic-Interval-Units.milliseconds with the possible
values of 10, 20, 100, 1000, or 2000.
5. The size of the TWAMP packets for each TWAMP Session is specified by the ‘padding-length’. In this
implementation the range of valid values is 0-1431 instead of 64-4096 that the TWAMP YANG model
defines. A value of 0 will produce a total frame size of 87 bytes and a value of 1431 will produce a total
frame size of 1518 bytes.
6. Results are sent to the Collector using an address specified in the Result schedule portion of the
configuration.
7. Simultaneous TWAMP initiator tests will be required to have a unique source IP address.
8. When instances of the TWAMP initiator test are submitted to the Viavi Controller, a limit of 175 TWAMP
sessions will be accepted per test.

TWAMP Initiator test parameters for standard destinations

The IETF TWAMP YANG Model defines the parameters to setup the TWAMP Client and Session-Senders. A
copy of that model is show next with fields not supported identified in the comments.
+--rw twamp
+--rw twamp-client! {control-client}?
| +--rw client-admin-state Boolean
| +--rw mode-preference-chain* [priority] // list with one element
| | +--rw priority uint16 // 1
| | +--rw mode? Mode // bits.unauthenticated
| +--rw key-chain* [key-id] // N/A – keys are not used in this
implementation
| | +--rw key-id string
| | +--rw secret-key? string
| +--rw twamp-client-ctrl-connection* [ctrl-connection-name]
| +--rw ctrl-connection-name string
| +--rw client-ip? inet:ip-address
| +--rw server-ip inet:ip-address
| +--rw server-tcp-port? inet:port-number // 862
| +--rw dscp? inet:dscp // 0
| +--rw key-id? String // N/A – keys are not used in this
implementation
| +--rw max-count? uint32 // N/A – not supported in this
implementation
| +--rw twamp-session-request* [test-session-name] // list of TWAMP Flows
| +--rw test-session-name string
| +--rw sender-ip? inet:ip-address
| +--rw sender-udp-port? inet:port-number
| +--rw reflector-ip inet:ip-address
| +--rw reflector-udp-port? inet:port-number
| +--rw timeout? uint64
| +--rw padding-length? uint32
| +--rw dscp? inet:dscp
| +--rw start-time? uint64 // N/A – not supported

Fusion PM MA APIs

9 December 2018 Confidential Page 21

 | +--rw repeat? uint32 // N/A – not supported
| +--rw repeat-interval? uint32 // N/A – not supported
| +--rw pm-reg-list* [pm-index] // N/A – not supported
| | +--rw pm-index uint16

+--rw twamp-session-sender {session-sender}?

| +--rw session-sender-admin-state Boolean
| +--rw twamp-sender-test-session* [test-session-name] // List of entries for each
TWAMP Flow
| +--rw test-session-name string
| +--rw fill-mode? fill-mode // fill-mode.zero
| +--rw number-of-packets? uint32 // N/A – specifying total number
of packets to send is not supported in this implementation
| +--rw (packet-distribution)?
| | +--:(periodic)
| | | +--rw periodic-interval? uint32
| | | +--rw periodic-interval-units? units // units.Milliseconds

The following is a list of TWAMP Client and Session-Sender parameters that are defaulted or not supported:

1. Client-Control-Connection Client-IP and Session-Request Sender-IP must match. Only one Client
Source IP Address will be specified.
2. Client-Control-Connection DSCP – 0 – the TWAMP Control-Channel will use Best Effort for the DSCP
value in the TCP header
3. Client-Control-Connection Key-ID – not supported; Control-Channel does not use Authentication
4. Session-Request Sender-UDP-Port – only one value can be specified for entire test. TWAMP Initiator
tests DSCP values on Data Flows based on the same starting offset specified by Sender-UDP-Port
5. Session-Request Repeat and Repeat-Interval – periodicity of the test is handled by LMAP parameters
6. Session-Request PM List – not supported in this section. Metrics are specified in the LMAP portion of
the message.
7. Sender-Test-Session Fill-Mode.zero – the data portion of the UDP packets are set to ‘0’s.
8. Sender-Test-Session Poisson – not supported in the first release; the effort to add support for this is
being investigated.

Below is the TWAMP portion of a test start message containing three Client-Control-Connections with two
Session-Requests/Session-Senders on each. This message represents one TWAMP Client connecting to three
TWAMP Servers which create two TWAMP Reflector Sessions each. In other words, using three Control-
Channels, six Data Flow Sessions will be created. Note the format of the example is JSON for readability.
LMAP requires the value of all test parameters to be a string so the content below would need to be stringified
when sent to the MA as the example further down shows.
{
"ietf-twamp:twamp": {
"twamp-client": {
"client-admin-state": "true",
"mode-preference-chain": [{
"priority": "1"
}, {
"mode": "bits.unauthenticated"
}],

"twamp-client-ctrl-connection": [ {
"ctrl-connection-name": "TWAMP Server 1",
"client-ip": "172.17.10.3",

Fusion PM MA APIs

Page 22 Confidential 9 December 2018

 "server-ip": "172.17.11.10",
"server-tcp-port": "862",
"dscp": "0",
"twamp-session-request": [{
"test-session-name": "10.15.13.218_P1__10.15.13.219_P1__184",
"sender-ip": "172.17.10.3",
"sender-udp-port": "50000",
"reflector-ip": "172.17.11.4",
"reflector-udp-port": "50001",
"timeout": "900",
"padding-length": "483",
"dscp": "46"
}, {
"test-session-name": "10.15.13.218_P1__10.15.13.219_P1__128",
"sender-ip": "172.17.10.3",
"sender-udp-port": "50000",
"reflector-ip": "172.17.11.4",
"reflector-udp-port": "50001",
"timeout": "900",
"padding-length": "483",
"dscp": "32"
}]
}, {
"ctrl-connection-name": "TWAMP Server 2",
"client-ip": "172.17.10.3",
"server-ip": "172.17.13.10",
"server-tcp-port": "862",
"dscp": "0",
"twamp-session-request": [{
"test-session-name": "10.15.13.218_P1__10.15.13.215_P1__184",
"sender-ip": "172.17.10.3",
"sender-udp-port": "50000",
"reflector-ip": "172.17.13.4",
"reflector-udp-port": "50001",
"timeout": "900",
"padding-length": "483",
"dscp": "46"
}, {
"test-session-name": "10.15.13.218_P1__10.15.13.215_P1__128",
"sender-ip": "172.17.10.3",
"sender-udp-port": "50000",
"reflector-ip": "172.17.13.4",
"reflector-udp-port": "50001",
"timeout": "900",
"padding-length": "483",
"dscp": "32"
}]
}, {
"ctrl-connection-name": "TWAMP Server 3",
"client-ip": "172.17.10.3",
"server-ip": "172.17.15.10",
"server-tcp-port": "862",
"dscp": "0",
"twamp-session-request": [{
"test-session-name": "10.15.13.218_P1__10.15.13.216_P1__184",
"sender-ip": "172.17.10.3",
"sender-udp-port": "50000",
"reflector-ip": "172.17.15.4",
"reflector-udp-port": "50001",
"timeout": "900",

Fusion PM MA APIs

9 December 2018 Confidential Page 23

 "padding-length": "483",
"dscp": "46"
}, {
"test-session-name": "10.15.13.218_P1__10.15.13.216_P1__128",
"sender-ip": "172.17.10.3",
"sender-udp-port": "50000",
"reflector-ip": "172.17.15.4",
"reflector-udp-port": "50001",
"timeout": "900",
"padding-length": "483",
"dscp": "32"
}]
}
],

"twamp-session-sender": {
"session-sender-admin-state": "true",
"twamp-sender-test-session": [ {
"test-session-name": "10.15.13.218_P1__10.15.13.219_P1__184",
"fill-mode": "fill-mode.zero",
"periodic-interval": "1000",
"periodic-interval-units": "milliseconds"
}, {
"test-session-name": "10.15.13.218_P1__10.15.13.219_P1__128",
"fill-mode": "fill-mode.zero",
"periodic-interval": "1000",
"periodic-interval-units": "milliseconds"
}, {
"test-session-name": "10.15.13.218_P1__10.15.13.215_P1__184",
"fill-mode": "fill-mode.zero",
"periodic-interval": "1000",
"periodic-interval-units": "milliseconds"
}, {
"test-session-name": "10.15.13.218_P1__10.15.13.215_P1__128",
"fill-mode": "fill-mode.zero",
"periodic-interval": "1000",
"periodic-interval-units": "milliseconds"
}, {
"test-session-name": "10.15.13.218_P1__10.15.13.216_P1__184",
"fill-mode": "fill-mode.zero",
"periodic-interval": "1000",
"periodic-interval-units": "milliseconds"
}, {
"test-session-name": "10.15.13.218_P1__10.15.13.216_P1__128",
"fill-mode": "fill-mode.zero",
"periodic-interval": "1000",
"periodic-interval-units": "milliseconds"
} ]
}
}
}

To summarize the above RESTConf TWAMP message produces the following standard TWAMP connections
and flows:

TWAMP Initiator

Fusion PM MA APIs

Page 24 Confidential 9 December 2018

 Client Control-Connection 1 TWAMP Server 1
172.17.10.3 172.17.11.10:862
Session-Senders Session-Reflectors
172.17.10.3:5000 Data Flow 1 172.17.11.4:50001 DSCP 46
172.17.10.3:5000 Data Flow 2 172.17.11.4:50001 DSCP 32

Client Control-Connection 2 TWAMP Server 2

172.17.10.3 172.17.13.10:862
Session-Senders Session-Reflectors
172.17.10.3:5000 Data Flow 3 172.17.13.4:50001 DSCP 46
172.17.10.3:5000 Data Flow 4 172.17.13.4:50001 DSCP 32

Client Control-Connection 3 TWAMP Server 3

172.17.10.3 172.17.15.10:862
Session-Senders Session-Reflectors
172.17.10.3:5000 Data Flow 5 172.17.15.4:50001 DSCP 46
172.17.10.3:5000 Data Flow 6 172.17.15.4:50001 DSCP 32

TWAMP Initiator test overview for Light destinations

1. Test Schedules are received from the Controller via RESTConf POST messages.
2. The Test Schedules contain arrays of test-sessions. The test-session constructs represent the data
flows between TWAMP Initiator and the TWAMP Light Reflector.
3. For each test-session, transmit UDP packets to test-session.Reflector-IP/Reflector-UDP-Port at test-
session.interval. In this implementation, the parameter test-session.interval is interpreted as
milliseconds with the possible values of 10, 20, 100, 1000, or 2000.
4. The size of the TWAMP packets for each TWAMP Session is specified by the ‘packet-padding-size’. In
this implementation the range of valid values is 0-1431 instead of 64-4096 that the TWAMP YANG
model defines. A value of 0 will produce a total frame size of 87 bytes and a value of 1431 will produce
a total frame size of 1518 bytes.
5. As for standard connections, results are sent to the Collector using an address specified in the Result
schedule portion of the configuration.

TWAMP Initiator test parameters for Light destinations

The IETF TWAMP Light Yang Model defines the parameters to setup the TWAMP test-sessions. A copy of that
model is show next with fields not supported identified in the comments.
module: ietf-twamp-light
+--rw twamp-light
| +--rw twamp-light-session-sender {session-sender-light}?
| | +--rw sender-light-enable? enable // required to be true
| | +--rw test-session* [session-id] // List of entries for each TWAMP Flow
| | +--rw session-id uint32
| | +--rw test-session-enable? enable // required to be true
| | +--rw number-of-packets? uint32 // Not supported

Fusion PM MA APIs

9 December 2018 Confidential Page 25

 | | +--rw packet-padding-size? uint32
| | +--rw session-authentication-mode? Enumeration // required to be
unauthenticated
| | +--rw interval? uint32
| | +--rw sender-ip inet:ip-address
twampInitiatorSource.srcIPAddress
| | +--rw sender-udp-port inet:port-number
twampInitiatorSource.startingSourcePortForRange
| | +--rw reflector-ip inet:ip-address
twampFlowData.destIPAddress
| | +--rw reflector-udp-port inet:port-number
twampFlowData.destinationPort
| | +--rw dscp? inet:dscp

The following is a list of TWAMP Light test-session parameters that are defaulted or not supported:

1. Sender-light-enable and test-session-enable shall always report true (enabled).

2. test-session.number-of-packets – limit the number of packets sent over the specified data-flow is not
supported.
3. Test-session.session-authentication-mode – defaulted to unauthenticated

Below is an LMAP schedule with a TWAMP Light Initiator request included. This message would be received by
the MA in the body portion of a RESTConf POST message.

Note: LMAP requires the value of all test parameters to be a string so the value for the ‘twamp-light’ option
below would need to be stringified when sent to the MA, similar to the value of the ‘session-map’ option.
{ "ietf-lmap-control:lmap":{
"schedules":{
"schedule":[
{
"name":"Test-2016-09-25-11:55",
"start":"immediate",
"action":[
{
"name":"Test-2016-09-25-11:55-action",
"task":"twamp-initiator",
"option":[
{
"id":"subnet",
"value":"255.255.255.0"
},
{
"id":"gateway",
"value":"192.168.2.1"
},
{
"id":"session-map",
"value":"{\"1\":{\"name\":\"Flow 1 for session
1\"},\"2\":{\"name\":\"Flow 2 for session 1\"},\"3\":{\"name\":\"Flow 1 for session 2\"}}"
},
{
"id":"twamp-light",
"value": {
"ietf-twamp-light:twamp-light": {
"twamp-light": {
"twamp-light-session-sender": {

Fusion PM MA APIs

Page 26 Confidential 9 December 2018

 "sender-light-enable": true,
"test-session": [{
"session-id": 1,
"test-session-enable": true,
"packet-padding-size": 483,
"session-authentication-mode": "unauthenticated",
"interval": 10,
"sender-ip": "192.168.2.10",
"sender-udp-port": 50000,
"reflector-ip": "1.1.1.1",
"reflector-udp-port": 50000,
"dscp": 0
}, {
"session-id": 2,
"test-session-enable": true,
"packet-padding-size": 483,
"session-authentication-mode": "unauthenticated",
"interval": 10,
"sender-ip": "192.168.2.10",
"sender-udp-port": 50000,
"reflector-ip": "1.1.1.1",
"reflector-udp-port": 50000,
"dscp": 46
}, {
"session-id": 3,
"test-session-enable": true,
"packet-padding-size": 483,
"session-authentication-mode": "unauthenticated",
"interval": 10,
"sender-ip": "192.168.2.10",
"sender-udp-port": 50000,
"reflector-ip": "2.2.2.2",
"reflector-udp-port": 50000,
"dscp": 0
}]
}
}
}
} ],
"destination":[
"Test-2016-09-25-11:55-results-periodic-pm",
"Test-2016-09-25-11:55-results-periodic-rt"
]
}
]
},
{
"name":"Test-2016-09-25-11:55-results-periodic-pm",
"start":"Test-2016-09-25-11:55-results-periodic-pm-event",
"action":[
{
"name":"Test-2016-09-25-11:55-results-periodic-pm-action",
"task":"results",
"option":[
{
"id":"result-type",
"value":"pm"
},
{
"id":"channel",

Fusion PM MA APIs

9 December 2018 Confidential Page 27

 "value":"http://10.15.14.167:26088/restconf/operations/ietf-lmap-re-
port:report"
}
]
}
]
},
{
"name":"Test-2016-09-25-11:55-results-periodic-rt",
"start":"Test-2016-09-25-11:55-results-periodic-rt-event",
"action":[
{
"name":"Test-2016-09-25-11:55-results-periodic-rt-action",
"task":"results",
"option":[
{
"id":"result-type",
"value":"rt"
},
{
"id":"channel",
"value":"http://10.15.14.167:26088/restconf/operations/ietf-lmap-re-
port:report"
}
]
}
]
}
]
},
"events":{
"event":[
{
"name":"Test-2016-09-25-11:55-results-periodic-pm-event",
"periodic":{
"interval":300
}
},
{
"name":"Test-2016-09-25-11:55-results-periodic-rt-event",
"periodic":{
"interval":5
}
}
]
}
}
}

To summarize the above RESTConf TWAMP message produces the following TWAMP Light flows:

TWAMP Light Initiator

Sender Reflector
192.168.2.10:5000 Data Flow 1 – “Flow 1 for session 1” 1.1.1.1:50000 DSCP 0

Fusion PM MA APIs

Page 28 Confidential 9 December 2018

192.168.2.10:5000 Data Flow 2 – “Flow 2 for session 1” 1.1.1.1:50000 DSCP 46
192.168.2.10:5000 Data Flow 3 – “Flow 1 for session 2” 2.2.2.2:50000 DSCP 0

Additional test specific parameters

Additional information not defined in the TWAMP YANG or TWAMP Light YANG models is provided using
parameters outside of the ietf-twamp models.

1. gateway – IPv4 address of router.

2. subnet – IPv4 subdivision (mask) of network.
3. session-map (used for Light only) – TWAMP Light Yang model only defines an integer to identify the
different data flows. Consequently, an option list parameter can be defined that adds more description
to each data flow.
4. session-group-map (used for Light only) – provides a way to name a group of flows having the same
destination IP. (This information is not used by the MA.)
5. overlay-component – string giving the name of the overlay, if the task is associated with an overlay.
When provided, the task and flow resources will be allocated from those reserved for overlays
(“overlay.overlaytasks” and “overlay.overlayflows” as described in Device Configuration API on page
16)
6. twamp-keep-alive-interval (not applicable to Light) – the parameter ‘twamp-keep-alive-interval’ when
defined is the number of seconds between sending a TCP keep-alive to the Control Session port (default
862). Some reflectors require this otherwise they will end the session. Not sending the parameter or
setting it to 0 disables the functionality. The valid range is 0-7200 seconds. Since LMAP dictates that
the value of all options is a string, this is an example of how it would be used:
{
"id": "twamp-keep-alive-interval",
"value": "300"
},

QT-600-10

• requires an extra phy-id parameter to identify which of the two test ports the test should run. The
value in the test configuration must match one of the phy-id values returned by the capabilities
request within the phy-list array of physical interfaces.

TWAMP Initiator test example, showing both types of destinations

{
"ietf-lmap-control:lmap":{
"schedules":{
"schedule":[
{
"name":"Test-2016-10-14-17:25",
"start":"immediate",

Fusion PM MA APIs

9 December 2018 Confidential Page 29

 "action":[
{
"name":"Test-2016-10-14-17:25-action",
"task":"twamp-initiator",
"option":[
{
"id":"subnet",
"value":"255.255.255.0"
},
{
"id":"gateway",
"value":"192.168.2.1"
},
{
"id":"session-map",
"value":"{\"1\":{\"name\":\"Flow 1\"},\"2\":{\"name\":\"Flow
2\"},\"3\":{\"name\":\"Flow 3\"}}"
},
{
"id": "session-group-map",
"value": {"Dest 1":{"session-names":["Flow 1", "Flow 2”,”Flow 3"]}}
}

{
"id":"twamp-light",
"value":"{\"ietf-twamp-light:twamp-light\":{\"twamp-light-session-
sender\":{\"sender-light-enable\":true,\"test-session\":[{\"session-id\":1,\"test-session-
enable\":true,\"packet-padding-size\":425,\"session-authentication-
mode\":\"unauthenticated\",\"interval\":10,\"sender-ip\":\"192.168.2.10\",\"sender-udp-
port\":50000,\"reflector-ip\":\"192.168.2.20\",\"reflector-udp-
port\":50000,\"dscp\":0},{\"session-id\":2,\"test-session-enable\":true,\"packet-padding-
size\":0,\"session-authentication-mode\":\"unauthenticated\",\"interval\":20,\"sender-
ip\":\"192.168.2.10\",\"sender-udp-port\":50000,\"reflector-ip\":\"192.168.2.20\",\"reflector-
udp-port\":50000,\"dscp\":8},{\"session-id\":3,\"test-session-enable\":true,\"packet-padding-
size\":1431,\"session-authentication-mode\":\"unauthenticated\",\"interval\":1000,\"sender-
ip\":\"192.168.2.10\",\"sender-udp-port\":50000,\"reflector-ip\":\"192.168.2.20\",\"reflector-
udp-port\":50000,\"dscp\":40}]}}}"
} {
"id":"twamp",
"value":"{\"ietf-twamp:twamp\":{\"twamp-client\":{\"client-admin-
state\":true,\"mode-preference-
chain\":[{\"priority\":\"1\",\"mode\":\"bits.unauthenticated\"}],\"twamp-client-ctrl-
connection\":[{\"ctrl-connection-name\":\"My Session\",\"client-
ip\":\"172.20.30.29\",\"server-ip\":\"172.20.30.21\",\"server-tcp-
port\":\"862\",\"dscp\":\"0\",\"twamp-session-request\":[{\"test-session-name\":\"Flow
1\",\"sender-ip\":\"172.20.30.29\",\"sender-udp-port\":\"50000\",\"reflector-
ip\":\"172.20.30.21\",\"reflector-udp-port\":\"50000\",\"timeout\":\"2\",\"padding-
length\":\"483\",\"dscp\":\"0\"}]}],\"twamp-session-sender\":{\"session-sender-admin-
state\":true,\"twamp-sender-test-session\":[{\"test-session-name\":\"Flow 1\",\"fill-
mode\":\"fill-mode.zero\",\"periodic-interval\":\"10\",\"periodic-interval-
units\":\"milliseconds\"}]}}}}"
}

],
"destination":[
"Test-2016-10-14-17:25-results-periodic-pm",
"Test-2016-10-14-17:25-results-periodic-rt"

Fusion PM MA APIs

Page 30 Confidential 9 December 2018

 ]
}
]
},
{
"name":"Test-2016-10-14-17:25-results-periodic-pm",
"start":"Test-2016-10-14-17:25-results-periodic-pm-event",
"action":[
{
"name":"Test-2016-10-14-17:25-results-periodic-pm-action",
"task":"results",
"option":[
{
"id":"result-type",
"value":"pm"
},
{
"id":"channel",
"value":"http://10.15.14.167:26088/restconf/operations/ietf-lmap-
report:report"
}
]
}
]
},
{
"name":"Test-2016-10-14-17:25-results-periodic-rt",
"start":"Test-2016-10-14-17:25-results-periodic-rt-event",
"action":[
{
"name":"Test-2016-10-14-17:25-results-periodic-rt-action",
"task":"results",
"option":[
{
"id":"result-type",
"value":"rt"
},
{
"id":"channel",
"value":"http://10.15.14.167:26088/restconf/operations/ietf-lmap-
report:report"
}
]
}
]
}
]
},
"events":{
"event":[
{
"name":"Test-2016-10-14-17:25-results-periodic-pm-event",
"periodic":{
"interval":60
}
},
{
"name":"Test-2016-10-14-17:25-results-periodic-rt-event",
"periodic":{
"interval":5

Fusion PM MA APIs

9 December 2018 Confidential Page 31

 }
}
]
}
}
}

TWAMP Reflector Submission

Using the IETF TWAMP YANG model as a reference, the TWAMP Reflector application contains the TWAMP
Server and Session-Reflector functionalities. In the Full TWAMP model, TWAMP Server must be listening for
control connections for the TWAMP test to begin. Consequently, the TWAMP Reflector application must be
started first.

TWAMP Reflector overview

1. Listen on Server IP Address/TCP Listening Port for a connection with the TWAMP Client to create the
Control-Channel
2. Receive Session-Requests on the Control-Channel from the TWAMP Client.
3. Spawn TWAMP Session-Reflectors that listen on a specified UDP port for packets from the TWAMP
Initiator.
4. One instance of the TWAMP Reflector configuration is supported per MA.

TWAMP Reflector parameters

Some necessary parameters are not defined in the TWAMP YANG model; therefore they are specified using
parameters outside of the ietf-twamp model.

1. source-ip – IPv4 address of TWAMP Server to be contacted by TWAMP Client for communication of
TWAMP Session messages.
2. gateway – IPv4 address of router.
3. subnet – IPv4 subdivision (mask) of network.
4. max-connections – Maximum number of TWAMP control sessions to accept. This is a value from 1 to
the value of ‘max-control-sessions’ in the custom capabilities API. TWAMP control sessions above this
value are ignored. This is required so resources can be reserved since the MA can also perform
TWAMP Iniitiator tests.
5. max-flows – Maximum number of TWAMP flows to accept. This is a value from 1 to the value of ‘max-
flows’ in the custom capabilities API. TWAMP flows above this value are ignored.
6. overlay-component – string giving the name of the overlay, if the task is associated with an overlay.
When provided, the task resources will be allocated from those reserved for overlays
(“overlay.overlaytasks” as described in Device Configuration API on page 16)

Fusion PM MA APIs

Page 32 Confidential 9 December 2018

 7. TWAMP YANG Model parameters in string format
a) Server TCP Listening Port – TCP port to be contacted by TWAMP Client for communication of
TWAMP Session messages
b) DSCP – value to be used over communication channel
c) Mode (authentication type) – authentication between TWAMP Client and TWAMP Server over
the Control-Channel is not supported so value is set to “bits.unauthenticated”

TWAMP Reflector example

{
"ietf-lmap-control:lmap":{
"schedules":{
"schedule":[
{
"name":"My Test",
"start":"immediate",
"action":[
{
"name":"My Test-action",
"task":"twamp-reflector",
"option":[
{
"id": "max-connections",
"value": "5"
},
{
"id": "max-flows",
"value": "50"
},
{
"id":"source-ip",
"value":"172.20.31.140"
},
{
"id":"subnet",
"value":"255.255.255.0"
},
{
"id":"gateway",
"value":"172.20.31.1"
},
{
"id":"twamp",
"value":"{\"ietf-twamp:twamp\":{\"twamp-server\":{\"server-ad-
min-state\":true,\"server-tcp-port\":862,\"dscp\":0,\"mode\":\"bits.unauthenticated\"}}}"
}
]
}
]
}
]
}
}
}

Fusion PM MA APIs

9 December 2018 Confidential Page 33

TWAMP Light Reflector Submission

TWAMP Reflector overview

The TWAMP Light Reflector is very simple. It will reflect any TWAMP packets received with the configured
IP address and port.

TWAMP Reflector parameters

The Light Reflector parameters are all specified using specified using parameters outside of the ietf-twamp
model.

1. source-ip – IPv4 address of TWAMP Server to be contacted by TWAMP Client for communication of
TWAMP Session messages.
2. gateway – IPv4 address of router.
3. subnet – IPv4 subdivision (mask) of network.
4. reflector-udp-port (range is 49152 through 65535, default 50000)
5. overlay-component – string giving the name of the overlay, if the task is associated with an overlay.
When provided, the task resource will be allocated from those reserved for overlays
(“overlay.overlaytasks” as described in Device Configuration API on page 16)

TWAMP Reflector example

{
"ietf-lmap-control:lmap":{
"schedules":{
"schedule":[
{
"name":"My Test",
"start":"immediate",
"action":[
{
"name":"My Test-action",
"task":"twamp-reflector",
"option":[
{
"id":"source-ip",
"value":"172.20.31.140"
},
{
"id":"subnet",
"value":"255.255.255.0"
},
{
"id":"gateway",
"value":"172.20.31.1"
},
{
"id":"overlay-component",
"value":"mymesh"

Fusion PM MA APIs

Page 34 Confidential 9 December 2018

 },
{
"id":"reflector-udp-port",
"value":"55555"
}
]
}
]
}
]
}
}
}

Fusion PM MA APIs

9 December 2018 Confidential Page 35

TWAMP Results
The TWAMP YANG model defines some measurements and they are defined within structured objects.
This MA follows the LMAP YANG model instead which defines results as one or more table definitions.
The TWAMP results follow a single table definition.
TWAMP Initiator Results

The TWAMP initiator test will send realtime intermediate results every 5 seconds and PM intermediate results at
an interval of 1 min, 5 min or 15 min. The statistical values measured in the reports span the report interval.
The same set of results will be provided in both types of reports. The reports are differentiated by the ‘report-
type’ tag included in each report, which will be either ‘report-type:rt’ or ‘report-type:pm’.

TWAMP realtime and pm report content

Data Reference
Keyword Type Units Eligible Values Definition and Notes Standards

FLOW/SOAM PM string FLOW Constant

Period Start Time string yyyyMMddhhmmss The period start time of the interval for which the PM data is being TMF814
e.g. 20130825144500 reported. MEF7.1
Time is specified in UTC using the indicated ISO 8601 format. The
period start time occurs on the boundary of the time granularity
(measurement interval).

Granularity enum 5-min The count period (measurement interval) of the PM data being TMF814
string reported.

FDFr EVC ID string The name of the Flow Domain Fragment instantiating the EVC Q.840.1
connecting the two specified UNI Flow Points. The EVC ID identifies MEF10.2
an EVC within the CEN. The EVC ID MUST be unique across all EVCs
in the CEN.

Monitored Time float us The number of microseconds for which monitoring occurred, during
the reported period.
When the Period Status is Valid, will be equal to the value indicated
by the Granularity, within the precision of the device clock, plus or
minus any clock adjustment.
When the Period Status is incomplete, will be less than the nominal
value indicated by the Granularity.

FD 1way Status N->F enum Valid, Incomplete, The validity status of the one-way frame delay performance TMF814
string Invalid, Unavailable measurements in the forward direction (near-end to far-end) MEF7.1
conducted during the measurement interval.
Valid - valid data for the whole period.
Incomplete - data available for a part of the measurement interval.
In this case, the Monitored Time measurement is expected to be
less than the interval length.
Invalid - data available but marked as invalid for the interval. When
the device cannot distinguish incomplete measurements from
invalid measurements, "Invalid" will be used.
Unavailable - no data is available within the measurement period.

Fusion PM MA APIs

Page 36 Confidential 9 December 2018

FD 1way Min N->F float us The minimum one-way frame delay in the forward direction (near- MEF7.1
end to far-end) calculated by this near-end MEP for this MEF-SOAM-
measurement interval. PM-MIB

FD 1way Avg N->F float us The average one-way frame delay in the forward direction (near- MEF7.1
end to far-end) calculated by this near-end MEP for this MEF-SOAM-
measurement interval. PM-MIB

FD 1way Max N->F float us The maximum one-way frame delay in the forward direction (near- MEF7.1
end to far-end) calculated by this near-end MEP for this MEF-SOAM-
measurement interval. PM-MIB

FD 1way N->F integer

Dropped Samples

FD 1way Status F->N enum Valid, Incomplete, The validity status of the one-way frame delay performance TMF814
string Invalid, Unavailable measurements in the backward direction (far-end to near-end) MEF7.1
conducted during the measurement interval.
See Field Num 6 for complete description.

FD 1way Min F->N float us The minimum one-way frame delay in the backward direction (far- MEF7.1
end to near-end) calculated by this near-end MEP for this MEF-SOAM-
measurement interval. PM-MIB

FD 1way Avg F->N float us The average one-way frame delay in the backward direction (far- MEF7.1
end to near-end) calculated by this near-end MEP for this MEF-SOAM-
measurement interval. PM-MIB

FD 1way Max F->N float us The maximum one-way frame delay in the backward direction (far- MEF7.1
end to near-end) calculated by this near-end MEP for this MEF-SOAM-
measurement interval. PM-MIB

FD 1way F->N integer

Dropped Samples

FD 2way Status enum Valid, Incomplete, The validity status of the two-way frame delay performance TMF814
string Invalid, Unavailable measurements conducted during the measurement interval. MEF7.1
See Field Num 6 for complete description.

FD 2way Min float us The minimum two-way frame delay calculated by this near-end MEF7.1
MEP for this measurement interval. MEF-SOAM-
PM-MIB

FD 2way Avg float us The average two-way frame delay calculated by this near-end MEP MEF7.1
for this measurement interval. MEF-SOAM-
PM-MIB

FD 2way Max float us The maximum two-way frame delay calculated by this near-end MEF7.1
MEP for this measurement interval. MEF-SOAM-
PM-MIB

FD 2way Dropped integer

Samples

IFDV 1way Status N->F enum Valid, Incomplete, The validity status of the one-way inter-frame delay variation TMF814
string Invalid, Unavailable performance measurements in the forward direction (near-end to MEF7.1
far-end) conducted during the measurement interval.
See Field Num 6 for complete description.

Fusion PM MA APIs

9 December 2018 Confidential Page 37

IFDV 1way Min N->F float us The minimum one-way inter-frame delay variation in the forward MEF7.1
direction (near-end to far-end) calculated by this near-end MEP for MEF-SOAM-
this measurement interval. PM-MIB

IFDV 1way Avg N->F float us The average one-way inter-frame delay variation in the forward MEF7.1
direction (near-end to far-end) calculated by this near-end MEP for MEF-SOAM-
this measurement interval. PM-MIB

IFDV 1way Max N->F float us The maximum one-way inter-frame delay variation in the forward MEF7.1
direction (near-end to far-end) calculated by this near-end MEP for MEF-SOAM-
this measurement interval. PM-MIB

IFDV 1way N->F integer

Dropped Samples

IFDV 1way Status F->N enum Valid, Incomplete, The validity status of the one-way inter-frame delay variation TMF814
string Invalid, Unavailable performance measurements in the backward direction (far-end to MEF7.1
near-end) conducted during the measurement interval.
See Field Num 6 for complete description.

IFDV 1way Min F->N float us The minimum one-way inter-frame delay variation in the backward MEF7.1
direction (far-end to near-end) calculated by this near-end MEP for MEF-SOAM-
this measurement interval. PM-MIB

IFDV 1way Avg F->N float us The average one-way inter-frame delay variation in the backward MEF7.1
direction (far-end to near-end) calculated by this near-end MEP for MEF-SOAM-
this measurement interval. PM-MIB

IFDV 1way Max F->N float us The maximum one-way inter-frame delay variation in the backward MEF7.1
direction (far-end to near-end) calculated by this near-end MEP for MEF-SOAM-
this measurement interval. PM-MIB

IFDV 1way F->N integer

Dropped Samples

IFDV 2way Status enum Valid, Incomplete, The validity status of the two-way inter-frame delay variation
string Invalid, Unavailable performance measurements conducted during the measurement
interval.
See Field Num 6 for complete description.

IFDV 2way Min float us The minimum two-way inter-frame delay variation calculated by MEF7.1
this near-end MEP for this measurement interval. MEF-SOAM-
PM-MIB

IFDV 2way Avg float us The average two-way inter-frame delay variation calculated by this MEF7.1
near-end MEP for this measurement interval. MEF-SOAM-
PM-MIB

IFDV 2way Max float us The maximum two-way inter-frame delay variation calculated by MEF7.1
this near-end MEP for this measurement interval. MEF-SOAM-
PM-MIB

IFDV 2Way Dropped integer

Samples

FLR 1way Status N->F enum Valid, Incomplete, The validity status of the one-way frame loss ratio performance TMF814
string Invalid, Unavailable measurements in the forward direction (near-end to far-end) MEF7.1
(see Note) conducted during the measurement interval.
See Field Num 6 for complete description.

Fusion PM MA APIs

Page 38 Confidential 9 December 2018

FLR 1way Min N->F float % The minimum one-way frame loss ratio in the forward direction MEF-SOAM-
(near-end to far-end) calculated by this near-end MEP for this PM-MIB
(see Note) measurement interval.

FLR 1way Avg N->F float % The average one-way frame loss ratio in the forward direction MEF-SOAM-
(near-end to far-end) calculated by this near-end MEP for this PM-MIB
(see Note) measurement interval.

FLR 1way Max N->F float % The maximum one-way frame loss ratio in the forward direction MEF-SOAM-
(near-end to far-end) calculated by this near-end MEP for this PM-MIB
(see Note) measurement interval.

FLR 1way Status F->N enum Valid, Incomplete, The validity status of the one-way frame loss ratio performance TMF814
string Invalid, Unavailable measurements in the backward direction (far-end to near-end) MEF7.1
(see Note) conducted during the measurement interval.
See Field Num 6 for complete description.

FLR 1way Min F->N float % The minimum one-way frame loss ratio in the backward direction MEF-SOAM-
(far-end to near-end) calculated by this near-end MEP for this PM-MIB
(see Note) measurement interval.

FLR 1way Avg F->N float % The average one-way frame loss ratio in the backward direction MEF-SOAM-
(far-end to near-end) calculated by this near-end MEP for this PM-MIB
(see Note) measurement interval.

FLR 1way Max F->N float % The maximum one-way frame loss ratio in the backward direction MEF-SOAM-
(far-end to near-end) calculated by this near-end MEP for this PM-MIB
(see Note) measurement interval.

FL Count N->F integer The count of frames lost near-end to far-end for this measurement MEF-SOAM-
interval. PM-MIB
(see Note) FLR 1way Status N->F applies to this measurement.

Count N->F Dropped integer

Samples

FL Count F->N integer The count of frames lost far-end to near-end for this measurement MEF-SOAM-
interval. PM-MIB
(see Note) FLR 1way Status F->N applies to this measurement.

Count F->N Dropped integer

Samples

FA Count integer The count of frames attempted in each direction, both near-end to MEF-SOAM-
far-end and far-end to near-end for this measurement interval. PM-MIB

No FSync Count integer >=0 For every 5s sample, if the "Sync" bit in the reflected TWAMP
packet is not set this count is incremented.

F Usync Count integer >=0 0 - indicates far end time is in sync with QT time
>0 - Far end time is not in sync with QT time.

F Time string yyyyMMddhhmmss UTC time at far end.

e.g. 20130825144500

OOS Count N->F integer >=0 Number of Out of Sequence packets in the near to far direction
during the measurement interval - status flag based on FLR 1 way
Status N->F

Fusion PM MA APIs

9 December 2018 Confidential Page 39

 OOS Count F->N integer >=0 Number of Out of Sequence packets in the far to near direction
during the measurement interval - status flag based on FLR 1 way
Status F->N

Dup Count N->F integer >=0 Number of Duplicate packets in the near to far direction during the
measurement interval - status flag based on FLR 1 way Status N->F

Dup Count F->N integer >=0 Number of Duplicate packets in the far to near direction during the
measurement interval - status flag based on FLR 1 way Status F->N

FD Count 1 integer >=0 Frames with 2 way delay < 4ms during the measurement interval -
status flag based on FD 2 way Status

FD Count 2 integer >=0 Frames with 2 way delay between (>=) 4 and (<) 8 ms during the
measurement interval - status flag based on FD 2 way Status

FD Count 3 integer >=0 Frames with 2 way delay between (>=) 8 and (<) 16 ms during the
measurement interval - status flag based on FD 2 way Status

FD Count 4 integer >=0 Frames with 2 way delay >=16 ms during the measurement interval
- status flag based on FD 2 way Status

Synthetic Time integer 0,1 Indicator that timestamp smoothing algorithm was applied to
Reflector (Far-end) timestamps

FA Count F->N integer 0 Not Applicable to this device

Raw FL Count F->N integer 0 Not Applicable to this device

Raw FL Count N->F integer 0 Not Applicable to this device

Raw Received Count integer 0 Not Applicable to this device

Remote Port integer 1-65535 The UDP port on the reflector to where the TWAMP packets are
being sent. For standard TWAMP, this is the value that resulted
from the control session negotiation and is not necessarily the value
that was requested in the test configuration. For TWAMP light, this
is the configured value.

Note: If the reflector is not session aware then F->N Frame Loss statistics represent 2-way/roundtrip
results. In this case, N->F Frame Loss statistics will always be 0. TWAMP Light reflectors are not expected
to be “session aware.”

TWAMP Reflector Status

The TWAMP Reflector configuration does not produce reports and so does not require Result Schedules in the
test configuration. When the LMAP state API is requested the following information will be returned as a
structured value in string format in the ‘last-message’ object:

Keyword Definition and Notes

TWAMP Reflector test Value of ‘Enabled’ will be returned as confirmation

the test is of type TWAMP Reflector

Fusion PM MA APIs

Page 40 Confidential 9 December 2018

 testPort Value of ‘Configured’ will be returned when the
test interface has been created and has link.

Number of Connections Current number of TWAMP connections the

TWAMP Reflector is servicing. (Not provided for
TWAMP Light Reflector)

Number of Sessions Current number of TWAMP flows the TWAMP

Reflector is servicing. (Not provided for TWAMP
Light Reflector)

Reflected Packets Count of TWAMP packets reflected since the test

start across all TWAMP flows. This is a 64-bit
counter.

Wrap Count Count of how many times the Reflected Packet

counter has wrapped since the test was started.

testMessage Text providing information about the state of the

test

TWAMP Reflector status example

{
"ietf-lmap-control:lmap-state":{
"tasks":{
"task":[
{
"version":"1.0",
"name":"twamp-initiator"
},
{
"version":"1.0",
"name":"twamp-reflector"
},
{
"version":"1.0",
"name":"twamp-light-reflector"
},

{
"version":"1.0",
"name":"results"
}
]
},
"agent":{
"last-started":"2016-05-16T15:27:16.678457",
"agent-id":"abfc14b6-1b7a-11e6-b32d-fa163e5bfbb0",
"device-id":"urn:viavisolutions:model:vPMA:mac:%FA%16%3E%5B%FB%B0",
"version":"1.0"
},
"schedules":{
"schedule":[
{
"last-invocation":"2016-05-17T15:22:39.540871",

Fusion PM MA APIs

9 December 2018 Confidential Page 41

 "name":"PM-Reflector-HP-159"
"action":[
{
"state":"running",
"last-status":0,
"last-message":"{\"Number of Connections\": \"0\", \"Number of
Sessions\": \"0\", \"TWAMP Reflector test\": \"Enabled\", \"Wrap Count\": \"1\", \"testPort\":
\"Configured\", \"Reflected Packets\": \"15449757\"}"
}
]
}
]
}
}
}

Fusion PM MA APIs

Page 42 Confidential 9 December 2018

 Fusion PM MA APIs

9 December 2018 Confidential Page 43