5G: SDN IP/MPLS Backbone
Selama beberapa tahun terakhir, semua pelaku industri telekomunikasi, termasuk vendor, penyedia layanan jaringan, badan standardisasi (mis., IETF, GSMA), dan forum industri (mis., ONF, OIF, OpenConfig, TMForum) telah bekerja menuju habilitasi otomatis kontrol jaringan dan programabilitas. Banyak upaya telah dilakukan untuk membuat software defined networking (SDN) menjadi kenyataan, oleh karena itu sejumlah besar kerangka kerja arsitektur telah diusulkan. Sekarang saatnya menentukan strategi umum untuk mengurangi dan memilih standar yang paling cocok untuk menyatukan solusi SDN yang berbeda.
Grup operator jaringan peringkat teratas di seluruh dunia—dibentuk oleh Telefonica, Vodafone, MTN, Telia Company, DeutscheTelekom, dan Orange—telah bergabung dalam upaya untuk berkolaborasi dalam SDN transportasi terbuka dalam grup proyek Telecom Infra Project's Open Optical and Packet Transport (OOPT) . Mereka akan memimpin alur kerja baru yang disebut HARUS (Persyaratan Kasus Penggunaan Wajib untuk SDN untuk Transportasi). Buku putih ini menyajikan tampilan arsitektur umumnya, metodologi berbasis kasus penggunaan, dan pemilihan antarmuka standar yang paling relevan untuk diterapkan oleh industri.
Arsitektur referensi target untuk pengontrol SDN transportasi bersifat hierarkis, dengan pengontrol domain spesifik per domain teknologi (IP/MPLS, microwave, optik) dan pengontrol hierarkis untuk menyediakan kontrol real-time dari sumber daya jaringan transportasi multi-lapisan dan multi-domain. Operation support system (OSS)—termasuk orkestrasi layanan dan inventaris layanan dan sumber daya—akan menggunakan sekumpulan API yang diekspos oleh pengontrol untuk menangani data dan konfigurasi ke end user dan memungkinkan pemenuhan layanan.
Berdasarkan use case umum yang ditentukan oleh operator, rangkaian interface SDN standar dipilih dan dirinci untuk menghasilkan spesifikasi industri yang umum. Arsitektur SDN yang disajikan memungkinkan sistem lain yang bertanggung jawab atas perencanaan, inventaris, orkestrasi NFV, orkestrasi layanan, kinerja, atau manajemen kesalahan untuk mengambil informasi dan memprogram jaringan dengan interface vendor-agnostik yang terkenal. Pengontrol SDN akan mengaktifkan konfigurasi sumber daya. Tingkat abstraksi sumber daya yang diekspos di northbound interface (NBI) akan bergantung pada definisi kasus penggunaan dan teknologi yang dipertimbangkan.
Menerapkan spesifikasi standar yang lengkap adalah proses yang memakan waktu. Untuk mempercepat adopsi, operator telah menyusun kebutuhan berbagai tim operasi, teknik, dan perencanaan, dan telah memilih use case umum yang paling relevan. Berdasarkan ini, persyaratan teknis disiapkan dan dibagikan dengan vendor. Spesifikasi ini akan digabungkan sebagai bagian dari proses RFQ di masa mendatang, yang akan memfasilitasi implementasi bertahap dari standar yang ditetapkan sesuai dengan rencana prioritas kasus penggunaan tertentu.
Untuk mencapai tujuan jaringan transportasi terbuka yang dapat diprogram, operator akan meminta pemasok solusi (baik perangkat keras maupun perangkat lunak—termasuk sistem operasi jaringan dan perangkat lunak pengontrol) untuk menyertakan antarmuka standar yang dipilih dalam rilis produk komersial mereka, sehingga mengurangi kebutuhan pengembangan ad hoc selama penyebaran solusi fase.
Operator yang menandatangani whitepaper ini mendorong orang lain untuk bergabung dan berkontribusi dalam menentukan dan mempercepat standardisasi dan implementasi antarmuka SDN yang diperlukan dan kasus penggunaan yang diperlukan untuk jaringan transportasi kami.
This document summarizes the open transport SDN strategy with respect to the SDN, together with objectives and activities roadmap needed to accomplish the goal of a full automated IP/optical transport network. This document will not cover technical details associated with SDN [SDN1] and assumes the reader is familiar with the basic concepts.
Over the last few years operators have worked hard on network simplification, aiming to reduce complexity, maintenance needs, and operational burden, while simultaneously producing economic efficiencies within the respective areas. One step ahead, SDN aims to fulfill the same goals by advocating the need to separate the data plane (by transforming network switches to simple packet forwarding devices) from the control plane (by putting a centralized software component, also known as SDN controller, in control of entire network behavior).
It’s not foreseen that a complete separation or decoupling of the control plane is required to benefit from the high survivability of networks against failures, disaster recovery, et al. The more practical approach is to enhance network programmability through a hybrid, hierarchical SDN architecture, in which management and control functionalities are split between devices and a set of controllers.
By way of definition, service is always considered as the E2E service consumed by an end user and involves several domains and corresponding resources. Management of such services is achieved at the OSS/service orchestration layer. By contrast, the transport connectivity service refers to resources handled by the transport domain (IP/MPLS, optical, microwave), and can be considered as a part of the overall service.
The main goals of the SDN approach are:
• Agile Network Programmability – Enabling full network automation and reducing time-to-market of service introduction. This is achieved through a dynamic use caseoriented strategy and by standardizing network interfaces.
• Network Abstraction – Introducing the adequate level of abstraction at each layer of the architecture (network elements, domain controllers, hierarchical controller), simplifying the development of the OSSes and orchestrators. The first level is moving from a vendor-specific view of networks and devices to a technological one—agnostic from who is implementing the network function. The second level refers to specific use cases, where some device-level behavior is automatically inferred by the SDN control mechanisms. This facilitates interactions among components and therefore overall network automation.
• Open Transport Networks – Enabling deployment of open network devices at any transport layer (IP, optical, MW) as suppliers implement the same configuration interface. Controller interfaces will be based on generic functions, not on vendorspecific implementations, thereby reducing the vendor lock-in associated with closed management platforms that were to be used with their own devices.
• Network Intelligence – Enabling traffic engineering (TE) and automated service provisioning between layers and vendor technologies.