5G: SDN IP/MPLS Backbone - Revision history

Onnowpurbo: /* Referensi */

2022-12-09T04:09:06Z

Referensi

Onnowpurbo at 04:04, 9 December 2022

2022-12-09T04:04:24Z

Onnowpurbo at 04:03, 9 December 2022

2022-12-09T04:03:50Z

Onnowpurbo at 03:16, 9 December 2022

2022-12-09T03:16:25Z

Onnowpurbo at 03:13, 9 December 2022

2022-12-09T03:13:23Z

Onnowpurbo at 03:09, 9 December 2022

2022-12-09T03:09:52Z

Onnowpurbo at 06:11, 30 November 2022

2022-11-30T06:11:25Z

Onnowpurbo at 06:07, 30 November 2022

2022-11-30T06:07:38Z

Onnowpurbo: Created page with " ==Referensi== * https://cdn.brandfolder.io/D8DI15S7/at/jh6nnbb6bjvn7w7t5jbgm5n/OpenTransportArchitecture-Whitepaper_TIP_Final.pdf"

2022-11-27T07:03:31Z

Created page with " ==Referensi== * https://cdn.brandfolder.io/D8DI15S7/at/jh6nnbb6bjvn7w7t5jbgm5n/OpenTransportArchitecture-Whitepaper_TIP_Final.pdf"

New page

==Referensi==

* https://cdn.brandfolder.io/D8DI15S7/at/jh6nnbb6bjvn7w7t5jbgm5n/OpenTransportArchitecture-Whitepaper_TIP_Final.pdf

← Older revision		Revision as of 04:09, 9 December 2022
Line 36:		Line 36:

	* https://cdn.brandfolder.io/D8DI15S7/at/jh6nnbb6bjvn7w7t5jbgm5n/OpenTransportArchitecture-Whitepaper_TIP_Final.pdf		* https://cdn.brandfolder.io/D8DI15S7/at/jh6nnbb6bjvn7w7t5jbgm5n/OpenTransportArchitecture-Whitepaper_TIP_Final.pdf
		+
		+
		+	==Pranala Menarik==
		+
		+	* [[5G]]

@@ Line 20: / Line 20: @@
 Tujuan utama dari pendekatan SDN adalah:
-• Agile Network Programmability – Mengaktifkan otomatisasi jaringan penuh dan mengurangi waktu pengenalan layanan ke pasar. Hal ini dicapai melalui strategi penggunaan berorientasi kasus yang dinamis dan dengan standarisasi interface jaringan.
+* Agile Network Programmability – Mengaktifkan otomatisasi jaringan penuh dan mengurangi waktu pengenalan layanan ke pasar. Hal ini dicapai melalui strategi penggunaan berorientasi kasus yang dinamis dan dengan standarisasi interface jaringan.
-• Network Abstraction – Memperkenalkan tingkat abstraksi yang memadai pada setiap lapisan arsitektur (elemen jaringan, pengontrol domain, pengontrol hierarkis), menyederhanakan pengembangan OSS dan orkestra. Tingkat pertama berpindah dari tampilan jaringan dan perangkat khusus vendor ke tampilan teknologi—agnostik dari siapa yang mengimplementasikan fungsi jaringan. Tingkat kedua mengacu pada kasus penggunaan khusus, di mana beberapa perilaku tingkat perangkat disimpulkan secara otomatis oleh mekanisme kontrol SDN. Ini memfasilitasi interaksi antar komponen dan otomatisasi jaringan secara keseluruhan.
+* Network Abstraction – Memperkenalkan tingkat abstraksi yang memadai pada setiap lapisan arsitektur (elemen jaringan, pengontrol domain, pengontrol hierarkis), menyederhanakan pengembangan OSS dan orkestra. Tingkat pertama berpindah dari tampilan jaringan dan perangkat khusus vendor ke tampilan teknologi—agnostik dari siapa yang mengimplementasikan fungsi jaringan. Tingkat kedua mengacu pada kasus penggunaan khusus, di mana beberapa perilaku tingkat perangkat disimpulkan secara otomatis oleh mekanisme kontrol SDN. Ini memfasilitasi interaksi antar komponen dan otomatisasi jaringan secara keseluruhan.
-• Open Transport Network – Mengaktifkan penyebaran perangkat jaringan terbuka di setiap lapisan transport (IP, optik, MW) karena pemasok mengimplementasikan antarmuka konfigurasi yang sama. Antarmuka pengontrol akan didasarkan pada fungsi generik, bukan pada implementasi khusus vendor, sehingga mengurangi penguncian vendor terkait dengan platform manajemen tertutup yang akan digunakan dengan perangkat mereka sendiri.
+* Open Transport Network – Mengaktifkan penyebaran perangkat jaringan terbuka di setiap lapisan transport (IP, optik, MW) karena pemasok mengimplementasikan antarmuka konfigurasi yang sama. Antarmuka pengontrol akan didasarkan pada fungsi generik, bukan pada implementasi khusus vendor, sehingga mengurangi penguncian vendor terkait dengan platform manajemen tertutup yang akan digunakan dengan perangkat mereka sendiri.
-• Network Intelligence – Mengaktifkan traffic engineering (TE) dan penyediaan layanan otomatis antara lapisan dan teknologi vendor.
+* Network Intelligence – Mengaktifkan traffic engineering (TE) dan penyediaan layanan otomatis antara lapisan dan teknologi vendor.

@@ Line 12: / Line 12: @@
 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.
 Selama beberapa tahun terakhir, operator telah bekerja keras dalam penyederhanaan jaringan, yang bertujuan untuk mengurangi kompleksitas, kebutuhan pemeliharaan, dan beban operasional, sekaligus menghasilkan efisiensi ekonomi di wilayah masing-masing. Selangkah lebih maju, SDN bertujuan untuk memenuhi tujuan yang sama dengan mengadvokasi kebutuhan untuk memisahkan bidang data (dengan mengubah sakelar jaringan menjadi perangkat penerusan paket sederhana) dari bidang kontrol (dengan meletakkan komponen perangkat lunak terpusat, juga dikenal sebagai pengontrol SDN, di kontrol seluruh perilaku jaringan).
+Menurut definisi, layanan selalu dianggap sebagai layanan E2E yang dikonsumsi oleh end user dan melibatkan beberapa domain dan sumber daya yang sesuai. Pengelolaan layanan tersebut dicapai pada lapisan orkestrasi OSS/layanan. Sebaliknya, layanan konektivitas transportasi mengacu pada sumber daya yang ditangani oleh domain transportasi (IP/MPLS, optik, gelombang mikro), dan dapat dianggap sebagai bagian dari keseluruhan layanan.
 Tujuan utama dari pendekatan SDN adalah:
-• Programabilitas Jaringan Agile – Mengaktifkan otomatisasi jaringan penuh dan mengurangi waktu pengenalan layanan ke pasar. Hal ini dicapai melalui strategi penggunaan berorientasi kasus yang dinamis dan dengan standarisasi antarmuka jaringan.
+• Agile Network Programmability – Mengaktifkan otomatisasi jaringan penuh dan mengurangi waktu pengenalan layanan ke pasar. Hal ini dicapai melalui strategi penggunaan berorientasi kasus yang dinamis dan dengan standarisasi interface jaringan.
-• Abstraksi Jaringan – Memperkenalkan tingkat abstraksi yang memadai pada setiap lapisan arsitektur (elemen jaringan, pengontrol domain, pengontrol hierarkis), menyederhanakan pengembangan OSSe dan orkestra. Tingkat pertama berpindah dari tampilan jaringan dan perangkat khusus vendor ke tampilan teknologi—agnostik dari siapa yang mengimplementasikan fungsi jaringan. Tingkat kedua mengacu pada kasus penggunaan khusus, di mana beberapa perilaku tingkat perangkat disimpulkan secara otomatis oleh mekanisme kontrol SDN. Ini memfasilitasi interaksi antar komponen dan otomatisasi jaringan secara keseluruhan.
+• Network Abstraction – Memperkenalkan tingkat abstraksi yang memadai pada setiap lapisan arsitektur (elemen jaringan, pengontrol domain, pengontrol hierarkis), menyederhanakan pengembangan OSS dan orkestra. Tingkat pertama berpindah dari tampilan jaringan dan perangkat khusus vendor ke tampilan teknologi—agnostik dari siapa yang mengimplementasikan fungsi jaringan. Tingkat kedua mengacu pada kasus penggunaan khusus, di mana beberapa perilaku tingkat perangkat disimpulkan secara otomatis oleh mekanisme kontrol SDN. Ini memfasilitasi interaksi antar komponen dan otomatisasi jaringan secara keseluruhan.
-• Open Transport Networks – Mengaktifkan penyebaran perangkat jaringan terbuka di setiap lapisan transport (IP, optik, MW) karena pemasok mengimplementasikan antarmuka konfigurasi yang sama. Antarmuka pengontrol akan didasarkan pada fungsi generik, bukan pada implementasi khusus vendor, sehingga mengurangi penguncian vendor terkait dengan platform manajemen tertutup yang akan digunakan dengan perangkat mereka sendiri.
+• Open Transport Network – Mengaktifkan penyebaran perangkat jaringan terbuka di setiap lapisan transport (IP, optik, MW) karena pemasok mengimplementasikan antarmuka konfigurasi yang sama. Antarmuka pengontrol akan didasarkan pada fungsi generik, bukan pada implementasi khusus vendor, sehingga mengurangi penguncian vendor terkait dengan platform manajemen tertutup yang akan digunakan dengan perangkat mereka sendiri.
-• Intelijen Jaringan – Mengaktifkan rekayasa lalu lintas (TE) dan penyediaan layanan otomatis antara lapisan dan teknologi vendor.
+• Network Intelligence – Mengaktifkan traffic engineering (TE) dan penyediaan layanan otomatis antara lapisan dan teknologi vendor.

@@ Line 20: / Line 20: @@
 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.
@@ Line 35: / Line 49: @@

← Older revision		Revision as of 03:13, 9 December 2022
Line 7:		Line 7:
	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.		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 ~~kasus penggunaan~~ 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 ~~antarmuka utara~~ (NBI) akan bergantung pada definisi kasus penggunaan dan teknologi yang dipertimbangkan.	+	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.
−
−
−	Based on common use cases defined by the operators, the set of standard SDN interfaces are selected and detailed to produce a common industry specification. The presented SDN architecture enables other systems in charge of planning, inventory, NFV orchestration, service orchestration, performance, or fault management to retrieve information and program the network with well-known, vendor-agnostic interfaces. The SDN controllers will enable resource configuration. The resource abstraction level exposed in the northbound interface (NBI) will depend on the use case definition and the technology considered.
−
−
−
−
−
−
−
−
−
−	Over the past few years all the telecommunications industry actors, including vendors, network service providers, standardization bodies (e.g., IETF, GSMA), and industry fora (e.g., ONF, OIF, OpenConfig, TMForum) have been working toward the habilitation of automatic network control and programmability. Many efforts have been made to make software defined networking (SDN) a reality, hence a large number of architectural frameworks have been proposed. It’s now time to define a common strategy to reduce and select the most suitable standards to unify disparate SDN solutions.
−
−	A worldwide, top-ranked network operators group—formed by Telefonica, Vodafone, MTN, Telia Company, DeutscheTelekom, and Orange—has joined efforts to collaborate on open transport SDN within the Telecom Infra Project’s Open Optical and Packet Transport (OOPT) project group. They’ll be leading a new workstream called MUST (Mandatory Use case requirements for SDN for Transport). This white paper presents its common architectural view, the use casebased methodology, and the selection of the most relevant standard interfaces to be implemented by the industry.
−
−	The target reference architecture for the transport SDN controllers is hierarchical, with specific domain controllers per technological domain (IP/MPLS, microwave, optical) and a hierarchical controller to provide real-time control of multi-layer and multi-domain transport network resources. The operation support systems (OSS)—including service orchestration and service and resource inventory—will be consuming a set of APIs exposed by the controllers to handle the data and configurations toward end users and enabling service
−	~~fulfillment.~~
−
−	Based on common use cases defined by the operators, the set of standard SDN interfaces are selected and detailed to produce a common industry specification. The presented SDN architecture enables other systems in charge of planning, inventory, NFV orchestration, service orchestration, performance, or fault management to retrieve information and program the network with well-known, vendor-agnostic interfaces. The SDN controllers will enable resource configuration. The resource abstraction level exposed in the northbound interface (NBI) will depend on the use case definition and the technology considered.
−
−
−
−	Implementing a complete standard specification is a time-consuming process. To accelerate adoption, the operators have compiled the needs of multiple operations, engineering, and planning teams, and have selected the most relevant common use cases. Based on this, technical requirements are prepared and shared with the vendors. These specifications will be incorporated as part of future RFQ processes, which will facilitate a gradual implementation of the defined standards according to a given use case prioritization plan.
−
−
−	To achieve the open programmable transport networks goal, operators will require solution suppliers (both hardware and software—including network operating system and controller software) to include the selected standard interfaces in their commercial product releases, reducing the need for ad hoc development during solution deployment phase.
−
−	The operators signing this whitepaper encourage others to join and contribute toward defining and accelerating standardization and implementation of the required SDN interfaces and use cases needed for our transport networks.

		+	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.

@@ Line 1: / Line 1: @@
 [[File:SDN-ip-mpls.png|center|400px|thumb|Open transport SDN architecture vision]]
-Over the past few years all the telecommunications industry actors, including vendors, network service providers, standardization bodies (e.g., IETF, GSMA), and industry fora (e.g., ONF, OIF, OpenConfig, TMForum) have been working toward the habilitation of automatic network control and programmability. Many efforts have been made to make software defined networking (SDN) a reality, hence a large number of architectural frameworks have been proposed. It’s now time to define a common strategy to reduce and select the most suitable
+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.
-A worldwide, top-ranked network operators group—formed by Telefonica, Vodafone, MTN, Telia Company, DeutscheTelekom, and Orange—has joined efforts to collaborate on open transport SDN within the Telecom Infra Project’s Open Optical and Packet Transport (OOPT) project group. They’ll be leading a new workstream called MUST (Mandatory Use case requirements for SDN for Transport). This white paper presents its common architectural view, the use casebased methodology, and the selection of the most relevant standard interfaces to be
+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.
-implemented by the industry.
 Based on common use cases defined by the operators, the set of standard SDN interfaces are selected and detailed to produce a common industry specification. The presented SDN architecture enables other systems in charge of planning, inventory, NFV orchestration, service orchestration, performance, or fault management to retrieve information and program the network with well-known, vendor-agnostic interfaces. The SDN controllers will enable resource configuration. The resource abstraction level exposed in the northbound interface (NBI) will depend on the use case definition and the technology considered.
@@ Line 20: / Line 20: @@
-Over the past few years all the telecommunications industry actors, including vendors, network service providers, standardization bodies (e.g., IETF, GSMA), and industry fora (e.g., ONF, OIF, OpenConfig, TMForum) have been working toward the habilitation of automatic network control and programmability. Many efforts have been made to make software defined networking (SDN) a reality, hence a large number of architectural frameworks have been proposed. It’s now time to define a common strategy to reduce and select the most suitable
+Over the past few years all the telecommunications industry actors, including vendors, network service providers, standardization bodies (e.g., IETF, GSMA), and industry fora (e.g., ONF, OIF, OpenConfig, TMForum) have been working toward the habilitation of automatic network control and programmability. Many efforts have been made to make software defined networking (SDN) a reality, hence a large number of architectural frameworks have been proposed. It’s now time to define a common strategy to reduce and select the most suitable standards to unify disparate SDN solutions.
-A worldwide, top-ranked network operators group—formed by Telefonica, Vodafone, MTN, Telia Company, DeutscheTelekom, and Orange—has joined efforts to collaborate on open transport SDN within the Telecom Infra Project’s Open Optical and Packet Transport (OOPT) project group. They’ll be leading a new workstream called MUST (Mandatory Use case requirements for SDN for Transport). This white paper presents its common architectural view, the use casebased methodology, and the selection of the most relevant standard interfaces to be
+A worldwide, top-ranked network operators group—formed by Telefonica, Vodafone, MTN, Telia Company, DeutscheTelekom, and Orange—has joined efforts to collaborate on open transport SDN within the Telecom Infra Project’s Open Optical and Packet Transport (OOPT) project group. They’ll be leading a new workstream called MUST (Mandatory Use case requirements for SDN for Transport). This white paper presents its common architectural view, the use casebased methodology, and the selection of the most relevant standard interfaces to be implemented by the industry.
 The target reference architecture for the transport SDN controllers is hierarchical, with specific domain controllers per technological domain (IP/MPLS, microwave, optical) and a hierarchical controller to provide real-time control of multi-layer and multi-domain transport network resources. The operation support systems (OSS)—including service orchestration and service and resource inventory—will be consuming a set of APIs exposed by the controllers to handle the data and configurations toward end users and enabling service

← Older revision		Revision as of 06:11, 30 November 2022
Line 40:		Line 40:
	The operators signing this whitepaper encourage others to join and contribute toward defining and accelerating standardization and implementation of the required SDN interfaces and use cases needed for our transport networks.		The operators signing this whitepaper encourage others to join and contribute toward defining and accelerating standardization and implementation of the required SDN interfaces and use cases needed for our transport networks.

		+
		+
		+
		+
		+
		+
		+
		+	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.

← Older revision	Revision as of 06:07, 30 November 2022
Line 1:	Line 1:
	+	[[File:SDN-ip-mpls.png\|center\|400px\|thumb\|Open transport SDN architecture vision]]
	+
	+	Over the past few years all the telecommunications industry actors, including vendors, network service providers, standardization bodies (e.g., IETF, GSMA), and industry fora (e.g., ONF, OIF, OpenConfig, TMForum) have been working toward the habilitation of automatic network control and programmability. Many efforts have been made to make software defined networking (SDN) a reality, hence a large number of architectural frameworks have been proposed. It’s now time to define a common strategy to reduce and select the most suitable
	+	standards to unify disparate SDN solutions.
	+
	+	A worldwide, top-ranked network operators group—formed by Telefonica, Vodafone, MTN, Telia Company, DeutscheTelekom, and Orange—has joined efforts to collaborate on open transport SDN within the Telecom Infra Project’s Open Optical and Packet Transport (OOPT) project group. They’ll be leading a new workstream called MUST (Mandatory Use case requirements for SDN for Transport). This white paper presents its common architectural view, the use casebased methodology, and the selection of the most relevant standard interfaces to be
	+	implemented by the industry.
	+
	+	The target reference architecture for the transport SDN controllers is hierarchical, with specific domain controllers per technological domain (IP/MPLS, microwave, optical) and a hierarchical controller to provide real-time control of multi-layer and multi-domain transport network resources. The operation support systems (OSS)—including service orchestration and service and resource inventory—will be consuming a set of APIs exposed by the controllers to handle the data and configurations toward end users and enabling service
	+	fulfillment.
	+
	+	Based on common use cases defined by the operators, the set of standard SDN interfaces are selected and detailed to produce a common industry specification. The presented SDN architecture enables other systems in charge of planning, inventory, NFV orchestration, service orchestration, performance, or fault management to retrieve information and program the network with well-known, vendor-agnostic interfaces. The SDN controllers will enable resource configuration. The resource abstraction level exposed in the northbound interface (NBI) will depend on the use case definition and the technology considered.
	+
	+
	+
	+
	+
	+
	+
	+
	+
	+	Over the past few years all the telecommunications industry actors, including vendors, network service providers, standardization bodies (e.g., IETF, GSMA), and industry fora (e.g., ONF, OIF, OpenConfig, TMForum) have been working toward the habilitation of automatic network control and programmability. Many efforts have been made to make software defined networking (SDN) a reality, hence a large number of architectural frameworks have been proposed. It’s now time to define a common strategy to reduce and select the most suitable
	+	standards to unify disparate SDN solutions.
	+
	+	A worldwide, top-ranked network operators group—formed by Telefonica, Vodafone, MTN, Telia Company, DeutscheTelekom, and Orange—has joined efforts to collaborate on open transport SDN within the Telecom Infra Project’s Open Optical and Packet Transport (OOPT) project group. They’ll be leading a new workstream called MUST (Mandatory Use case requirements for SDN for Transport). This white paper presents its common architectural view, the use casebased methodology, and the selection of the most relevant standard interfaces to be
	+	implemented by the industry.
	+
	+	The target reference architecture for the transport SDN controllers is hierarchical, with specific domain controllers per technological domain (IP/MPLS, microwave, optical) and a hierarchical controller to provide real-time control of multi-layer and multi-domain transport network resources. The operation support systems (OSS)—including service orchestration and service and resource inventory—will be consuming a set of APIs exposed by the controllers to handle the data and configurations toward end users and enabling service
	+	fulfillment.
	+
	+	Based on common use cases defined by the operators, the set of standard SDN interfaces are selected and detailed to produce a common industry specification. The presented SDN architecture enables other systems in charge of planning, inventory, NFV orchestration, service orchestration, performance, or fault management to retrieve information and program the network with well-known, vendor-agnostic interfaces. The SDN controllers will enable resource configuration. The resource abstraction level exposed in the northbound interface (NBI) will depend on the use case definition and the technology considered.
	+
	+
	+
	+	Implementing a complete standard specification is a time-consuming process. To accelerate adoption, the operators have compiled the needs of multiple operations, engineering, and planning teams, and have selected the most relevant common use cases. Based on this, technical requirements are prepared and shared with the vendors. These specifications will be incorporated as part of future RFQ processes, which will facilitate a gradual implementation of the defined standards according to a given use case prioritization plan.
	+
	+
	+	To achieve the open programmable transport networks goal, operators will require solution suppliers (both hardware and software—including network operating system and controller software) to include the selected standard interfaces in their commercial product releases, reducing the need for ad hoc development during solution deployment phase.
	+
	+	The operators signing this whitepaper encourage others to join and contribute toward defining and accelerating standardization and implementation of the required SDN interfaces and use cases needed for our transport networks.
	+
	+
	+
	+
	+
	+
	+
	+
	+