Brocade Multi-Service IronWare Administration Guide (Supporting R05.6.00) - Manual (Page 297)

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.