Service IronWare Administration Guide (Supporting R05.6.00) User Manual

Multi-Service IronWare Administration Guide 279
53-1003028-02
NETCONF in client/server architecture
8
FIGURE 17 NETCONF communication
The communication between the client and server consists of a series of alternating request and
reply messages. The NETCONF peers use
<rpc> and <rpc-reply> elements to provide transport
protocol-independent framing of NETCONF requests and responses. The NETCONF server
processes the RPC requests sequentially in the order in which they are received.
RPC request
The <rpc> element is used for enclosing a NETCONF request sent from the client to the server.
Every
<rpc> element contains a mandatory attribute, the message-id. This attribute has a unique
value for every RPC request, and is used to associate every RPC request with the corresponding
response. The
message-id value is a monotonically increasing integer string. The maximum length
of the string is 4095 characters. If the
message-id is not present in the RPC request, the server
rejects the request by returning an
<rpc-error> with the error-tag element set to the
missing-attribute.
If there are any additional attributes present in the RPC request, the NETCONF server returns them
unmodified in the corresponding RPC reply.
RPC reply
An <rpc-reply> element is sent in response to every RPC request. The <rpc-reply> element
contains the mandatory attribute
message-id copied from the corresponding RPC request, along
with any additional attributes that are present in the RPC request.
For successfully processed
get or get-config requests, the response data is encoded as the
content of the
<rpc-reply> element.
For successfully processed
edit-config or close-session requests, the <ok> element is
encoded as the content of the
<rpc-reply> element.
For unsuccessful RPC requests, one or more
<rpc-error> elements are encoded inside the
<rpc-reply> element.