Services¶

Connect provides six service types, each managed through Inmanta’s Lifecycle Service Manager (LSM). This page describes each service, its API attributes, and how it works.

Network Element¶

The Network Element service manages a device through the LSM API. It deploys base device configuration and caches high-level device information (name, management IP, vendor, model, OS, role, …) for other services to consume. On creation, attributes are populated from the configured inventory resolver based on the identifier. Operator overrides are supported: attributes carry rw+ modifiers, so the resolved values can be edited through the LSM API after creation.

This service is useful to:

Make device data queryable through the same API surface as connectivity services.
Carry a per-device role (PE, P, Border, CPE, RR) that other services can consume in their decomposition.
Apply and update base device configuration.

Attributes¶

Attribute	Modifier	Type	Description
`identifier`	`rw`	string	Reference to the device in the inventory. May include an inventory scheme prefix (e.g. `netbox:router-east`).
`role`	`rw+`	`PE` / `P` / `Border` / `CPE` / `RR`	Role this device plays in the network. Resolved from the inventory.
`name`	`rw+`	string	Device name. Matches the `device_name` used by the UNI and L2 Connect services. Resolved.
`router_ip`	`rw+`	IPv4 address	The device loopback / router IP address. Resolved.
`href`	`rw+`	string	Link to an external resource representing the device. Resolved.
`options`	`rw+`	dict	Free-form vendor or deployment-specific options.
`device`	`rw+`	object (embedded)	Managed device backing this network element. Resolved (see below).

Device attributes (embedded, all resolved from the inventory):

Attribute	Modifier	Type	Description
`mgmt_ip`	`rw+`	IPv4 address	Management IP at which the orchestrator can reach the device.
`mgmt_port`	`rw+`	port	Management port at which the orchestrator can reach the device.
`vendor`	`rw+`	string	Vendor of the device (e.g. `nokia`, `cisco`, `juniper`).
`model`	`rw+`	string	Model of the device.
`os`	`rw+`	string	Operating system of the device.
`version`	`rw+`	string	Software version running on the device.
`options`	`rw+`	dict	Free-form vendor or deployment-specific options.

Example¶

{
  "identifier": "router-east"
}

All other attributes are populated by the orchestrator from the inventory resolver selected by the identifier scheme prefix (or the default inventory if no prefix is given). Resolved attributes can subsequently be overridden by the operator through the LSM API.

User Network Interface (UNI)¶

A UNI represents a customer’s attachment point to the provider network. It maps to one or more physical ports on provider-edge routers. UNIs are prerequisites for all other connectivity services – you must create UNIs before creating connections between them.

Attributes¶

Attribute	Modifier	Type	Description
`name`	`rw`	string	Unique name identifying the UNI
`mtu`	`rw+`	positive int	Maximum transmission unit
`encapsulation`	`rw`	`dot1q` / `qinq`	VLAN encapsulation type
`ports`	`rw+`	list	Port references (see below)
`lag`	`rw`	object	LAG configuration (optional, see below)

Port attributes:

Attribute	Modifier	Type	Description
`port_name`	`rw`	string	Physical port name (e.g., `1/1/c2/1`)
`device_name`	`rw`	string	Device hosting the port
`port_speed`	`rw+`	string	Port speed (optional)
`auto_negotiation`	`rw+`	bool	Enable auto-negotiation (optional)

During updates, ports can only be added or removed when a lag is configured on the UNI. When a LAG is present, added/removed ports must remain on the same device(s) as the existing ports.

LAG attributes:

Attribute	Modifier	Type	Description
`name`	`rw+`	string	LAG interface name. Auto-generated as `lag-{id}` if not provided.
`id`	`rw+`	int	LAG ID used to resolve LACP parameters. Auto-allocated from configured range if not provided.
`manage`	`rw+`	bool	Whether to manage the LAG parameters. If `false`, the LAG is only referenced in services. Default: `true`.
`options`	`rw+`	dict	Additional vendor-specific options (e.g., `es_id` for EVPN Ethernet Segment).

Single-Homed vs LAG¶

Single-homed: One port, no lag attribute needed.
LAG (Link Aggregation): Set the lag attribute to configure a LAG across the UNI ports. Use manage: true (default) to let the orchestrator allocate the LAG ID and manage the LAG. On Nokia SR OS a managed LAG is configured on the device (admin-state, encap-type, mode, LACP keyed on the LAG ID, and the UNI ports as members). Use manage: false to reference an existing unmanaged LAG.

Example: Single-Homed UNI¶

{
  "name": "customer-east",
  "mtu": 9212,
  "encapsulation": "qinq",
  "ports": [
    {
      "port_name": "1/1/c2/1",
      "device_name": "router-east"
    }
  ]
}

Example: Multi-Homed UNI with LAG¶

{
  "name": "customer-west",
  "mtu": 9212,
  "encapsulation": "dot1q",
  "ports": [
    {
      "port_name": "1/1/c2/1",
      "device_name": "router-west-1"
    },
    {
      "port_name": "1/1/c2/1",
      "device_name": "router-west-2"
    }
  ],
  "lag": {
    "manage": true
  }
}

L2 Connect¶

L2 Connect provides Layer 2 point-to-point and multipoint connectivity between UNIs. It is the most sophisticated service in Connect, using segment decomposition to support connections across heterogeneous network domains.

Attributes¶

Attribute	Modifier	Type	Description
`identifier`	`rw`	string	Unique service identifier
`bandwidth`	`rw+`	int	Bandwidth in kbps (0 = unlimited)
`service_id`	`r`	positive int	Auto-allocated service ID
`connection_type`	`rw`	string	`POINT_TO_POINT` or `MULTIPOINT`
`endpoints`	`rw`	list (2+)	Endpoint definitions (see below)
`parameters`	`rw+`	object	Backend parameters (see below)
`details`	`r`	object	Auto-populated segments and nodes (read-only)

Endpoint attributes:

Attribute	Modifier	Type	Description
`identifier`	`rw`	string	Endpoint identifier (unique within the service)
`uni`	`rw`	ref	Reference to an existing UNI service instance
`vlan`	`rw`	string	VLAN tag expression (e.g., `100`, `100.*`, `100.200`)

Parameters attributes:

Attribute	Modifier	Type	Description
`mpls_backend`	`rw+`	`LDP` / `EVPN`	MPLS backend technology
`mpls_p2p_service`	`rw+`	`vpls` / `vpws`	Service type for point-to-point connections
`mac_address_blocklist`	`rw+`	list of MAC	MAC addresses to block on the service

VLAN Tag Expressions¶

The vlan field on endpoints supports several formats:

Expression	Encapsulation	Meaning
`100`	dot1q	Outer VLAN 100
`100.*`	qinq	Outer VLAN 100, any inner VLAN
`100.200`	qinq	Outer VLAN 100, inner VLAN 200
`untagged`	untagged	No VLAN tagging
`auto`	(any)	Auto-allocate a VLAN from the available pool

Segment Details (Read-Only)¶

After allocation, the details field is populated with the decomposed service structure:

segments: List of network segments, each with a type, identifier, and set of network elements with their interfaces.
nodes: List of junction points between segments, each with VLAN allocation and encapsulation.
network_elements: Information about each device participating in the service.

Example¶

{
  "identifier": "east-west-evpn",
  "bandwidth": 1000000,
  "connection_type": "POINT_TO_POINT",
  "endpoints": [
    {
      "identifier": "ep-east",
      "uni": "customer-east",
      "vlan": "1730.*"
    },
    {
      "identifier": "ep-west",
      "uni": "customer-west",
      "vlan": "1731.*"
    }
  ],
  "parameters": {
    "mpls_backend": "EVPN",
    "mpls_p2p_service": "vpws"
  }
}

Carrier Ethernet EVC¶

The Carrier Ethernet EVC provides a MEF-compliant API for Ethernet Virtual Connections. It supports point-to-point (E-Line) and multipoint (E-LAN) service types with bandwidth profiles and VLAN mapping, following the MEF 10.4 specification.

Attributes¶

Attribute	Modifier	Type	Description
`identifier`	`rw`	string (1-45 chars)	Unique EVC identifier
`connectionType`	`rw`	`POINT_TO_POINT` / `MULTIPOINT`	Service topology
`evcEndPoints`	`rw`	list (2+)	EVC endpoint definitions
`ext_networkBackend`	`rw`	object	Backend selection (`LDP` / `EVPN`)

EVC Endpoint attributes:

Attribute	Modifier	Type	Description
`subscriberUniRef`	`rw`	ref	Reference to subscriber UNI
`evcEndPointId`	`rw`	string	Endpoint identifier
`cosIdentifier`	`rw+`	string	Class of Service identifier
`egressBwpFlow`	`rw+`	object	Egress bandwidth profile (CIR in kbps)
`evcEndPointMap`	`rw`	object	VLAN mapping configuration

VLAN mapping (evcEndPointMap) supports:

ALL: All VLANs on the UNI
LIST: Specific VLAN IDs (with optional inner VLAN for Q-in-Q)
UNTAGGED: Untagged frames only

Example¶

{
  "identifier": "evc-east-west",
  "connectionType": "POINT_TO_POINT",
  "ext_networkBackend": {
    "type": "EVPN"
  },
  "evcEndPoints": [
    {
      "evcEndPointId": "ep-1",
      "subscriberUniRef": {
        "href": "inmanta:456-852-789"
      },
      "evcEndPointMap": {
        "type": "LIST",
        "vlanIdList": [
          {"vlanId": 100}
        ]
      },
      "egressBwpFlow": {
        "cir": 1000000
      }
    },
    {
      "evcEndPointId": "ep-2",
      "subscriberUniRef": {
        "href": "inmanta:123-852-456"
      },
      "evcEndPointMap": {
        "type": "LIST",
        "vlanIdList": [
          {"vlanId": 200}
        ]
      },
      "egressBwpFlow": {
        "cir": 1000000
      }
    }
  ]
}

L3 VPN¶

L3 VPN provides Layer 3 Virtual Private Network connectivity with MPLS transport. It creates a VPN routing instance (VRF) on each endpoint device and establishes routing sessions with customer-edge equipment.

Attributes¶

Attribute	Modifier	Type	Description
`identifier`	`rw`	string	Unique service identifier
`rd_number`	`rw+`	int (opt)	Route Distinguisher (auto-allocated if omitted)
`route_target`	`rw+`	int (opt)	Route Target (auto-allocated if omitted)
`bandwidth`	`rw+`	int	Bandwidth per endpoint in kbps (0 = unlimited)
`allowed_ipv4_networks`	`rw+`	list	IPv4 firewall allow-list
`allowed_ipv6_networks`	`rw+`	list	IPv6 firewall allow-list
`endpoints`	`rw+`	list (1+)	Endpoint definitions (see below)
`parameters`	`rw+`	object	Service parameters

Endpoint attributes:

Attribute	Modifier	Type	Description
`identifier`	`rw`	string	Endpoint identifier
`uni`	`rw`	ref	Reference to existing UNI service
`vlan_id`	`rw`	int (1-4094)	VLAN for PE-CE communication
`routing_protocol`	`rw`	`static` / `bgp`	Routing protocol with customer
`bgp_remote_as`	`rw`	int (opt)	Customer BGP AS number (required for BGP)
`bfd_interval`	`rw+`	int	BFD interval in ms (0 = disabled)
`ipv4`	`rw+`	object	IPv4 configuration
`ipv6`	`rw+`	object (opt)	IPv6 configuration (dual-stack)

IPv4/IPv6 configuration:

Attribute	Modifier	Type	Description
`p2p_network`	`rw+`	IP network	PE-CE point-to-point network (auto-allocated if omitted)
`prefixes`	`rw+`	list	Customer prefixes to route into the VPN

Parameters:

Attribute	Modifier	Type	Description
`transport_technology`	`rw+`	`LDP` / `SR-MPLS`	MPLS transport technology

Example¶

{
  "identifier": "vpn-customer-a",
  "bandwidth": 100000,
  "allowed_ipv4_networks": ["10.0.0.0/8", "172.16.0.0/12"],
  "endpoints": [
    {
      "identifier": "site-east",
      "uni": "customer-east",
      "vlan_id": 500,
      "routing_protocol": "bgp",
      "bgp_remote_as": 65001,
      "bfd_interval": 300,
      "ipv4": {
        "p2p_network": "192.168.1.0/30",
        "prefixes": ["10.1.0.0/16"]
      },
      "ipv6": {
        "p2p_network": "2001:db8:1::/126",
        "prefixes": ["2001:db8:100::/48"]
      }
    },
    {
      "identifier": "site-west",
      "uni": "customer-west",
      "vlan_id": 501,
      "routing_protocol": "bgp",
      "bgp_remote_as": 65001,
      "ipv4": {
        "prefixes": ["10.2.0.0/16"]
      }
    }
  ],
  "parameters": {
    "transport_technology": "LDP"
  }
}

Direct Internet Access (DIA)¶

DIA provides internet connectivity for a customer by creating a dedicated VRF and leaking routes between the customer VRF and the default routing table. Customer prefixes are advertised and internet routes are made available to the customer.

Attributes¶

Attribute	Modifier	Type	Description
`identifier`	`rw`	string	Unique service identifier
`routing_protocol`	`rw`	`static` / `bgp`	Routing protocol with customer
`prefixes`	`rw+`	list	Customer IP prefixes
`bgp_remote_as`	`rw`	int (opt)	Customer BGP AS (required for BGP)
`service_id`	`r`	positive int	Auto-allocated service ID
`endpoints`	`rw`	list (1+)	Endpoint definitions (see below)

Endpoint attributes:

Attribute	Modifier	Type	Description
`identifier`	`rw`	string	Endpoint identifier
`uni`	`rw`	ref	Reference to existing UNI service
`vlan_id`	`rw`	int (1-4094)	VLAN for PE-CE communication
`p2p_network`	`r`	IP network	Auto-allocated PE-CE point-to-point network
`bfd_interval`	`rw+`	int	BFD interval in ms (0 = disabled)

Example¶

{
  "identifier": "dia-customer-a",
  "routing_protocol": "bgp",
  "bgp_remote_as": 65001,
  "prefixes": ["203.0.113.0/24"],
  "endpoints": [
    {
      "identifier": "ep-1",
      "uni": "customer-east",
      "vlan_id": 600
    }
  ]
}

Operational verification (Nokia Lightspan)¶

On the Nokia Lightspan (fiber access / OLT) platform, the Network Element (ONT) and UNI services do not stop at pushing configuration: once the config is deployed, the orchestrator reads operational state back from the OLT and fails the deploy if the link is not actually healthy. This is implemented with yang::NetconfVerify resources that run read-only NETCONF gets and compare the result against a threshold.

Behavior is the same for every check:

The verify requires the service’s configuration resource, so it only runs after the config has been pushed.
While the service is still creating, a failing check is skipped (the ONT may not be ranged yet, the customer may not have connected the CPE). Once the service reaches up, a failing check fails the deploy.
A failed verify does not block provisioning of other services on the element: a connectivity service such as l2Connect only needs an existing UNI, not a fully compliant one.
There is one verify resource per service, carrying one entry per checked item.

Optical values are expressed in 0.1 dBm (e.g. -280 means -28.0 dBm).

Network Element (ONT) checks¶

Check	Passes when	Read from
Upstream optical power	OLT-measured `rssi` for the ONT is within the per-PON-tech range	OLT pon transceiver-link diagnostics (`rssi-onu`)
Operational state	ONT is present on its intended channel-termination	v-ani `onu-presence-state`
Ranging distance	measured fiber distance is below `max_fiber_distance_m`	v-ani `onu-present-on-this-olt/onu-fiber-distance`
Transmission quality	uncorrectable FEC codewords in the current 15-min interval `<= max_uncorrectable_fec`	v-ani 15-min performance counters
Downstream optical power	optical power the ONT receives is within `ont_rx_power`	ONT optics, via the OLT’s emulated-onu mount (ANIPORT)

The operational-state check verifies the intended channel-termination, so it also catches an ONT that has ranged on the wrong PON (a cross-connect). The upstream and downstream power checks together verify the optical budget in both directions.

UNI (iHub) checks¶

Check	Passes when	Read from
Port up	the port is operationally up	SR OS `state/port/oper-state`
Negotiated speed	the port negotiated the configured speed (fixed-speed ports only; skipped when `auto_negotiation` is enabled)	SR OS `state/port/ethernet/oper-speed`

Configurable thresholds¶

The thresholds live in the module configuration under lightspan.verify and can be tuned per deployment (the defaults below are sensible starting points; the per-PON-tech upstream ranges differ because OLT receiver sensitivity and overload points differ between 25GS-PON and XGS-PON):

Config key	Default (`min` / `max`)	Meaning
`lightspan.verify.rssi_25gspon`	`-270` / `-60`	Accepted OLT-measured upstream rssi range for 25GS-PON ONTs.
`lightspan.verify.rssi_xgspon`	`-280` / `-80`	Accepted OLT-measured upstream rssi range for XGS-PON ONTs.
`lightspan.verify.ont_rx_power`	`-270` / `-80`	Accepted downstream optical power received at the ONT.
`lightspan.verify.max_fiber_distance_m`	`20000`	Maximum accepted ONT ranging distance, in meters.
`lightspan.verify.max_uncorrectable_fec`	`0`	Maximum uncorrectable FEC codewords in the current 15-min interval.

See the configuration reference for the full schema and how to set these values.

Operational verification (Nokia SR OS)¶

On the Nokia SR OS platform, a UNI service applies the same operational verification as the Lightspan iHub UNI: once the port configuration is pushed, the orchestrator reads the port state back from the router and fails the deploy if the port is not actually healthy. This uses a yang::NetconfVerify resource with the same behavior as described above (it requires the config resource, is skipped while the uni is creating, and fails the deploy once the uni is up). There is one verify resource per uni service, with one entry per port.

Check	Passes when	Read from
Port up	the port is operationally up	SR OS `state/port/oper-state`
Negotiated speed	the port negotiated the configured speed (fixed-speed ports only; skipped when `auto_negotiation` is enabled)	SR OS `state/port/ethernet/oper-speed`

When the uni port is a lag member, it reports oper-state down (e.g. down - Active in lag-608) while traffic flows over the lag, so verifying the port oper-state would always fail. In that case the lag oper-state is verified instead, reading state/lag/oper-state. The negotiated-speed check still applies to the physical member port.

Operational status in the documentation tab¶

Beyond failing a deploy, every verified value is also surfaced for visibility in the documentation tab of the service it belongs to. Each verify entry publishes its result as a fact, and the documentation renders an Operational status table with one row per verified value:

Check	Current status
Port `1/1/1` operational state	✅ `up`

The status column holds a reference that is resolved on the orchestrator every time the service is (re)deployed, so the tab always reflects the value last read back from the device (a green check with the observed value when the check passes, a red cross with the observed and expected values otherwise). This is why the documentation is rendered with future::std::jinja (via connect::get_template_value_as_string) rather than std::template: only the former can carry references through to deploy time. The table is wired into every service (uni, network element, l2Connect, l3vpn, DIA) but the whole section is omitted from services that currently have no operational checks. The template path of each service is operator-tunable through its <service>.documentation_template config key.

Service Dependencies¶

Services have dependencies that must be respected during creation and deletion:

UNIs must be created before any connectivity service that references them.
A UNI cannot be deleted while connectivity services still reference it (enforced by deletion validation when enabled).
Multiple connectivity services can share the same UNI, each using a different VLAN.
Network Element is independent of the other services: it carries device-level data and base configuration, but has no runtime dependency on the connectivity services.

Attribute Modifiers¶

The modifier column in the attribute tables refers to LSM attribute modifiers that control when an attribute can be set. See the LSM documentation for details.