Home > Articles

  • Print
  • + Share This
This chapter is from the book

The Server Architecture: Datastore

In the typical YANG-based solution, the client and server are driven by the content of YANG modules. The server includes the definitions of the modules as metadata that is available to the NETCONF/RESTCONF engine. This engine processes incoming requests, uses the metadata to parse and verify the request, performs the requested operation, and returns the results to the client, as shown in Figure 2-5.


Figure 2.5 The Server Architecture (RFC 6244)

The YANG modules, which model a specific problem domain, are loaded, compiled, or coded into the server.

The sequence of events for the typical NETCONF client/server interaction occur as follows:

  1. A client application opens a NETCONF session to the server (device).

  2. The client and server exchange <hello> messages containing the list of capabilities supported by each side. This hello exchange includes the list of YANG 1.0 modules supported by the server.

  3. The client builds and sends an operation defined in the YANG module, encoded in XML, within NETCONF’s <rpc> element.

  4. The server receives and parses the <rpc> element.

  5. The server verifies the contents of the request against the data model defined in the YANG module.

  6. The server performs the requested operation, possibly changing the configuration datastore.

  7. The server builds the response message, containing the response itself, any requested data, and any errors.

  8. The server sends the response, encoded in XML, within NETCONF’s <rpc-reply> element.

  9. The client receives and parses the <rpc-reply> element.

  10. The client inspects the response and processes it as needed.

  • + Share This
  • 🔖 Save To Your Account