8  Server Callback Examples

This section was written by Mark Pashley for the Yuma Integration Test Suite.

It is included here because it explains the details of SIL callback for several message flow examples.

This document details the SIL callbacks that are made when YumaPro processes NETCONF edit queries when configured to use the candidate database configuration (--target=candidate).

8.1  YANG

The following YANG defines the configuration that is used for all of the examples within this document.

 

 

container xpo {

        presence "Indicates that the Device Test API is available.";

        description "Top-level container for all configuration and   status objects.";

 

        ////////////////////////////////////

        // Start of main configuration block

        ////////////////////////////////////                        

        grouping connectionItem {

            description "Connection container.";

 

            leaf sourceId {

                description "The ID of the item providing the input                            to the connection.";

                type uint32;

            }

 

            leaf bitrate {

                description "The maximum expected bitrate over this connection.";

                type uint32;

                units "bps";

            }

        }

 

        list profile {

            key id;

            description "Profile container.";

 

            leaf id {

                description "Unique ID for this profile.";

                type uint32;

            }

 

            list streamConnection {

                description "Connection between two streams.";

                key id;

 

                leaf id {

                    description "Connection identifier.";

                    type uint32;

                }

 

                uses connectionItem;

            }

        }

 

        leaf activeProfile {

            description "The number of the active profile.";

            type uint32;

        }

    }

 

 

8.2  Edit Operations

The following sections identify the messages sent by the Netconf Client and the SIL callbacks that will be made. The message sequence charts do not show operations for locking and unlocking of the running and candidate configurations.

8.2.1  Create an XPO container

The message sequence chart below shows the expected SIL callbacks for a create xpo container operation.

graphics8

  1. The client issues an rpc edit-config to create an xpo container:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="4"
    xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <edit-config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   <target> <candidate/> </target>
   <default-operation>merge</default-operation>
   <config>
     <xpo xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
                    nc:operation="create"
          xmlns="http://www.ericsson.com/television/ns/xpo3/base"/>
   </config>
 </edit-config>
</rpc>

 

  1. Netconf executes the xpo_edit<validate> callback to validate the change to the candidate configuration.

  2. Netconf executes the xpo_edit<apply> callback to apply the change to the candidate configuration.

  3. The client receives an rpc-reply indicating success.

  4. The client issues an rpc commit to commit the change to the running configuration.

  5. Netconf executes the xpo_edit<validate> callback to validate the change to the running configuration.

  6. Netconf executes the xpo_edit<commit create> callback to perform a create operation change to the candidate configuration.

  7. The client receives an rpc-reply indicating success.

8.2.2  Create a Profile

The message sequence chart below shows the expected SIL callbacks for a create profile operation.

graphics18

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="5"
    xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <edit-config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   <target> <candidate/> </target>
   <default-operation>merge</default-operation>
   <config>
     <xpo
      xmlns="http://www.ericsson.com/television/ns/xpo3/base">
      <profile xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
               nc:operation="create"><id>1</id></profile></xpo>
   </config>
 </edit-config>
</rpc>

8.2.3  Create a Stream Connection

The message sequence chart below shows the expected SIL callbacks for a create profile stream connection operation. In this scenario the XPO container is empty prior to step 1.

graphics19

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="5"
    xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <edit-config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   <target> <candidate/> </target>
   <default-operation>merge</default-operation>
   <config>
     <xpo xmlns="http://www.ericsson.com/television/ns/xpo3/base">
<profile><id>1</id>
<streamConnection xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="create"><id>1</id>
   <sourceId>100</sourceId>
   <bitrate>500</bitrate>
</streamConnection>
</profile></xpo>
   </config>
 </edit-config>
</rpc>

8.2.4  Delete an XPO Container

The message sequence chart below shows the expected SIL callbacks for a delete xpo container operation. In this scenario the XPO container is populated with at last one profile prior to step 1.

graphics20

  1. The client issues an rpc edit-config to delete an xpo container:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="10"
    xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <edit-config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   <target> <candidate/> </target>
   <default-operation>merge</default-operation>
   <config>
     <xpo xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
                    nc:operation="delete"
          xmlns="http://www.ericsson.com/television/ns/xpo3/base"/>
   </config>
 </edit-config>
</rpc>

  1. Netconf executes the xpo_edit<validate> callback to validate the change to the candidate configuration.

  2. Netconf executes the xpo_edit<apply> callback to apply the change to the candidate configuration.

  3. The client receives an rpc-reply indicating success.

  4. The client issues an rpc commit to commit the change to the running configuration.

  5. Netconf executes the xpo_edit<validate> callback to validate the change to the running configuration.

  6. Netconf executes the xpo_edit<commit delete> callback to perform a create operation change to the candidate configuration.

  7. The client receives an rpc-reply indicating success.

8.2.5  Delete a Profile

The message sequence chart below shows the expected SIL callbacks for a delete xpo profile operation. In this scenario the XPO container is populated with at last one profile prior to step 1.

graphics21

  1. The client issues an rpc edit-config to delete a profile:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="10"
    xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <edit-config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   <target> <candidate/> </target>
   <default-operation>merge</default-operation>
   <config>
     <xpo xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<profile xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="delete"><id>1</id></profile></xpo>
   </config>
 </edit-config>
</rpc>

  1. Netconf executes the xpo_profile_edit<validate> callback to validate the change to the candidate configuration.

  2. Netconf executes the xpo_ profile_edit<apply> callback to apply the change to the candidate configuration.

  3. The client receives an rpc-reply indicating success.

  4. The client issues an rpc commit to commit the change to the running configuration.

  5. Netconf executes the xpo_ profile_edit<validate> callback to validate the change to the running configuration.

  6. Netconf executes the xpo_ profile_edit<commit delete> callback to perform a create operation change to the candidate configuration.

  7. The client receives an rpc-reply indicating success.

8.2.6  Delete a Stream Connection

Deleting a stream connection is no different to deleting a profile. For delete operations SIL callbacks are only made for the highest level node that is being deleted.