Performance Session Types

In Legacy 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 (Layer 3 session type)
• NFV sessions (via an NFV tunnel)

This article introduces each of the session types.

TWAMP Sessions

Legacy 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

Legacy 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 Provider Connectivity Assurance Solution. The sender can be a Assurance Sensor Control or a Sylight sensor: module (connected to Provider Connectivity Assurance 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. Legacy 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.
Legacy 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): Cisco provides an enhanced bi- directional measurement function for Layer 2 networks by implementing Cisco'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 a 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 reflector agent.

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

• Between two Cisco 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 a Cisco sender device and a Cisco 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 Cisco devices (one acting as the sender and one acting as the reflector). Session B is between an Cisco device (acting as the sender) and a third party server with an embedded Cisco reflector agent (acting as the reflector).

NFV Sessions

The Assurance Sensor Control is a key component in the Provider Connectivity Assurance solution. A single Assurance Sensor Control can be linked to hundreds of Cisco Assurance Sensor Modules installed throughout the network. While an Assurance Sensor Control can itself act as the sender in a performance session, the more common scenario is for the Assurance Sensor Modules linked to the Assurance Sensor Control to act as senders in sessions.

The Assurance Sensor Control uses Network Function Virtualization (NFV) to allow its Assurance Sensor Modules to act as the sender in sessions. The Assurance Sensor Control generates the packet stream and sends it to a Assurance Sensor Module via an NFV tunnel. The Assurance 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 an Assurance 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 Assurance 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 an Assurance Sensor Module connected to a sensor: control. A VCE has been defined for the Assurance Sensor Module on the sensor: control. The Assurance Sensor Control generates the stream and sends it to the Assurance Sensor Module (via the NFV tunnel). The Assurance Sensor Module timestamps the packets and sends them to the reflector. The Assurance Sensor Module also timestamps the stream that it receives from the reflector.

Legacy orchestrator supports up to 500 VCEs for each Assurance Sensor Control that is in its list of Managed Elements. The 500 VCEs can be defined for a single Assurance Sensor Module or can be spread across up to 500 Assurance 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 Assurance Sensor Module. Used for Layer 2 sessions.
• TP-Z interface: The NNI interface (Network-to-Network Interface) of the Assurance 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 Assurance Sensor Module for communication between the Assurance Sensor Control and the Assurance Sensor Module. When a Assurance Sensor Control is added to Legacy 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 Assurance Sensor Control in Legacy orchestrator by selecting the Assurance 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 Assurance Sensor Module. Please refer to the table below for the list of supported configurations.

For more information about setting up VCEs on a Assurance Sensor Control, see the "Assurance Sensor Control User Manual".

VCEs can also be configured on an Assurance Sensor Control from Legacy orchestrator using a configuration job. See "Setting Up a Virtual Connection Endpoint (VCE) Configuration Job".