IM Engineer Study Notes
← Back to list
Networking
#인텐트 기반 네트워킹#IBN#SDN#폐루프 자동화#네트워크 관리#3GPP TS 28.312#TM Forum
Last updated · 2026-09-29

Intent-Based Networking (IBN) and Intent-Driven Network Operations

1. Overview

A. Definition

Intent-Based Networking (IBN) is a closed-loop approach to network operations in which an operator declaratively expresses desired goals, requirements, and constraints, and a system translates and applies them as executable policies and configurations, then continuously verifies achievement using observed data.

The central shift in IBN is from manually writing device-specific commands to expressing the business outcomes the network must achieve. Instead of specifying “configure this path with four hops,” an operator can state, “keep payment traffic on the corporate network below 20 ms latency and 99.99% availability, and prevent direct access from the public internet.” The system compares the goal with the actual topology, resources, policies, and device capabilities, creates an execution plan, and checks whether the result remains compliant after the change.

IBN is therefore more than a natural-language command interface or a configuration script. Natural language can be an input aid, but before execution, ambiguity must be removed and the request normalized into a verifiable model. Automation must also extend beyond writing configuration to the assurance stage, where telemetry is used to compare observed results with the intended outcome.

3GPP defines intent as a set of expectations, including requirements, goals, and constraints, given to a system without specifying how to achieve them. The key is separating what must be achieved from how it will be implemented. Although IBN became prominent in telecommunications, the same approach can be applied to policies and service-level management in data centers, enterprise campuses, and cloud networks.

B. Background and Need

Enterprise networks have become more complex as on-premises data centers, public clouds, branches, mobile users, 5G, and IoT are combined across multiple domains. Devices use different command-line interfaces and configuration models, and changes are interdependent, making it difficult even for experienced operators to understand the full impact. As the number of devices grows, repetitive configuration, change verification, and troubleshooting consume more time, while manual work accumulates configuration drift and human error.

Traditional automation is useful for quickly executing a predetermined sequence of commands, but the achievement of the business objective still needs to be assessed separately. IBN interprets a goal as policies, observes whether real results match it, and may recommend corrective plans or take limited automated action when deviations occur. Human review and approval, change history, and rollback must remain as controls regardless of the degree of autonomy.

IBN uses the separation of control and data planes and programmability provided by software-defined networking (SDN), but IBN and SDN are not synonyms. SDN is an enabling architecture that makes network control programmable, whereas IBN is an operational model for expressing, realizing, and assuring business requirements on that foundation. In other words, SDN emphasizes the ability to control, while IBN emphasizes a management approach that continuously achieves desired outcomes.

C. Key Characteristics

  • Outcome orientation: Describe results such as service quality, reachability, and security rather than device-level procedures.
  • Abstraction and translation: Convert business language into network objects, policies, and configurations while hiding implementation details.
  • Verifiability: An intent needs measurable indicators, scope, conditions, and constraints.
  • Closed-loop operations: Repeatedly observe and assess the network to reduce the gap between desired and actual states.
  • Policy consistency: Apply policies consistently across devices and domains and detect conflicts.

These characteristics depend on one another. An unmeasurable goal cannot be assured, and a goal without a precise scope and constraints can be misinterpreted during translation. Conversely, granting broad execution rights without safeguards can make automation spread an outage or security incident as quickly as it spreads a change.

2. IBN Reference Architecture and Closed Loop

IBN can be described as a layered structure that connects requirements from people and business systems to network policies and device behavior, then compares results with the original requirements. Its logical functions are commonly organized around translation, activation, and assurance, although an implementation may distribute them across one controller or several management systems. The diagram shows how an intent becomes policies and configurations, and how observed results return to assurance.

flowchart LR
  U["Business user / operator"] --> I["Intent model<br/>requirements, goals, constraints"]
  I --> T["Translation, conflict and feasibility checks"]
  T --> P["Policies and change plan"]
  P --> O["Orchestrator / controller"]
  O --> A["Domain adapters<br/>API, NETCONF, CLI"]
  A --> N["Routers, switches, firewalls, cloud networks"]
  N --> M["Telemetry, logs, performance metrics"]
  M --> Q["Assurance and deviation analysis"]
  Q --> I

The intent consumer may be a service owner, network operator, application, or higher-level management system. Instead of specifying detailed network configuration, the consumer supplies the target service, quality goals, scope, validity period, and security constraints. Business requirements should be agreed with the network team and converted into measurable definitions rather than directly put into production as unreviewed user statements.

The intent model and translation function normalize a request into a structure that machines can interpret. The translation function identifies target objects and metrics, detects missing values or conflicting conditions, and assesses feasibility based on supported capabilities and available resources. If requirements are impossible or conflict, the system should report the conflict and possible alternatives or negotiable target values rather than silently ignoring part of the request.

Policy and plan generation and orchestration decompose the changes needed to reach the desired state into domain-specific execution steps. For example, the goal “only the payment system at branches may access internal applications” can be decomposed into address groups, firewall rules, routing, and authentication policies. The planning phase must consider dependencies, scope of impact, resource shortages, change order, pre- and post-checks, and compensating actions.

Domain adapters and network resources deliver abstract policies through device-specific or cloud-provider-specific interfaces. Adapters abstract heterogeneous methods such as REST APIs, model-driven management interfaces, and device APIs, but they do not eliminate all capability differences. A capability catalog, adapter versions, supported scope, and error-handling lifecycle must be managed to preserve consistency in a multivendor environment.

The assurance function collects service-level metrics such as actual packet loss, latency, availability, reachability, and security events, not only the configuration state in a management system. It compares observed data with objectives and reports goal status together with policy application, data freshness, and confidence. When deviations are found, it performs the predefined response—recalculation, alerting, approval request, or automatic correction—and verifies the result again.

An important principle is distinguishing the configured desired state from the observed actual state. Even if a policy is registered in the controller, service results may differ if a device did not accept it or traffic took an unexpected route. Assurance should therefore combine configuration checks with service-outcome verification, and attach evidence, timestamps, and confidence levels to each finding.

3. Intent Model and Lifecycle

A. Intent Elements

An intent is not just a natural-language sentence; it is a structured set of expectations with a scope and an evaluation method. It commonly distinguishes target objects, expectations, targets, values or conditions, context, and constraints. For example, “keep round-trip latency for the Seoul headquarters payment service below 20 ms during business hours and prevent direct access from the public internet” includes a target, time scope, performance goal, and security constraint.

The target object identifies the network, service, device, area, or slice to which an intent applies. If the target is unclear, a policy may be applied too broadly or only to some devices, leaving the service path incomplete. Target selection can use fixed identifiers or context such as tags, location, and role; the effect of changing those conditions must be assessed.

Goals and expectations state desired outcomes and the indicators used to judge them. Terms such as “fast” or “secure” cannot be assessed on their own, so they need to be specified using latency limits, availability, tolerated loss, allowed-access lists, or other measurable rules. Over-optimizing a single indicator can harm other objectives such as cost, resilience, or security, so relative priority and acceptable ranges must also be defined.

Context and constraints describe the conditions under which goals apply. Specifying time of day, traffic type, location, capacity limits, regulatory zones, maintenance windows, or budget allows different policies to be selected for the same service in different situations. Constraints define boundaries that must not be crossed while reaching the goal, such as “do not increase costs without limit to improve availability.”

An intent report communicates acceptance, feasibility, fulfillment status, conflicts, failure causes, and achieved metrics to the consumer. The state model must distinguish acknowledgement of a request from actual goal achievement (fulfilled). Because reports support coordination and audit, they should preserve the goal version, scope, observation time, and decision rationale.

B. Management Lifecycle

The operational lifecycle is a repeated process from receiving a goal through validation, execution, assurance, change, and retirement. 3GPP management services address intent creation, modification, deletion, and query; activation and deactivation; report queries and subscriptions; capability queries; and feasibility checks and negotiation procedures. These functions enable operators to update policies in a controlled manner when service requirements change or seasonal and event-driven demand shifts.

flowchart TD
  A["1. Gather business requirements"] --> B["2. Normalize expression and define scope"]
  B --> C["3. Discover capabilities and check feasibility"]
  C -->|Feasible / agreed| D["4. Generate policy and change plan"]
  C -->|Infeasible / conflict| X["Propose options, negotiate, approve"]
  X --> B
  D --> E["5. Review risk and impact; approve"]
  E --> F["6. Activate progressively"]
  F --> G["7. Assure with telemetry"]
  G -->|Goal met| H["Report and continue observation"]
  G -->|Deviation / incident| R["Adjust, roll back, or involve operator"]
  R --> D
  H -->|Requirement changes / expires| A

First, requirement gathering and normalization align stakeholder terminology and identify the intent target, metrics, time conditions, priorities, and owners. Even if some input analysis is automated, an ambiguous term such as “as fast as possible” should not be converted into an arbitrary SLA; it should require clarification or approval.

Second, capability discovery and feasibility checking determine whether the responsible domain supports the required metrics and policies and whether devices and resources can meet the goal. Feasibility is more than a syntax check; it should consider the current state, other intents, shared resources, and safety or regulatory constraints. If a goal is unrealistic, negotiation should provide reasons for infeasibility and adjustable values or alternatives.

Third, planning and approval calculate the change order, impact analysis, risks, and recovery strategy in case of failure. For a path with significant business impact, even an automatically generated plan should pass operator approval, maintenance-window, and change-management controls before execution. Progressive rollout and a small blast radius reduce the risk that an error spreads across the entire network.

Fourth, activation and continuous assurance evaluate both configuration results and real service performance. If metrics are abnormal, an automated action may be taken, but action rights, change rate, retry counts, and stop conditions must be limited in advance. After changing a policy, verify goal achievement again; if evidence is uncertain or observations are insufficient, prefer an alert and human judgment to automated action.

4. Operational Comparison and Design Case

In traditional device-by-device operations, an operator chooses the implementation procedure and enters commands on each device. This approach gives explicit control and is understandable in a small environment, but policy inconsistency and repetitive work increase at scale. Scripts and configuration-management tools automate execution, but outcome verification and goal-driven adjustments beyond the predefined procedure need separate design.

Dimension Device commands / scripts SDN-based automation Intent-based operations
Input perspective Device actions and commands Network resources and policies Business goals, requirements, constraints
Implementation responsibility Operator writes procedures Controller abstracts and deploys Translation, planning, and validation are connected
Verification level Command success Policy or configuration applied Continuous achievement of desired outcomes
Feedback Post-check or manual Controller state and events Telemetry-driven closed-loop assurance
Risk Configuration drift and human error Controller or domain dependency Goal misinterpretation and excessive automation

IBN is an outcome-oriented operating approach built on SDN and existing management systems, not an independent protocol that replaces SDN. It may overlap with policy-based management and configuration automation, so adoption should not be judged by a product label alone. In practice, the distinguishing questions are whether goals use machine-interpretable structures, whether achievement is measured after execution, and whether deviations follow a controlled feedback path.

Case: Quality and Security Intent for a Multi-Branch Payment Service

Assume a financial company operates a payment service distributed across branches and cloud infrastructure. The business owner states, “During business hours, round-trip latency for payment application traffic must remain below 20 ms, monthly availability must be 99.99%, and databases must not be directly reachable from the public internet.” The network team structures this into service groups, time ranges, measurement points, and metrics, and defines how latency and availability are calculated, permitted exceptions, and database access paths.

The translation function reviews WAN paths, cloud security groups, firewall policies, service tags, and current bandwidth to create a plan. If the current link is congested and cannot meet the goal, it reports options such as using another path, expanding bandwidth, or changing the target, and obtains approval from the service owner. The approved change is validated at one branch before expansion to the rest, with payment latency and connection success rates checked at each stage.

If telemetry later finds both latency violations and a possible firewall-rule bypass, performance tuning and security blocking should not be forced into a single change without analysis. First classify causes and policy conflicts, evaluate service continuity impact, and then apply a restricted alternate path or an approved rollback. This case shows that measurement, conflict resolution, approval, and evidence retention—not just declaring a goal in one sentence—determine IBN reliability.

Comparison: Network Slicing and IBN

Network slicing provides logical networks with different service characteristics over shared physical infrastructure. IBN is a management approach that expresses requirements and configures, observes, and adjusts a network to achieve desired outcomes. IBN can send requirements to a slice manager, which can realize them as specific resources; the concepts can therefore be combined at different layers rather than treated as competitors.

5. Advanced Topic: Standardization, Autonomy, and Limitations

The term IBN is widely used in industry, but it should not be assumed that one universal specification with identical information models and behavior has been completed across all vendors. Device capabilities, intent expressions, reports, conflict handling, and automatic correction vary by product and domain. Organizations should therefore examine data models, APIs, interoperability, audit functions, automation rights, and actual outcome measures rather than rely on product marketing terms.

In telecommunications, 3GPP TS 28.312 specifies intent-driven management services for mobile networks, including intent lifecycle, reporting, capability queries, and negotiation procedures. The 3GPP model structures management interfaces across network domains by distinguishing service consumers and producers, intent expectations, intent-handling functions, and reports. As checked in September 2026, the official 3GPP technology page lists V19.1.0 as the latest version of TS 28.312; implementation and procurement should recheck the applicable release and revision on the official page. Separately, TM Forum develops intent concepts, common models, lifecycles, and management API work for autonomous networks; the scope and version of each specification should be distinguished.

It is advisable to expand operational autonomy in stages. Initially, focus on collecting and validating intent, impact analysis, and generating a change plan, using an operator-reviewed and approved approach to reduce risk. Once data and policy quality have been validated, allow constrained automated execution for low-risk tasks, while retaining approval, rollback, and stop conditions for high-impact changes.

The stability of closed-loop control is affected by network-control latency and observation intervals. Corrections that are too frequent can create oscillation by triggering repeated changes before the system is adequately observed, while corrections that are too slow can leave SLA violations unresolved. Use hysteresis, stabilization time, rate limits, retry limits, and action-specific cooldowns, and test under realistic load and failure conditions.

6. Considerations and Implications

  • Measurable goals and ambiguity removal: Decompose business statements into metrics, ranges, time, targets, and exceptions. If departments use different measurement definitions, a green dashboard may still fail to meet actual service requirements.
  • Conflict and shared-resource management: Specify intent priorities, resource competition, policy conflicts, and delegation scope. Do not silently ignore impossible goals; report evidence and negotiation options.
  • Change safety and human control: Implement impact analysis, approval gates, progressive rollout, rollback, stop switches, and audit logs. Set autonomy levels according to business impact and recoverability.
  • Assurance data quality: Manage telemetry completeness, accuracy, time synchronization, and collection delays. Do not treat missing data as proof of goal achievement; show an unobservable state separately.
  • Multivendor interoperability: Validate capability catalogs, common object models, interface versions, and exception handling. Design abstraction to expose hidden constraints rather than conceal vendor differences.
  • Security, authorization, and accountability: Authenticate intent consumers and execution identities, and apply role-based and least-privilege access, policy signing, secret protection, and immutable audit records. A compromised input path can turn legitimate automation into an attack mechanism.
  • Metrics and investment value: Measure change failure rate, MTTR, SLA achievement, configuration drift, recurrence after auto-remediation, and operator intervention time—not deployment speed alone. Do not mistake technology adoption for autonomy outcomes.
  • Incremental adoption and operational capability: Mature observability, policy management, and configuration automation first, then validate one domain and a low-risk case. Network, security, and application teams must jointly define goals and ownership.

From an information technology professional perspective, IBN is an outcome-oriented operating paradigm connecting SDN, network automation, AIOps, closed-loop control, and autonomous networks. Success depends less on adopting artificial intelligence than on formalizing business goals, ensuring trustworthy observations, managing changes safely, and assigning accountability. An adoption roadmap should therefore set out measurable service improvements and controllable automation scope in stages rather than pursue “full autonomy” as a single objective.

References

In one line: IBN declares network goals and constraints, realizes them as policies and configurations, and continuously validates them against service metrics; measurable intent, safe automation, and trustworthy observations determine success.