Performance Session Types

In Skylight orchestrator, you can set up the following types of performance sessions:

• TWAMP sessions (stateful and stateless)
• Echo sessions (ICMP and UDP)
• Ethernet OAM sessions (ETH-DM, ETH-LB, ETH-VS)
• 2xOneway sessions (Accedian Layer 3 session type)
• NFV sessions (via an NFV tunnel)

This article introduces each of the session types.

TWAMP Sessions

Skylight orchestrator supports Two-Way Active Measurement Protocol (TWAMP) sessions in accordance with the RFC 5357 specification. TWAMP sessions monitor performance on Layer 3.

RFC 5357 specifies two protocols:

• TWAMP-Test protocol
• TWAMP-Control protocol

Skylight orchestrator supports both TWAMP protocols. The setup required for both protocols are explained and illustrated below in this section.
For the metrics reported by TWAMP sessions, see "Performance Session Metrics".
For more information about the TWAMP protocol, see the RFC-5357 specification.

Setup for a Basic TWAMP Session

A basic TWAMP session (using the TWAMP-Test protocol) takes place over a UDP connection set up between a sender and a reflector. The TWAMP session has two directions: uplink (sender to reflector) and downlink (reflector to sender).

The following diagram shows how a basic TWAMP session is set up in the Skylight Solution. The sender can be a Skylight sensor: control or a Sylight sensor: module (connected to Skylight sensor: control and configured as a VCE). The reflector can be any device capable of reflecting standard TWAMP.

Setup for a TWAMP Session with TWAMP-Control

The TWAMP-Control protocol uses an additional TCP connection to control the TWAMP-test session taking place on the UDP connection. The TWAMP-Control requires four components:

• Sender: The component that generates the TWAMP-test packets and sends them to the reflector.
• Reflector: The component that receives the TWAMP-test packets from the sender and
• reflects them back to the sender.
• Control Client: The component that initiates the TCP connection.
• Control Server: The component that acknowledges the TCP connection. Control messages are exchanged between the control client and the control server.

The four components could reside on four different devices, however they typically reside on two devices as follows:

• One device hosts the control client and the sender
• One device hosts the control server and the reflector

The following diagram shows the typical setup for a TWAMP with control session:

Stateful and Stateless TWAMP Reflectors

TWAMP reflectors can be stateful or stateless. Skylight orchestrator supports both types of reflectors.

• A stateful reflector provides a separate series of sequence numbers for the return packets. Metrics (for packet loss, reorder and duplication) are reported separately for the uplink and downlink directions.
• A stateless reflector does not have sequence numbers so round-trip packet domain metrics are reported.

Echo Sessions

Echo sessions monitor performance on Layer 3. Echo sessions are used for continuous monitoring of bidirectional connectivity toward any regular IP-enabled network element such as a server, Layer-3 CPE or managed Ethernet switch.
An Echo session can be configured to use one of the following protocols:

• ICMP Echo Request. An ICMP Echo session measures and reports on bidirectional connectivity and round-trip metrics using the ICMP Echo protocol (ping).
• UDP Echo Request. A UDP Echo session measures and reports on bidirectional connectivity and round-trip metrics using the UDP Echo protocol.

For the metrics reported by Echo sessions, see "Performance Session Metrics". The following diagram illustrates both types of Echo sessions.

Ethernet OAM Sessions

Ethernet OAM sessions monitor performance on Layer 2. The ITU-T Y.1731 and IEEE 802.1ag standards define an Operations, Administration and Maintenance (OAM) framework for Ethernet based networks and defines OAM functions for fault management and performance monitoring.
Skylight orchestrator supports sessions based on the following Ethernet OAM functions:

• Ethernet Loopback (ETH-LB): An ETH-LB session is set up toward an ITU-T Y.1731 (or IEEE 802.1ag) enabled network device to measure and verify bi-directional connectivity between the sender and network devices (MEP to MEP/MIP).
  The ETH-LB function measures and reports on round-trip time (RTT), RTT variation, packet loss, reordered and duplicated packets based on two-way measurements
• Frame Delay Measurement (ETH-DM): An ETH-DM session is set up toward an ITU-T Y.1731 enabled network device to measure and verify bidirectional connectivity between the sender and network devices (MEP to MEP).
  The ETH-DM function measures and reports round-trip time (RTT), RTT variation, one- way propagation delay for both uplink and downlink directions. It also measures and reports on packet loss, reordered packets and duplicated packets based on two-way measurements.
• 2xOneWay in Vendor Specific PDU (ETH-VS): Accedian provides an enhanced bi- directional measurement function for Layer 2 networks by implementing Accedian's 2xOneWay session as a vendor-specific OAM PDU (ETH-VSP) session. This type of session measures and reports all metrics (delay, jitter, loss, and so on) based on one-way measurements.

For the metrics reported by Ethernet OAM sessions, see "Performance Session Metrics".

The following diagram shows ETH-LB and ETH-DM measurements toward network devices enabled for ITU-T Y.1731 (IEEE 802.1ag).

2xOneWay Sessions

The 2xOneWay session is an Accedian proprietary performance session that provides a superset of features compared to a standard RFC 5357 TWAMP session. 2xOneWay sessions monitor performance on Layer 3. They are designed for use with the Accedian reflector agent.

A 2xOneWay session can be set up in two ways:

• Between two Accedian devices: One device acts as the sender and is responsible for originating and terminating the session. The other device acts as the reflector and is only responsible for reflecting packets back to the sender. The following encapsulations are available: UDP, TCP, GRE, SCTP, ICMP and RTP.
• Between an Accedian sender device and an Accedian reflector agent embedded in a third-party device or host (a user-space reflector): Only UDP encapsulation is supported.

For the metrics reported by 2xOneWay sessions, see "Performance Session Metrics".

The following diagram shows the two ways of setting up 2xOneWay sessions. Session A is between two Accedian devices (one acting as the sender and one acting as the reflector). Session B is between an Accedian device (acting as the sender) and a third party server with an embedded Accedian reflector agent (acting as the reflector).

NFV Sessions

The Skylight sensor: control is a key component in the Skylight solution. A single Skylight sensor: control can be linked to hundreds of Accedian Skylight sensor: modules installed throughout the network. While a Skylight sensor: control can itself act as the sender in a performance session, the more common scenario is for the Skylight sensor: modules linked to the Skylight sensor: control to act as senders in sessions.

The Skylight sensor: control uses Network Function Virtualization (NFV) to allow its Skylight sensor: modules to act as the sender in sessions. The Skylight sensor: control generates the packet stream and sends it to a Skylight sensor: module via an NFV tunnel. The Skylight sensor: module timestamps the packets and sends them to the reflector. This arrangement permits highly accurate timestamping of sessions.

The Virtual Connection Endpoint (VCE) is the mechanism that enables a Skylight sensor: module to act as a sender or reflector in a session. A VCE is a specialized interface that is defined on a sensor: control. A VCE defines the NFV IP address and VLAN header for one of the Skylight sensor: modules linked to the sensor: control.

Sessions that use a VCE as the sender or the reflector are called NFV sessions. VCEs can be used for the following types of sessions:

• NFV ECHO-ICMP and NFV ECHO-UDP sessions (on Layer 3)
• NFV ETH-DM, NFV ETH-LB and NFV ETH-VS sessions (on Layer 2)
• NFV TWAMP sessions (on Layer 3)

The metrics reported for an NFV session are the same as the metrics for the corresponding non-NFV session. For more information, see "Performance Session Metrics".

The following diagram shows an NFV session. The sender is a Skylight sensor: module connected to a sensor: control. A VCE has been defined for the Skylight sensor: module on the sensor: control. The Skylight sensor: control generates the stream and sends it to the Skylight sensor: module (via the NFV tunnel). The Skylight sensor: module timestamps the packets and sends them to the reflector. The Skylight sensor: module also timestamps the stream that it receives from the reflector.

Skylight orchestrator supports up to 500 VCEs for each Skylight sensor: control that is in its list of Managed Elements. The 500 VCEs can be defined for a single Skylight sensor: module or can be spread across up to 500 Skylight sensor: modules.
Three interfaces can be defined for a VCE:

• Standard interface: Used for Layer 3 sessions. Contains the IP address used as the source IP address for sessions originating through this VCE.
• TP-A interface: The UNI interface (User-to-Network Interface) of the Skylight sensor: module. Used for Layer 2 sessions.
• TP-Z interface: The NNI interface (Network-to-Network Interface) of the Skylight sensor: module. Used for Layer 2 sessions.

The TP-A and TP-Z interfaces can be configured for two purposes: for VLAN tagging and for enabling/disabling the Layer 2 and Layer 3 capabilities of the VCEs. Both interfaces are always enabled for NFV sessions on Layer 2. Each interface can be enabled or disabled separately for NFV sessions on Layer 3.

All three interfaces use the NFV tunnel dedicated to the Skylight sensor: module for communication between the Skylight sensor: control and the Skylight sensor: module. When a Skylight sensor: control is added to Skylight orchestrator, its VCE interfaces are added to the list of interfaces available for setting up sessions. You can manually refresh the list of interfaces for a Skylight sensor: control in Skylight orchestrator by selecting the Skylight sensor: control in the Managed Elements list and clicking above the list.

VCE Rules for Layer 2 Performance Sessions
VCEs for Layer 2 performance sessions are impacted by the SOAM library version of the underlying Skylight sensor: module. Please refer to the table below for the list of supported configurations.

For more information about setting up VCEs on a Skylight sensor: control, see the "Skylight sensor: control User Manual".

VCEs can also be configured on a Skylight sensor: control from Skylight orchestrator using a configuration job. See "Setting Up a Virtual Connection Endpoint (VCE) Configuration Job".