You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Restconf protocol overview

RESTCONF is a REST like protocol based on HTTP [RFC7230] for configuring data defined in YANG version 1 [RFC6020] or YANG version 1.1 [RFC7950], using the datastore concepts defined in the Network Configuration Protocol (NETCONF) [RFC6241].

NETCONF defines configuration datastores and a set of Create, Read, Update, Delete (CRUD) operations that can be used to access these datastores.

NETCONF also defines a protocol for invoking these operations. The YANG language defines the syntax and semantics of datastore content, configuration, state data, RPC operations, and event notifications.

RESTCONF uses HTTP methods to provide CRUD operations on a conceptual datastore containing YANG-defined data. Request and response data can be in XML or JSON format. XML has structure according to yang by XML-YANG and JSON by JSON-YANG.


RESTCONF Client overview

RESTCONF client based on RESTCONF protocol enables following:

  • CRUD operation (via RestconfApiCallNode)

  • Notification handling (via RestconfDiscoveryNode)


Restconf Client Components

RestconfApiCallNode Overview:

RestconfApiCallNode combines the simplicity of HTTP with the predictability and automation potential of a schema-driven API. It uses YANG guided serializers/deserializers which uses YANG to determine schema and automates the serialization/deserialization to/from external formats like JSON/XML, thereby avoiding the need to write handcrafted templates for JSON/XML.

RestconfApiCallNode comparison with RestApiCallNode:

RestconfApiCallNode is meant to be used only for scenarios wherein the Server (3rd party Controllers or Devices) exposes RESTCONF based API’s for REST based API’s still RestApiCallNode is supposed to be used.

Advantages of using RestconfApiCallNode for RESTCONF API’s

  1. Avoid the efforts required to write and maintain JSON/XML templates as required in case of RestApiCallNode.

  2. With RESTCONF it’s possible to perform CRUD operation on whole data tree, on a subtree or even on a single leaf. With RestconfApiCallNode it’s possible to do all this without need to write multiple templates as required in case of RestApiCallNode currently.




RestconfDiscoveryNode:

The RESTCONF protocol supports YANG-defined event notifications.  The solution preserves aspects of NETCONF event notifications [RFC5277] while utilizing the Server-Sent Events [W3C.REC-eventsource-20150203] transport strategy. It’s based on pub-sub mechanism as defined below:

RestconfDiscoveryNode enables the supports YANG-defined event notifications based on following standards:

Mechanisms to support event subscription and push are defined in [I-D.draft-ietf-netconf-subscribed-notifications].

Enhancements to [I-D.draft-ietf-netconf-subscribed-notifications] which enable YANG datastore subscription and push are defined in [I-D.ietf-netconf-yang-push].

[I-D.ietf-netconf-restconf-notif] provides a transport specification for these protocols over RESTCONF [RFC8040] and HTTP

(Kindly Note: Basic support is available as part of Casablanca)


Usage:

RestconfApiCallNode:

It is implemented as a plugin in CCSDK (org.onap.ccsdk.sli.plugins.restconfapicall.RestconfApiCallNode)

Following are the list of Mandatory parameters

  • restapiUrl: URL to send request to server also this is used for resource identification in a YANG schema.

  • httpMethod: HTTP method to use while sending the request.

  • dirPath: Directory path which contains YANG files (main and dependent)


RestconfApiCallNode:

It is implemented as a plugin in CCSDK (org.onap.ccsdk.sli.plugins.restconfdiscovery.RestconfDiscoveryNode)

Following are the list of Mandatory parameters

  • subscriberId: identifier to be used while creating and deleting the subscription.

  • httpMethod: HTTP method to use while sending the request.

  • dirPath: Directory path which contains YANG files (main and dependent)

  • restapiUrl: URL to send request to server for establish-subscription request.

  • sseConnectURL: URL to send request to server for SSE events GET message.

    Next 4 parameters are for callback DG identification. Callback DG will be invoked for every received event and its supposed to implement the logic which needs to be executed for received event.

  • module: module of callback DG

  • rpc: rpc of callback DG

  • version: version of callback DG

  • mode: mode of callback DG


Enhancements for Dublin:

TBD



  • No labels