Fusion Controller Collector API 4.1

Controller & Collector APIs
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 4 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.
MA, Controller and Collector APIs

Page 3 Confidential 4 December 2018
ContentsReferences .................................................................................................................................. 8
Overview 9
MA APIs 13
Test Configuration ......................................................................................................... 14
LMAP Model ............................................................................................................................. 14
Summary of LMAP approach .................................................................................................... 16
Summary of Viavi approach ...................................................................................................... 17
Examples .................................................................................................................................. 19
Test Termination ........................................................................................................... 23
LMAP Model ............................................................................................................................. 23
Example .................................................................................................................................... 24
MA State Retrieval......................................................................................................... 24
LMAP Model ............................................................................................................................. 24
TWAMP vPMA Example ........................................................................................................... 28
MA Result Posting ......................................................................................................... 29
LMAP Model ............................................................................................................................. 29
Y.1564 vTA Examples............................................................................................................... 31
MA Registration ............................................................................................................. 33
Controller/Collector NETCONF APIs ...................................................................................................... 35
MA, Controller and Collector APIs

Contents
Login ............................................................................................................................. 36
Logout ........................................................................................................................... 37
Get Token Details .......................................................................................................... 37
Renew Token ................................................................................................................ 38
MA List .......................................................................................................................... 38
Test Configuration ......................................................................................................... 40
Test Submission ....................................................................................................................... 40
Test Termination ........................................................................................................... 42
MA State Retrieval......................................................................................................... 43
Test Result Retrieval ..................................................................................................... 43
Test Submission Examples ........................................................................................... 45
Y1564 (loopback mode on vTA) ................................................................................................ 45
Y1564 (bi-directional mode on vTA) .......................................................................................... 46
TrueSpeed (MA to MA on vTA) ................................................................................................. 48
TWAMP Initiator (on vPMA) ...................................................................................................... 49
TWAMP Reflector (on vPMA) .................................................................................................... 50
UDP (MA to MA on vTA) ........................................................................................................... 50
Get Final Result ........................................................................................................................ 51
Get Intermidate Result .............................................................................................................. 52
Stop Test .................................................................................................................................. 52
Controller and Collector APIs

Document Change History
Date Revis Author Description of Changes
ion
Oct 12, 1.0 Ron Initial Revision
2016 Stana
Oct 17, 1.0.1 John Lei
2016 Added sample NETCONF XML for the following API:
1. Get Final Result

2. Get Intermediate Result
3. Stop Test
Oct 26, 1.0.2 Ron Added limit of 175 TWAMP sessions per test
2016 Stana
Nov 2, 1.0.3 Ron 1. Added ‘runlater’ to NETCONF start test for TrueSpeed Client to MA
2016 Stana 2. Added ‘sha’ to NETCONF start test response for TrueSpeed Client to MA
3. Removed ‘test’ object from NETCONF start test examples
Dec 29, 1.0.4 Ron Changed MA registration request to Controller from GET to POST
2016 Stana
May 1, 1.0.5 Ron Updated test termination to require a tag object containing the schedule-id. This
2017 Stana is what our MAs have been expecting.
Nov 14, 3.0.0 Seisaku Added the UDP test submission example
2017 Nomura
Jan 29, 3.0.1 Ken Updated Version to 3.0.1.
2018 Lambert
Jun 19, 4.0 John Lei Updated per Ron Stana’s comments below:
2018 Removed references to the “encrypted” user name from API.
Aug 15, 4.0.1 Ron Added MA table with test types
2018 Stana
Dec 4, 4.1 John Lei Updated version to 4.1
2018 Added TWAMP tests for QT-600-10

Contents
References
• A Framework for Large-Scale Measurement of Broadband Performance
https://tools.ietf.org/html/rfc7594 (RFC-7594 September 2015)
• Information Model for Large-Scale Measurement Platforms
https://tools.ietf.org/html/draft-ietf-lmap-information-model-09 (Draft version 9)
• YANG Data Model for LMAP
https://tools.ietf.org/html/draft-ietf-lmap-yang-04 (Draft version 4)
• YANG Modeling Language
https://tools.ietf.org/html/rfc6020
• NETCONF
http://tools.ietf.org/html/rfc6241
• NETCONF YANG Model
http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#candidate.96

1
Overview
The purpose of this document is to explain the APIs for use in executing tests and obtaining results
from measurement agents (MA) supported by the Viavi controller and collector.
The APIs presented are split into these categories:
1. MA APIs
• describes the common aspects of the test control APIs on the measurement agents such
as test submission, state retrieval and general result format
2. Controller/Collector APIs
• describes the test control APIs offered to an external client using NETCONF
The following image depicts the MA APIs and Controller/Collector APIs along with internal APIs that
connect everything:

4 December 2018 Confidential Page 9
Chapter 1 Product Name Overview
The MA APIs are expected to follow the LMAP documentation [References A,B,C]. LMAP defines common
APIs for test submission, test termination, test status retrieval and result reporting. LMAP is a delivery
mechanism for test-specific information. Since the delivery is the same for all device types it is explained
once in this document. The test specific information is outside the scope of LMAP and is explained in
additional MA specific documents.
The following is a list of the MAs that are currently supported and their test types:
Model Platform MA Tests

Version
vTA Virtual 1.0.4 • Y.1564 Layer 2 & 3
o vTA to vTA
o vTA to externally looped up
device (Loopback test mode)
• Loopback device mode

• RFC-6349 Layer 4 TrueSpeed
o vTA to vTA
• UDP
o vTA to vTA
PC Client PC 2.0.6 • RFC-6349 Layer 4 TrueSpeed

o PC Client to vTA-TS
o PC Client to QT-600-10
• UDP
vTA-TS Virtual 1.0.4 • RFC-6349 Layer 4 TrueSpeed

o Instrument to vTA-TS
• UDP
vPMA Virtual 2.1 • RFC-5357 TWAMP & TWAMP Light

o Initiator
o Reflector
T-BERD/MTS-5800v2 Instrument 26.3 Controller submitted tests

• SC4800 27.0 • Y.1564 Layer 3
• SC4800P o Instrument to Instrument
• T-BERD5800V2 o Instrument to externally looped up
• MTS5800V2 device (Loopback test mode)
• T-BERD5882
• MTS5882 Tests created locally on Instrument
• RFC-6349 Layer 4 TrueSpeed
T-BERD/MTS-5800-100G o Instrument to vTA-TS
o Instrument to QT-600-10
MAP-2100
QT-600-10 QT-600-10 11.7.2 • RFC-6349 Layer 4 TrueSpeed

o PC Client to QT-600-10
o Instrument to QT-600-10
• RFC-5357 TWAMP & TWAMP Light
o Initiator
o Reflector
MA specific API documentation is available for these.
The Controller/Collector APIs are also expected to follow the LMAP documentation and use the
LMAP YANG model as much as possible. Since LMAP defines the MA interface additional information
will be needed for the controller/collector such as which MA to perform the operation. Some requests
such as test submission will go to the Controller and then to the MA while other requests such as result
queries will go to the Collector.

Chapter 1 Product Name Overview
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 needed by the MAs. Not all functionality
defined by LMAP is needed and some extensions are required. These differences will be identified in this
document.
Terminology used in the document
LMAP defines the operation of testing the network as an Instruction Task and the location of where to
send results as a Result Task. Both are associated with an LMAP event that specifies when they
should be performed. The linking of a task to an event is done using an LMAP schedule.
Within this document the following terminology will be used for brevity:
• the term Test Task means the same as an Instruction Task. The focus of this document is test
execution so using the term Test makes the discussion clear.
• the term Test Schedule means a schedule that references a Test Task
• the term Result Schedule means a schedule that references a Result Task
• the term Test means the combination of everything needed to execute the Test Task:
o Test Schedule
o Result Schedule(s)
o Test parameters
o Events

2
MA APIs
This chapter covers these common MA APIs:
• Test configuration
• Test termination
• MA state retrieval
• MA result posting
The APIs are the row identified by the green arrow in the picture below from the overview:
Statements common across all APIs in this chapter:
1. These APIs will be implemented using RESTCONF

2. These 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 the initial release.

Test Configuration
LMAP Model
The LMAP model for starting the execution of a test is defined using the lmap object of the ietf-lmap-con-
trol module.
The YANG model for this was obtained from the following location:
Section 4 "YANG Modules" of the IETF document https://datatracker.ietf.org/doc/draft-ietf-lmap-yang/.
The structure of the model follows for reference.

module: ietf-lmap-control
+--rw lmap
+--rw agent
| +--rw agent-id? yang:uuid
| +--rw device-id? inet:uri
| +--rw group-id? string
| +--rw measurement-point? string
| +--rw report-agent-id? boolean
| +--rw report-measurement-point? boolean
| +--rw controller-timeout? uint32
+--rw tasks
| +--rw task* [name]
| +--rw name lmap:identifier
| +--rw metric* [uri]
| | +--rw uri inet:uri
| | +--rw role* string
| +--rw program? string
| +--rw option* [id]
| | +--rw id lmap:identifier
| | +--rw name? string
| | +--rw value? string
| +--rw suppress-by-default? boolean
| +--rw tag* lmap:identifier
+--rw schedules
| +--rw schedule* [name]
| +--rw start event-ref
| +--rw (stop)?
| | +--:(end)
| | | +--rw end? event-ref
| | +--:(duration)
| | +--rw duration? uint32
| +--rw execution-mode? enumeration
| +--rw tag* lmap:tag
| +--rw suppression-tag* lmap:tag
| +--rw action* [name]
| +--rw task task-ref
| +--rw parameters
| | +--rw (extension)?
| +--rw option* [id]
| | +--rw id lmap:identifier
| | +--rw name? string

| | +--rw value? string
| +--rw destination* schedule-ref
| +--rw tag* lmap:tag
| +--rw suppression-tag* lmap:tag
+--rw suppressions
| +--rw suppression* [name]
| +--rw start? event-ref
| +--rw end? event-ref
| +--rw match* lmap:glob-pattern
| +--rw stop-running? boolean
+--rw events
+--rw event* [name]
+--rw name lmap:identifier
+--rw (event-type)?
| +--:(periodic)
| | +--rw periodic
| | +--rw interval uint32
| | +--rw start? yang:date-and-time
| | +--rw end? yang:date-and-time
| +--:(calendar)
| | +--rw calendar
| | +--rw month* lmap:month-or-all
| | +--rw day-of-month* lmap:day-of-months-or-all
| | +--rw day-of-week* lmap:weekday-or-all
| | +--rw hour* lmap:hour-or-all
| | +--rw minute* lmap:minute-or-all
| | +--rw second* lmap:second-or-all
| | +--rw timezone-offset? lmap:timezone-offset
| | +--rw start? yang:date-and-time
| | +--rw end? yang:date-and-time
| +--:(one-off)
| | +--rw one-off
| | +--rw time yang:date-and-time
| +--:(immediate)
| | +--rw immediate empty
| +--:(startup)
| | +--rw startup empty
| +--:(controller-lost)
| | +--rw controller-lost empty
| +--:(controller-connected)
| +--rw controller-connected empty
+--rw random-spread? uint32

Summary of LMAP approach
This section describes Viavi’s understanding of the current approach in the LMAP documentation.
Test submission requires the following pieces of information:
1. Task
a. can be defined for various reasons; the ones concerning test submission are for tests and
results
b. each task can include instance data (parameters) in the form of an 'options' object
c. a task does not execute without a schedule (see below)
2. Events
a. define a time period
b. some are predefined by the MA (ex. immediate) and some the user can define (examples:
run every Monday at 9:00am or run every 5 minutes)
3. Schedule
a. each instance of a schedule contains a reference to a test or result task
b. can optionally contain the same 'options' object that is allowed in the task. If the 'options' ob-
ject is provided in both the schedule and the task and if both instances define the value for
the same parameter, the value in the schedule is used. The following use case can then be
supported:
• if a user wants to run a test multiple times with only one parameter changing each
time, the common parameters could be defined in the ‘options’ of the test task and
the 'per run' parameters could then be defined in the ‘option’ of the schedule.
c. contains a reference to an event that defines when the test or result task should execute
• periodic (run every x milliseconds, start & end date/time optional)
• calendar (run based on time of day, start & end date/time optional)
• one-off (run once, start at a specific date/time)
• immediate (run once, run now)
• startup (run at MA startup)
d. for schedules that reference a test task the schedule also contains a reference to one or
more additional result schedules. These result schedules are another instance of a schedule
and they contain:
• a reference to a result task
• optionally an 'options' object that specifies where to send the data and any other pa-
rameters. Where to send the data is called a 'channel' in LMAP terminology.
• a reference to an event that defines how often the test should report the data
To summarize, in order to start a test a user needs to minimally provide:
• one test schedule that:

o references a test task
o optionally contains task-specific parameters
o references an event for when the test should execute
o references at least one result schedule
• one result schedule that:
o references a result task
o optionally contains task-specific parameters
o references an event for when results should be sent
• any event definitions referenced by the schedules that are not predefined

For more complicated scenarios:
• The user could provide parameters in a task and then assume they will be used for all future sched-
ules that reference that task.
• The user could provide parameters in a task and then override the values by specifying them again
in schedules that reference that task.
• Multiple result schedules may need to be provided if the test task can send multiple types of results
o for example, the test may support aggregation of the results across different intervals – a
short interval for troubleshooting and a longer interval for official reporting. A result schedule
would be needed for each that define the different rates at which the results are sent.
o for example, the test may support sending 'sla-passing' results at a 5 min rate but 'sla-failing'
results more frequently. Again this would require different result schedules that define the
different rates.
Summary of Viavi approach
LMAP defines many objects, possible combinations and interactions. The expectation is Viavi will
implement a subset of this functionality initially and support additional functionality over subsequent
releases.
The following general approach and simplifications are proposed for the first release.
Test Submission
Test submission will be performed by issuing an HTTP POST to /restconf/data/ietf-lmap:lmap.
Each MA may implement a different subset of the LMAP specification based on needed functionality.
Therefore the MA specific documentation will explain what each MA supports if different from what this
document states.
Concepts common to all tests

For the purpose of result correlation the controller will add a unique schedule id and run id to each new
test schedule before it is delivered to the MA. These ids will be added to the lmap/schedules/sched-
ule/action/tag object so the MA will automatically include them in each report.
Note: The LMAP committee acknowledges the need for identifiers like these and is in discussion on
where they should be placed within the test configuration. The discussion has been around an object re-
ferred to as a cycle id. This discussion is resulting in updates to the LMAP documentation that will be
considered for replacement of the schedule id and run id in a future release.
The parameters needed to execute the test schedule will be provided within the LMAP ‘option’ object that
resides under lmap/schedules/schedule/action.
While the ‘option’ object can be provided in the task and/or schedule per the LMAP documentation, it will
only be accepted in a schedule in the initial release. This is because LMAP requires a schedule to start a
test so it is always required. Thus the ‘options’ object within the LMAP ‘task’ object will be ignored. The
benefits are:

• The user only has to submit a schedule instead of a schedule + task
• The data from one task execution does not bleed into the next since the task itself is never
changed
The names of the options will be defined by a test-specific YANG model. See the MA specific docu-
mentation for further details.
Task objects:
• based on the prior item, tasks will be predefined by the MA and will not be able to be modi-
fied
• The following tasks will be predefined by the MA:
• Test Task for each test type
• Result Task that contains parameters for:
• a single channel setting for where to send the results
• the channel setting for all Result Tasks in the same schedule submission will
be expected to have the same value for the channel (ie. all results will go to
the same Collector)
• a setting to state how the task is being used - specifically if it is for realtime
intermediate results, performance monitoring (pm) intermediate results or fi-
nal results
Event objects:
• The following types of Event objects will be supported:

• Immediate
• will be predefined by the MA. The MA will provide an event that uses the
LMAP ‘immediate’ event type. For the examples shown in this document,
assume the name of this predefined event will be ‘immediate’.
• must be used in all user-defined Result Schedules that reference the Result
Task and define it for final result functionality. Thus, final results are sent to
the Collector immediately after the schedule completes.
• Periodic
• to be used for user-defined Result Schedules that reference the Result Task
and define it for intermediate results (realtime or pm)
• the interval setting will be supported
• the start and end date/time settings will not be supported when used with a
Result Schedule. The test start/end will be assumed.
• the 'random-spread' option which adds random delay to start of the event will not be sup-
ported in the initial release.
Schedule object for Test Tasks (Test Schedules):
• must reference one of the test tasks predefined by the MA

• will contain the test parameters in the 'option' object.
• will only support the 'immediate' event (start object)
• will not support the stop object since its existence is being questioned by the LMAP Commit-
tee

• will only support one 'action' instance
• only one action will be supported, therefore the 'execution-mode' will be ignored
• will not support the 'suppression-tag'
• will not support the ‘parameters’ object with the action since its purpose is not yet clear
Schedule object for Result Tasks (Result Schedules):
• must reference the predefined result task on the MA

• must define the result parameters in the 'option’ object
• will only support the 'immediate' event for result tasks configured for final results (start object)
• will only support the 'periodic' event for result tasks configured for intermediate results (start
object)
• will not support the stop object
• will only support one 'action' instance
• only one action will be supported, therefore the 'execution-mode' will be ignored
• will not support the 'suppression-tag'
• will not support the ‘parameters’ object with the action
Agent object:
• will be ignored in the intial release; thus settings like ‘measurement-point’ and ‘controller-
timeout’ will not be supported
Suppressions object:
• will not be supported in the initial release
API Operations
• The API will only support write/POST operations for the entire content of the ‘lmap’ object
defined in ‘ietf-lmap-control’ module.
• each test submission will be required to be complete, meaning the schedule for the
test task, schedules for the result tasks and any user-defined events must all be in
the same data set.
• update/PUT operations for the ‘ietf-lmap-control’ module will not be supported
• read/GET operations for the ‘ietf-lmap-control’ module will not be supported
• delete operations will be supported for the purpose to stopping a test (see Test Termination)
Examples
The following examples show the general structure and information required by the MA to start a test. A
single Test Schedule is provided along with the necessary Result Schedules and events needed for both.
TWAMP Initiator Example (on vPMA)
Note: A limit of 175 TWAMP sessions will be accepted per test submission

{
"ietf-lmap-control:lmap":{
"schedules":{
"schedule":[
{
"name":"My Test",
"start":"immediate",
"action":[
{
"name":"My Test-action",
"task":"twamp-initiator",
"option":[
{
"id":"subnet",
"value":"255.255.255.0"
},
{
"id":"gateway",
"value":"172.20.30.1"
},
{
"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.21\",\"server-ip\":\"172.20.31.40\",\"server-tcp-
port\":\"862\",\"dscp\":\"0\",\"twamp-session-request\":[{\"test-session-
name\":\"Flow 1\",\"sender-ip\":\"172.20.30.21\",\"sender-udp-
port\":\"50000\",\"reflector-ip\":\"172.20.31.40\",\"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":[
"My Test-results-periodic-pm",
"My Test-results-periodic-rt"
]
}
]
},
{
"name":"My Test-results-periodic-pm",
"start":"My Test-results-periodic-pm-event",
"action":[
{
"name":"My Test-results-periodic-pm-action",
"task":"results",
"option":[
{
"id":"result-type",
"value":"pm"
},
{
"id":"channel",
"value":"http://10.3.80.203:26088/restconf/operations/ietf-lmap-report:report"

}
]
}
]
},
{
"name":"My Test-results-periodic-rt",
"start":"My Test-results-periodic-rt-event",
"action":[
{
"name":"My Test-results-periodic-rt-action",
"task":"results",
"option":[
{
"id":"result-type",
"value":"rt"
},
{
"id":"channel",
"value":"http://10.3.80.203:26088/restconf/operations/ietf-lmap-report:report"
}
]
}
]
}
]
},
"events":{
"event":[
{
"name":"My Test-results-periodic-pm-event",
"periodic":{
"interval":300
}
},
{
"name":"My Test-results-periodic-rt-event",
"periodic":{
"interval":5
}
}
]
}
}
}
Y.1564 Example (on vTA)

{
"ietf-lmap-control:lmap":{
"schedules":{
"schedule":[
{
"name":"My Test",

"action":[
{
"task":"y1564",
"option":[
{
"id":"y1564",
"value":"{\"y1564:y1564\":{\"engine-a-info\":{\"engine-
type\":\"vprobe\",\"address\":\"10.12.57.251\",\"port\":\"8081\"},\"y1564-
parameters\":{\"simulated\":false,\"mode\":\"loopback-engine-a\",\"layer\":\"L3\",\"run-
config-test\":true,\"step-duration\":10,\"step-percents\":[\"25\",\"50\",\"75\"],\"run-
perf-test\":true,\"perf-test-duration\":900,\"abort-on-
failure\":false},\"streams\":[{\"stream-number\":0,\"name\":\"My Connection:Stream
1\",\"cir-from-engine-a\":10,\"eir-from-engine-a\":0,\"run-policing-from-engine-
a\":false,\"frame-loss-ratio-threshold\":0,\"enable-frame-delay\":true,\"frame-delay-
threshold\":100,\"l3-ipv4-config\":{\"destination-
ip\":\"192.168.1.2\",\"tos\":184,\"ttl\":32,\"frame-length\":512,\"payload\":\"fill-
byte\"}}]}}"
},
{
"id":"role",
"value":"primary"
}
],
"destination":[
"My Test-results-immediate-final",
"My Test-results-periodic-rt"
]
}
]
},
{
"name":"My Test-results-immediate-final",
"action":[
{
"name":"My Test-results-immediate-final-action",
"task":"results",
"option":[
{
"id":"result-type",
"value":"final"
},
{
"id":"channel",
"value":"http://10.3.80.203:26088/restconf/operations/ietf-lmap-
report:report"
}
]
}
]
},
{
"name":"My Test-results-periodic-rt",
"start":"My Test-results-periodic-rt-event",
"action":[
{
"name":"My Test-results-periodic-rt-action",
"task":"results",

"option":[
{
"id":"result-type",
"value":"rt"
},
{
"id":"channel",
"value":"http://10.3.80.203:26088/restconf/operations/ietf-lmap-
report:report"
}
]
}
]
}
]
},
"events":{
"event":[
{
"name":"My Test-results-periodic-rt-event",
"periodic":{
"interval":1
}
}
]
}
}
}
Test Termination
LMAP Model
The LMAP model for terminating the execution of a test is defined using the lmap object of the ietf-lmap-
control module.
See the LMAP Model section of Test Configuration since it uses the same module.
LMAP defines the suppression object for temporarily stopping a Test Schedule.
LMAP documentation is not very clear on how a Test Schedule should be permanently stopped (ie.
terminated); the documentation seems to suggest there are two approaches :
1. Remove the schedule

2. Submit a suppression object that contains the ‘stop-running’ object set to ‘true’
The following general approach and simplifications are proposed for the first release:
Approach #1 above will be used as follows:

1. Temporarily stopping a Test Schedule will not be supported
2. Test Termination will be performed by issuing an HTTP DELETE to /restconf/data/ietf-lmap:lmap.
3. The request will contain an instance of the lmap object that specifies the name of the schedule and
the immediate event. Note the event object is a mandatory object although it is not needed for this
operation since terminating a schedule is always an immediate operation. The schedule is required
to contain an action object containing the schedule-id sent by the controller when the test was
started.
Example
{
"ietf-lmap-control:lmap": {
"schedules": {
"schedule": [{
"name": "My Test",
"event": "immediate",
"action":[
{
"task":"y1564",
"tag":["schedule-id:1000647"],
"option":[]
}
]
}]
}
}
}
MA State Retrieval
LMAP Model
The LMAP model for retrieving the state information for the MA and its schedules is defined using the lmap-
state object of the ietf-lmap-control module (same module that is used for test configuration).

module: ietf-lmap-control
+--ro lmap-state
+--ro agent
| +--ro agent-id yang:uuid
| +--ro device-id inet:uri
| +--ro hardware string
| +--ro firmware string
| +--ro version string
| +--ro last-started yang:date-and-time

+--ro tasks
| +--ro task* [name]
| +--ro name lmap:identifier
| +--ro metric* [uri]
| | +--ro uri inet:uri
| | +--ro role* string
| +--ro version? string
| +--ro program? string
+--ro schedules
| +--ro schedule* [name]
| +--ro state? enumeration
| +--ro invocations? yang:counter32
| +--ro suppressions? yang:counter32
| +--ro overlaps? yang:counter32
| +--ro failures? yang:counter32
| +--ro last-invocation? yang:date-and-time
| +--ro action* [name]
| +--ro state? enumeration
| +--ro invocations? yang:counter32
| +--ro suppressions? yang:counter32
| +--ro overlaps? yang:counter32
| +--ro failures? yang:counter32
| +--ro last-invocation? yang:date-and-time
| +--ro last-completion? yang:date-and-time
| +--ro last-status? lmap:status-code
| +--ro last-message? string
| +--ro last-failed-completion? yang:date-and-time
| +--ro last-failed-status? lmap:status-code
| +--ro last-failed-message? string
+--ro suppressions
+--ro suppression* [name]
+--ro name lmap:identifier
+--ro state? enumeration
LMAP defines this interface for the purpose of retrieving status information for both the MA itself and the
schedules it has been configured with.
The enumerated values for the state objects are defined as:
• enabled
• running
• disabled
• suppressed

Reading the MA status will be done by issuing an HTTP GET to /restconf/data/ietf-lmap-control:lmap-state.
The response will consist of the following objects:
1. Agent object that contains:

• agent-id (MA-ID)
• device-id
• version
• last-started
2. Task object that contains:

• Name of each predefined test and the result task
• version for each task
• Note: The LMAP committee is considering reducing the task to simply containing the version.
3. Schedules object that contains:
• instance for each Test Schedule
• since the schedules only have one action in the first release, the fields that are common
across the schedule and action will just be returned within the action object
• The following will be returned for the schedule/action:
i. name (whatever value was in the test configuration for the action)
ii. state
1. ‘running’ – when the Test Schedule is executing.
2. ‘enabled’ – when the Test Schedule is waiting to execute
3. ‘disabled - when the Test Schedule ran to completion.
4. Since the suppression operation will not be supported in the initial release,
the state of ‘suppressed’ will not be returned.
Thus, a test like Y.1564 will report ‘running’ and then ‘disabled’ when it completes
on its own. A test like TWAMP initiator or reflector that is a ‘run forever’ test, will
report ‘running’ until it is manually terminated.
Note that after a test completes on its own or is manually terminated, the
controller will remove the test from the MA using the API described in the Test
Termination section. This is done to allow the MA to cleanup resources
associated with the test. After Test Termination has been performed the test will
no longer be returned by the MA
iii.invocations
iv. failures
v. last-invocation
vi. last-completion
vii. suppressions and overlaps will not be supported in the first release
viii.last-status
0 if no error, 1 if test cancelled, 2 if test error
ix. last-message
any message regarding state; may be a structured list of name/value pairs
x. last-failed-completion
xi. last-failed-status

0 if test ran to completion without error or was cancelled, > 0 if test had error
xii. last-failed-message
explanation of error when last-failed-status > 0
General Response for test running but has errors that don't cause it to stop or it has status to return
state = running
last-status = 0
last-message = 'whatever information is useful’
last-failed-completion = empty
last-failed-status = 0
last-failed-message = empty
General Response for test completed successfully on its own

state = disabled
last-status = 0
last-message = 'test completed'
General Response for test cancelled by user

state = disabled
last-status = 1
last-message = 'test cancelled'
General Response for test failure

state = disabled
last-status = 2
last-message = meaningful message
last-failed-completion = date/time
last-failed-status = same value as last-status
last-failed-message = same value as last-message
• The suppressions object will not be returned since suppressions are not supported in the first
release
4. The API will only support a read operation for the entire content of ‘lmap-state’ object defined in ‘ietf-
lmap-control’ module. Thus, trying to read a subset (ex. lmap-state:schedules) will not be supported.

TWAMP vPMA Example
{
"ietf-lmap-control:lmap-state":{
"tasks":{
"task":[
{
"version":"1.0",
"name":"twamp-initiator"
},
{
"version":"1.0",
"name":"twamp-reflector"
},
{
"version":"1.0",
"name":"results"
}
]
},
"agent":{
"last-started":"2016-05-13T01:15:09.836709",
"agent-id":"22c5ea5c-18a8-11e6-9d27-fa163e8956a7",
"device-id":"urn:viavisolutions:model:vPMA:mac:%FA%16%3E%89%56%A7",
"version":"1.0"
},
"schedules":{
"schedule":[
{
"name":"My Test",
"last-invocation":"2016-05-20T13:52:17.987131",
"action":[
{
"state":"disabled",
"invocations":1,
"failures":1,
"last-status":2,
"last-invocation":"2016-05-20T13:50:05.510115",
"last-completion":"2016-05-20T13:52:48.510115",
"last-failed-completion":"2016-05-20T13:52:48.510115",
"last-failed-message":"None of the Destination IP address in the list
of flows could be resolved with ARP for source 172.20.30.128",
"last-completion":"2016-05-20T13:52:48.510115",
"last-message":"{\"TWAMP test\": \"Enabled\", \"testPort\": \"Config-
ured\"}",
"last-failed-status":1
}
]
}
]
}
}
}

MA Result Posting
LMAP Model
The LMAP model for sending results to a Collector is defined using the report object of the ietf-lmap-report
module.

module: ietf-lmap-report
rpcs:
+---x report
+---w input
+---w date yang:date-and-time
+---w agent-id? yang:uuid
+---w group-id? string
+---w measurement-point? string
+---w result*
+---w schedule-name? lmap:identifier
+---w action-name? lmap:identifier
+---w task-name? lmap:identifier
+---w metric* [uri]
| +---w uri inet:uri
| +---w role* string
+---w option* [id]
| +---w id lmap:identifier
| +---w name? string
| +---w value? string
+---w tag* lmap:tag
+---w start yang:date-and-time
+---w end? yang:date-and-time
+---w conflict* lmap:identifier
+---w table*
+---w column* string
+---w row*
+---w value* string
LMAP uses this module to define the format of the data sent from the MA to the Collector.
A list of one or more tasks are included in each data set and each task can contain one or more tables of
results.
The test parameters can optionally be included with each task in the ‘option’ object.

1. A single Test Task may need to report data that conforms to different table definitions.
Note: The LMAP committee is currently discussing the way to achieve this.
LMAP model draft version 4 has been updated to support multiple tables per task but there is not a
way to identify what data set is in each table. Until this is resolved the data set included in a report
will be identified using tag values and each table will be sent to the collector separately as its
own report.
2. Each Report Result will contain information useful for combining the data with other result sets. It
will place this data in the ‘tag’ object. The data that is expected to be reported is:
• schedule-id – created by the Viavi Controller. This represents a configuration that can be run
repeatedly.
• run-id - created by the Viavi Controller. This represents the number of times the user has re-
submitted the same schedule id. Value starts at 1.
• instance-start-time – created by the MA, this is reported if the schedule id was provided in
the test configuration. This value would be updated each time the schedule is executed.
Thus it would only have one value for an immediate test. It would have a different value for
each execution of a periodic test.
• sequence - created by the MA, this is a number that increases by one in each result set and
is used to detect missing results.
• result-type – created by the MA, this identifies the result schedule that generated the report:
realtime (rt), performance monitoring (pm) or final
• table-type – created by the MA, this identifies different table formats. This will only be used
when a test generates multiple report formats within the same result-type. For example, the
Y.1564 test produces final results for the Service Configuration and the Service Performance
subtests. It will report ‘table-type:sc’ or ‘table-type:sp’ so a client can identify them.
3. The ‘tag’ object will also contain any values defined in the schedule/tag or schedule/action/tag ob-
jects that were part of the test configuration.
4. Each result set sent to the Collector will include :
• Date
• Agent-id (MA-ID)
5. Group-id and measurement-point will not be supported.
6. The schedule-name, action-name and task-name will be provided in each report.
7. Until it is clear how to use the metric object in the report it will not be included.
8. The test configuration will be included in the ‘options’ object in the first report from a schedule
execution after it starts execution.
9. The ‘conflict’ object will not be included.
10. Each result set sent to the Collector will be for one test.

Y.1564 vTA Examples
Y.1564 vTA example while test is executing:

{
"ietf-lmap-report:report":{
"date":"2016-05-23T11:36:08-04:00",
"result":[
{
"start":"2016-05-23T11:36:08-04:00",
"option":[
],
"tag":[
"schedule-id:10000",
"result-type:rt"
],
"table":[
{
"column":[
"originator",
"stream-number",
"tx-frame-count",
"rx-frame-count",
"frame-loss-count",
"frame-loss-ratio",
"current-thruput",
"average-thruput",
"time-remaining",
"status"
],
"row":[
{
"value":[
"ENGINE_A",
"0",
"1000",
"1000",
"1234",
"0.0",
"0.0",
"0.0",
"20",
"TEST_STATUS_RUNNING_CIR_TEST_LOOPBACK_ENGINE_A_0"
]
}
]
}
],
"schedule-name":"my-schedule",
"action-name":"my-action",
"task-name":"my-task"
}
],
"agent-id":"123e4567-e89b-12d3-a456-426655440000",
}
}
Y.1564 vTA Final Service Configuration Report Example:

{
"ietf-lmap-report:report":{
"date":"2016-05-23T11:36:18-04:00",
"result":[
{
"start":"2016-05-23T11:36:08-04:00",
"option":[
],
"tag":[
"schedule-id:10000",
"result-type:final",
"table-type:sc"
],
"table":[
{
"column":[
"originator",
"step-name",
"stream-number",
"verdict",
"average-thruput",
"tx-frame-count",
"rx-frame-count",
"frame-loss-count",
"frame-loss-ratio",
"flr-verdict",
"oos-count",
"rtd-avg",
"rtd-max",
"rtd-min",
"fd-verdict",
"frame-size-average"
],
"row":[
{
"value":[
"engine-a",
"CIR",
"0",
"pass",
"0.0",
"1000",
"1000",
"1234",
"0.0",
"pass",
"0",
"0.0",
"0.0",
"0.0",
"no-verdict",
"64.0"
]
}
]
}
],
"schedule-name":"my-schedule",
"action-name":"my-action",

"task-name":"my-task"
}
],
"agent-id":"123e4567-e89b-12d3-a456-426655440000",
}
}
MA Registration
LMAP requires the MA to register with the controller when the MA application is started. Registration for this
controller consists of an HTTP POST from the MA to a pre-determined URL along with a URL parameter
that specifies which port on the MA to use for LMAP requests and which version of LMAP the MA supports.
http://<controller IP>:<controller port>/restconf/data/call-home? ma_listening_port=30500&lmap_api_ver-
sion=draft-ietf-lmap-yang-04
This channel configuration will need to be provided as part of the initial configuration for the MA when the
MA is created.
The Controller extracts the IP address of the MA from the request packet, uses the value of ma_listen-
ing_port from the registration request and issues an HTTP GET for the MA State (/restconf/data/ietf-lmap-
control:lmap-state) which will return agent information such as the MA-ID and the list of tasks the MA sup-
ports.
Note: Viavi has the need to return vendor-specific information when the controller reads the capabilities from
an MA. Especially for virtual devices, the hardware and environment that a VM is installed in will dictate the
capabilities of the software so Viavi wants to make this information available to the controller. A request was
made to the LMAP committee to add support for vendor/device-specific capabilities and that request has
been put on ‘hold’ by the LMAP committee:
https://www.ietf.org/mail-archive/web/lmap/current/msg02503.html
In the interim, a Viavi specific API will be used to retrieve the custom capabilities from each MA. This will be
an HTTP GET request to the MA for /restconf/data/capabilities. See the MA specific documentation for
details on what each MA returns.

4
Controller/Collector NETCONF APIs
A NETCONF interface on the server that hosts the Controller and Collector will be provided that will support the
following operations:
• Test configuration
• Test termination
• MA state retrieval
• Test Result Retrieval
The APIs are the row identified by the green arrow in the picture below from the overview:

These NETCONF APIs follow the LMAP documentation as close as possible, extending the MA API to an
external user.
The operations above require extra information not defined by LMAP. This is minimally identification of the
device on which to perform the operation, but in the case of Test Result Retrieval other inputs are required to
filter the result set.
These inputs are not defined by LMAP because LMAP defines the API for an MA.
These inputs are not defined by NETCONF since it assumes it is running on the device that is being
configured/queried.
These additional inputs are therefore expected to be obtained by offering new operations (rpc commands) in a
separate Viavi YANG model. The input and output of the operations is expected to be LMAP compliant where
possible.
Note: The ‘anyxml’ objects below are expected to be JSON formatted values. For example, when a test is
submitted, there is an XML ‘wrapper’ defined below that states which device the test if for but the test settings
themselves are expected to be JSON formatted data. Likewise, when status or report data is requested, the
request is made using the XML request below and the response contains JSON formatted data.
The format of the rpc operations will be similar to the rpc operations NETCONF defines such as ‘get’ and ‘get-
config’.
NETCONF YANG model for reference:
http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#candidate.96
Login
rpc login {
input {
leaf username {
type string;
description “user name”;
}
leaf password {
type string;
description “password”;
}
}
output {
leaf token {
type string;
}
leaf ttl {
type string;
description “time to live (in seconds)”;
}
leaf username {
type string;
}

list roles {
leaf role-name {
type string;
description “admin, xts, reports, etc.”;
}
}
leaf errorCode {
type string;
description “unique error identifier”;
}
leaf errorMessage {
type string;
description “optional descriptive text that describes the error”;
}
}
}
Logout
rpc logout {
input {
leaf token {
type string;
}
}
output {
leaf errorCode {
type string;
}
leaf errorMessage {
type string;
}
}
}
Get Token Details

rpc getTokenDetails {
input {
leaf token {
type string;
}
}
output {
leaf ttl {
type string;
description “time to live (in seconds)”;
}
leaf username {
type string;

}
list roles {
leaf role-name {
type string;
description “admin, xts, reports, etc.”;
}
}
leaf errorCode {
type string;
}
leaf errorMessage {
type string;
}
}
}
Renew Token
rpc renewToken {
input {
leaf token {
type string;
}
}
output {
leaf errorCode {
type string;
}
leaf errorMessage {
type string;
}
}
}
MA List
The Controller will keep a list of the MAs that register with it. Tests can only be executed on these devices per
LMAP. The list of MAs currently known by the Controller can be optained using this API. An controller-specific
id will be returned for each MA that will be used as input into other APIs to specify the MA on which those opera-
tions are to be performed.
rpc getMAList {
input {
leaf token {
type string;
}
}

output {
list devices {
key id;
leaf id {
type string;
description "unique controller id for device"
}
container model {
leaf vendor {
type string;
}
leaf model {
type string;
}
leaf version {
type string;
}
}
list connections {
leaf type {
type string;
description "proxy, probe, etc"
}
leaf uri {
type inet:uri;
description "base information for communication"
}
}
}
}
}
The operation will not take any input parameters. The output will be a list of objects that minimally contain the
data shown above.
• TWAMP MA will return

• model ‘vPMA’
• one connection of type ‘probe’, with a uri value in the format: "tcp://<management IP
address>:<management port, typically 80>"
• A Y.1564 MA will have two connections:
• model ‘vTA’
• one connection of type ‘proxy, with a uri value in the format: "tcp://<management IP
• one connection of type ‘probe’, with a uri value in the format: "tcp://<management IP

Test Configuration
Test Submission
Test submission data is expected to follow the format defined in the MA Test Submisison section for the MA.
The entire test (Test Schedule including test-specific parameters, Results Schedules and events) will be
provided along with the id of the MA(s) that should receive the test. A TWAMP test (initiator or reflector) can
only be sent to one MA at a time. A Y.1564 test will require one or two MAs depending on the test mode.
Y.1564 tests in loopback mode require one MA, the rest of the modes require two MAs (primary and secondary).
The Controller will inject a schedule id and run id into the schedule/action/tag object within the configuration
before sending the test request to the MA. These schedule and run ids will be returned as output to this API and
they will additionally then be included in reports sent to the collector so they can be used to retrieve results.
Note: The format of the example data shown in the MA Test Submission section is JSON and for NETCONF it is
required to be XML.
rpc startMATest {
input {
leaf token {
type string;
}
leaf runlater {
type string;
default "no";
}
container agent {
container primary {
leaf id {
type string;
}
leaf type {
type enumeration {
enum inventory {
description "device in inventory";
}
}
default "inventory";
}
leaf config {
type string;
description "name of test configuration section that follows"
}
}
list secondary {
key id;
leaf id {
type string;
}
leaf type {
type enumeration {

enum inventory {
description "device in inventory";
}
}
default "inventory";
}
leaf config {
type string;
description "name of test configuration section that follows"
}
}
}
anyxml config;
}
output {
leaf status {
type uint32;
}
leaf message {
type string;
}
leaf id {
type string;
description "schedule id for test on primary MA; assigned by Controller";
}
run-id {
type string;
description "run id for test on primary MA; assigned by Controller";
}
sha {
type string;
description "alternative to schedule id for identifying test; assigned by
Controller;";
}
leaf container-id {
type string;
description "id of container test that is an association of primary and secondary
tests; assigned by Controller only when test contains a secondary MA";
}
list secondary-id {
leaf agent-id {
type string;
description "secondary agent id";
}
leaf id {
type string;
description "schedule id for test on this secondary MA; assigned by
Controller";
}
}
time {
type string;
description "controller time ex. 20160202205124";
}
}
}
Example test configuration structure for Y.1564 test in concurrent bidirectional mode:

<viavi-config>
<agent>
<primary>
<type>inventory</type>
<id>Y1564-Agent5</id>
<config>primary-config</config>
</primary>
<secondary>
<id>Y1564-Agent6</id>
<config>secondary-config</config>
</secondary>
</agent>
<config>
<primary-config>
// LMAP configuration for primary MA goes here
</primary-config>
<secondary-config>
// LMAP configuration for secondary MA goes here
</secondary-config>
</config>
</viavi-config>
Test Submision Steps:
STEP 1: Build the Test Specific Data (e.g. TWAMP) XML per Viavi specification
STEP 2: Build the “LMAP” outer layer XML per Viavi “Test Submission” specification
STEP 3: Put the XML from step 1 and 2 together by inserting the XML content from step 1 into the XML in
step 2 at this location /ietf-lmap-control:lmap/schedules/schedule/action/option/value
See the examples in Chapter 2/Test Submission.
STEP 4: Build the XML that defines the device(s) that must receive the test.
• All tests would require one MA assigned to the primary role.
• Some tests, like Y.1564, may require a second MA assigned to the secondary role. For Y.1564
tests that require two MAs, the only difference between the test configurations is the value of the
‘role’ test parameter.
STEP 5: Submit the XML from steps 3 and 4 to the ‘startMATest’ operation in the ‘agents’ and ‘config’ objects
respectively.
Examples of test submission are below in a separate section.
Test Termination
Stopping a test can be performed using one of two sets of inputs.
• schedule id of primary/secondary/container test

• agent id and schedule name
In both cases the tests on the primary and secondary MAs involved in the test will be stopped.

rpc stopMATest {
input {
leaf token {
type string;
}
leaf agent-id {
type string;
}
leaf schedule-name {
type string;
}
leaf schedule-id {
type string;
}
}
}
The response from the operation will not contain any data, it will be success or failure.
MA State Retrieval
Since the LMAP command to retrieve the MA state does not define the MA as input, a new RPC operation will
be offered.
rpc getMAState {
input {
leaf token {
type string;
}
leaf agent-id {
type string;
}
}
output {
anyxml result;
}
}
The response from the operation will be an instance of the ‘ietf-lmap-control:lmap-state’ object.
Test Result Retrieval

Different types of results will exist depending on the test. Realtime intermediate, PM intermediate and Final
results are the types of results returned across TWAMP Initiator, Y.1564, TrueSpeed, and UDP tests.
The following scenarios are supported:

Use case 1: Get latest Intermediate or Final Results
- While a test is running, retrieve the latest set of results
Use case 2: Get range of Intermediate Results

- Retrieve multiple reports based on an optional starting timestamp

Two RPC operations will be offered to support these scenarios.
rpc getLatestReport {
input {
leaf token {
type string;
}
leaf schedule-id {
type string;
}
leaf run-id {
type string;
default "1";
description "instance of the schedule; returned when test was started";
}
leaf result-type {
type string;
description "report type such as rt, pm or final";
}
}
output {
anyxml result;
}
}
Inputs to getLatestReport are :
• schedule id of primary/secondary/container test (returned when test was started)

• run-id (returned when test was started)
• result-type (‘rt’ for realtime, ‘pm’ for performance monitoring or ‘final’ for final results)
The response will contain a single instance of an ietf-lmap-report:report.
rpc getReports {
input {
leaf token {
type string;
}
leaf schedule-id {
type string;
}
leaf run-id {
type string;
default "1";
description "instance of the schedule; returned when test was started";
}
leaf result-type {
type string;
description "report type such as rt, pm or final";
}
leaf starting-time {
type yang:date-and-time;
description "Timestamp of first report to return";
}
leaf max-reports {
type uint16{

range "1..25";
}
default 5;
description "Max number of reports to return";
}
}
output {
anyxml result;
}
}
Inputs to getReports are :
• schedule id of primary/secondary/container test (returned when test was started)

• run-id (returned when test was started)
• result-type (‘rt’ for realtime, ‘pm’ for performance monitoring or ‘final’ for final results)
and optionally:
• starting-time (timestamp that should be is first report returned. This is typically the value of ietf-
lmap-report:report/date from a report that was already returned)
• max-reports
The response will contain an array of ietf-lmap-report:report instances.
Note: The ietf-lmap-report:report/date and ietf-lmap-report:report/result/start will be reported in the Collector’s

timezone.
Use case 1: Get latest results
- getLatestReport is used with these input parameters:
• schedule-id
• run-id
• result-type=(‘rt’ or ‘final’ for Y.1564, TrueSpeed, and UDP; ‘rt’ or ‘pm’ for TWAMP)
Use case 2: Get range of Results

- getReports is used with these input parameters:
• schedule-id
• run-id
• result-type=(‘rt’ or ‘final’ for Y.1564, TrueSpeed, and UDP; ‘rt’ or ‘pm’ for TWAMP)
• starting-time (if all results are desired then the first request would not contain this parameter and
then subsequent requests would be made with this parameter set to the value of ietf-lmap-report:re-
port/date in the last report returned from the prior request until all data has been retrieved)
• max-reports
Test Submission Examples

Y1564 (loopback mode on vTA)

<?xml version="1.0" encoding="UTF-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<action xmlns="http://tail-f.com/ns/netconf/actions/1.0">
<data>
<startMATest xmlns="http://viavisolutions.com/ns/yang/vtest">
<token>ntcadmin</token>
<agent>
<primary>
<id>SAT-PROBE0</id>
<config>primaryConfig</config>
</primary>
</agent>
<config>{"config":[{"primaryConfig":{"ietf-lmap-
control:lmap":{"schedules":{"schedule":[{"name":"My
Test","start":"immediate","action":[{"name":"My Test-
action","task":"y1564","option":[{"id":"y1564","value":"{"y1564:y1564":{"engine-a-
info":{"engine-type":"vprobe","address":"10.12.57.103","port":"8081"},"y1564-
parameters":{"simulated":false,"mode":"loopback-engine-a","layer":"L2","run-config-
test":true,"step-duration":10,"step-percents":["25","50","75"],"run-perf-test":true,"perf-
test-duration":900,"abort-on-failure":false},"streams":[{"stream-number":0,"name":"My
Connection:Stream 1","cir-from-engine-a":10,"eir-from-engine-a":0,"run-policing-from-engine-
a":false,"frame-loss-ratio-threshold":0,"enable-frame-delay":true,"frame-delay-
threshold":100,"l2-config":{"destination-mac":"00:AA:BB:CC:DD:EE","frame-
length":512,"payload":"fill-byte"}}]}}"},{"id":"role","value":"primary"}],"destination":["My
Test-results-immediate-final","My Test-results-periodic-rt"]}]},{"name":"My Test-results-
immediate-final","start":"immediate","action":[{"name":"My Test-results-immediate-final-
action","task":"results","option":[{"id":"result-
type","value":"final"},{"id":"channel","value":"http://10.3.80.235:26088/restconf/operations/i
etf-lmap-report:report"}]}]},{"name":"My Test-results-periodic-rt","start":"My Test-results-
periodic-rt-event","action":[{"name":"My Test-results-periodic-rt-
type","value":"rt"},{"id":"channel","value":"http://10.3.80.235:26088/restconf/operations/ietf
-lmap-report:report"}]}]}]},"events":{"event":[{"name":"My Test-results-periodic-rt-
event","periodic":{"interval":1}}]}}}}]}</config>
</startMATest>
</data>
</action>
</rpc>
Y1564 (bi-directional mode on vTA)

<data>
<agent>
<primary>
<id>SAT-PROBE0</id>
</primary>
<secondary>

<id>SAT-PROBE1</id>
<config>secondaryConfig</config>
</secondary>
</agent>
info":{"engine-type":"vprobe","address":"10.12.57.103","port":"8081"},"engine-b-
parameters":{"simulated":false,"mode":"concurrent-bidirectional","layer":"L2","run-config-
a":false,"cir-from-engine-b":10,"eir-from-engine-b":0,"run-policing-from-engine-
b":false,"frame-loss-ratio-threshold":0,"l2-config":{"frame-length":512,"payload":"fill-
byte"}}]}}"},{"id":"role","value":"primary"}],"destination":["My Test-results-immediate-
final","My Test-results-periodic-rt"]}]},{"name":"My Test-results-immediate-
final","start":"immediate","action":[{"name":"My Test-results-immediate-final-
event","periodic":{"interval":1}}]}}}},{"secondaryConfig":{"ietf-lmap-
info":{"engine-type":"vprobe","address":"10.12.57.103","port":"8081"},"engine-b-
parameters":{"simulated":false,"mode":"concurrent-bidirectional","layer":"L2","run-config-
a":false,"cir-from-engine-b":10,"eir-from-engine-b":0,"run-policing-from-engine-
b":false,"frame-loss-ratio-threshold":0,"l2-config":{"frame-length":512,"payload":"fill-
byte"}}]}}"},{"id":"role","value":"secondary"}],"destination":["My Test-results-immediate-
final","My Test-results-periodic-rt"]}]},{"name":"My Test-results-immediate-
final","start":"immediate","action":[{"name":"My Test-results-immediate-final-
event","periodic":{"interval":1}}]}}}}]}</config>
</startMATest>
</data>
</action>
</rpc>

TrueSpeed (MA to MA on vTA)

<data>
<agent>
<primary>
<id>SAT-PROBE0</id>
</primary>
<secondary>
<id>SAT-PROBE3</id>
</secondary>
</agent>
control:lmap":{"schedules":{"schedule":[{"name":"Test-2016-07-15-
11:40","start":"immediate","action":[{"name":"Test-2016-07-15-11:40-
action","task":"truespeed","option":[{"id":"truespeed","value":"{"truespeed:truespeed":{"engin
e-a-info":{"engine-type":"vprobe","address":"10.12.57.106","port":"8081"},"engine-b-
info":{"engine-type":"vprobe","address":"10.12.57.107","port":"8081"},"truespeed-
parameters":{"engine-a-to-b-cir":100,"engine-b-to-a-cir":100,"percent-start-window-
walk":50,"window-duration":15,"connections":0,"num-windows":1,"run-saturation-
window":false,"bdp-table-version":1,"tos-
dscp":{"type":"dscp","dscp":0}}}}"},{"id":"role","value":"primary"}],"destination":["Test-
2016-07-15-11:40-results-immediate-final","Test-2016-07-15-11:40-results-periodic-
rt"]}]},{"name":"Test-2016-07-15-11:40-results-immediate-
final","start":"immediate","action":[{"name":"Test-2016-07-15-11:40-results-immediate-final-
etf-lmap-report:report"}]}]},{"name":"Test-2016-07-15-11:40-results-periodic-
rt","start":"Test-2016-07-15-11:40-results-periodic-rt-event","action":[{"name":"Test-2016-07-
15-11:40-results-periodic-rt-action","task":"results","option":[{"id":"result-
-lmap-report:report"}]}]}]},"events":{"event":[{"name":"Test-2016-07-15-11:40-results-
periodic-rt-event","periodic":{"interval":1}}]}}}},{"secondaryConfig":{"ietf-lmap-
11:40","start":"immediate","action":[{"name":"Test-2016-07-15-11:40-
action","task":"truespeed","option":[{"id":"truespeed","value":"{"truespeed:truespeed":{"engin
e-a-info":{"engine-type":"vprobe","address":"10.12.57.106","port":"8081"},"engine-b-
info":{"engine-type":"vprobe","address":"10.12.57.107","port":"8081"},"truespeed-
parameters":{"engine-a-to-b-cir":100,"engine-b-to-a-cir":100,"percent-start-window-
walk":50,"window-duration":15,"connections":0,"num-windows":1,"run-saturation-
window":false,"bdp-table-version":1,"tos-
dscp":{"type":"dscp","dscp":0}}}}"},{"id":"role","value":"secondary"}],"destination":["Test-
2016-07-15-11:40-results-immediate-final","Test-2016-07-15-11:40-results-periodic-
rt"]}]},{"name":"Test-2016-07-15-11:40-results-immediate-
final","start":"immediate","action":[{"name":"Test-2016-07-15-11:40-results-immediate-final-
etf-lmap-report:report"}]}]},{"name":"Test-2016-07-15-11:40-results-periodic-
rt","start":"Test-2016-07-15-11:40-results-periodic-rt-event","action":[{"name":"Test-2016-07-

15-11:40-results-periodic-rt-action","task":"results","option":[{"id":"result-
-lmap-report:report"}]}]}]},"events":{"event":[{"name":"Test-2016-07-15-11:40-results-
periodic-rt-event","periodic":{"interval":1}}]}}}}]}</config>
</startMATest>
</data>
</action>
</rpc>
TWAMP Initiator (on vPMA)
Note: A limit of 175 TWAMP sessions will be accepted per test submission
<data>
<agent>
<primary>
<id>rs-sprint11-2</id>
</primary>
</agent>
control:lmap":{"events":{"event":[{"name":"T3-results-periodic-pm-
event","periodic":{"interval":60}},{"name":"T3-results-periodic-rt-
event","periodic":{"interval":5}}]},"schedules":{"schedule":[{"action":[{"destination":["T3-
results-periodic-pm","T3-results-periodic-rt"],"name":"T3-
action","option":[{"id":"subnet","value":"255.255.255.0"},{"id":"gateway","value":"0.0.0.0"},{
"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.31.161","server-
ip":"172.20.31.162","server-tcp-port":862,"dscp":0,"twamp-session-request":[{"test-session-
name":"Flow 1","sender-ip":"172.20.31.161","sender-udp-port":50000,"reflector-
ip":"172.20.31.162","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"}]}}}}"}],"tag":["schedule-
id:1001440","run-id:1"],"task":"twamp-
initiator"}],"name":"T3","start":"immediate"},{"action":[{"name":"T3-results-periodic-pm-
action","option":[{"id":"result-
type","value":"pm"},{"id":"channel","value":"http://10.3.80.203:26088/restconf/operations/ietf
-lmap-report:report"}],"task":"results"}],"name":"T3-results-periodic-pm","start":"T3-results-
periodic-pm-event"},{"action":[{"name":"T3-results-periodic-rt-
action","option":[{"id":"result-
-lmap-report:report"}],"task":"results"}],"name":"T3-results-periodic-rt","start":"T3-results-
periodic-rt-event"}]}}}}]}</config>
</startMATest>
</data>
</action>
</rpc>

TWAMP Reflector (on vPMA)

<data>
<agent>
<primary>
<id>rs-sprint-11-1</id>
</primary>
</agent>
control:lmap":{"schedules":{"schedule":[{"action":[{"name":"TWAMP-REFLECTOR-rs-sprint-11-1-
action","option":[{"id":"source-
ip","value":"172.20.31.162"},{"id":"subnet","value":"255.255.255.0"},{"id":"gateway","value":"
172.20.31.1"},{"id":"twamp","value":"{"ietf-twamp:twamp":{"twamp-server":{"server-admin-
state":true,"server-tcp-
port":"862","dscp":0,"mode":"bits.unauthenticated"}}}"}],"tag":["schedule-id:1001408","run-
id:1"],"task":"twamp-reflector"}],"name":"TWAMP-REFLECTOR-rs-sprint-11-
1","start":"immediate"}]}}}}]}</config>
</startMATest>
</data>
</action>
</rpc>
UDP (MA to MA on vTA)

<data>
<agent>
<primary>
<id>SAT-PROBE0</id>
</primary>
<secondary>
<id>SAT-PROBE3</id>
</secondary>
</agent>
16:58:38","start":"immediate","action":[{"name":"Test-2017-07-14-16:58:38-
action","task":"udp","option":[{"id":"udp","value":"{\"udp:udp\":{\"engine-a-info\":{\"engine-

type\":\"vprobe\",\"address\":\"10.12.57.111\",\"port\":\"25080\",\"test-
ip\":\"192.168.57.111\",\"test-subnet-mask\":\"255.255.255.0\",\"test-
gateway\":\"192.168.57.1\"},\"engine-b-info\":{\"engine-
gateway\":\"192.168.57.1\"},\"udp-
parameters\":{\"mode\":\"unidirectional\",\"duration\":900,\"enable-
rtt\":true},\"streams\":[{\"stream-number\":1,\"name\":\"My Connection:Stream 1\",\"cir-from-
engine-a\":\"10\",\"udp-port\":\"8080\",\"frame-size\":\"512\",\"jitter-
threshold\":10}]}}"},{"id":"role","value":"primary"}],"destination":["Test-2017-07-14-
16:58:38-results-immediate-final","Test-2017-07-14-16:58:38-results-periodic-
rt"]}]},{"name":"Test-2017-07-14-16:58:38-results-immediate-
final","start":"immediate","action":[{"name":"Test-2017-07-14-16:58:38-results-immediate-
final-action","task":"results","option":[{"id":"result-
type","value":"final"},{"id":"channel","value":"http://10.104.16.212:26088/restconf/operations
/ietf-lmap-report:report"}]}]},{"name":"Test-2017-07-14-16:58:38-results-periodic-
rt","start":"Test-2017-07-14-16:58:38-results-periodic-rt-event","action":[{"name":"Test-2017-
07-14-16:58:38-results-periodic-rt-action","task":"results","option":[{"id":"result-
type","value":"rt"},{"id":"channel","value":"http://10.104.16.212:26088/restconf/operations/ie
tf-lmap-report:report"}]}]}]},"events":{"event":[{"name":"Test-2017-07-14-16:58:38-results-
periodic-rt-event","periodic":{"interval":1}}]}}}},{"secondaryConfig":{"ietf-lmap-
16:58:38","start":"immediate","action":[{"name":"Test-2017-07-14-16:58:38-
action","task":"udp","option":[{"id":"udp","value":"{\"udp:udp\":{\"engine-a-info\":{\"engine-
gateway\":\"192.168.57.1\"},\"engine-b-info\":{\"engine-
gateway\":\"192.168.57.1\"},\"udp-
parameters\":{\"mode\":\"unidirectional\",\"duration\":900,\"enable-
rtt\":true},\"streams\":[{\"stream-number\":1,\"name\":\"My Connection:Stream 1\",\"cir-from-
engine-a\":\"10\",\"udp-port\":\"8080\",\"frame-size\":\"512\",\"jitter-
threshold\":10}]}}"},{"id":"role","value":"secondary"}],"destination":["Test-2017-07-14-
16:58:38-results-immediate-final","Test-2017-07-14-16:58:38-results-periodic-
rt"]}]},{"name":"Test-2017-07-14-16:58:38-results-immediate-
final","start":"immediate","action":[{"name":"Test-2017-07-14-16:58:38-results-immediate-
final-action","task":"results","option":[{"id":"result-
type","value":"final"},{"id":"channel","value":"http://10.104.16.212:26088/restconf/operations
/ietf-lmap-report:report"}]}]},{"name":"Test-2017-07-14-16:58:38-results-periodic-
rt","start":"Test-2017-07-14-16:58:38-results-periodic-rt-event","action":[{"name":"Test-2017-
07-14-16:58:38-results-periodic-rt-action","task":"results","option":[{"id":"result-
type","value":"rt"},{"id":"channel","value":"http://10.104.16.212:26088/restconf/operations/ie
tf-lmap-report:report"}]}]}]},"events":{"event":[{"name":"Test-2017-07-14-16:58:38-results-
periodic-rt-event","periodic":{"interval":1}}]}}}}]}</config>
</startMATest>
</data>
</action>
</rpc>
Get Final Result

<data>

<getLatestReport xmlns="http://viavisolutions.com/ns/yang/vtest">
<schedule-id>1001591</schedule-id>
<result-type>final</result-type>
</getLatestReport>
</data>
</action>
</rpc>
Get Intermidate Result
1 of 2:
<data>
<getReports xmlns="http://viavisolutions.com/ns/yang/vtest">
<run-id>1</run-id>
<result-type>rt</result-type>
<max-reports>3</max-reports>
</getReports>
</data>
</action>
</rpc>
2 of 2
<data>
<getReports xmlns="http://viavisolutions.com/ns/yang/vtest">
<result-type>rt</result-type>
<starting-time>2016-07-29T21:28:00Z</starting-time>
<max-reports>3</max-reports>
</getReports>
</data>
</action>
</rpc>
Stop Test

<data>
<stopMATest xmlns="http://viavisolutions.com/ns/yang/vtest">

</stopMATest>
</data>
</action>
</rpc>


Fusion Controller Collector API 4.1

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Fusion Controller Collector API 4.1

Încărcat de

Drepturi de autor:

Formate disponibile

Controller & Collector APIs

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

MA, Controller and Collector APIs

LMAP Model ............................................................................................................................. 14

Summary of LMAP approach .................................................................................................... 16

Summary of Viavi approach ...................................................................................................... 17

Test Termination ........................................................................................................... 23

LMAP Model ............................................................................................................................. 23

Summary of LMAP approach .................................................................................................... 23

Summary of Viavi approach ...................................................................................................... 23

LMAP Model ............................................................................................................................. 24

Summary of LMAP approach .................................................................................................... 25

Summary of Viavi approach ...................................................................................................... 25

TWAMP vPMA Example ........................................................................................................... 28

MA Result Posting ......................................................................................................... 29

LMAP Model ............................................................................................................................. 29

Summary of LMAP approach .................................................................................................... 29

Summary of Viavi approach ...................................................................................................... 30

Y.1564 vTA Examples............................................................................................................... 31

Controller/Collector NETCONF APIs ...................................................................................................... 35

MA, Controller and Collector APIs

Get Token Details .......................................................................................................... 37

Renew Token ................................................................................................................ 38

Test Configuration ......................................................................................................... 40

Test Submission ....................................................................................................................... 40

Test Termination ........................................................................................................... 42

Test Result Retrieval ..................................................................................................... 43

Test Submission Examples ........................................................................................... 45

Y1564 (loopback mode on vTA) ................................................................................................ 45

Y1564 (bi-directional mode on vTA) .......................................................................................... 46

TrueSpeed (MA to MA on vTA) ................................................................................................. 48

TWAMP Initiator (on vPMA) ...................................................................................................... 49

TWAMP Reflector (on vPMA) .................................................................................................... 50

UDP (MA to MA on vTA) ........................................................................................................... 50

Get Final Result ........................................................................................................................ 51

Get Intermidate Result .............................................................................................................. 52

Stop Test .................................................................................................................................. 52

Controller and Collector APIs

1. Get Final Result

Controller and Collector APIs

• A Framework for Large-Scale Measurement of Broadband Performance

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

• Information Model for Large-Scale Measurement Platforms

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

• YANG Data Model for LMAP

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

• YANG Modeling Language

• NETCONF YANG Model

Controller and Collector APIs

The APIs presented are split into these categories:

Controller and Collector APIs

Model Platform MA Tests

• Loopback device mode

Controller and Collector APIs

Page 10 Confidential 4 December 2018

PC Client PC 2.0.6 • RFC-6349 Layer 4 TrueSpeed

vTA-TS Virtual 1.0.4 • RFC-6349 Layer 4 TrueSpeed

vPMA Virtual 2.1 • RFC-5357 TWAMP & TWAMP Light

T-BERD/MTS-5800v2 Instrument 26.3 Controller submitted tests

QT-600-10 QT-600-10 11.7.2 • RFC-6349 Layer 4 TrueSpeed

MA specific API documentation is available for these.

Controller and Collector APIs

4 December 2018 Confidential Page 11

Controller and Collector APIs