Protocolul de configurare a rețelei, NETCONF , este un protocol de gestionare a dispozitivelor de rețea. A fost dezvoltat în cadrul grupului de lucru NETCONF și publicat pentru prima dată în RFC 4741 , care a fost revizuit la RFC 6241 în iunie 2011.
NETCONF oferă mecanisme pentru setarea, gestionarea și deconfigurarea dispozitivelor de rețea prin apeluri de procedură la distanță RPC. NETCONF folosește XML ca mijloc de furnizare a configurației și ca mijloc de generare de mesaje pentru un protocol care este implementat deasupra unui transport.
NETCONF poate fi împărțit aproximativ în patru niveluri:
Exemplu de nivel +----------------+ +------------------------------- ------------+ | Conținut | | Configurare dispozitiv | +----------------+ +------------------------------- ------------+ | | +----------------+ +------------------------------- ------------+ | Operațiuni | |<get-config>, <edit-config>, <notificare>| +----------------+ +------------------------------- ------------+ | | | +----------------+ +-----------------------+ | | RPC | | <rpc>, <rpc-reply> | | +----------------+ +-----------------------+ | | | | +----------------+ +------------------------------- ------------+ | Transport | | BEEP, SSH, SSL, consolă | | protocol | | | +----------------+ +------------------------------- ------------+Implementarea de bază a protocolului include următoarele tipuri de solicitări: <get>, <get-config>, <edit-config>, <copy-config>, <delete-config>, <lock>, <unlock>, < close-session>, <kill-session>.
Funcționalitatea de bază a NETCONF poate fi extinsă cu suplimente. Când se stabilește o sesiune, clientul și serverul schimbă între ele informații despre extensiile instalate. RFC 4741 definește caracteristici suplimentare, în special: xpath și :validate.
Capacitatea de a vă abona și de a primi mesaje asincrone este publicată în RFC 5277 . Acesta definește o solicitare de tip <create-subscription> care include posibilitatea de a vă abona la mesaje în timp real. La rândul lor, mesajele sunt trimise prin instrucțiunea <notificare>. RFC definește, de asemenea, o caracteristică: intercalare care, împreună cu: notificare, ajută la gestionarea diferitelor solicitări NETCONF în timpul unui abonament activat.
Caracteristicile suplimentare includ blocarea unei părți a configurației. Acest lucru vă permite să editați arbori care nu se suprapun într-o configurație executabilă în mai multe sesiuni. Fără această adăugare, este posibilă doar blocarea întregii configurații.
Grupul de lucru lucrează în prezent la suport pentru mesaje care permit schimbul de șabloane ( XML Schema , Relax NG , etc.) care definesc arborele NETCONF.
NETCONF poate rula pe mai multe protocoale de transport:
Conținutul solicitărilor NETCONF este XML valid, majoritatea fiind legat de configurația dispozitivului.
Grupul de lucru NETMOD a finalizat lucrul la un limbaj orientat spre om pentru reprezentarea stării curente a dispozitivului, configurația, alertele și operațiunile, numit YANG . YANG este definit în RFC 6020 și extins de RFC 6021 , care introduce tipurile de date de bază.
În vara anului 2010, grupului de lucru NETMOD i s-a oferit posibilitatea de a lucra la un model de configurare (sistem, interfețe, rutare) compatibil cu modelul SNMP .
La sfârșitul anilor 80, IETF a dezvoltat SNMP , care a devenit foarte popular. În ciuda faptului că SNMP a oferit capacitatea de a configura dispozitive, acest protocol a fost folosit în general pentru monitorizarea rețelelor. În 2002, Consiliul de Arhitectură a Internetului și membrii cheie ai comunității IETF au făcut echipă cu transportatorii pentru a discuta această situație. Rezultatele discuției sunt publicate în RFC 3535 . La acel moment, operatorii de telecomunicații foloseau o interfață de comandă proprietară pentru a-și configura dispozitivele. Interfața avea multe facilități, spre deosebire de SNMP. În plus, mulți producători nu au permis configurarea completă a dispozitivelor lor prin SNMP. Inginerii de rețea au scris în mare parte scripturi care i-au ajutat să gestioneze dispozitivele, cu toate acestea, interfața de comandă în acest caz este cauza multor dificultăți. Cea mai semnificativă dintre acestea este imprevizibilitatea ieșirii generate de dispozitivul de rețea. Conținutul și formatarea rezultatelor tind să se schimbe în moduri care nu sunt întotdeauna previzibile.
În același timp, Juniper Networks a folosit o configurație bazată pe XML. Acest lucru a fost propus de IETF și distribuit în comunitate.
Aceste două fapte au condus la crearea unui protocol care să satisfacă atât cerințele operatorilor de rețea, cât și ale vânzătorilor de echipamente.