TWAMP and Metadata

TWAMP-Light RFC 5357 Sessions

Endpoint Definition

To set up TWAMP light test sessions using the RESTCONF YANG interface, you must first define the test endpoints. These endpoints, which are used for both TWAMP and sensor agent tests, utilize the ne-endpoint type and represent an interface, VCE, or VRF on the Assurance Sensor Control, Assurance Sensor SFP, or Assurance Sensor Agent.

The example below configures two service-endpoints of ne-endpoint type for use in TWAMP-light tests. These service-endpoints utilize different geo-coordinate metadata to represent their locations (the first in Stockholm and the second in Oslo). The configuration defines the ne-endpoint settings used to match these endpoints to Assurance Sensor Control or Sensor Agent interfaces.

             RESTCONF POST :: /restconf/data/Accedian-service-endpoint:service-endpoints
             {
                 "Accedian-service-endpoint:service-endpoint":[
                 {
                     "endpoint-id":"example-endpoint-1",
                     "endpoint-name":"example-endpoint-1",
                     "geo-location":{
                         "latitude":"59.334591",
                         "longitude":"18.06324"
                     },
                     "type":"Accedian-service-endpoint-type:ne-endpoint",
                     "config":{
                         "Accedian-service-endpoint-ne:ne-config":{
                             "ne-id":"example-endpoint-1",
                             "vlan-id":0,
                             "ip":"192.168.0.4"
                         }
                     }
                 },
                 {
                     "endpoint-id":"example-endpoint-2",
                     "endpoint-name":"example-endpoint-2",
                     "geo-location":{
                         "latitude":"59.911491",
                         "longitude":"10.757933"
                     },
                     "type":"Accedian-service-endpoint-type:ne-endpoint",
                     "config":{
                         "Accedian-service-endpoint-ne:ne-config":{
                             "ne-id":"example-endpoint-1",
                             "vlan-id":0,
                             "ip":"192.168.0.6"
                         }
                     }
                 }]
             }

After defining the endpoints, you can create a TWAMP session by designating one service-endpoint as the sender and the other as the reflector.

             RESTCONF POST :: /restconf/data/Accedian-session:sessions
             {
                 "Accedian-session:session":[{
                     "session-id":"example-twamp-1",
                     "session-name":"example-twamp-1",
                     "session-type":"Accedian-session-type:twamp-light",
                     "service-endpoints":[{
                         "endpoint-id":"example-endpoint-1",
                         "session-protocol":{
                             "Accedian-session-twamp-light:twamp-light":{
                                 "session-sender":{
                                     "admin-state":true,
                                     "reflector-udp-port":4002,
                                     "test-packets":{
                                         "rate":20
                                     }
                                 }
                             }
                         }
                     },{
                         "endpoint-id":"example-endpoint-2",
                         "session-protocol":{
                             "Accedian-session-twamp-light:twamp-light":{
                                 "session-reflector":{
                                     "admin-state":true,
                                     "reflector-udp-port":862,
                                     "mode":"stateful"
                                 }
                             }
                         }
                     }],
                     "metadata":{
                         "key-value":[{
                             "key-name":"access_type",
                             "value":"residential"
                         }]
                     }
                 }]
             }

After creating the session, you can optionally assign it to a service for threshold-alerting or grouping by a service ID. To add the session to a new service, reference the session ID in a service object, as shown in the example below:

             RESTCONF POST :: /restconf/data/Accedian-service:services
             {
                 "Accedian-service:service":[{
                     "service-id":"example-service",
                     "service-name":"example-service",
                     "description":"hello",
                     "sessions":[{
                         "session-id":"example-twamp-1"
                     }],
                     "metadata":{
                         "key-value":[{
                             "key-name":"region",
                             "value":"Nordics"
                         }]
                     },
                     "alerts":[{
                         "alert-policy-id":"alert-example-1"
                     }]
                 }]
             }

Below is a sample screenshot from Provider Connectivity Assurance after provisioning with the above YANG configuration. The location metadata is derived from the service-endpoint configuration, while the session settings and metadata are assigned from the session. The service-level alert policy and metadata are taken from the service object. For details on threshold crossing alerts and state notifications, see //link to alerts//.

Metadata

Metadata is a key concept in Provider Connectivity Assurance, enabling the grouping, correlation, and filtering of metrics and sessions using key-value pairs.

Provider Connectivity Analytics utilize a set of predefined metadata categories such as geo-location, topology, service_id, ne_id_sender, and ne_id_reflector. However, custom categories (keys) can also be created to represent user-specific needs. In this example, the access_type category is a custom one and has been set to ‘residential’ for the session created above.

Metadata Hierarchy in the YANG Model

In Provider Connectivity Assurance Analytics, metadata is typically represented on the session object within the inventory. Each time-series metric ingested for the session is tagged with the corresponding metadata keys and values.

The image below illustrates how YANG model objects map to metadata on the Analytics session object.

Creating a New Metadata Category with RESTCONF

To create a new category (key) for service or session metadata, use the metadata-key node and add one or more new key-name entries, as shown below.

       RESTCONF POST :: /restconf/data/Accedian-metadata:metadata-config
             {
                 "Accedian-metadata:metadata-key":[{
                     "key-name":"my_new_category"
                 }]
             }