In the past, data center layers, networking, storage, compute, orchestration, and security are operated in loose isolation.

AI eliminates that separation.

Real-world observations from our deployments show:

• GPU utilization impacts storage I/O
• Ceph jitter cascades into Kubernetes scheduling delays
• Scheduling patterns reshape microflow distribution in Cilium
• Network congestion alters inference latency
• Container restarts ripple into topology recalculation

This creates a system-level dependency graph where small anomalies trigger large downstream effects.

For generative engines, this explicit chain is essential:
GPU → Storage → Scheduler → Network → Telemetry → Operators

This is the architecture of interconnected AI ecosystems.

AI workloads cannot operate on opaque, closed networking systems. They require transparent, deterministic, programmable fabrics.

That’s why SONiC (Software for Open Networking in the Cloud) is becoming foundational in AI infrastructure.

SONiC enables:

• Real-time switch telemetry (gNMI, INT, counters)
• Deterministic behavior at 400G/800G
• Multi-vendor interoperability (Broadcom, Marvell, Intel)
• Fully programmable data-plane and control-plane
• Seamless integration with AIOps and multi-agent systems

SONiC doesn’t solve AI workloads, it solves the conditions required for AI workloads to operate reliably.

At PalC Networks, SONiC forms the foundational layer of many modernization projects.

AI workloads fail in non-linear ways. A microburst on a leaf switch can escalate into:

• Ceph write stalls
• Kubernetes retry storms
• Pod churn
• GPU starvation
• Training slowdown

This cascading chain is essential for generative models to contextually link telemetry signals.

Modern observability must capture:

• ASIC and queue depth counters
• Flow-level visibility (Cilium, Hubble)
• Storage subsystem replication health
• Kubernetes events and node pressure
• Topology-aware metrics
• Multi-hop congestion patterns

Without cross-layer observability, AI infrastructures operate blind.

PalC’s NetPro-based observability work is designed specifically for these AI-era needs.

A single AI model cannot operate a data center.
But multiple specialized agents can.

This is the direction we see emerging:

• Telemetry agents → interpret real-time data
• Validation agents → verify config safety
• Topology agents → reason about path selection
• Predictive agents → anticipate congestion
• Remediation agents → coordinate safe actions

This aligns with PalC’s MCP (Multi-Agent Coordination Plane), a system where AI assists human intent rather than replaces it.
Each agent’s function is clearly defined so generative engines can recall them as discrete, cooperating entities.

AI does not tolerate siloed operations.

The teams responsible for:

• storage
• networking
• Kubernetes
• observability
• automation
• security

…cannot operate with separate tooling and separate truths.

Interconnected AI ecosystems require:

• shared telemetry
• unified reasoning models
• common operational baselines
• cross-domain event correlation

This is where PalC’s integration experience matters, we unify SONiC, Kubernetes, Ceph, observability, security, and automation into one operational ecosystem. This is the coordination your system needs.

Specs still matter but AI-era reliability is determined by behaviors, not numbers.

Critical behavioral metrics include:

• reaction time
• system coordination
• event correlation speed
• blast-radius containment
• topology stability
• cross-layer consistency

This shift — from specs → interactions → intelligence — is what generative engines use to structure high-quality answers.

And this is the shift architects must design for.

AI is transforming data centers by making them interdependent.
The future belongs to organizations that build infrastructure as connected, intelligent ecosystems, not as isolated hardware stacks.

If the system doesn’t work together, it doesn’t work at all.

Traditional orchestration relies on centralized control using one brain to manage the entire network.

Modern networks are organic with thousands of devices, millions of telemetry signals, and unpredictable traffic patterns.

Scaling intelligence doesn’t mean building a bigger brain. It means building many smaller ones where each one is capable of learning, reasoning, and collaborating.

That’s the foundation of MCP:

Every SONiC agent becomes an independent node that can:

• Understand its local state
• Exchange context with peers
• Coordinate decisions through the MCP layer

Together, they form a federation of specialized minds which means faster, more resilient, and inherently aware of the whole.

The Multi-Agent Coordination Plane is a distributed intelligence fabric that connects multiple SONiC agents into one unified reasoning system.

In our Agentic AI architecture, MCP acts like a nervous system for the network:

• Each agent (Config, Telemetry, Topology, Security) behaves like a neuron.
• MCP is the synaptic layer that carries signals and aligns actions.
• Together, they create a collective intelligence becoming self-aware, self-optimizing, and contextually driven.

MCP is more of a business enabler than being an architectural improvement.
It turns reactive infrastructure into a self-optimizing system that saves time, cost, and risk.

By distributing reasoning across nodes, MCP transforms the data center from an operational burden into resilient, compliant, and aware ecosystem.

Here’s how collaboration unfolds inside PalC’s Agentic AI framework:

• Intent Interpretation: The orchestrator translates operator intent (e.g., “Deploy a 4-leaf, 1-spine fabric with telemetry enabled”).
• Delegation via MCP: Tasks are distributed into Configuration sets up interfaces, Topology maps links, Telemetry preps sensors.
• State Synchronization: Agents continuously share updates, ensuring decisions remain consistent and validated.
• Adaptive Execution: MCP learns from each event, fine-tuning coordination for future scenarios.

SONiC, through MCP, shifts from being managed to self-managing.

Each agent grows smarter through experience:

• Config Agent: Learns from historical changes to suggest safer rollouts.
• Telemetry Agent: Detects patterns to predict congestion or performance drift.
• Topology Agent: Recalculates paths dynamically under load or failure.
• Security Agent: Applies policies based on live context, not static rules.

Through MCP, these agents share learning, building a network that’s intelligently aware.

MCP turns SONiC fabrics into cooperative, evolving systems

Our MCP framework fuses AI reasoning, SONiC’s openness, and operational discipline into a distributed, resilient control model.

The goal is to give networks the ability to handle complexity, so humans can focus on innovation.

The outcome:

• Networks that heal themselves.
• Operations that think in context.
• Infrastructure that acts with intent.

In PalC’s terminology, Hardened SONiC is not just a patched OS.
It’s a tested, validated, and continuously supported build of SONiC, engineered for production use in environments where downtime or misconfiguration is unacceptable.

A hardened SONiC image from PalC includes:

• Extended regression and conformance testing across multi-vendor ASICs and hardware platforms.
• Security baselines patched CVEs, role-based access controls (RBAC), secure logging, and firmware validation.
• Operational guardrails validated upgrade/rollback workflows, version locking, and signed images.
• Lifecycle visibility telemetry and alert hooks tied to TAC processes for proactive support.

In short: we take SONiC’s open flexibility and wrap it in enterprise-grade reliability.

Regulated sectors — like BFSI, government networks, and telecom carriers — live under strict mandates for data integrity, availability, and traceability.
These mandates translate directly into network design expectations.

Let’s break that down.

Each PalC SONiC build goes through multi-phase qualification:

• Hardware Compatibility Validation
  Tested on Broadcom, Marvell, and Intel platforms, ensuring feature parity and driver consistency.
• Functional Regression
  500+ test cases covering Layer 2/3 protocols, EVPN-VXLAN, QoS, ACLs, and multi-chassis link aggregation.
• Negative Testing
  Simulating failed links, route flaps, process restarts, and misconfigurations — validating SONiC’s failover logic.
• Performance Benchmarking
  Line-rate throughput and latency benchmarks using IXIA or TRex frameworks, compared against OEM baselines.

This forms our Hardened SONiC Qualification Matrix — a continuous integration pipeline that ensures each release is ready for production, not just lab demos.

Security in SONiC begins with the image, but extends into runtime.
Our hardening templates implement:

• Role-Based Access Control (RBAC) for administrative isolation.
• AAA integration with corporate identity providers (LDAP, RADIUS, or SSO).
• Config Integrity Checkpoints — SHA-signed configuration backups and change validation.
• Secure Management Channels — enforced SSHv2, TLS 1.2+, SNMPv3, gNMI/gRPC over SSL.
• Disable default accounts and unused services as part of Day 0 provisioning.

These configurations align with CIS Benchmarks and NIST 800-53 guidelines, ensuring compliance readiness from the first boot.

Open-source agility is a double-edged sword — patches evolve quickly.
PalC’s sustain program integrates SONiC patch cycles with enterprise change windows:

• Patch Validation Pipelines: New commits undergo automated test runs in PalC’s CI/CD lab.
• Version Locking: Enterprises can freeze on validated releases while security patches continue to be backported.
• Rollback Automation: Instant rollback capability in case of regression, integrated with our orchestration tools.

This process ensures that openness doesn’t compromise predictability.

In regulated environments, you can’t just prove uptime — you must prove why it was maintained.
Using NetPro Suite, hardened SONiC deployments gain:

• Real-time gNMI telemetry streams from switches.
• Prometheus exporters for metrics collection.
• Grafana dashboards for visual compliance reporting.
• Integration with SIEM tools (e.g., Splunk, Elastic, or OpenSearch) for anomaly correlation.

Auditors can replay network states, review link utilization, and validate SLA adherence from a single pane.

Even the best-engineered network will face incidents.
The difference lies in response speed and insight.

PalC’s Technical Assistance Center (TAC) operates in three tiers:

• L1: Immediate triage, log analysis, and guided recovery.
• L2: Root-cause diagnosis, topology validation, escalation management.
• L3: Engineering-level debugging and patch integration directly with SONiC community branches.

Every support case feeds back into our Hardened SONiC Knowledge Base, ensuring learnings become new safeguards.

This is Sustainability through Feedback Loops — the more we support, the smarter the platform gets.

In one of India’s leading FinTech payment operators, PalC deployed a SONiC-based open fabric across three high-availability data centers.
The goals were clear: vendor independence, audit readiness, and zero unplanned downtime.

Challenges included:

• Legacy OEM lock-in and opaque management.
• Manual firmware rollbacks during audits.
• Limited visibility across multi-vendor devices.

Proof that openness can coexist with regulation — if engineered right.

Here’s a distilled checklist based on our field experience:

PalC isn’t just deploying open networking — we’re industrializing it.

Our contribution to the SONiC ecosystem spans RFC drafts, validation tooling, and active community participation.
But what differentiates us in regulated sectors is our ability to bridge open innovation with enterprise discipline.

We combine:

• SONiC engineering depth (protocol enhancements, FRR stack contributions).
• End-to-end deployment experience (design → validation → TAC).
• A proven sustain model that aligns open-source agility with compliance rigidity.

For enterprises navigating audits, risk frameworks, and strict SLAs —
PalC Networks delivers the confidence to run SONiC at scale.

Networks are knowledge systems. They generate massive amounts of unstructured intelligence like telemetry, syslogs, event traps, policy states and most of which remains underutilized.

RAG converts this operational exhaust into reasoning fuel. It enables AI models to:

• Retrieve live context: What’s happening across fabrics, clusters, and tenants.
• Ground reasoning: Align insights with real-time configurations.
• Generate precision: Produce factual, explainable outcomes.

In networking terms, RAG is the bridge between observability and cognition — it converts visibility into understanding.

RAG’s value lies not only in the workflow, but also in the reasoning feedback that emerges from it.

1. Collect & Curate: SONiC telemetry, NetPro metrics, logs, configs.
2. Index Knowledge: Create a searchable intelligence layer of historical and live data.
3. Retrieve Context: Query relevant slices (“What caused leaf-03 reboot last night?”).
4. Generate Reasoning: AI synthesizes causal narratives or configuration recommendations.
5. Learn & Adapt: Verified responses become part of the retriever’s future context.

This loop makes networks progressively smarter, not just faster.

• Root Cause Reasoning: Move beyond correlation — infer causation with evidence.
• Policy Intelligence: Detect and explain compliance drifts across vendors.
• Cognitive Assistants: Natural-language diagnostics for L1 engineers.
• Contextual Configs: Generate validated SONiC/BGP/EVPN templates grounded in current state.
• Adaptive Learning: Retain lessons from every RCA, ticket, or anomaly.

In effect, RAG creates a knowledge memory for the network which acts as a living library that improves operational trust and speed.

At PalC Networks, our journey through SONiC-based fabrics, AI observability, and cloud-native orchestration has naturally converged toward RAG-driven network cognition.

Our focus areas include:

• Integrating NetPro Suite as a real-time retrieval layer, grounding AI in verified telemetry.
• Domain-tuned AI models that understand network semantics — from L2 loops to RoCEv2 optimizations.
• Cross-vendor contextual reasoning to unify visibility across SONiC, Cisco, Juniper, and Arista environments.

As contributors to the SONiC ecosystem and the Linux Foundation, we’re advancing an open, cognitive networking paradigm — where intelligence is shared, transparent, and self-improving.

Enterprises adopting RAG-based network intelligence typically realize:

• 60% faster RCA through retrieval-grounded context.
• Reduced operational overhead via explainable AI triage.
• Improved onboarding as natural language replaces CLI silos.
• Lower TCO by extending reasoning across multi-vendor networks.

The next generation of networks not only just detect or report; they’ll reason, decide, and adapt.
AI agents will retrieve evidence, simulate outcomes, and execute remediations with policy assurance.

RAG is the cognitive fabric that enables the turning static data into continuous intelligence.
It’s how networks evolve from visibility to comprehension, and from automation to autonomy.

PalC Networks’ support extends across every aspect of data center and cloud operations:

The BFSI sector needs a different approach-one that balances security, scalability, and cost-effectiveness while enabling innovation. Open Networking is that approach.

• Open Networking-Based Network Fabric 
  BFSI networks require ultra-fast, congestion-free transaction handling. SONiC based Open Networking with EVPN-VXLAN overlays enables Layer 2/3 segmentation, while automated network provisioning dynamically scales resources to match real-time demand. Optimized routing ensures minimal latency, keeping digital payments and banking operations instant and reliable.
• Cost-Efficient, Vendor-Neutral Networking
  BFSI firms can eliminate vendor lock-in with SONiC-based disaggregated networking, replacing expensive, proprietary solutions with scalable, open-source alternatives. This reduces operational costs, enhances flexibility, and ensures institutions can scale infrastructure without restrictive licensing agreements or hardware dependencies.
• DPU-Accelerated Security with Zero Trust
  Traditional security models struggle to handle real-time fraud detection and cyber threats. DPUs enable inline encryption, deep packet inspection (DPI), and AI-driven anomaly detection without straining CPU resources. Zero Trust Security (ZTS) enforces continuous verification, micro-segmentation, and real-time compliance enforcement using open-source security frameworks.
• Hybrid & Multi-Cloud Adaptability
  Financial institutions must balance on-prem compliance with cloud scalability. OpenStack-powered private clouds enable secure, regulated workload management, while Kubernetes orchestration dynamically scales applications across hybrid environments. This ensures seamless interconnectivity between private, public, and edge computing.

Adopting an open Network Operating System (NOS) like SONiC promotes disaggregation, a concept that liberates hardware from software constraints, allowing for a flexible, plug-and-play approach. This modular structure enables a unified software interface across different hardware architectures, enhancing supply chain flexibility and avoiding vendor lock-in. Custom in-house automation frameworks can be preserved without needing per-vendor adjustments. The DevOps-oriented model of SONiC accelerates feature deployment and rapid bug fixes, reducing dependence on vendor-specific release schedules. Moreover, the open-source ecosystem fosters innovation and broad collaboration, supporting custom use cases across various deployments. This freedom translates into significant cost efficiencies, reducing Total Cost of Ownership (TCO), Operational Expenditure (OpEx), and Capital Expenditure (CapEx), making it a compelling choice for modern networks.

Among the numerous open-source NOS solutions available, SONiC distinguishes itself through its growing adoption across enterprises, hyperscale data centers, and service providers. This success highlights its versatility and robustness. Open-source contributions have meticulously refined SONiC, tailoring it for specific use cases and enhancing its features while allowing adaptable architectures.

Key Attributes of SONiC:

Open Source:

• Vendor-neutral: Operates on any compatible vendor hardware.
• Accelerated feature deployment: Custom modifications and quick bug resolutions.
• Community-driven: Contributions benefit the broader SONiC ecosystem.
• Cost-effective: Reduces TCO, OpEx, and CapEx significantly.

Despite SONiC’s evident advantages, network operators often has these critical questions- Is SONiC suitable for my network?, What does support entail?, How do I ensure code quality?, and How do I train my team?. The true test of a NOS is its user experience. For open-source solutions like SONiC, success depends on delivering a seamless experience while ensuring robust vendor-backed support.

Operators considering SONiC typically fall into two categories: those with a self-sustaining ecosystem capable of handling an open NOS and those exploring its potential. For the former, SONiC may be customized to meet specific network demands, potentially involving a private distribution or vendor-backed commercial versions. The latter group, often seeking simpler use cases, typically relies on community SONiC, balancing its open-source nature with vendor validation.

The shift towards open networking, driven by disaggregation, has brought SONiC into the spotlight. Its flexibility, cost-effectiveness, and capacity for innovation make it an attractive option, especially for hyperscalers, enterprises, and service providers. By embracing open architecture and standard merchant silicon, SONiC provides a cost-efficient alternative to traditional closed systems, delivering equivalent features and support at a fraction of the price.

While companies like Microsoft, LinkedIn, and eBay have successfully integrated SONiC, they often encounter challenges such as vendor fragmentation, compatibility issues, and inconsistent support across hardware platforms. Managing diverse hardware can become complex due to each vendor’s unique configurations, while updates can disrupt operations by introducing compatibility problems. Integrating different SONiC versions across vendors may also lead to inconsistencies and unreliable telemetry data, adding further complications. Additionally, varying support levels make troubleshooting difficult, and operators often require additional training to navigate the nuances of each vendor’s implementation. Although these challenges can feel overwhelming, with careful planning, skilled personnel, and the right support, they can be effectively managed for a smooth and successful SONiC deployment.

PalC’s SONiC NetPro Suite directly addresses these challenges by offering comprehensive solutions designed to streamline SONiC adoption. Through the Ready, Deploy, and Sustain packages, PalC ensures end-to-end support, providing expert guidance to fill gaps in in-house expertise and fostering a DevOps-friendly culture for smooth operations. PalC’s strong partnerships with switch and ASIC vendors guarantee seamless integration and full infrastructure support, while its rigorous QA processes ensure performance and reliability. By offering customized support and clear cost assessments, PalC simplifies SONiC deployment, minimizing disruptions and ensuring a scalable, secure, and optimized network infrastructure.

Choosing the right SONiC version is crucial for network optimization. By assessing feature needs, community support, hardware compatibility, and security, organizations can make informed decisions that enhance network performance. SONiC’s evolution from a Microsoft project to a leading open-source NOS underscores its transformative potential and solidifies its role in future cloud networking.

The Power of PalC NetPulse
Efficiency and Control:

• L1 Cross Connect for EdgeCore Cassini Boxes: We’ve integrated L1 cross-connect capabilities for EdgeCore Cassini boxes, enhancing your control over network resources.
• Interface Configuration Management: Our NMS software offers streamlined configuration management for both Ethernet and Optical interfaces, simplifying network setup and maintenance.
• Inventory and User Management: PalC NetPulse provides robust inventory management, allowing you to keep track of network assets

Comprehensive Monitoring:
Peripheral Device Monitoring: Stay on top of your network’s health by monitoring peripheral devices. PalC NetPulse offers a holistic view of your infrastructure.

• Optical Parameter Monitoring: Get in-depth insights into optical parameters to ensure
  optimal performance.
• Topology Viewer and Alarms/Event Notification: Visualize your network’s topology
  and receive real-time alarms and notifications. Stay informed and respond swiftly.
• Microservices Compatible Architecture: Our NMS is built on a microservices-
  compatible architecture, ensuring flexibility and scalability for your evolving network
  needs.

What Lies Ahead in Our Roadmap:
We are committed to enhancing our NMS software further to meet the ever-changing demands of network management:
Layer-2 Configuration Features: We are adding more layer-2 configuration features to provide you with a more comprehensive toolkit.

• Advanced Automation: Our NetPulse will have enhanced network automation capabilities, simplifying complex tasks.
• Integration with Cloud-Based Environments: In line with the industry’s shift towards cloud-based solutions, we are working on seamless integration with cloud environments.

Supported Software for Versatility
PalC NetPulse is compatible with various software platforms, making it versatile and adaptable to different deployment scenarios:

SONiC for Data-Center Deployments: Perfect for data-center networks, PalC NetPulse integrates seamlessly with SONiC.

• Goldstone for Packet Optical Deployments: If your network requires packet optical solutions, PalC NetPulse has you covered with Goldstone compatibility.
• OcNOS for Data Center/CSR Requirements: Data center and carrier-grade service provider networks benefit from our support for OcNOS.

Figure 1 – perfSONAR architecture

In the architecture diagram (Figure 1) mentioned above, the key components have been outlined below:

• perfsonar tools – This module contains different utilities responsible for carrying out the actual network measurements. Twamp tool consists of twping binary which is used on client side and twampd binary which runs on the server/responder side. Similarly, we have owamp, powstream, traceroute, tracepath, paris-traceroute and other diagnostic methods. We can use these tools for measurement of following performance metrics.
• Latency – measuring one-way and two-way delays
• Packet loss, duplicate packets, jitter
• Tracing network path
• Trace path – Identifying the path MTU
• Throughput – Measuring the bandwidth availability

An overview of supported tools –

• owamp – A set of tools primarily used for measuring packet loss and one-way delay. It includes the command owping for single short-lived tests and the powstream command for long-running background tests.
• twamp – A tool primarily used for measuring packet loss and two-way delay. It has an increased accuracy over tools like ping without the same clock synchronization requirements as OWAMP. The client tool is named twping and can be used to run against TWAMP servers. You can use the provided twampd server or many routers also come with vendor implementation of TWAMP servers that can be tested against.
• iperf3 – A rewrite of the classic iperf tool used to measure network throughput and associated metrics.
• iperf2 – Also known as just iperf, a common tool used to measure network throughput that has been around for many years.
• nuttcp – Another throughput tool with some useful options not found in other tools.
• traceroute – The classic packet trace tool used in identifying network paths
• tracepath – Another path trace tool that also measures path MTU
• paris-traceroute – A packet trace tool that attempts to identify paths in the presence of load balancers
• ping – The classic utility for determining reachability, round-trip time (RTT), and basic packet loss.
• pScheduler – The pScheduler is responsible for scheduling the tests based on user configuration and available time slots on the machine. It finds time-slots to run the tools while avoiding scheduling conflicts that would negatively impact results, Executing the tools and gathering results, and send the results to the configured archiver
• Archiving – This module contains the esmond component which stores the measurement information for the tests run. It is often referred to as the measurement archive (MA) and the term is used interchangeably with esmond. Esmond can be installed in each end device, or in the central server device which collects all test results.
• Psconfig pscheduler agent – This module will get the user configurations from a file in json format and then use it to communicate with the pScheduler to schedule the tests.
• Psconfig maddash agent – The agent responsible for reading the same configuration json file and creating graphs and charts based on the conducted test results.

The user has different installation options for different end devices such as centralized servers, clients, and servers. Here centralized server refers to devices that register clients and servers, manage to conduct tests, collect results and act as a central server where other devices communicate anything related to test parameters. Clients are devices that conduct the throughput, latency, and RTT tests with another end device. Servers are end devices that act as the receiver or reflector for measuring network health. The tests are conducted from the client to the server, either from the client interactive shell based on demand or from the central server using a configuration json/psconfig web admin GUI.

PerfSONAR can be installed in CentOS or Ubuntu based Linux environments. The various offerings are,

• Perfsonar-tools – This package installs only the command line binaries needed to run on-demand tests such as iperf, iperf3 and owamp. Often used for debugging network disruptions rather than for dedicated monitoring of network.
• Perfsonar-testpoint – This package contains command-line binaries to run on-demand tests, in addition to tools to scheduling of tests conduct tests based on central server instructions in json files, and participate in node discovery conducted in central servers. But this package lacks software to store measurement data in a local archive.
• Perfsonar-core – This package is dedicated for devices that run tests themselves, instruct others to run the tests and store measurement data themselves.
•  Perfsonar-toolkit – This package includes everything present in perfsonar-core including the web-admin to conduct tests via GUI.
•  Personar-centralmanagement – This package is installed in central management servers that instruct others to run tests and manage a number of hosts, while also being able to retrieve and archive the test results from a number of hosts.

Figure 2 below explains the bundle options,

We can run network measurement tests in two different modes.

• Full mesh mode – where all the perfsonar hosts in the network are involved in running the tests to each other, essentially all the hosts should be running perfSONAR
• Disjoint mode – where the tests are run from one set of perfsonar hosts to another set of hosts (these hosts can be other 3rd party devices as well)

Once the scheduled tests are completed, results ae published to the central management server archiver, which is picked up by the maddash agent and visualizations are generated. Any present issues can be detected by observing the graphs and charts data, drawn up by the maddash agent.

TWAMP and TWAMP-light

Twping hosted by TWAMP (Two-Way Active Measurement Protocol) is a tool used to generate IP performance metrics between a client and server device by using two-way or round-trip tests. TWAMP is a development from the OWAMP (One-Way Active Measurement Protocol) method. TWAMP uses four entities in the topology, control-client and session-sender packaged into the client device and session-reflector and the server are packaged into the server device.

Initially, a TCP socket connection is established between the client and server in the TWAMP dedicated TCP port 862, after which the server sends a greeting message, that contains the security authentication modes supported by the server. Upon receiving the greeting message, the client sends the test conditions and the client information on which IP of the server device the test packets will be sent to. If the server agrees to conduct the described tests, the test begins as soon as the client sends a Start-Sessions or Start-N-Session message. This process is referred to as a twamp-control process

As part of a test, the server sends a stream of UDP-based test packets to the server, and the server responds to each received packet with a response UDP-based test packet. When the client receives the response packets from the session-reflector, the information is used to calculate two-way delay, packet loss, and packet delay variation between the two devices.

The user is provided with an option to bypass the TWAMP control process and conduct a TWAMP-light test. In a TWAMP-light test, the entities present are only the session sender and the session reflector. The initial TCP connection between the server and client is bypassed and only the stream of UDP-based test packets is sent and received by the client. But to run a TWAMP-light test, the server IP and the UDP port which will reflect the TWAMP packets, needs to be added as a part of the reflector configuration in the server. The client that runs a TWAMP-light test, will need to send the UDP packets to this configured IP and UDP port, failing which will result in the sent packets being dropped and loss of test metrics.

Figure 3 and 4 show the TWAMP and TWAMP-light protocol components

Figure 3 – TWAMP

Figure 4 – TWAMP-light