เน็ตคอนฟ์

โปรโตคอลการกำหนดค่าเครือข่าย ( NETCONF ) เป็น โปรโตคอล การจัดการเครือข่ายที่พัฒนาและกำหนดมาตรฐานโดยIETFได้รับการพัฒนาในกลุ่มงาน NETCONF ^{[ 1 ]}และเผยแพร่ในเดือนธันวาคม พ.ศ. 2549 ในชื่อ RFC 4741 ^{[ 2 ]}และต่อมาได้รับการแก้ไขในเดือนมิถุนายน พ.ศ. 2554 และเผยแพร่ในชื่อ RFC 6241 ^{[ 3 ]}ข้อกำหนดโปรโตคอล NETCONF เป็นเอกสารมาตรฐานอินเทอร์เน็ต

NETCONF มีกลไกในการติดตั้ง จัดการ และลบการกำหนดค่าของอุปกรณ์เครือข่าย การทำงานของมันเกิดขึ้นบน เลเยอร์ การเรียกใช้ฟังก์ชันระยะไกล (RPC) ที่เรียบง่าย โปรโตคอล NETCONF ใช้ การเข้ารหัสข้อมูลแบบ XML ( Extensible Markup Language ) สำหรับข้อมูลการกำหนดค่าและข้อความโปรโตคอล ข้อความโปรโตคอลจะถูกแลกเปลี่ยนบนโปรโตคอลการขนส่งที่ปลอดภัย

โปรโตคอล NETCONF สามารถแบ่งออกเป็น 4 ชั้นตามแนวคิดได้ดังนี้:

1. เลเยอร์เนื้อหาประกอบด้วยข้อมูลการกำหนดค่าและข้อมูลการแจ้งเตือน
2. เลเยอร์การปฏิบัติงานจะกำหนดชุดของการดำเนินการโปรโตคอลพื้นฐานเพื่อเรียกดูและแก้ไขข้อมูลการกำหนดค่า
3. เลเยอร์ข้อความมีกลไกสำหรับการเข้ารหัสการเรียกใช้กระบวนการระยะไกล (RPC) และการแจ้งเตือน
4. เลเยอร์การขนส่งที่ปลอดภัย (Secure Transport layer) ช่วยให้การส่งข้อความระหว่างไคลเอ็นต์และเซิร์ฟเวอร์มีความปลอดภัยและเชื่อถือได้

โปรโตคอล NETCONF ได้ถูกนำไปใช้ในอุปกรณ์เครือข่าย เช่น เราเตอร์และสวิตช์ โดยผู้ผลิตอุปกรณ์รายใหญ่บางราย จุดเด่นอย่างหนึ่งของ NETCONF คือการรองรับการเปลี่ยนแปลงการกำหนดค่าที่แข็งแกร่งโดยใช้ธุรกรรมที่เกี่ยวข้องกับอุปกรณ์จำนวนมาก

IETF ได้พัฒนาSimple Network Management Protocol (SNMP) ในช่วงปลายทศวรรษ 1980 และพิสูจน์แล้วว่าเป็นโปรโตคอลการจัดการเครือข่าย ที่ได้รับความนิยมอย่างมาก ในช่วงต้นศตวรรษที่ 21 ปรากฏชัดว่า แม้จะมีจุดประสงค์ดั้งเดิม แต่ SNMP กลับไม่ได้ถูกนำไปใช้ในการกำหนดค่าอุปกรณ์เครือข่าย แต่ส่วนใหญ่ถูกนำไปใช้ในการตรวจสอบเครือข่ายในเดือนมิถุนายน ปี 2002 คณะกรรมการสถาปัตยกรรมอินเทอร์เน็ตและสมาชิกหลักของชุมชนการจัดการเครือข่ายของ IETF ได้ร่วมประชุมกับผู้ให้บริการเครือข่ายเพื่อหารือเกี่ยวกับสถานการณ์ดังกล่าว ผลลัพธ์ของการประชุมครั้งนี้ได้รับการบันทึกไว้ใน RFC 3535 ปรากฏว่าผู้ให้บริการเครือข่ายแต่ละรายส่วนใหญ่ใช้ส่วนต่อประสานบรรทัดคำสั่ง (CLI) ที่เป็นกรรมสิทธิ์ของตนเองในการกำหนดค่าอุปกรณ์ ซึ่งมีคุณสมบัติหลายอย่างที่ผู้ให้บริการชื่นชอบ รวมถึงการที่เป็นข้อความ ซึ่งแตกต่างจาก SNMP ที่เข้ารหัสแบบ BERนอกจากนี้ ผู้จำหน่ายอุปกรณ์หลายรายไม่ได้ให้ตัวเลือกในการกำหนดค่าอุปกรณ์ของตนอย่างสมบูรณ์ผ่าน SNMP เนื่องจากผู้ใช้งานส่วนใหญ่ชอบเขียนสคริปต์เพื่อช่วยจัดการอุปกรณ์ของตน พวกเขาจึงพบว่า SNMP CLI มีข้อบกพร่องอยู่หลายประการ ที่เห็นได้ชัดที่สุดคือลักษณะของผลลัพธ์ที่ไม่แน่นอน เนื้อหาและรูปแบบของผลลัพธ์มีแนวโน้มที่จะเปลี่ยนแปลงไปในลักษณะที่คาดเดาไม่ได้

ในช่วงเวลาเดียวกันนั้นJuniper Networksได้นำวิธีการจัดการเครือข่ายแบบ XML มาใช้ ซึ่งได้มีการนำเสนอต่อ IETF และแบ่งปันให้กับชุมชนในวงกว้าง เหตุการณ์ทั้งสองนี้รวมกันนำไปสู่การก่อตั้งกลุ่มทำงาน NETCONF ในเดือนพฤษภาคม 2546 กลุ่มทำงานนี้มีหน้าที่ในการพัฒนาโปรโตคอลการกำหนดค่าเครือข่าย ซึ่งจะสอดคล้องกับความต้องการของผู้ให้บริการเครือข่ายและผู้จำหน่ายอุปกรณ์ได้ดียิ่งขึ้น โปรโตคอล NETCONF เวอร์ชันแรกได้รับการเผยแพร่เป็น RFC 4741 ในเดือนธันวาคม 2549 และมีการเผยแพร่ส่วนขยายเพิ่มเติมในอีกหลายปีต่อมา (การแจ้งเตือนใน RFC 5277 ในเดือนกรกฎาคม 2551 การล็อกบางส่วนใน RFC 5717 ในเดือนธันวาคม 2552 การกำหนดค่าเริ่มต้นใน RFC 6243 ในเดือนมิถุนายน 2554 การแจ้งเตือนระบบใน RFC 6470 ในเดือนกุมภาพันธ์ 2555 และการควบคุมการเข้าถึงใน RFC 6536 ในเดือนมีนาคม 2555) โปรโตคอล NETCONF ฉบับปรับปรุงได้รับการเผยแพร่เป็น RFC 6241 ในเดือนมิถุนายน 2011

เนื้อหาของการดำเนินการ NETCONF เป็น XML ที่มีรูปแบบถูกต้อง เนื้อหาส่วนใหญ่เกี่ยวข้องกับการจัดการเครือข่าย ต่อมาได้ เพิ่ม การรองรับการเข้ารหัสในรูปแบบ JavaScript Object Notation (JSON) ด้วย

กลุ่มทำงาน NETMOD ได้ดำเนินการกำหนดภาษาสร้างแบบจำลองที่เป็นมิตรกับมนุษย์ (human-friendly) สำหรับการกำหนดความหมายของข้อมูลการดำเนินงาน ข้อมูลการกำหนดค่า การแจ้งเตือน และการดำเนินการต่างๆ ซึ่งเรียกว่าYANG เสร็จสมบูรณ์แล้ว YANG ได้รับการกำหนดไว้ใน RFC 6020 (เวอร์ชัน 1) และ RFC 7950 (เวอร์ชัน 1.1) และมาพร้อมกับ "ประเภทข้อมูล YANG ทั่วไป" ที่พบใน RFC 6991

ในช่วงฤดูร้อนของปี 2010 กลุ่มทำงาน NETMOD ได้รับการจัดตั้งขึ้นใหม่เพื่อทำงานเกี่ยวกับแบบจำลองการกำหนดค่าหลัก (ระบบ อินเทอร์เฟซ และการกำหนดเส้นทาง) รวมถึงการทำงานเพื่อให้เข้ากันได้กับภาษาการสร้างแบบจำลอง SNMP

โปรโตคอลพื้นฐานกำหนดการทำงานของโปรโตคอลดังต่อไปนี้:

ฟังก์ชันการทำงานพื้นฐานของ NETCONF สามารถขยายได้โดยการกำหนดความสามารถของ NETCONF ชุดของคุณสมบัติโปรโตคอลเพิ่มเติมที่การใช้งานรองรับจะถูกสื่อสารระหว่างเซิร์ฟเวอร์และไคลเอ็นต์ในระหว่างส่วนการแลกเปลี่ยนความสามารถในการตั้งค่าเซสชัน คุณสมบัติโปรโตคอลที่บังคับจะไม่รวมอยู่ในการแลกเปลี่ยนความสามารถเนื่องจากถือว่ามีอยู่แล้ว RFC 4741 กำหนดความสามารถเสริมจำนวนหนึ่ง รวมถึง : xpathและ :validate โปรดทราบว่าRFC 6241ยกเลิก RFC 4741 แล้ว

ความสามารถในการรองรับการสมัครรับและรับการแจ้งเตือนเหตุการณ์แบบอะซิงโครนัสได้รับการเผยแพร่ใน RFC 5277 เอกสารนี้กำหนดการดำเนินการ <create-subscription> ซึ่งช่วยให้สามารถสร้างการสมัครรับแบบเรียลไทม์และแบบเล่นซ้ำได้ จากนั้นการแจ้งเตือนจะถูกส่งแบบอะซิงโครนัสโดยใช้โครงสร้าง <notification> นอกจากนี้ยังกำหนดความสามารถ :interleave ซึ่งเมื่อได้รับการสนับสนุนร่วมกับความสามารถ :notification พื้นฐาน จะช่วยอำนวยความสะดวกในการประมวลผลการดำเนินการ NETCONF อื่นๆ ในขณะที่การสมัครรับยังคงทำงานอยู่

RFC 5717 ได้กำหนดความสามารถในการล็อกบางส่วนของคอนฟิกที่กำลังทำงานอยู่ ซึ่งช่วยให้หลายเซสชันสามารถแก้ไขซับทรีที่ไม่ทับซ้อนกันภายในคอนฟิกที่กำลังทำงานอยู่ได้ หากไม่มีความสามารถนี้ การล็อกที่มีอยู่จะมีเพียงการล็อกคอนฟิกทั้งหมดเท่านั้น

ความสามารถในการตรวจสอบโปรโตคอล NETCONF ได้รับการกำหนดไว้ใน RFC 6022 เอกสารนี้ประกอบด้วยแบบจำลองข้อมูลซึ่งรวมถึงข้อมูลเกี่ยวกับที่เก็บข้อมูล เซสชัน ล็อก และสถิติของ NETCONF ซึ่งช่วยอำนวยความสะดวกในการจัดการเซิร์ฟเวอร์ NETCONF นอกจากนี้ยังกำหนดวิธีการสำหรับไคลเอ็นต์ NETCONF ในการค้นหาแบบจำลองข้อมูลที่เซิร์ฟเวอร์ NETCONF รองรับ และกำหนดการดำเนินการ <get-schema> เพื่อดึงข้อมูลเหล่านั้น

เลเยอร์ข้อความ NETCONF มีกลไกการจัดเฟรมที่เรียบง่ายและไม่ขึ้นอยู่กับวิธีการส่งข้อมูลสำหรับการเข้ารหัส

• การเรียกใช้ RPC (ข้อความ <rpc>)
• ผลลัพธ์ RPC (ข้อความ <rpc-reply>) และ
• การแจ้งเตือนเหตุการณ์ (ข้อความ <notification>)

ข้อความ NETCONF ทุกข้อความเป็นเอกสาร XML ที่มีรูปแบบถูกต้อง ผลลัพธ์ของ RPC จะเชื่อมโยงกับการเรียกใช้ RPC ด้วยแอตทริบิวต์ message-id ข้อความ NETCONF สามารถส่งต่อได้ กล่าวคือ ไคลเอนต์สามารถเรียกใช้ RPC หลายรายการโดยไม่ต้องรอผลลัพธ์ของ RPC ก่อน ข้อความ RPC ถูกกำหนดไว้ใน RFC 6241 และข้อความแจ้งเตือนถูกกำหนดไว้ใน RFC 5277

• โปรโตคอล NETCONF ผ่านSecure Shell (SSH): rfc:6242
• โปรโตคอล NETCONF ผ่านการรักษาความปลอดภัยระดับชั้นการขนส่ง (TLS) ด้วย การตรวจสอบสิทธิ์ X.509 แบบร่วมกัน : rfc:7589

• หยาง
• เรสต์คอนฟ์
• Stefan Wallin (18 ตุลาคม 2014). NETCONF Tutorial (YouTube). สตอกโฮล์ม: tail-f. เก็บถาวรจากต้นฉบับเมื่อ 21 ธันวาคม 2021
• การจัดการเครือข่าย
• การจัดการการกำหนดค่า
• การตรวจสอบเครือข่าย
• โครงสร้าง XML