1 Overview

This chapter provides an overview of the Oracle Communications Network Integrity NETCONF Network Discovery and UIM Integration cartridge.

About the NETCONF Network Discovery Cartridge

The Network Configuration (NETCONF) Network Discovery cartridge supports network discovery by using the NETCONF protocol. It generates a representation of the network infrastructure that comprises both logical and physical device hierarchies. The logical hierarchy features a logical device, child interfaces, sub-interfaces and device interface configurations. The physical hierarchy features the physical device, equipment, holders, and ports. This cartridge also creates associations between these hierarchies at the device level (between physical and logical devices) and at the interface level (between physical ports and interfaces).

Note:

Before using the NETCONF Network Discovery cartridge, you must ensure that your network devices support the NETCONF protocol and Yet Another Next Generation (YANG) models. Network Integrity relies on standard NETCONF/YANG interfaces for communication and does not offer tools to activate these protocols. To enable this support, contact the device manufacturer or vendor.

About the NETCONF Protocol

The Network Configuration Protocol (NETCONF), developed and standardized by the Internet Engineering Task Force (IETF) is used to manage network device configurations. This protocol provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses XML-based encoding for both configuration data and protocol messages. NETCONF performs its operations through remote procedure calls (RPCs), which help reduce the complexity of network communication.

Inputs for NETCONF are defined by the RPC operations as listed below.

• copy-config: Copies one configuration datastore to another
• delete-config: Deletes a configuration datastore
• get-config: Retrieves all or part of a configuration datastore
• get: Retrieves all or part of an operational datastore
• edit-config: Changes the contents of a configuration datastore

The below examples show sample NETCONF Request and responses.

Example 1: Sample NETCONF Request to retrieve all operational data for interfaces:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get>
    <filter type="subtree">
      <interfaces-state xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"/>
    </filter>
  </get>
</rpc>

Example 2: Sample NETCONF Response:

<rpc-reply message-id="102" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <data>
    <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
      <interface>
        <name>GigabitEthernet0/0/0</name>
        <description>Main uplink interface</description>
        <type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
          ianaift:ethernetCsmacd
        </type>
        <enabled>true</enabled>
      </interface>
    </interfaces>
  </data>
</rpc-reply>

About YANG Models

YANG is a data modeling language standardized by the IETF (Internet Engineering Task Force). It defines how to represent configuration data, state data, RPCs, and notifications for network management protocols. YANG is an API contract language, which defines how clients and servers interact through an API.

A YANG specification is called a YANG module, and a group of modules is often referred to as a YANG model. A YANG model serves as the schema of a network device, similar to a database schema or blueprint. This schema outlines the structure and types of data the system can exchange—such as possible configuration settings, monitoring data, notifications, and available actions. This is different from instance data, which shows the actual configuration and real-time monitoring values in use. While the YANG model defines what is possible, the instance data reflects the current state of the system.

Architecture for Network Management using NETCONF and YANG Models

Figure 1-1 shows the architecture for network management using NETCONF and YANG models.

Note:

In order to use YANG for network management, YANG modules must be defined to model the target domain. These modules must be then loaded, compiled, or coded into the server.

Figure 1-1 Architecture for Network Management Using NETCONF and YANG Models

Description of "Figure 1-1 Architecture for Network Management Using NETCONF and YANG Models"

The following sequence of events describe a typical client/server interaction for this architecture:

• The client application initiates a NETCONF session with the server, establishing a connection.
• The client and server exchange <hello> messages, containing the list of capabilities supported by each side, and learns about the modules the server supports.
• The client builds and sends an XML message with an operation in an <rpc> element.
• The server receives and parses the <rpc> element, then verifies the request against the data model defined in its YANG module.
• The server performs the operation, possibly changing the configuration datastore.
• The server builds the response, including the result, any requested data, and errors.
• The server sends XML response in an <rpc-reply> element.
• The client receives and parses the <rpc-reply> element, analyzes it, and processes it as needed.

NETCONF Communication between Network Integrity and Devices

When using NETCONF protocol to discover network devices, Network Integrity acts as a NETCONF client. This allows Network Integrity to communicate with the devices in the network and allows to retrieve device details, device status and configure the device.

When NI interacts with the devices using NETCONF protocol, it does the following:

1. The netconfConnectionInitializer processor acts as a NETCONF client and opens a NETCONF session with the device.
2. The client sends a hello message to the device:

   <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <capabilities>
       <capability>urn:ietf:params:netconf:base:1.0</capability>
     </capabilities>
   </hello>

3. The device replies with a hello message that includes a list of its supported capabilities. Based on the NETCONF version in the response, the client chooses a framing mechanism:
   • NETCONF 1.0 version uses End-of-Message Framing.
   • NETCONF 1.1 version uses Chunked Framing.
4. The client builds an XML request and sends it using the selected framing method.
5. The client receives the response from the device and decodes it.

About Supported Routing Protocols

This section provides information on the different routing protocol details that the NETCONF Network Discovery and UIM Integration cartridge can discover, as listed below:

• Open Shortest Path First (OSPF)
• Link Layer Discovery Protocol (LLDP)
• Routing Information Protocol (RIP)
• Internet Protocol (IP)
• Border Gateway Protocol (BGP)
• Layer 2 Virtual Private Network (L2VPN)

Open Shortest Path First (OSPF)

OSPF is a link-state Interior Gateway Protocol (IGP) used for routing within an autonomous system. Each router running OSPF exchanges link-state advertisements (LSAs) with its neighbors and builds a complete map of the network topology.

Network Integrity uses the ietf-ospf.yang file (subset of the ietf-routing.yang model) to discover OSPF details. The attributes dr-ip-addr, neighbor-router-id and address discovered from this YANG model can be used to create A-end and Z-end information.

Link Layer Discovery Protocol (LLDP)

LLDP operates as a Layer 2 discovery protocol that provides a standardized method to encapsulate information about device capabilities, management address, device ID, and interface ID into LLDP frames. This protocol allows Network Integrity to discover the topology of connected network devices, and display paths between clients, switches, routers, application servers, and network servers.

Network Integrity uses the openconfig-lldp.yang file to discover LLDP information. The attributes, interface name and management-address, discovered from this YANG file serve to create A-end and Z-end information. The IP Assimilation cartridge uses this protocol to create topological links.

Routing Information Protocol (RIP)

RIP functions as a dynamic routing protocol based on the distance-vector algorithm. Routers using RIP exchange routing tables periodically with neighbors, using hop count as the exclusive metric for route selection. The protocol limits the maximum hop count to 15, defining the reachable network scope. Periodic updates maintain routing information, while convergence occurs over time according to the protocol’s timing mechanisms. RIP remains configured primarily in small or legacy network environments.

Network Integrity uses the ietf-rip.yang file to discover RIP information. The attributes discovered include IPv4 and IPv6 information: address and prefix. The next-hop address contained in the YANG model is used to identify the Z-end interface address.

Internet Protocol (IP)

The Internet Protocol (IP) is the core protocol at the network layer that provides addressing and routing for communication across networks. Every device connected to an IP network is assigned a unique IP address (IPv4 or IPv6), which allows packets to be delivered from a source host to a destination host, even across multiple intermediate routers.

Network Integrity uses the ietf-ip.yang file (a subset of the ietf-interfaces.yang model) to discover IPV4 or IPV6 address, sub-netmask and prefix for the A-end Device Interface. This information is used in IP Assimilation cartridge to create A-end Device and Interface information for Links.

Border Gateway Protocol (BGP)

BGP operates as an Exterior Gateway Protocol that exchanges routing information between distinct autonomous systems. Unlike IGPs which function within a single asynchronous system, BGP uses a path-vector mechanism and associates routes with attributes such as AS-path to enable policy-based routing, control traffic flow, and prevent routing loops. BGP supports scalable and policy-driven route management across complex network environments.

Network Integrity discovers neighbor-address and local-address attributes from the openconfig-bgp.yang file, which is used for routing details.

BGP supports 2 operation types described below:

• External BGP (eBGP): Exchanges routing information between routers in different autonomous systems, typically at edge or border routers.
• Internal BGP (iBGP): Distributes routing information between routers within the same autonomous system to ensure consistent routing policies across the network.

Layer 2 Virtual Private Network (L2VPN)

L2VPN extends Layer 2 networks across wide-area backbones by enabling geographically dispersed sites to operate as part of the same Ethernet segment or LAN. It is implemented using Multiprotocol Label Switching (MPLS) pseudowires or IP-based tunneling techniques to encapsulate Layer 2 frames and transport them across the underlying infrastructure.

The solution remains transparent to Layer 3 protocols, allowing independent routing configurations within the extended Layer 2 domain. L2VPN supports network connectivity by delivering Layer 2 transport services without altering internal routing operations.

About Cartridge Dependencies

This section provides information on dependencies that the NETCONF Network Discovery cartridge has on other cartridges.

Run-Time Dependencies

This cartridge requires that the following cartridges be deployed to Network Integrity:

• Address_Handlers
• UIM_Integration_Cartridge

Design-Time Dependencies

The NETCONF Network Discovery cartridge has the following dependencies:

• Address_Handlers
• NetworkIntegritySDK
• ora_ni_uim_yang_model
• ora_uim_model
• UIM_Integration_Cartridge
• netconf-yang-model-8.0.0.jar

About the NETCONF YANG Model

The netconf-yang-model-8.0.0.jar is a NETCONF YANG model used in the NETCONF Network Discovery and UIM Intgeration cartridge is provided along with the cartridge. This model is generated from the YANG files used in the cartridge.

This NETCONF YANG model is generated from the Apache Maven project yang_sources_generator. This project can also be used to generate Java classes from YANG files of discovered devices. It is provided along with the NETCONF YANG model in the cartridge.

The project hierarchy is as shown below:

yangs_sources_generator 
  yangs_netconf
     src/main/netconf-yang
     pom.xml

To generate Java classes for other YANG files:

1. Provide required YANG files (of the network devices) along with all the dependency YANG files in yangs_netconf/src/main/netconf-yang directory.
2. Run the command mvn clean install in the yangs_netconf directory.

   The updated netconf-yang-model-8.0.0.jar will be generated in the yangs_netconf/target directory.

Opening the Cartridge Files in Design Studio

To use the NETCONF Network Discovery cartridge, you must first download the Oracle Communications NETCONF Network Discovery Cartridge software from the Oracle software delivery web site:

https://edelivery.oracle.com

The software contains the Netconf Network Discovery cartridge ZIP file, which has the following structure:

• UIM_Cartridge_Projects\

• Network_Integrity_Cartridge_Projects

• Address_Handlers.iar

• Netconf_Network_Discovery_Cartridge.iar

For more information about opening files in Design Studio, see Design Studio Modeling Network Integrity and Network Integrity Developer's Guide.

Building and Deploying the Cartridge

See SCD Modeling Network Integrity for information about building and deploying cartridges.