TechLibrary

Table of Contents

Guide That Contains This Content

[+] Expand All

[-] Collapse All

Overview of Network Director API

The Junos Space Network Director API application runs on the Junos Space Network Management Platform, and is exposed by the Network Director orchestration services.

The Network Director API is a set of Representational State Transfer (REST) APIs that enable network management functions, including:

Provisioning of secure multitenant networks in a shared network infrastructure
Automation of tenant services in the data center
Support for Layer 2 and Layer 3 security services
Provision of a single point of integration with external cloud and data center orchestration tools

This topic describes:

Network Director API Architecture

Figure 1 shows the high-level system architecture of the Network Director API in the Junos Space platform.

Figure 1: Network Director API Architecture

Supported Devices and Services

Network Director orchestration services and API support the following Juniper Networks devices:

EX Series switches
MX Series routers
QFX3500 and QFX3600 switches
QFabric systems
SRX Series Services Gateways

The type of network services supported depends on the device and the topology of the network.

Table 1 describes the supported devices, topologies, and services.

Table 1: Supported Devices, Topologies, and Services

Supported Devices and Topologies	Services	Configuration
EX Series switches—EX4200 and EX4550 switches QFabric systems—QFX 3000-G and QFX3000-M QFabric systems QFX Series—QFX3500 and QFX3600 switches	Layer 2	VLANs on the EX Series switch, QFX Series, or QFabric system
EX Series switch or QFX Series connected to an MX Series router QFabric system connected to an MX Series router	Layer 2 Layer 2 and Layer 3 Layer 2 and Layer 3 with Internet access	VLANs on the EX Series switch, QFX Series, or QFabric system Layer 3 interfaces on the MX Series router BGP static configuration on the MX Series router
EX Series switch or QFX Series connected to an SRX Services Gateway QFabric system connected to an SRX Services Gateway	Layer 2 Layer 2 and Layer 3 Layer 2 and Layer 3 with firewall	VLANs on the EX Series switch, QFX Series, or QFabric system Layer 3 interfaces on the SRX Services Gateway Security policies on the SRX Services Gateway

Network Director API Requirements

Before you can use the Network Director API, you must first install the following software:

Junos Space Release 13.1P5
Network Director API Release 1.5 or Network Director Release 1.5
Note: We recommend that you install Network Director API Release 1.5.
REST HTTP client, which can be browser-based or script-based
(Optional) Python 3 or later programming language software for running the sample API scripts included in the Network Director API software

Network Director Orchestration Services Overview

The Network Director orchestration services provide:

Support for a variety of predefined physical topology configurations, ranging from a single device to a complete complex data center infrastructure.
Static configuration management that enables the automatic download of static configurations to managed devices.
Flexible and extensible network service APIs that enable the definition of endpoints, connectivity between endpoints in Layer 2 and Layer 3, connectivity between Layer 2 and Layer 3, and policy applications, including those for security.

Network Director Orchestration Services Components

Network Director orchestration services are based on the Network as a Service (NaaS) model-based management system. NaaS consists of two logical components: NaaS service and NaaS domain.

The NaaS service runs in the Junos Space infrastructure and manages the NaaS domain in such a way that the NaaS domain appears to network administrators and tenants as a single device with a set of revenue ports. Revenue ports are data ports on Juniper Networks devices. In a typical data center environment, compute servers are attached to revenue ports through which NaaS service is provided. The Network Director API operations are performed using the NaaS service.
The NaaS domain represents the network infrastructure that the NaaS service manages. All elements, both physical and logical, in the domain are represented internally as instances of model classes in the Network Director orchestration services repository. The state of the elements in the repository is synchronized with the state in the NaaS domain by way of read-and-write activities such as discovery, configuration, and other events that occur in the management network.

In Network Director orchestration services provide network administrators with administrative and configuration privileges for performing network operations, including:

Configuring the network infrastructure
Performing basic create, replace, update, delete (CRUD) operations of tenants
Activating and deactivating NaaS service

Network Director API Overview

The Network Director orchestration services expose a set of REST APIs that is accessible through standard Web-based HTTP requests. You use the APIs to send requests to NaaS service resources to perform HTTP CRUD operations. The Network Director API is idempotent so that multiple requests to the same NaaS resources do not cause duplicate updates or provisioning errors.

The NaaS resources are represented in both JavaScript Object Notification (JSON) and Extensible Markup Language (XML) formats, and requests sent to the resource Universal Resource Identifier (URI) can be in either JSON or XML format.

The NaaS resources or services are grouped into classes by the type of services. For example:

ConnectivityGroups—Provides NaaS service for connectivity groups consisting of endpoints.
L2ConnectivityServices—Provides Layer 2 connectivity services.
L3ConnectivityServices—Provides Layer 3 connectivity services.
SecurityPolicies—Provides NaaS service to enable security policies.

Each class might contain resources. Examples of resource URIs are:

Network Director API Setup Overview

After you install the Network Director API software, the only NaaS service that is available for use is the service for importing the physical network topology of the NaaS domain. Before you can use the full set of NaaS service resources with the API, you must initialize NaaS service and import static configurations to your managed devices.

You initialize the NaaS service by importing the physical topology and populating the NaaS service repository with the topology. The NaaS service then performs a discovery of the devices in the NaaS domain. When the device discovery is complete, all devices in the topology are ready for configuration.

After the NaaS service is initialized, you must configure all managed devices. You must push the static configuration files of supported features to the devices. Static configurations are typically stable configurations, but they could be updated in the future if necessary. For example, to enable BGP on a device, you must push the static configuration file for BGP to the device. Pushing static configuration files to your devices enables them to be managed and configured using the Network Director API.

After you have set up the NaaS service for the Network Director API, all NaaS service resources that are supported for your network topology and devices are available for use.

For more information about the Network Director API setup, see Setting Up the Network Director API.

Common CRUD Operations

Requests are sent to the URI of the resource. For each resource, you can perform one or more of the four common CRUD operations. (A CRUD operation is also called a resource method.) Interactions with each resource follow specific formats, depending on the operation.

Table 2 describes the common CRUD operations.

Table 2: Common CRUD Operations

Operation	Description	Request Format	Response Format
Create (POST)	Creates an instance of the resource by sending an HTTP POST request to the designated URI for that resource type.	POST <resourceURI> HTTP/1.1 URL = https:// <server-ip>/api/ juniper/nd/<resource> Content-Type = application/vnd/juniper/ nd/<resource>+(json\|xml); version=1;charset=UTF-8 Accept = application/vnd.juniper.nd. <resource>+(json\|xml);version=1 <body of request>	HTTP/1.1 200 OK https:// <server-ip>/api/ juniper/nd/<resource>/<resource-id>
Read (GET)	Retrieves the representation of a resource by sending an HTTP GET request to the resource URI.	GET <resourceURI> HTTP/1.1 URL = https:// <server-ip>/api/ juniper/nd/<resource> Content-Type = application/vnd/juniper/ nd/<resource>+(json\|xml); version=1;charset=UTF-8 Accept = application/vnd.juniper.nd. <resource>+(json\|xml);version=1 <body of request>	HTTP/1.1 200 OK <body of response>
Update (PUT)	Updates the representation of a resource by sending an HTTP PUT request to the resource URI. Note: If the server detects that the request attempts to update a read-only attribute, the server ignores the update request, but does not generate an error.	PUT <resourceURI> HTTP/1.1 URL = https:// <server-ip>/api/ juniper/nd/<resource> Content-Type = application/vnd/juniper/ nd/<resource>+(json\|xml); version=1;charset=UTF-8 Accept = application/vnd.juniper.nd. <resource>+(json\|xml);version=1 <body of request>	HTTP/1.1 200 OK
Delete (DELETE)	Deletes a resource by sending an HTTP DELETE request to the resource URI.	DELETE <resourceURI> HTTP/1.1 URL = https:// <server-ip>/api/ juniper/nd/<resource> Content-Type = application/vnd/juniper/ nd/<resource>+(json\|xml); version=1;charset=UTF-8 Accept = application/vnd.juniper.nd. <resource>+(json\|xml);version=1 <body of request>	HTTP/1.1 204 OK https:// <server-ip>/api/ juniper/nd/<resource>/<resource-id>

NaaS Request State Changes

The state of a NaaS request typically undergoes multiple transitions because external API calls or internal Network Director orchestration services processes might trigger state changes. The life cycle of a NaaS request includes different request states and the transitions between those states.

Figure Figure 2 illustrates the different states and transitions of a NaaS request.

Figure 2: NaaS Request State Changes

A typical NaaS request consists of the following events and transitions:

Create a NaaS request—An HTTP POST action triggers the creation of a NaaS request. The newly created NaaS request is placed in a defined state.
Update NaaS request—An HTTP PUT action triggers an update to the NaaS request, resulting in the request being edited. The request state does not change.
Activate NaaS request—An HTTP PUT event triggers the activation of the request, which moves to an activating state, during which the configuration is validated and pushed to devices. If the activation succeeds, the NaaS request moves to the activated state. If the activation fails, the request returns to the defined state for modification.
Delete NaaS request—The completed NaaS request is deleted.
Update NaaS request after activation—After a NaaS request is activated, an HTTP PUT action will trigger an update to the NaaS request, and moves it to a modified state. The NaaS request can then be activated again, as described in Step 3.
Restore NaaS request—This event restores the request to the previous activated state from a modified state. The restore action applies only to a NaaS request in the modified state.
Deactivate NaaS request—If the request is in the activated state, an HTTP PUT action triggers a deactivate NaaS request, which moves the request to a deactivating state. If deactivation succeeds, the request changes back to a defined state.

API Reference Documentation

For more information about using Network Director APIs, see the API reference documentation (apiDocumentation.zip).

For information about accessing the API reference documentation, see Locating API Reference Information.