Service Endpoints

Service Endpoint

The service-endpoint object defines the logical test endpoint for a test session and typically reference an interface or physical port. Both the source (sender) and destination (target/reflector) endpoints of a test session need to be defined in the YANG model as service-endpoints.

When configuring a test session between two service-endpoints, only the Provider Connectivity Assurance sensor endpoints can be defined as the sender.

A non-Provider Connectivity Assurance device or server that is acting as a reflector/responder/loopback also needs to be defined as an endpoint in the YANG service model in order to be referenced by any test sessions monitoring towards this endpoint. This type of external reflector is sometimes referred to as "unmanaged reflector" or "third-party responder". A server with ICMP echo reply support is an example of an unmanaged reflector.

When using Cisco Provider Connectivity Assurance Sensor Control (formerly Skylight sensor control) with Cisco Provider Connectivity Assurance Sensor SFP (formerly Skylight sensor: SFP compute), each VCE (Virtual Circuit Endpoint) must be defined as a service-endpoint. The same applies to Assurance Sensor Agents, where each VRF is defined as a service-endpoint.

Mapping service-endpoint to a Provider Connectivity Assurance Device

For the Provider Connectivity Assurance YANG gateway to associate a service-endpoint with the correct Sensor SFP, Sensor Control, or Assurance Sensor Agent interface, parameters in the service-endpoint "config" section are used to match the proper device. Depending on if the service-endpoint is going to be used for assurance sessions or SAT (RFC2544/Y.1731 testing) there are two different sub types of the service-endpoint: "ne-endpoint" or "nid-endpoint".

service-endpoint for TWAMP and Sensor Agent Test Sessions

To define a service-endpoint for service assurance and Assurance Sensor Agent type tests, the endpoint needs to be set to type "ne-endpoint", and include as a minimum the "ne-id" and "vlan" parameters. If VRF or Sensor SFP is used, then the sub-interface must also be defined. The IP address field is optional. If it is not specified here on the endpoint, it needs to be defined on the session instead.

Example

"config":{
                        "Accedian-service-endpoint-ne:ne-config":{
                            "ne-id":"example-ne-endpoint",
                            "vlan-id":1,
                            "ip":"10.1.2.3",
                            "sub-interface":"myYellowVRF"
                        }
                    }

To facilitate the matching to a physical or virtual sensor, the following configuration needs to be done on the sensor itself:

Assurance Sensor Agent: define the ne-id and vlan-id as environment variables in the docker-compose file or as startup options for "docker run".

Assurance Sensor Control: rename the local or VCE interface so it contains the ne-id and either a vlan-id or sub-interface, with the syntax "ne-id+vlan-id+sub-interface+".

Example:
my-ne-endpoint+0++

See, TWAMP for examples of how to define service-endpoints and TWAMP tests.

service-endpoint for RFC2544 / Y.1731 Service Activation Testing (SAT)

To define a service-endpoint for SAT tests, the type "nid-endpoint" is used together with a "config" that defines which Assurance Sensor Control (nid-id), which Sensor SFP (sub-id) and which side of the Sensor SFP to transmit from (port).

Example

 "config":{
                        "Accedian-service-endpoint-nid:nid-config":{
                            "nid-id":"SensorControlName",
                            "sub-id":"P123-1234",    <-- ID of the SFP Compute
                            "port":"P123-1234-NNI"   <-- NNI or UNI side of the SFP Compute
                        }
                        

See SAT for details and examples of how to define service-endpoints and SAT tests.

Endpoint Object Parameters Reference

Endpoint RESTCONF Example for ne-endpoint (TWAMP and Agent Tests)

Example RESTCONF message to create a new endpoint object:

             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"
                         }
                     }
                 }]
             }

In this example, "example-endpoint-1" is used for both the endpoint ID, endpoint-name and as ne-id string. It is recommended to use this scheme unless there are reasons to do it differently.

Matching rules for ne-endpoint config parameters can be seen below for Assurance Sensor Agents and Assurance Sensor Control interfaces/VCEs.

Endpoint RESTCONF Example for nid-endpoint (RFC2544 and Y.1564 SAT tests)

Example RESTCONF message to create two new endpoint object for SAT testing.

Note that the endpoint definition does not specify if an endpoint will be used for sending or as the test loopback, that is instead defined on the SAT test session.

POST http://localhost:8081/restconf/data/Accedian-service-endpoint:service-endpoints
{
  "Accedian-service-endpoint:service-endpoint": [
    {
      "endpoint-id": "my_first_endpoint",
      "endpoint-name": "my_first_endpoint",
      "description": "SAT y1564 or RFC2544 endpoint",
      "type": "Accedian-service-endpoint-type:nid-endpoint",
      "config": {
        "Accedian-service-endpoint-nid:nid-config": {
          "nid-id": "PCASC-DEMO-1",
          "sub-id": "P802-0325",
          "port": "P802-0325-NNI"
        }
      }
    },
    {
      "endpoint-id": "my_second_endpoint",
      "endpoint-name": "my_second_endpoint",
      "description": "SAT y1564 or RFC2544 endpoint",
      "type": "Accedian-service-endpoint-type:nid-endpoint",
      "config": {
        "Accedian-service-endpoint-nid:nid-config": {
          "nid-id": "PCASC-DEMO-1",
          "sub-id": "P802-0323",
          "port": "P802-0323-UNI"
        }
      }
    }
  ]
}

In this example, "PCASC-DEMO-1" refers to the Assurance Sensor Control instance name and is the "nid-id" for both endpoints. The "sub-id" and "port" settings point to the individual Sensor SFP that is managed by this Assurance Sensor Control.

Matching rules for nid-endpoint config parameters can be seen below for Assurance Sensor Control / Assurance Sensor SFP.