Layer Example

■ The transport protocol layer provides for the underlying communication transport. Different transports are possible and can be used—for example, Secure Shell (SSH) and Block Extensible Exchange Protocol (BEEP). Those protocols are specified elsewhere and are not specific to management. What Netconf does is specify the requirements that a protocol must meet so that it can be used. (It also specifies bindings for a few transports, including the ones mentioned.)

For example, the transport must provide support for authentication. This allows manager and agent to ascertain that the other side is indeed who it claims to be. Obviously, this is an important security property—if your device is asked to change its configuration, you want it to be sure that the request came from the authorized manager, not from an intruder. Upper Netconf layers do not provide this function. Therefore, for this and some other functions, Netconf relies on the protocol that Netconf messages are transported over.

■ The RPC layer provides primitives that enable managers to invoke functions on agents, using a request-response pattern. The primitives that Netconf provides are, accordingly, RPC and RPC reply. RPC alludes to a remote-procedure call—that is, a management request. RPC reply is the response to that call. The response can include an indication of success and be accompanied with additional information, or it can be an error response. The operations of the operations layer are wrapped into those RPC elements.

■ The operations layer contains the guts of the Netconf protocol—that is, the management operations themselves. This includes everything from managing the management association itself to operations to manipulate and push around configuration files. We discuss the details of the operations layer in the next section.

■ The content layer deals with the management payload—specifically, the configuration data that is contained in the configuration files that are subjected to the Netconf operations. What this data is and how it is represented is actually outside the scope of the Netconf specification; Netconf stipulates only that some such content needs to be provided.

Eventually, a dedicated management information specification language and data models might be standardized for use with Netconf, but this is not the case today. Having said that, Netconf does make the assumption that management information can be transported as part of an XML document. After all, Netconf operations are encoded as XML documents and require management information to be exchanged between managers and agents. Management information must therefore be "XML-ized."

Of course, XML-ized data can take many different forms. It can be represented in a sophisticated XML document in which every parameter and attribute is represented through its own standardized tag. On the other hand, it can simply consist of a set of XML tags that are used to delimit a configuration file in its entirety. Although this conforms in letter, it violates the spirit of Netconf. In some ways, it is reminiscent of the old joke of the man (perhaps one of the blind men from the earlier story) who wanted to take an elephant across the border (see Figure 8-13). Of course, Customs did not allow it and sent him back. Undeterred, the man decided to get two pieces of toast, spread butter on them, and stick one on the elephant's belly, the other on the elephant's backside. When he came back to the border, Customs tried to send him back again, but he objected: "Of course, I wouldn't try to take an elephant with me, but a sandwich can't be forbidden!"

Figure 8-13 The CLIBlob Elephant and the XML Sandwich

In most typical implementations, the Netconf payload data at the minimum takes a form in which individual CLI statements are delimited by XML tags. In addition, CLI statements that belong to different subsystems are grouped to delimit different configuration subtrees. This particular aspect is revisited in the next section, "Netconf Operations."

Figure 8-14 depicts the structure of a Netconf message. You can see how management content in the message is encapsulated by Netconf operations and their parameters, which, in turn, are encapsulated in an RPC wrapper, which, in turn, is put on a transport in the application protocol layer.

Figure 8-14 Netconf Message Structure

Figure 8-14 Netconf Message Structure

Netconf Protocol Layers

Example 8-4 provides a taste of what an XML document representing a Netconf request looks like. Example 8-4 A Netconf Request

<rpc message-id="101

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<get-config>

<source>

<running/>

</source>

<filter type='

subtree">

<top xmlns='

http://example.com/schema/1.2/config">

<bgp/>

</top>

</filter>

</get-config>

</rpc>

The RPC tags (<rpc message-id = "101" ..> and </rpc>) provide the RPC opening and closing brackets that frame the overall message. The Netconf operation here is get-config, again enclosing the rest of the message in the corresponding tags (<get-config> being the opening, "</get-config>" the closing bracket). Two parameters are provided with the request: the <source> specifies the config being requested (in this case, the running config), whereas the <filter> specifies the subtree within the config being requested (everything in the config belonging to bgp).

Example 8-5 shows a reply to the request.

Example 8-5 A Netconf Reply

<rpc-reply message-id="101"

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data>

<top xmlns="http://example.com/schema/1.2/config"> <bgp>

chunk of BGP data </bgp> </top> </data> </rpc-reply>

Was this article helpful?

+1 0

Post a comment