SDSM-15. Tentang QoS. Sekarang dengan kemungkinan permintaan tarik .

Jadi kita sampai pada topik QoS.

Apakah Anda tahu mengapa hanya sekarang dan mengapa itu akan menjadi artikel penutup dari seluruh kursus SDSM? Karena QoS sangat kompleks. Hal tersulit yang ada sebelumnya dalam siklus.

Ini bukan semacam pengarsip ajaib yang secara cerdik memadatkan lalu lintas dengan cepat dan mendorong gigabit Anda menjadi uplink seratus megabit. QoS adalah tentang bagaimana mengorbankan sesuatu yang tidak perlu, mendorong yang tak termakan ke dalam kerangka kerja yang diizinkan.

QoS sangat terjerat dengan aura perdukunan dan tidak dapat diaksesnya sehingga semua insinyur muda (dan tidak hanya) mencoba untuk mengabaikan keberadaannya dengan hati-hati, percaya bahwa itu cukup untuk menimbulkan masalah dengan uang, dan memperluas hubungan tanpa akhir. Benar, sampai mereka menyadari bahwa dengan pendekatan ini, kegagalan pasti akan menunggu mereka. Entah bisnis akan mulai mengajukan pertanyaan tidak nyaman, atau akan ada banyak masalah yang hampir tidak berhubungan dengan lebar saluran, tetapi langsung bergantung pada efisiensi penggunaannya. Ya, VoIP secara aktif melambaikan pena dari belakang layar, dan lalu lintas multicast membelai Anda dari belakang.

Karena itu, mari kita sadari bahwa QoS adalah wajib, Anda harus mengetahuinya dengan satu atau lain cara, dan untuk beberapa alasan, jangan mulai sekarang, dalam suasana yang santai.

---

Isi

1. Apa yang menentukan QoS?

• Kerugian
• Keterlambatan
• Jitter

2. Tiga model QoS

• Efek terbaik
• Layanan terpadu
• Layanan berbeda

3. Mekanisme DiffServ

4. Klasifikasi dan pelabelan

• Agregasi perilaku
• Multi-bidang
• Berbasis antarmuka

5. Antrian

6. Menghindari Kemacetan

• Jatuhkan Ekor dan Jatuhkan Kepala
• Merah
• Wred

7. Manajemen Kemacetan

• Pertama masuk, keluar pertama
• Antrian prioritas
• Antrian yang adil
• Round robin

8. Batas kecepatan

• Membentuk
• Pemolisian
• Bucket Leaky dan Token Bucket

9. Implementasi perangkat keras QoS

---

Sebelum pembaca masuk ke dalam lubang ini, saya akan meletakkan tiga pengaturan di dalamnya:

• Tidak semua masalah bisa diselesaikan dengan memperluas band.
• QoS tidak memperluas band.
• QoS tentang mengelola sumber daya terbatas.

1. Apa yang menentukan QoS?

Bisnis mengharapkan tumpukan jaringan untuk melakukan fungsi sederhana dengan baik - untuk mengirimkan bitstream dari satu host ke yang lain: lossless dan dalam waktu yang dapat diprediksi.

Dari kalimat singkat ini, semua metrik kualitas jaringan dapat diturunkan:

• Kerugian
• Keterlambatan
• Jitter

Ketiga karakteristik ini menentukan kualitas jaringan terlepas dari sifatnya: paket, saluran, IP, MPLS, radio, merpati .

Kerugian

Metrik ini memberi tahu Anda berapa banyak paket yang dikirim oleh sumber mencapai tujuan.
Penyebab hilangnya mungkin masalah di antarmuka / kabel, kemacetan jaringan, kesalahan bit yang memblokir aturan ACL.

Apa yang harus dilakukan jika kehilangan ditentukan oleh aplikasi. Itu dapat mengabaikan mereka, seperti dalam kasus percakapan telepon, di mana paket terlambat tidak lagi diperlukan, atau mengirim kembali - ini adalah apa yang dilakukan TCP untuk memastikan pengiriman data sumber yang akurat.



Bagaimana mengelola kerugian, jika mereka tidak terhindarkan, dalam bab Manajemen Kemacetan.

Cara memanfaatkan kerugian di bab Pencegahan Kemacetan.

Keterlambatan

Ini adalah waktu yang dibutuhkan data dari sumber ke tujuan.



Penundaan kumulatif terdiri dari komponen-komponen berikut.

• Serialization Delay - waktu yang diperlukan suatu simpul untuk menguraikan paket menjadi bit dan memasukkan tautan ke simpul berikutnya. Ini ditentukan oleh kecepatan antarmuka. Jadi, misalnya, mentransfer paket berukuran 1500 byte melalui antarmuka 100 Mb / s akan membutuhkan 0,0001 dtk, dan untuk 56 Kb / dt - 0,2 dt.
• Propagation Delay adalah hasil dari keterbatasan kecepatan rambat gelombang elektromagnetik yang terkenal. Fisika tidak memungkinkan Anda untuk pergi dari New York ke Tomsk di permukaan planet lebih cepat daripada dalam 30 ms (pada kenyataannya, sekitar 70 ms).
• Penundaan yang diperkenalkan oleh QoS adalah mendekamnya paket dalam antrian ( Antrian Delay ) dan konsekuensi dari pembentukan ( Shaping Delay ). Kita akan banyak membicarakan hal ini hari ini di bab Kontrol kecepatan.
• Keterlambatan dalam pemrosesan paket ( Processing Delay ) - waktu untuk memutuskan apa yang harus dilakukan dengan paket: lookup, ACL, NAT, DPI - dan mengirimkannya dari antarmuka input ke output. Tetapi pada hari Juniper memisahkan Control dan Data Plane dalam M40-nya, penundaan pemrosesan bisa diabaikan.

Penundaan tidak terlalu buruk untuk aplikasi yang tidak perlu terburu-buru: berbagi file, berselancar, VoD, stasiun radio Internet, dll. Sebaliknya, mereka sangat penting untuk yang interaktif: 200ms sudah tidak enak didengar selama percakapan telepon.

Istilah terkait penundaan yang tidak identik dengan RTT ( Round Trip Time ) adalah round trip. Saat melakukan ping dan tracing, Anda melihat persis RTT, dan bukan penundaan satu arah, meskipun nilainya memiliki korelasi.

Jitter

Perbedaan penundaan antara pengiriman paket berurutan disebut jitter.



Seperti latensi, jitter tidak masalah untuk banyak aplikasi. Dan bahkan, tampaknya, apa bedanya - paket telah dikirimkan, jadi apa lagi?

Namun, untuk layanan interaktif itu penting.

Ambil contoh telepon yang sama. Bahkan, ini adalah digitalisasi sinyal analog dengan divisi menjadi potongan data terpisah. Outputnya adalah aliran paket yang cukup seragam. Di sisi penerima ada penyangga kecil ukuran tetap ke mana paket-paket tiba secara berurutan sesuai. Untuk mengembalikan sinyal analog, sejumlah tertentu diperlukan. Dalam kondisi penundaan mengambang, potongan data berikutnya mungkin tidak tiba tepat waktu, yang setara dengan kerugian, dan sinyal tidak dapat dipulihkan.

Kontribusi terbesar untuk menunda variabilitas dibuat oleh QoS saja. Ini juga banyak dan menjemukan di Batas Kecepatan bab yang sama.

---

Ini adalah tiga karakteristik utama kualitas jaringan, tetapi ada dua karakteristik lain yang juga memainkan peran penting.

Pengiriman acak

Sejumlah aplikasi, seperti telepon, NAS , CES, sangat sensitif terhadap pengiriman paket acak ketika mereka tiba di penerima dalam urutan yang salah di mana mereka dikirim. Ini dapat menyebabkan hilangnya konektivitas, kesalahan, kerusakan pada sistem file.

Meskipun pengiriman acak bukan fitur QoS formal, itu pasti merujuk pada kualitas jaringan.

Bahkan dengan toleran TCP terhadap masalah seperti ini, ACK duplikat dan transmisi ulang terjadi.

Bandwidth

Itu tidak dibedakan sebagai metrik kualitas jaringan, karena pada kenyataannya kerugiannya menghasilkan tiga di atas. Namun, dalam kenyataan kami, ketika harus dijamin untuk beberapa aplikasi atau, sebaliknya, harus dibatasi oleh kontrak, misalnya, MPLS TE menyimpannya di seluruh LSP, perlu disebutkan, setidaknya sebagai metrik yang lemah.
Mekanisme kontrol kecepatan akan dibahas dalam bab Batas Kecepatan.

---

Mengapa spesifikasi bisa menjadi buruk?

Jadi, kita mulai dengan ide yang sangat primitif bahwa perangkat jaringan (apakah itu switch, router, firewall, apa pun) hanyalah sepotong pipa yang disebut saluran komunikasi, sama seperti kawat tembaga atau kabel optik.



Kemudian semua paket terbang dalam urutan yang sama di mana mereka tiba dan tidak mengalami penundaan tambahan - tidak ada tempat untuk berlama-lama.

Namun pada kenyataannya, setiap router mengembalikan bit dan paket dari sinyal, melakukan sesuatu dengan mereka (kami belum memikirkannya) dan kemudian mengubah paket kembali menjadi sinyal.

Penundaan serialisasi muncul. Tetapi secara umum, ini tidak menakutkan karena konstan. Tidak menakutkan selama lebar antarmuka output lebih besar dari input.

Misalnya, di pintu masuk ke perangkat adalah port gigabit, dan pada outputnya adalah 620 Mb / s jalur radio relay yang terhubung ke port gigabit yang sama?

Tidak ada yang akan melarang peluru melalui lalu lintas gigabit tautan formal gigabit.
Tidak ada yang bisa dilakukan - 380 Mb / s akan tumpah ke lantai.

Inilah mereka - kerugian.

Tetapi pada saat yang sama, saya sangat menginginkan bagian terburuk yang ditumpahkan - video dari youtube, dan percakapan telepon direktur eksekutif dengan direktur pabrik tidak mengganggu atau bahkan parau.

Saya ingin suara memiliki saluran khusus.

Atau ada lima antarmuka input, tetapi satu output, dan pada saat yang sama lima node mulai mencoba menyuntikkan lalu lintas ke satu penerima.

Tambahkan sejumput teori VoIP (sebuah artikel yang tidak ada yang menulis tentang) - sangat sensitif terhadap penundaan dan variasinya.

Jika untuk aliran video TCP dari youtube (pada saat penulisan artikel QUIC - itu masih tetap sebuah eksperimen) penundaan bahkan dalam hitungan detik sama sekali tidak berharga karena buffering, maka direktur setelah percakapan pertama dengan Kamchatka akan memanggil kepala departemen teknis.
Di masa lalu, ketika penulis siklus masih mengerjakan pekerjaan rumahnya di malam hari, masalahnya sangat akut. Koneksi modem memiliki kecepatan 56k .

Dan ketika paket 1.5K masuk ke koneksi seperti itu, ia menempati seluruh baris selama 200 ms. Tidak ada orang lain yang bisa lulus saat ini. Sebuah suara? Tidak, saya belum pernah mendengar.

Oleh karena itu, pertanyaan MTU sangat penting - paket tidak boleh menempati antarmuka terlalu lama. Semakin sedikit kecepatan, semakin rendah MTU yang dibutuhkan.

Inilah mereka - penundaan.

Sekarang salurannya gratis dan penundaannya rendah, setelah sedetik seseorang mulai mengunduh file besar dan penundaan bertambah. Ini dia - jitter.

Dengan demikian, perlu bahwa paket suara terbang melalui pipa dengan penundaan minimal, dan youtube akan menunggu.

Tersedia 620 Mb / s harus digunakan untuk suara, dan untuk video, dan untuk klien B2B yang membeli VPN. Saya ingin satu lalu lintas tidak menindas yang lain, jadi kami membutuhkan jaminan band.

---

Semua karakteristik di atas bersifat universal mengenai sifat jaringan. Namun, ada tiga pendekatan berbeda untuk ketentuan mereka.

2. Tiga model QoS

• Upaya Terbaik - tidak ada jaminan kualitas. Semuanya sama.
• IntServ adalah jaminan kualitas untuk setiap aliran. Cadangan sumber daya dari sumber ke tujuan.
• DiffServ - Tidak ada reservasi. Setiap node itu sendiri menentukan cara memastikan kualitas yang tepat.

Upaya Terbaik (BE)

Tidak ada jaminan

Pendekatan paling sederhana untuk menerapkan QoS, dari mana jaringan IP dimulai dan masih dipraktikkan sampai hari ini - kadang-kadang karena itu sudah cukup, tetapi lebih sering karena tidak ada yang memikirkan QoS.

Omong-omong, ketika Anda mengirim lalu lintas ke Internet, itu akan diproses di sana sebagai BestEffort. Oleh karena itu, melalui VPN yang digulirkan ke Internet (tidak seperti VPN yang disediakan oleh penyedia), lalu lintas penting, seperti percakapan telepon, mungkin tidak terlalu percaya diri.

Dalam kasus BE, semua kategori lalu lintas sama, tidak ada preferensi yang diberikan kepada siapa pun. Dengan demikian, tidak ada jaminan keterlambatan / jitter atau band.

Pendekatan ini memiliki nama yang agak berlawanan dengan intuisi - Upaya Terbaik, yang disalahartikan oleh pendatang baru dengan kata "terbaik."

Namun, frasa "Saya akan melakukan yang terbaik" berarti bahwa pembicara akan berusaha melakukan apa saja yang bisa, tetapi tidak menjamin apa pun.

Tidak ada yang diperlukan untuk mengimplementasikan BE - ini adalah perilaku default. Murah untuk diproduksi, staf tidak perlu pengetahuan khusus yang mendalam, QoS dalam hal ini tidak dapat disesuaikan.

Namun, kesederhanaan dan statis ini tidak mengarah pada fakta bahwa pendekatan Upaya Terbaik tidak digunakan di mana pun. Ia menemukan aplikasi dalam jaringan dengan bandwidth tinggi dan tidak adanya kemacetan dan semburan.

Misalnya, di jalur lintas benua atau di jaringan beberapa pusat data di mana tidak ada kelebihan langganan.
Dengan kata lain, dalam jaringan tanpa kemacetan dan di mana tidak perlu berhubungan dengan lalu lintas apa pun (misalnya, telepon) dengan cara khusus, BE cukup tepat.

Interv

Pemesanan awal sumber daya untuk aliran dari sumber ke tujuan.

Ayah dari jaringan MIT, Xerox, dan ISI memutuskan untuk menambahkan elemen prediktabilitas ke Internet sembarangan yang tumbuh, sambil mempertahankan operabilitas dan fleksibilitasnya.

Jadi pada tahun 1994, gagasan IntServ lahir sebagai tanggapan terhadap pertumbuhan lalu lintas waktu-nyata yang cepat dan pengembangan multicast. Itu kemudian direduksi menjadi IS.

Nama tersebut mencerminkan keinginan dalam jaringan yang sama untuk secara bersamaan menyediakan layanan untuk jenis lalu lintas waktu-nyata dan non-waktu-nyata, memberikan hak prioritas pertama untuk menggunakan sumber daya melalui pemesanan pita. Kemampuan untuk menggunakan kembali band tempat semua orang menghasilkan uang, dan berkat IP shot, dipertahankan.

Misi cadangan ditugaskan ke protokol RSVP, yang untuk setiap aliran cadangan pita di setiap perangkat jaringan.

Secara kasar, sebelum mengatur sesi Single Color Three Color MarkerP atau memulai pertukaran data, host akhir mengirim Jalur RSVP dengan bandwidth yang diperlukan. Dan jika keduanya mengembalikan RSVP Resv - mereka dapat mulai berkomunikasi. Pada saat yang sama, jika tidak ada sumber daya yang tersedia, maka RSVP mengembalikan kesalahan dan host tidak dapat berkomunikasi atau mengikuti BE.

Biarkan sekarang para pembaca yang paling berani membayangkan bahwa suatu saluran akan diberi sinyal terlebih dahulu untuk aliran apa pun di Internet saat ini. Menimbang bahwa ini memerlukan CPU dan biaya memori yang tidak nol pada setiap node transit, menunda interaksi sebenarnya untuk beberapa waktu, menjadi jelas mengapa IntServ ternyata merupakan ide lahir mati yang sebenarnya - skalabilitas nol.

Dalam arti tertentu, inkarnasi modern IntServ adalah MPLS TE dengan versi pelabelan teradaptasi dari RSVP - RSVP TE. Meskipun di sini, tentu saja, tidak End-to-End dan tidak per-aliran.

IntServ dijelaskan dalam RFC 1633 .
Dokumen ini, pada prinsipnya, penasaran untuk mengevaluasi seberapa naifnya perkiraan Anda.

Diffserv

DiffServ rumit.

Ketika menjadi jelas di akhir tahun 90-an bahwa pendekatan IP IntServ End-to-End gagal, IETF mengadakan kelompok kerja Layanan Diferensial pada tahun 1997, yang mengembangkan persyaratan berikut untuk model QoS baru:

• Tidak ada pensinyalan (Adjos, RSVP!).
• Berdasarkan klasifikasi lalu lintas agregat, alih-alih berfokus pada arus, pelanggan, dll.
• Ini memiliki seperangkat tindakan terbatas dan deterministik untuk memproses lalu lintas data kelas.

Sebagai hasilnya, tengara RFC 2474 ( Definisi Bidang Layanan Diferensial (Bidang DS) di Header IPv4 dan IPv6 ) dan RFC 2475 ( Arsitektur untuk Layanan Berbeda ) lahir pada tahun 1998.

Dan lebih jauh lagi, kita hanya akan berbicara tentang DiffServ.

Perlu dicatat bahwa nama DiffServ bukan antitesis dari IntServ. Ini mencerminkan bahwa kami membedakan layanan yang disediakan oleh berbagai aplikasi, atau lebih tepatnya lalu lintasnya, dengan kata lain, kami membagikan / membedakan jenis lalu lintas ini.
IntServ melakukan hal yang sama - ia membedakan antara jenis lalu lintas BE dan Real-Time, yang dikirimkan pada jaringan yang sama. Baik: dan IntServ dan DiffServ - merujuk pada cara membedakan layanan.

---

3. Mekanisme DiffServ

Apa itu DiffServ dan mengapa itu mengalahkan IntServ?

Jika sangat sederhana, lalu lintas dibagi menjadi beberapa kelas. Paket di pintu masuk ke setiap node diklasifikasikan dan seperangkat alat diterapkan untuk itu, yang memproses paket dari kelas yang berbeda dengan cara yang berbeda, sehingga memberikan mereka dengan tingkat layanan yang berbeda.

Tapi itu tidak akan terjadi .

Inti dari DiffServ adalah konsep IP IP PHB yang dibumbui secara ideal - Perilaku Per-Hop . Setiap node di jalur lalu lintas secara independen membuat keputusan tentang bagaimana berperilaku relatif terhadap paket yang masuk, berdasarkan header-nya.

Tindakan router paket akan disebut model Perilaku. Jumlah model tersebut bersifat deterministik dan terbatas. Pada perangkat yang berbeda, model perilaku sehubungan dengan lalu lintas yang sama mungkin berbeda, oleh karena itu mereka per-hop.

Konsep Perilaku dan PHB akan saya gunakan dalam artikel sebagai sinonim.

Ada sedikit kebingungan. PHB adalah, di satu sisi, konsep umum perilaku independen setiap node, dan di sisi lain, model spesifik pada node tertentu. Dengan ini kita akan mencari tahu.

Model perilaku ditentukan oleh seperangkat alat dan parameternya: Pemolisian, Menjatuhkan, Mengantri, Menjadwalkan, Membentuk.

Menggunakan model perilaku yang tersedia, jaringan dapat menyediakan berbagai kelas layanan ( Kelas Layanan ).

Artinya, berbagai kategori lalu lintas dapat menerima berbagai tingkat layanan di jaringan dengan menerapkan PHB yang berbeda kepada mereka.

Oleh karena itu, pertama-tama, Anda perlu menentukan kelas rujukan lalu lintas layanan mana - Klasifikasi .

Setiap node secara independen mengklasifikasikan paket yang masuk.



Setelah klasifikasi, pengukuran terjadi ( Pengukuran ) - berapa banyak bit / byte lalu lintas dari kelas ini telah tiba di router.

Berdasarkan hasil, paket dapat dicat ( Pewarnaan ): hijau (dalam batas yang ditentukan), kuning (di luar batas), merah (benar-benar memperdayai pantai).



Jika perlu, maka Pemolisian terjadi (maaf untuk kertas kalkir seperti itu, ada pilihan yang lebih baik - tulis, saya akan berubah). Polisher yang didasarkan pada warna paket memberikan aksi ke paket - mengirim, membuang, atau menandai ulang.



Setelah itu, paket harus masuk ke salah satu antrian ( Antrian ). Antrian terpisah dialokasikan untuk setiap kelas layanan, yang memungkinkan mereka untuk dibedakan menggunakan PHB yang berbeda.

Tetapi bahkan sebelum paket memasuki antrian, itu bisa dijatuhkan ( Dropper ) jika antrian penuh.

Jika berwarna hijau, maka akan lulus, jika berwarna kuning, maka kemungkinan besar akan dibuang jika garisnya penuh, dan jika merah adalah bom bunuh diri yang pasti. Secara kondisional, kemungkinan menjatuhkan tergantung pada warna paket dan kepenuhan antrian di mana ia akan mendapatkan.



Pada saat keluar dari antrian, Pembentuk bekerja, tugas yang sangat mirip dengan tugas dari polyser - untuk membatasi lalu lintas ke nilai yang diberikan.

Anda dapat mengonfigurasi pembentuk sembarang untuk masing-masing antrian, atau bahkan dalam antrian.
Pada perbedaan antara pembentuk dan polyser di bab Batas Kecepatan.

Semua antrian pada akhirnya harus bergabung menjadi satu antarmuka keluaran.

Ingat situasi ketika di jalan 8 jalur bergabung menjadi 3. Tanpa pengontrol lalu lintas, ini berubah menjadi kekacauan. Pemisahan bergantian tidak masuk akal jika kita memiliki output yang sama dengan input.

Oleh karena itu, ada operator khusus ( Penjadwal ), yang secara siklis mengeluarkan paket dari antrian yang berbeda dan mengirimkannya ke antarmuka ( Penjadwalan ).

Faktanya, kombinasi seperangkat antrian dan operator adalah mekanisme QoS yang paling penting yang memungkinkan Anda untuk menerapkan aturan yang berbeda untuk berbagai kelas lalu lintas, yang satu menyediakan bandwidth lebar, latensi rendah lainnya, ketiadaan ketiga tetes.

Kemudian paket-paket sudah pergi ke antarmuka, di mana paket-paket diubah menjadi aliran bit - serialisasi ( Serialisasi ) dan kemudian sinyal lingkungan.



Dalam DiffServ, perilaku setiap node tidak tergantung pada yang lain, tidak ada protokol pensinyalan yang akan menunjukkan kebijakan QoS mana yang ada di jaringan. Pada saat yang sama, dalam jaringan, saya ingin lalu lintas ditangani dengan cara yang sama. Jika hanya satu node berperilaku berbeda, seluruh kebijakan QoS sia-sia.

Untuk ini, pertama, pada semua router, kelas dan PHB yang sama dikonfigurasikan untuk mereka, dan kedua, Penandaan paket digunakan - miliknya ke kelas tertentu dicatat dalam header (IP, MPLS, 802.1q).

Dan keindahan dari DiffServ adalah bahwa node selanjutnya dapat mengandalkan label ini untuk klasifikasi.

Zona kepercayaan semacam itu, di mana aturan klasifikasi lalu lintas yang sama dan perilaku yang sama berlaku, disebut domain DiffServ ( DiffServ-Domain ).



Dengan demikian, di pintu masuk ke domain DiffServ, kita dapat mengklasifikasikan paket berdasarkan 5-Tuple atau antarmuka, tandai ( Remark / Tulis ulang ) sesuai dengan aturan domain, dan node lebih lanjut akan mempercayai penandaan ini dan tidak membuat klasifikasi yang kompleks.
Yaitu, tidak ada pensinyalan eksplisit di DiffServ, tetapi node dapat memberi tahu semua yang berikut kelas mana paket ini perlu disediakan, menunggu untuk dipercaya.

Di persimpangan antara domain DiffServ, Anda perlu menegosiasikan kebijakan QoS (atau tidak).

Seluruh gambar akan terlihat seperti ini:

Untuk memperjelasnya, saya akan memberikan analog dari kehidupan nyata.
Terbang dengan pesawat (bukan Kemenangan).
Ada tiga kelas layanan (CoS): Ekonomi, Bisnis, Pertama.
Saat membeli tiket, Klasifikasi terjadi - penumpang menerima kelas layanan tertentu berdasarkan harga.
Di bandara ada tanda (Komentar) - tiket dikeluarkan menunjukkan kelas.
Ada dua perilaku (PHB): Upaya Terbaik dan Premium.
Ada mekanisme yang menerapkan perilaku: ruang tunggu umum atau VIP Lounge, minibus atau bus bersama, kursi besar yang nyaman atau barisan yang sempit, jumlah penumpang per pramugari, kemampuan untuk memesan alkohol.
Bergantung pada kelasnya, model perilaku ditugaskan - ke ekonomi Usaha Terbaik, ke Bisnis - Premium dasar, dan ke yang Pertama - Premium SUPER-POWER-NINJA-TURBO-NEO-ULTRA-HYPER-MEGA-MULTI-ALPHA-META-EXTRA-UBER-PREFIX!
Pada saat yang sama, dua Premium berbeda dalam hal itu, dalam satu mereka memberikan segelas semisweet, dan yang lain mereka memiliki Bacardi tanpa batas.

Kemudian, setibanya di bandara, semua orang datang melalui satu pintu. Mereka yang mencoba membawa senjata atau tidak memiliki tiket tidak diperbolehkan (Drop). Bisnis dan ekonomi masuk ke ruang tunggu yang berbeda dan transportasi yang berbeda (Antrian). Pertama mereka membiarkan Kelas Satu naik, lalu bisnis, lalu Ekonomi (Penjadwalan), tetapi kemudian mereka semua terbang ke tujuan dengan satu pesawat (antarmuka).

Dalam contoh yang sama, penerbangan di pesawat terbang adalah penundaan Propagasi, pendaratan adalah penundaan Serialisasi, menunggu pesawat di aula antrian, dan kontrol paspor sedang Memproses. Perhatikan bahwa di sini Keterlambatan Pemrosesan biasanya diabaikan dalam hal total waktu.

Bandara berikutnya dapat menangani penumpang dengan cara yang sangat berbeda - PHB-nya berbeda. Tetapi pada saat yang sama, jika penumpang tidak mengubah maskapai, maka kemungkinan besar sikap terhadapnya tidak akan berubah, karena satu perusahaan adalah satu domain DiffServ.

Seperti yang mungkin Anda perhatikan, DiffServ sangat kompleks (atau tidak terbatas). Tetapi kami akan menganalisis semua yang dijelaskan di atas. Pada saat yang sama, dalam artikel saya tidak akan masuk ke nuansa implementasi fisik (mereka dapat berbeda bahkan pada dua papan router yang sama), saya tidak akan berbicara tentang HQoS dan MPLS DS-TE.

Ambang untuk memasuki lingkaran insinyur yang memahami teknologi untuk QoS jauh lebih tinggi daripada protokol routing, MPLS, atau, maafkan saya, Radya, STP.

Meskipun demikian, DiffServ telah mendapatkan pengakuan dan implementasi pada jaringan di seluruh dunia, karena, seperti yang mereka katakan, sangat scalable.

Sepanjang sisa artikel ini, saya hanya akan menganalisis DiffServ.

Di bawah ini kami akan menganalisis semua alat dan proses yang ditunjukkan dalam ilustrasi.

---

Dalam perjalanan memperluas topik, saya akan menunjukkan beberapa hal dalam praktik.
Kami akan bekerja dengan jaringan seperti itu:



Trisolarans adalah klien penyedia tautan dengan dua titik koneksi.

Area kuning adalah domain DiffServ dari jaringan tautan, di mana kebijakan QoS tunggal berlaku.
Linkmeup_R1 adalah perangkat CPE yang dikelola oleh penyedia, dan karenanya di zona tepercaya. OSPF dinaikkan dengan itu dan interaksi terjadi melalui IP bersih.

Di dalam inti jaringan ada MPLS + LDP + MP-BGP dengan L3VPN, membentang dari Linkmeup_R2 ke Linkmeup_R4.
Saya akan memberikan semua komentar lain seperlunya.

File konfigurasi awal .

---

4. Klasifikasi dan pelabelan

Dalam jaringannya, administrator mendefinisikan kelas layanan yang dapat ia berikan lalu lintas.

Oleh karena itu, hal pertama yang dilakukan setiap node ketika menerima paket adalah mengklasifikasikannya.

Ada tiga cara:

1. Agregat Perilaku ( BA )
   Percaya saja label paket yang ada di header-nya. Misalnya, bidang IP DSCP.
   Disebut demikian karena di bawah label yang sama di bidang DSCP berbagai kategori lalu lintas dikumpulkan yang mengharapkan perilaku yang sama sehubungan dengan diri mereka sendiri. Sebagai contoh, semua sesi SIP akan digabungkan menjadi satu kelas.
   
   Jumlah kelas layanan yang mungkin, dan karena itu pola perilaku, terbatas. Oleh karena itu, mustahil untuk setiap kategori (atau bahkan lebih untuk streaming) untuk mengalokasikan kelas yang terpisah - perlu untuk agregat.
2. Berbasis antarmuka
   Segala sesuatu yang datang ke antarmuka tertentu harus ditempatkan dalam satu kelas lalu lintas. Sebagai contoh, kita tahu pasti bahwa server database terhubung ke port ini dan tidak lebih. Dan di workstation karyawan lain.
3. MultiField ( MF )
   Menganalisis bidang header paket - alamat IP, port, alamat MAC. Secara umum, bidang yang arbitrer.
   
   Misalnya, semua lalu lintas yang menuju subnet 10.127.721.0/24 pada port 5000 harus ditandai sebagai lalu lintas, yang secara kondisional membutuhkan layanan kelas 5.

Administrator menentukan sekumpulan kelas layanan yang dapat disediakan jaringan, dan memetakannya beberapa nilai digital.

Di pintu masuk ke domain-DS, kami tidak mempercayai siapa pun, sehingga klasifikasi dilakukan dengan cara kedua atau ketiga: berdasarkan alamat, protokol atau antarmuka, kelas layanan dan nilai digital yang sesuai ditentukan.

Pada saat keluar dari node pertama, digit ini dikodekan dalam bidang DSCP header IP (atau bidang lain dari Kelas Lalu Lintas: Kelas Lalu Lintas MPLS, Kelas Lalu Lintas IPv6, Ethernet 802.1p) - sebuah komentar muncul.

Merupakan kebiasaan untuk mempercayai pelabelan ini di dalam domain DS, oleh karena itu, transit node menggunakan metode klasifikasi pertama (BA) - yang paling sederhana. Tidak ada analisis judul yang rumit, lihat saja nomor yang direkam.

Di persimpangan dua domain, Anda dapat mengklasifikasikan berdasarkan antarmuka atau MF, seperti yang saya jelaskan di atas, atau Anda dapat mempercayai pemberian tanda BA dengan pemesanan.

Misalnya, percaya semua nilai kecuali 6 dan 7, dan tetapkan kembali 6 dan 7 hingga 5.

Situasi ini dimungkinkan ketika penyedia menghubungkan entitas hukum yang memiliki kebijakan pelabelannya sendiri. Penyedia tidak keberatan menyimpannya, tetapi tidak ingin lalu lintas jatuh ke dalam kelas di mana ia menerima paket protokol jaringan.

Agregasi perilaku

BA menggunakan klasifikasi yang sangat sederhana - Saya melihat angka - Saya mengerti kelasnya.
Jadi, berapa angkanya? Dan di bidang apa ini direkam?

• Kelas Lalu Lintas IPv6
• Kelas Lalu Lintas MPLS
• Ethernet 802.1p

Klasifikasi terutama didasarkan pada header pergantian.

Saya memanggil header komuter yang didasarkan pada perangkat yang menentukan ke mana harus mengirim paket sehingga menjadi lebih dekat ke penerima.
Yaitu, jika paket IP tiba di router, header IP dan bidang DSCP dianalisis. Jika MPLS tiba, ia diuraikan - MPLS Traffic Class.

Jika paket Ethernet + VLAN + MPLS + IP datang ke L2-switch biasa, maka 802.1p akan dianalisis (meskipun ini dapat diubah).

IPv4 TOS

Bidang QoS menyertai kita persis seperti IP. Bidang TOS delapan bit - Jenis Layanan - seharusnya membawa prioritas paket.

Bahkan sebelum munculnya DiffServ, RFC 791 ( INTERNET PROTOCOL ) menggambarkan bidang seperti ini:

IP Precedence (IPP) + DTR + 00.



Artinya, prioritas paket berjalan, maka bit ketepatan untuk Delay, Throughput, Keandalan (0 - tanpa persyaratan, 1 - dengan persyaratan).

Dua bit terakhir harus nol.


Kemudian di RFC 1349 ( Jenis Layanan di Internet Protocol Suite ), bidang TOS sedikit didefinisikan ulang:



Tiga bit tersisa tetap IP Precedence, empat berikutnya berubah menjadi TOS setelah menambahkan bit Biaya.

Berikut cara membaca unit dalam bit TOS ini:

• D - “minim d elay”,
• T - "maksimalkan t throughput",
• R - "maksimalkan keandalan",
• C - "meminimalkan masalah".

Deskripsi kabur tidak berkontribusi pada popularitas pendekatan ini.

Tidak ada pendekatan sistematis untuk QoS di sepanjang jalur, tidak ada rekomendasi yang jelas tentang cara menggunakan bidang prioritas, deskripsi bit Keterlambatan, Throughput, dan Keandalan sangat kabur.

Oleh karena itu, dalam konteks DiffServ, bidang TOS sekali lagi didefinisikan ulang dalam RFC 2474 ( Definisi Bidang Layanan Diferensial (Bidang DS) di Header IPv4 dan IPv6 ):



Alih-alih bit IPP dan DTRC, DSCP bidang enam-bit - Titik Kode Layanan Diferensial diperkenalkan, dua bit kanan tidak digunakan.

Sejak saat itu, bidang DSCP yang seharusnya menjadi penanda utama DiffServ: nilai tertentu (kode) ditulis di dalamnya, yang di dalam domain DS mencirikan kelas layanan tertentu yang diperlukan oleh paket dan prioritasnya yang menurun. Ini adalah angka yang sama.

Administrator dapat menggunakan semua 6 bit DSCP sesuai keinginannya, berbagi hingga maksimal 64 kelas layanan.

Namun, demi kompatibilitas dengan IP Precedence, mereka mempertahankan peran Class Selector untuk tiga bit pertama.

Yaitu, seperti dalam IPP, 3 bit Selector Kelas memungkinkan Anda untuk mendefinisikan 8 kelas.



Namun, ini masih tidak lebih dari pengaturan yang, dalam batas-batas DS-domain-nya, administrator dapat dengan mudah mengabaikan dan menggunakan semua 6 bit atas kebijakannya sendiri.

Lebih lanjut, saya juga mencatat bahwa menurut rekomendasi IETF, semakin tinggi nilainya yang dicatat dalam CS, semakin banyak trafik ke layanan ini.

Tapi ini tidak bisa dianggap sebagai kebenaran yang tidak bisa disangkal.

Jika tiga bit pertama menentukan kelas traffic, maka tiga bit berikutnya digunakan untuk menunjukkan prioritas paket drop ( Drop Precedence atau Packet Loss Priority - PLP ).

Delapan kelas - apakah banyak atau sedikit? Pada pandangan pertama, itu tidak cukup - setelah semua, begitu banyak lalu lintas yang berbeda terjadi pada jaringan yang ingin dibedakan setiap protokol dengan kelas. Namun, ternyata delapan sudah cukup untuk semua skenario yang mungkin.
Untuk setiap kelas, Anda perlu mendefinisikan PHB yang akan menanganinya dengan cara yang berbeda dari kelas lainnya.
Dan dengan peningkatan pembagi, dividen (sumber daya) tidak meningkat.
Saya sengaja tidak berbicara tentang nilai pasti dari kelas lalu lintas mana yang mereka gambarkan, karena tidak ada standar dan Anda dapat menggunakannya secara resmi atas kebijakan Anda sendiri. Di bawah ini saya akan memberi tahu Anda kelas mana dan nilainya yang sesuai direkomendasikan.

---

Praktek klasifikasi DSCP

Tidak ada ruginya sedikit berlatih.

Skemanya sama.



Untuk memulai, cukup kirim permintaan ICMP:

Linkmeup_R1#ping ip 172.16.2.2 source 172.16.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.2.2, timeout is 2 seconds: Packet sent with a source address of 172.16.1.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms 

Linkmeup_R1. E0 / 0.


pcapng

Dan sekarang dengan nilai DSCP yang ditetapkan.

  Linkmeup_R1#ping ip 172.16.2.2 source 172.16.1.1 tos 184 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.2.2, timeout is 2 seconds: Packet sent with a source address of 172.16.1.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms 

Nilai 184 adalah representasi desimal dari biner 10111000. Dari jumlah tersebut, 6 bit pertama adalah 101110, yaitu desimal 46, dan ini adalah EF kelas.


Linkmeup_R2. E0 / 0


pcapng

Catatan ingin tahu: tujuan pingushka di ICMP Echo reply menetapkan nilai kelas yang sama seperti di Echo Request. Ini logis - jika pengirim mengirim paket dengan tingkat kepentingan tertentu, maka jelas dia ingin menerimanya kembali.

Linkmeup_R2. E0 / 0


File konfigurasi klasifikasi DSCP.

Kelas Lalu Lintas IPv6

IPv6 tidak jauh berbeda dalam hal QoS dari IPv4. Bidang delapan bit, yang disebut Kelas Lalu Lintas, juga dibagi menjadi dua bagian. 6 bit pertama - DSCP - memainkan peran yang persis sama.



Ya, Label Arus telah muncul. Mereka mengatakan bahwa itu dapat digunakan untuk diferensiasi kelas tambahan. Namun gagasan ini belum diterapkan dalam kehidupan.

Kelas Lalu Lintas MPLS

Konsep DiffServ difokuskan pada jaringan IP dengan routing header IP. Itu hanya nasib buruk - setelah 3 tahun, mereka menerbitkan RFC 3031 ( Multiprotocol Label Switching Architecture ). Dan MPLS mulai mengambil alih penyedia jaringan.

DiffServ tidak dapat diperpanjang kepadanya.

Secara kebetulan, bidang EXP tiga bit dimasukkan ke MPLS untuk kasus eksperimental apa pun. Dan terlepas dari kenyataan bahwa lama di RFC 5462 ( "EXP" Field Berganti nama menjadi "Traffic Class" ) secara resmi menjadi bidang Traffic Class, oleh inersia itu disebut IExPi.

Ada satu masalah dengan itu - panjangnya tiga bit, yang membatasi jumlah nilai yang mungkin sampai 9. Ini bukan hanya kecil, itu adalah 3 pesanan biner kurang dari DSCP.



Mengingat bahwa MPLS Traffic Class sering diwarisi dari paket IP DSCP, kami memiliki pengarsipan dengan kehilangan. Atau ... Tidak, Anda tidak ingin tahu itu ... L-LSP . Menggunakan kombinasi nilai label Traffic Class +.

Umumnya, situasinya aneh - MPLS dirancang sebagai bantuan IP untuk pengambilan keputusan cepat - label MPLS langsung terdeteksi di CAM oleh Pencocokan Penuh, alih-alih Pencocokan Awalan Terpanjang tradisional. Artinya, mereka tahu tentang IP, dan mengambil bagian dalam peralihan, tetapi tidak menyediakan bidang prioritas normal.

Faktanya, kita sudah melihat di atas bahwa hanya tiga bit pertama DSCP yang digunakan untuk menentukan kelas traffic, dan tiga bit lainnya adalah Drop Precedence (atau PLP - Packet Loss Priority).

Oleh karena itu, dalam hal kelas layanan, kami masih memiliki korespondensi 1: 1, hanya kehilangan informasi tentang Drop Precedence.

Dalam kasus MPLS, klasifikasi seperti dalam IP dapat didasarkan pada antarmuka, MF, IP DSCP atau Traffic Class MPLS.

Pelabelan berarti menulis nilai di bidang Kelas Lalu Lintas header MPLS.

Paket dapat berisi beberapa header MPLS. Untuk tujuan DiffServ, hanya bagian atas yang digunakan.

Ada tiga skenario penandaan ulang yang berbeda saat memindahkan paket dari satu segmen IP murni ke yang lain melalui domain MPLS: (ini hanya kutipan dari artikel ).

1. Mode seragam
2. Mode pipa
3. Mode pipa pendek

---

Praktek Klasifikasi Kelas Lalu Lintas MPLS

Skemanya sama:


File konfigurasi sama.

Dalam diagram jaringan linkmeup, ada transisi dari IP ke MPLS ke Linkmeup_R2.
Mari kita lihat apa yang terjadi dengan menandai ketika ping ping ip 172.16.2.2 sumber 172.16.1.1 tos 184 .

Linkmeup_R2. E0 / 0.

pcapng

Jadi, kita melihat bahwa label EF asli di IP DSCP diubah menjadi nilai 5 bidang EXP MPLS (ini juga merupakan Kelas Lalu Lintas, ingat ini) dari header VPN dan header transport.
Di sini kita adalah saksi mode operasi Uniform.

---

Ethernet 802.1p

Kurangnya bidang prioritas dalam 802.3 (Ethernet) dijelaskan oleh fakta bahwa Ethernet awalnya direncanakan secara eksklusif sebagai solusi untuk segmen LAN. Untuk uang sederhana, Anda bisa mendapatkan bandwidth yang berlebihan, dan uplink akan selalu menjadi hambatan - tidak ada yang perlu dikhawatirkan tentang memprioritaskan.

Namun, segera menjadi jelas bahwa daya tarik keuangan Ethernet + IP membawa bundel ini ke tingkat backbone dan WAN. Dan hidup bersama dalam satu segmen LAN dengan torrents dan telepon perlu diselesaikan.

Untungnya, 802.1q (VLAN) tiba pada waktunya untuk ini, di mana bidang 3-bit (lagi) dialokasikan untuk prioritas.

Dalam paket DiffServ, bidang ini memungkinkan Anda untuk menentukan 8 kelas lalu lintas yang sama.

---

Saat menerima paket, perangkat jaringan dari domain DS dalam banyak kasus memperhitungkan header yang digunakannya untuk berpindah:

• Switch Ethernet - 802.1p
• MPLS Node - MPLS Traffic Class
• IP Router - IP DSCP

Meskipun perilaku ini dapat diubah: Berbasis Antarmuka dan klasifikasi Multi-Bidang. Dan Anda kadang-kadang bahkan dapat secara eksplisit mengatakan di bidang CoS header yang harus dilihat.

---

Berbasis antarmuka

Ini adalah cara termudah untuk mengklasifikasikan paket di dahi. Segala sesuatu yang dituangkan ke antarmuka yang ditentukan ditandai dengan kelas tertentu.

Dalam beberapa kasus, rincian ini sudah cukup, sehingga berbasis antarmuka digunakan dalam kehidupan.

Praktek klasifikasi berbasis antarmuka

Skemanya sama:



Menyiapkan kebijakan QoS di peralatan sebagian besar vendor dibagi menjadi beberapa tahap.

1. Pertama, classifier didefinisikan:
   class-map match-all TRISOLARANS_INTERFACE_CM
match input-interface Ethernet0/2
   Segala sesuatu yang datang ke antarmuka Ethernet0 / 2.
   
2. Selanjutnya, kebijakan dibuat di mana classifier dan tindakan yang diperlukan terkait.
   
   

     policy-map TRISOLARANS_REMARK class TRISOLARANS_INTERFACE_CM set ip dscp cs7 

   
   Jika paket memenuhi classifier TRISOLARANS_INTERFACE_CM, tulis CS7 di bidang DSCP.
   

   Di sini saya maju menggunakan CS7 yang tidak jelas, lalu EF, AF. Di bawah ini Anda dapat membaca tentang singkatan ini dan perjanjian yang diterima. Sementara itu, cukup untuk mengetahui bahwa ini adalah kelas yang berbeda dengan tingkat layanan yang berbeda.
   

3. Dan langkah terakhir adalah menerapkan kebijakan ke antarmuka:
   
   

     interface Ethernet0/2 service-policy input TRISOLARANS_REMARK 

   
   

   Di sini, classifier sedikit berlebihan, yang akan memeriksa bahwa paket tersebut datang ke antarmuka e0 / 2, di mana kita kemudian menerapkan kebijakan tersebut. Orang bisa menulis yang cocok dengan apa saja:
   
   

    class-map match-all TRISOLARANS_INTERFACE_CM match any 

   
   Namun, kebijakan tersebut sebenarnya dapat diterapkan pada vlanif atau pada antarmuka keluaran, sehingga dimungkinkan.
   

   
   

Jalankan ping biasa pada 172.16.2.2 (Trisolaran2) dengan Trisolaran1:



Dan di dump antara Linkmeup_R1 dan Linkmeup_R2 kita akan melihat yang berikut:


pcapng

Konfigurasi File Klasifikasi Berbasis Antarmuka.

Multi-bidang

Jenis klasifikasi yang paling umum di pintu masuk ke domain DS. Kami tidak mempercayai label yang ada, dan atas dasar header paket kami menetapkan kelas.

Seringkali ini adalah cara untuk "mengaktifkan" QoS sama sekali, dalam hal ketika pengirim tidak menandai.

Alat yang cukup fleksibel, tetapi pada saat yang sama rumit - Anda perlu membuat aturan yang sulit untuk setiap kelas. Oleh karena itu, di dalam domain DS, BA lebih relevan.

Praktek klasifikasi MF

Skemanya sama:



Dari contoh praktis di atas, dapat dilihat bahwa perangkat jaringan dengan label kepercayaan default dari paket yang masuk.

Ini baik-baik saja di dalam domain DS, tetapi tidak dapat diterima di titik masuk.

Dan sekarang janganlah kita percaya secara membuta? Pada Linkmeup_R2, ICMP akan diberi label sebagai EF (misalnya saja), TCP sebagai AF12, dan yang lainnya adalah CS0.
Ini akan menjadi klasifikasi MF (Multi-Bidang).

1. Prosedurnya sama, tapi sekarang kami akan mencocokkan dengan ACL yang melepaskan kaitan kategori lalu lintas yang diperlukan, jadi pertama-tama kita buat mereka.
   
   Di Linkmeup_R2:
   
   

     ip access-list extended TRISOLARANS_ICMP_ACL permit icmp any any ip access-list extended TRISOLARANS_TCP_ACL permit tcp any any ip access-list extended TRISOLARANS_OTHER_ACL permit ip any any 

   
   
2. Selanjutnya, kita mendefinisikan pengklasifikasi:
   
   

     class-map match-all TRISOLARANS_TCP_CM match access-group name TRISOLARANS_TCP_ACL class-map match-all TRISOLARANS_OTHER_CM match access-group name TRISOLARANS_OTHER_ACL class-map match-all TRISOLARANS_ICMP_CM match access-group name TRISOLARANS_ICMP_ACL 

   
   
3. Dan sekarang kita mendefinisikan aturan berkomentar dalam politik:
   
   

     policy-map TRISOLARANS_ADMISSION_CONTROL class TRISOLARANS_ICMP_CM set ip dscp ef class TRISOLARANS_TCP_CM set ip dscp af11 class TRISOLARANS_OTHER_CM set ip dscp default 

   
   
4. Dan kami menggantung kebijakan di antarmuka. Di input, masing-masing, karena keputusan harus dibuat di pintu masuk ke jaringan.
   
   

     interface Ethernet0/1 service-policy input TRISOLARANS_ADMISSION_CONTROL 

   
   

Tes ICMP dari host terakhir Trisolaran1. Kami tidak secara khusus menentukan kelas - standarnya adalah 0.

Saya sudah menghapus kebijakan dengan Linkmeup_R1, jadi lalu lintas dilengkapi dengan tanda CS0, bukan CS7.



Berikut adalah dua kesedihan terdekat, dengan Linkmeup_R1 dan Linkmeup_R2:

Linkmeup_R1. E0 / 0.

pcapng

Linkmeup_R2. E0 / 0.

pcapng

Dapat dilihat bahwa setelah pengklasifikasi dan penandaan ulang Linkmeup_R2 pada paket ICMP, tidak hanya DSCP berubah menjadi EF, tetapi Kelas Lalu Lintas MPLS menjadi sama dengan 5.

Tes serupa dengan telnet 172.16.2.2. 80 - jadi periksa TCP:



Linkmeup_R1. E0 / 0.

pcapng

Linkmeup_R2. E0 / 0.

pcapng

BACA - Apa Dan Diperlukan Untuk Diharapkan. TCP ditransmisikan sebagai AF11.

Tes berikutnya akan menguji UDP, yang harus pergi ke CS0 sesuai dengan pengklasifikasi kami. Kami akan menggunakan iperf untuk ini (membawanya ke Linux Tiny Core via Apps). Di sisi remote iperf3 -s - mulai server, pada iperf3 lokal -c -u -t1 - client ( -c ), protokol UDP ( -u ), uji selama 1 detik ( -t1 ).



Linkmeup_R1. E0 / 0.

pcapng

Linkmeup_R2. E0 / 0

pcapng

Mulai sekarang, semua yang datang ke antarmuka ini akan diklasifikasikan sesuai dengan aturan yang dikonfigurasi.

---

Menandai di dalam perangkat

Sekali lagi: di pintu masuk ke klasifikasi DS-domain dapat terjadi MF, Interface-based atau BA.
Antara node dari domain DS, paket di header membawa tanda tentang kelas layanan yang diperlukan dan diklasifikasikan oleh BA.

Terlepas dari metode klasifikasi, setelah itu, paket tersebut diberikan kelas batin di dalam perangkat, sesuai dengan yang diproses. Header dihapus, dan paket telanjang (tidak ada) bergerak ke pintu keluar.
Dan pada output, kelas dalam dikonversi ke bidang CoS dari header baru.

Yaitu, Pos 1 ⇒ Klasifikasi ⇒ Kelas layanan internal ⇒ Pos 2.

Dalam beberapa kasus, Anda perlu menampilkan bidang tajuk dari satu protokol di bidang tajuk lainnya, misalnya, DSCP di Kelas Lalu Lintas.

Ini terjadi hanya melalui penandaan internal menengah.

Misalnya, Header DSCP ⇒ Klasifikasi ⇒ Kelas Layanan Internal ⇒ Header Kelas Lalu Lintas.

Secara formal, kelas batin dapat dipanggil sesuka Anda, atau hanya diberi nomor, dan mereka hanya memiliki antrian tertentu yang ditugaskan untuk mereka.

Pada kedalaman yang kita selami dalam artikel ini, tidak peduli apa namanya, penting bahwa model perilaku spesifik dikaitkan dengan nilai-nilai spesifik bidang QoS.

Jika kita berbicara tentang implementasi QoS tertentu, maka jumlah kelas layanan yang dapat disediakan perangkat tidak lebih dari jumlah antrian yang tersedia. Seringkali ada delapan dari mereka (baik di bawah pengaruh IPP, atau kadang-kadang dengan perjanjian tidak tertulis). Namun, tergantung pada vendor, perangkat, papan, mereka bisa lebih atau kurang.

Artinya, jika ada 4 antrian, maka kelas layanan sama sekali tidak masuk akal untuk melakukan lebih dari empat.

Mari kita bicarakan ini secara lebih rinci di bab perangkat keras.


Dalam hal PHB, sama sekali tidak ada perbedaan apa yang digunakan untuk klasifikasi - DSCP, Traffic Class, 802.1p.

Di dalam perangkat, mereka berubah menjadi kelas lalu lintas yang ditentukan oleh administrator jaringan.
Artinya, semua tanda ini adalah cara untuk memberi tahu para tetangga tentang kelas layanan yang harus mereka tetapkan untuk paket ini. Ini tentang seperti BGP Community, yang tidak berarti apa-apa sendiri, sampai kebijakan untuk menafsirkannya ditentukan pada jaringan.

---

Rekomendasi IETF (Kategori Lalu Lintas, Kelas Layanan, dan Perilaku)

Standar tidak menstandarkan sama sekali di mana kelas layanan tertentu harus ada, bagaimana mengklasifikasikan dan melabeli mereka, dan PHB mana yang berlaku untuk mereka.

Ini adalah berkat vendor dan administrator jaringan.

Kami hanya memiliki 3 bit - kami gunakan sesuai keinginan.

Ini bagus:

• Setiap bagian dari besi (vendor) secara independen memilih mekanisme mana yang akan digunakan untuk PHB - tanpa pensinyalan, tidak ada masalah kompatibilitas.
• Administrator setiap jaringan dapat secara fleksibel mendistribusikan lalu lintas di antara kelas yang berbeda, memilih kelas itu sendiri dan PHB yang sesuai.

Ini buruk:

• Pada batas-batas domain DS, masalah konversi muncul.
• Dalam kondisi kebebasan penuh untuk bertindak - ada yang di hutan, ada yang iblis.

Oleh karena itu, IETF pada tahun 2006 mengeluarkan manual pelatihan tentang cara mendekati diferensiasi layanan: RFC 4594 ( Pedoman Konfigurasi untuk Kelas Layanan DiffServ ).

Berikut ini adalah ringkasan singkat dari RFC ini.

Model Perilaku (PHB)

DF - Penerusan Default
Pengiriman standar.
Jika model lalu lintas tidak secara khusus ditetapkan sebagai model perilaku, itu akan diproses menggunakan Penerusan Default.

Ini adalah Upaya Terbaik - perangkat akan melakukan apa saja yang mungkin, tetapi tidak menjamin apa pun. Drops, disordering, keterlambatan tak terduga dan jitter mengambang adalah mungkin, tetapi ini tidak akurat.

Model ini cocok untuk aplikasi yang tidak menuntut, seperti unduhan surat atau file.
By the way, ada PHB dan bahkan kurang pasti - Upaya Lebih Rendah .

AF - Penerusan Tertanggung
Pengiriman terjamin.
Ini adalah peningkatan BE. Beberapa jaminan muncul di sini, misalnya, band. Tetes dan penundaan mengambang masih dimungkinkan, tetapi pada tingkat yang jauh lebih rendah.

Model ini cocok untuk multimedia: Streaming, konferensi video, game online.
RFC 2597 ( Grup PHB Penerusan Tertanggung ).

EF - Expedited Forwarding
Pengiriman darurat.
Semua sumber daya dan prioritas terburu-buru di sini. Ini adalah model untuk aplikasi yang tidak memerlukan kerugian, penundaan pendek, jitter stabil, tetapi mereka tidak serakah untuk band. Sebagai, misalnya, telepon atau layanan emulasi kawat (CES - Circuit Emulation Service).

Kerugian, gangguan, dan keterlambatan mengambang di EF sangat kecil kemungkinannya.
RFC 3246 ( PHB Ekspedisi Ekspedisi ).

CS - Pemilih Kelas
Ini adalah perilaku yang dirancang untuk mempertahankan kompatibilitas dengan IP-Precedence dalam jaringan yang mampu DS.

Kelas-kelas berikut ada di IPP: CS0, CS1, CS2, CS3, CS4, CS5, CS6, CS7.
Tidak selalu untuk mereka semua ada PHB terpisah, biasanya ada dua atau tiga, dan sisanya hanya diterjemahkan ke dalam kelas DSCP terdekat dan dapatkan PHB yang sesuai.
Jadi misalnya, paket berlabel CS 011000 dapat diklasifikasikan sebagai 011010.

Dari CS, pasti hanya CS6, CS7, yang direkomendasikan untuk NCP - Protokol Kontrol Jaringan dan memerlukan PHB terpisah, yang disimpan dalam peralatan.

Seperti EF, PHB CS6.7 dirancang untuk kelas yang memiliki latensi dan persyaratan kerugian yang sangat tinggi, tetapi agak toleran terhadap diskriminasi pita.
Tugas PHB untuk CS6.7 adalah untuk menyediakan tingkat layanan yang menghilangkan tetesan dan penundaan bahkan dalam kasus kelebihan antarmuka, chip dan antrian.

---

Penting untuk dipahami bahwa PHB adalah konsep abstrak - dan faktanya PHB diimplementasikan melalui mekanisme yang tersedia pada peralatan nyata.

Dengan demikian, PHB yang sama yang didefinisikan dalam domain DS dapat berbeda pada Juniper dan Huawei.

Selain itu, PHB tunggal bukanlah serangkaian tindakan statis, misalnya, PHB AF dapat terdiri dari beberapa opsi yang berbeda dalam tingkat jaminan (band, keterlambatan yang dapat diterima).

---

Kelas Layanan

IETF merawat para administrator dan mengidentifikasi kategori utama aplikasi dan kelas layanan mereka.

Saya tidak akan bertele-tele di sini, cukup masukkan beberapa piring dari Pedoman RFC ini.

Kategori aplikasi:



Persyaratan untuk karakteristik jaringan:



Dan akhirnya, nama kelas yang disarankan dan nilai DSCP yang sesuai:



Dengan menggabungkan kelas-kelas di atas dengan cara yang berbeda (agar sesuai dengan 8 yang tersedia), Anda bisa mendapatkan solusi QoS untuk jaringan yang berbeda.

Mungkin yang paling umum adalah ini:



Kelas DF (atau BE) menandai lalu lintas yang benar-benar tidak menuntut - ia menerima perhatian berdasarkan residual.

PHB AF melayani kelas AF1, AF2, AF3, AF4. Mereka semua perlu menyediakan jalur, sehingga merugikan keterlambatan dan kerugian. Kerugian dikendalikan oleh bit Drop Precedence, itulah sebabnya mereka disebut AFxy, di mana x adalah kelas layanan dan y adalah Drop Precedence.

EF membutuhkan semacam jaminan band minimum, tetapi yang lebih penting - jaminan keterlambatan, jitter, dan tidak ada kerugian.

CS6, CS7 membutuhkan bandwidth yang lebih sedikit, karena itu adalah tetesan paket layanan di mana semburan masih mungkin terjadi (Pembaruan BGP, misalnya), tetapi kerugian dan penundaan tidak dapat diterima di dalamnya - apa gunanya BFD dengan timer 10 ms jika Hello menabrak 100 ms antrian?

Artinya, 4 kelas dari 8 yang tersedia diberikan di bawah AF.

Dan terlepas dari kenyataan bahwa mereka biasanya melakukan hal itu, saya ulangi bahwa ini hanya rekomendasi, dan tidak ada yang mencegah tiga kelas dalam domain DS Anda dari menetapkan EF dan hanya dua untuk AF.

---

Ringkasan Klasifikasi

Di pintu masuk ke sebuah node, sebuah paket diklasifikasikan berdasarkan antarmuka, MF, atau pelabelannya (BA).
Pelabelan adalah nilai bidang DSCP di IPv4, Kelas Lalu Lintas di IPv6, dan di MPLS atau 802.1p di 802.1q.
Ada 8 kelas layanan yang menggabungkan berbagai kategori lalu lintas. Setiap kelas ditugaskan PHB sendiri, memenuhi persyaratan kelas.

Menurut rekomendasi IETF, kelas layanan berikut dibedakan: CS1, CS0, AF11, AF12, AF13, AF21, CS2, AF22, AF23, CS3, AF31, AF32, AF33, CS4, AF41, AF42, AF43, CS5, EF5, EF6, CS6, CS7 dalam meningkatkan pentingnya lalu lintas.

Dari mereka, Anda dapat memilih kombinasi 8, yang sebenarnya dapat dikodekan ke dalam bidang CoS.
Kombinasi yang paling umum: CS0, AF1, AF2, AF3, AF4, EF, CS6, CS7 dengan 3 gradasi warna untuk AF.

Setiap kelas ditugaskan PHB, yang ada 3 - Default Forwarding, Assured Forwarding, Expedited Forwarding dalam meningkatkan urutan keparahan. Sedikit ke samping adalah Pemilih Kelas PHB. Setiap PHB dapat bervariasi menurut parameter alat, tetapi lebih pada nanti.

---

Pada jaringan yang dibongkar, QoS tidak diperlukan, kata mereka. Setiap masalah QoS diselesaikan dengan memperluas tautan, kata mereka. Dengan Ethernet dan DWDM, kami tidak pernah menghadapi kemacetan garis, kata mereka.
Mereka adalah mereka yang tidak mengerti apa itu QoS.

Tetapi kenyataan mengenai VPN di ILV.

1. Tidak di mana-mana ada optik. RRL adalah realitas kita. Terkadang pada saat kecelakaan (dan tidak hanya) di tautan radio sempit ingin merayapi semua lalu lintas jaringan.
2. Semburan lalu lintas adalah kenyataan kita. Ledakan lalu lintas jangka pendek mudah mengantri, memaksa untuk menjatuhkan paket yang sangat diperlukan.
3. Telephony, konferensi video, game online adalah kenyataan kami. Jika antrian setidaknya agak sibuk, penundaan mulai menari.

Dalam praktik saya, ada contoh ketika telepon berubah menjadi kode Morse pada jaringan yang dimuat tidak lebih dari 40%. Tandai ulang di EF untuk menyelesaikan masalah sebentar.

Saatnya berurusan dengan alat yang memungkinkan Anda untuk menyediakan layanan yang berbeda untuk kelas yang berbeda.

---

Alat PHB

Sebenarnya hanya ada tiga kelompok alat QoS yang secara aktif memanipulasi paket:

• Menghindari Kemacetan - apa yang harus dilakukan untuk tidak menjadi buruk.
• Manajemen Kemacetan - apa yang harus dilakukan ketika sudah buruk.
• Pembatasan Nilai - bagaimana tidak menempatkan lebih banyak pada jaringan dari yang seharusnya, dan tidak melepaskan sebanyak yang mereka bisa terima.

Tetapi mereka semua, pada umumnya, akan sia-sia jika bukan karena antrian.

5. Antrian

Di taman hiburan, Anda tidak dapat memberikan prioritas kepada seseorang jika Anda tidak mengatur antrian terpisah untuk mereka yang membayar lebih.

Situasi yang sama di jaringan.

Jika semua lalu lintas dalam satu antrian, Anda tidak akan dapat mengeluarkan paket penting dari tengahnya untuk memberikan prioritas kepada mereka.

Itu sebabnya, setelah klasifikasi, paket ditempatkan dalam antrian yang sesuai dengan kelas ini.

Dan kemudian satu antrian (dengan data suara) akan bergerak cepat, tetapi dengan pita terbatas, lainnya lebih lambat (streaming), tetapi dengan pita lebar, dan beberapa sumber daya akan berjalan sesuai dengan prinsip residual.

Tetapi dalam batas-batas setiap antrian terpisah aturan yang sama berlaku - Anda tidak dapat menarik paket dari tengah - hanya dari kepalanya.

Setiap antrian memiliki panjang terbatas tertentu. Di satu sisi, ini ditentukan oleh keterbatasan perangkat keras, dan di sisi lain, tidak masuk akal untuk menyimpan paket dalam antrian terlalu lama. Paket VoIP tidak diperlukan jika ditunda selama 200 ms. TCP akan meminta penerusan, secara kondisional, setelah RTT berakhir (dikonfigurasi dalam sysctl). Karena itu, menjatuhkan tidak selalu buruk.
Pengembang dan perancang peralatan jaringan harus menemukan kompromi antara upaya untuk menyelamatkan paket selama mungkin dan, sebaliknya, untuk mencegah pemborosan bandwidth, mencoba mengirimkan paket yang tidak lagi diperlukan.

Dalam situasi normal, ketika antarmuka / chip tidak kelebihan beban, pemanfaatan buffer mendekati nol. Mereka menyerap semburan jangka pendek, tetapi ini tidak menyebabkan pengisian yang lama.

Jika ada lebih banyak lalu lintas daripada chip switching atau antarmuka keluaran dapat menangani, antrian mulai mengisi. Dan pemanfaatan kronis di atas 20-30% sudah merupakan situasi yang perlu ditangani.

---

6. Menghindari Kemacetan

Dalam kehidupan setiap router, ada saatnya ketika antrian penuh. Tempat meletakkan paket, jika tidak ada tempat untuk meletakkannya - itu saja, buffer sudah berakhir, dan tidak akan ada di sana, bahkan jika itu baik untuk dilihat, bahkan jika Anda membayar ekstra.

Ada dua cara: untuk membuang paket ini, atau mereka yang sudah mendapat skor.
Jika sudah ada dalam antrian, maka pertimbangkan apa yang hilang.

Dan jika yang ini, maka anggaplah dia tidak datang.

Dua pendekatan ini disebut Tail Drop dan Head Drop .

Jatuhkan Ekor dan Jatuhkan Kepala

Tail Drop - mekanisme manajemen antrian yang paling sederhana - buang semua paket yang baru tiba yang tidak muat di buffer.



Head Drop menjatuhkan paket yang telah antri untuk waktu yang sangat lama. Lebih baik membuangnya daripada menyimpan, karena kemungkinan besar itu tidak berguna. Tetapi paket yang lebih relevan yang tiba pada akhir antrian akan memiliki lebih banyak kesempatan untuk tiba tepat waktu. Plus, Head Drop memungkinkan Anda untuk tidak memuat jaringan dengan paket yang tidak perlu. Secara alami, paket tertua adalah paket yang ada di kepala antrian, maka itulah nama pendekatannya.



Head Drop memiliki keuntungan lain yang tidak jelas - jika Anda menjatuhkan paket di awal antrian, penerima akan segera mencari tahu tentang kemacetan di jaringan dan memberi tahu pengirim. Dalam kasus Tail Drop, informasi tentang paket yang dijatuhkan akan mencapai, mungkin, ratusan milidetik kemudian - sampai diperoleh dari ekor garis ke kepalanya.

Kedua mekanisme bekerja dengan diferensiasi pada gilirannya. Faktanya, tidak perlu seluruh buffer penuh. Jika antrian kedua kosong, dan yang nol ke bola mata, maka hanya paket dari nol yang akan dibuang.



Tail Drop dan Head Drop dapat bekerja secara bersamaan.

---

Tail dan Head Drop adalah “Dahi” yang Menghindari Kemacetan. Anda bahkan dapat mengatakan - ini adalah ketidakhadirannya.
Kami tidak melakukan apa pun hingga antrian 100% penuh. Dan setelah itu, kita mulai membuang semua paket yang baru tiba (atau ditunda dalam waktu lama).

Jika Anda tidak perlu melakukan apa pun untuk mencapai tujuan, maka di suatu tempat ada nuansa.
Dan nuansa ini adalah TCP.

Ingat ( lebih dalam dan sangat dalam ) bagaimana TCP bekerja - kita berbicara tentang implementasi modern.

Ada Sliding Window (Sliding Window atau rwnd - Reciever's Advertised Window ), yang dikendalikan oleh penerima, memberi tahu pengirim berapa yang dapat dikirim.

Dan ada jendela kelebihan ( CWND - Congestion Window), yang merespons masalah jaringan dan dikendalikan oleh pengirim.

Proses transfer data dimulai dengan awal yang lambat ( Slow Start ) dengan peningkatan eksponensial dalam CWND. Dengan setiap segmen yang dikonfirmasi, 1 ukuran MSS ditambahkan ke CWND, yaitu, pada kenyataannya, itu berlipat ganda dalam waktu yang sama dengan RTT (data di sana, ACK kembali) (Pidato tentang Reno / NewReno).

Sebagai contoh



Pertumbuhan eksponensial berlanjut ke nilai yang disebut ssthreshold (Slow Start Threshold), yang ditentukan dalam konfigurasi TCP pada host.

Selanjutnya, pertumbuhan linier 1 / CWND dimulai untuk setiap segmen yang dikonfirmasi sampai itu bertumpu pada RWND atau kerugian dimulai (kerugian dikonfirmasi dengan konfirmasi ulang (Duplikasi ACK) atau tidak ada konfirmasi sama sekali).

Segera setelah kehilangan segmen terdeteksi, TCP Backoff terjadi - TCP secara drastis mengurangi jendela, sebenarnya mengurangi kecepatan pengiriman - dan mekanisme Pemulihan Cepat dimulai :

1. mengirim segmen yang hilang (Pengiriman Cepat),
2. jendela digandakan,
3. Nilai ssthreshold juga menjadi sama dengan setengah dari jendela yang tercapai,
4. pertumbuhan linear dimulai lagi sampai kerugian pertama,
5. Ulangi

Kehilangan bisa berarti kehancuran total segmen jaringan dan kemudian menganggap bahwa itu hilang, atau kemacetan di telepon (baca buffer overflow dan buang segmen dari sesi ini).
Ini adalah metode TCP untuk memaksimalkan pemanfaatan bandwidth yang tersedia dan menangani kemacetan. Dan itu cukup efektif.

Namun, apa yang menyebabkan Drop Drop?

1. Katakanlah melalui router terletak jalur ribuan sesi TCP. Di beberapa titik, lalu lintas sesi mencapai 1,1 Gb / s, kecepatan antarmuka keluaran - 1 Gb / s.
2. Lalu lintas datang lebih cepat dari daun, buffer diisi vsklyan .
3. Tail Drop dinyalakan sampai operator mengeluarkan beberapa paket dari antrian.
4. Fast Recovery ( Slow Start).
5. , , Tail Drop .
6. TCP- , .
7. .
8. Fast Recovery/Slow Start.
9. .

Pelajari lebih lanjut tentang perubahan mekanisme TCP di RFC 2001 ( TCP Slow Start, Congestion Avoidance, Fast Retransmit, dan Fast Recovery Algorithms ).

Ini adalah ilustrasi khas dari situasi yang disebut Global TCP Synchronization :



Global karena banyak sesi yang dibuat melalui node ini menderita.
Sinkronisasi , karena mereka menderita pada saat bersamaan. Dan situasinya akan diulang sampai ada kelebihan.

TCP - karena UDP, yang tidak memiliki mekanisme kontrol kemacetan, tidak terpengaruh olehnya.

Tidak ada hal buruk yang akan terjadi dalam situasi ini jika tidak menyebabkan penggunaan strip yang tidak optimal - celah di antara gigi gergaji - uang yang terbuang.

Masalah kedua adalah TCP Starvation - TCP depletion. Sementara TCP melambat untuk mengurangi beban (jangan cerdik - pertama-tama, agar dapat benar-benar mengirimkan data kami), UDP, semua penderitaan moral ini secara umum oleh datagram - mengirimkan sebanyak mungkin.

Jadi, jumlah lalu lintas TCP berkurang, dan UDP tumbuh (mungkin), siklus Loss - Fast Recovery berikutnya terjadi pada batas bawah. UDP membutuhkan ruang. Jumlah total lalu lintas TCP turun.

Cara mengatasi masalah, lebih baik menghindarinya. Mari kita coba mengurangi beban sebelum mengisi antrian menggunakan Fast Recovery / Slow Start, yang baru saja melawan kita.

RED - Deteksi Dini Acak

Tetapi bagaimana jika kita mengambil dan mengoleskan tetes pada beberapa bagian buffer?

Secara relatif, mulailah menjatuhkan paket acak ketika antrian 80% penuh, memaksa beberapa sesi TCP untuk mengurangi jendela dan, karenanya, kecepatan.

Dan jika antriannya 90% penuh, kita mulai secara acak menjatuhkan 50% dari paket.
90% - probabilitas tumbuh hingga Tail Drop (100% dari paket baru dibuang).

Mekanisme yang menerapkan manajemen antrian seperti itu disebut Manajemen Antrian AQM - Adaptif (atau Aktif).

Inilah cara kerja RED .
Deteksi Dini - memperbaiki potensi kelebihan;
Acak - buang paket secara acak.
Terkadang mereka mendekode RED (menurut saya, secara semantik lebih tepat), seperti Random Early Discard.

Secara grafis, tampilannya seperti ini:





Sampai buffer penuh 80%, paket tidak dibuang sama sekali - probabilitasnya 0%.
Dari 80 hingga 100 paket mulai dibuang, dan semakin banyak mengisi antrian.
Jadi persentasenya tumbuh dari 0 menjadi 30.

Efek samping dari RED adalah bahwa sesi-sesi TCP yang agresif lebih cenderung melambat, hanya karena ada banyak paket dan mereka lebih cenderung untuk dijatuhkan.

Ketidakefisienan menggunakan strip RED teratasi dengan menumpulkan bagian yang jauh lebih kecil dari sesi tanpa menyebabkan penurunan serius antar gigi.
Tepat karena alasan yang sama, UDP tidak dapat menempati semuanya.

WRED - Deteksi Dini Acak Tertimbang

Tetapi pada sidang semua, mungkin, masih MENULIS . Pembaca linkmeup yang cerdik telah menyarankan bahwa ini adalah RED yang sama, tetapi berbobot secara bergantian. Dan dia tidak benar.
RED beroperasi dalam antrian yang sama. Tidak masuk akal untuk melihat kembali ke EF jika BE penuh. Dengan demikian, menimbang secara bergantian tidak akan membawa apa-apa.
Di sini Drop Precedence hanya berfungsi.

Dan dalam antrian yang sama, paket dengan prioritas drop yang berbeda akan memiliki kurva yang berbeda. Semakin rendah prioritas, semakin besar kemungkinan akan dibanting.



Ada tiga kurva di sini:
Merah - lalu lintas kurang prioritas (dalam hal menjatuhkan), kuning - lebih, hijau - maksimum.
Lalu lintas merah mulai dibuang ketika buffer 20% penuh, dari 20 hingga 40 turun menjadi 20%, lalu Tail Drop.
Kuning mulai nanti - dari 30 hingga 50, dibuang hingga 10%, lalu - Tail Drop.
Hijau adalah yang paling rentan: dari 50 hingga 100, ia tumbuh dengan lancar hingga 5%. Berikutnya adalah Drop Tail.
Dalam kasus DSCP, ini bisa AF11, AF12 dan AF13, masing-masing hijau, kuning dan merah.



Sangat penting di sini bahwa ia bekerja dengan TCP dan sama sekali tidak berlaku untuk UDP.
Atau aplikasi menggunakan UDP mengabaikan kerugian, seperti dalam hal telepon atau streaming video, dan ini berdampak negatif pada apa yang dilihat pengguna.

Atau aplikasi itu sendiri mengontrol pengiriman dan meminta Anda mengirim ulang paket yang sama. Namun, tidak perlu meminta sumber untuk menurunkan laju transmisi. Dan alih-alih mengurangi beban, peningkatan adalah karena transmisi ulang.

Itulah sebabnya hanya Tail Drop yang digunakan untuk EF.

Untuk CS6, CS7, Tail Drop juga digunakan, karena tidak ada kecepatan tinggi yang diasumsikan dan WRED tidak akan menyelesaikan apa pun.

Untuk AF, WRED diterapkan. AFxy, di mana x adalah kelas layanan, yaitu, antrian tempat ia jatuh, dan y adalah prioritas drop - warna yang sama.

Untuk BE, keputusan dibuat berdasarkan lalu lintas yang berlaku dalam antrian ini.

Dalam satu router, label internal paket khusus digunakan, berbeda dari yang membawa header. Oleh karena itu, MPLS dan 802.1q, di mana tidak mungkin untuk menyandikan Drop Precedence, dapat diproses dalam antrian dengan prioritas penurunan yang berbeda.
Sebagai contoh, paket MPLS datang ke sebuah node, itu tidak menanggung pelabelan Drop Precedence, namun, menurut hasil pemolesan, itu berubah menjadi kuning dan dapat dibuang sebelum ditempatkan dalam antrian (yang dapat ditentukan oleh bidang Kelas Lalu Lintas).

Perlu diingat bahwa seluruh pelangi ini hanya ada di dalam simpul. Tidak ada konsep warna di garis antara tetangga.

Meskipun dimungkinkan, tentu saja, untuk menyandikan warna di bagian Drop Precedence dari DSCP.

Drops juga dapat muncul di jaringan yang dibongkar, di mana kelihatannya tidak ada antrian yang melimpah. Bagaimana?
Alasan untuk ini mungkin semburan singkat - semburan - lalu lintas. Contoh paling sederhana - 5 aplikasi pada saat yang sama memutuskan untuk mentransfer lalu lintas ke satu host ujung.
Contohnya lebih rumit - pengirim terhubung melalui antarmuka 10 Gb / s, dan penerima adalah 1 Gb / s. Lingkungan itu sendiri memungkinkan Anda untuk membuat paket lebih cepat pada pengirim. Ethernet Flow Control penerima meminta host terdekat untuk memperlambat, dan paket mulai menumpuk di buffer.

---

Nah, apa yang harus dilakukan ketika semuanya memburuk?

7. Manajemen Kemacetan

Ketika semuanya buruk, prioritas pemrosesan harus diberikan pada lalu lintas yang lebih penting. Pentingnya setiap paket ditentukan pada tahap klasifikasi.

Tetapi apa yang buruk?

Tidak semua buffer harus tersumbat agar aplikasi mulai mengalami masalah.
Contoh paling sederhana adalah paket suara, yang berkerumun di sekitar paket besar paket besar aplikasi yang mengunduh file.

Ini akan meningkatkan penundaan, merusak jitter, dan mungkin menyebabkan tetes.
Artinya, kami memiliki masalah dengan menyediakan layanan berkualitas tanpa adanya kemacetan yang sebenarnya.

Masalah ini dirancang untuk menyelesaikan mekanisme Manajemen Kemacetan.
Lalu lintas aplikasi yang berbeda dibagi menjadi antrian, seperti yang kita lihat di atas.
Tetapi hanya sebagai hasilnya, semuanya harus kembali bergabung menjadi satu antarmuka. Serialisasi masih terjadi secara berurutan.

Bagaimana cara antrian yang berbeda mengelola untuk memberikan tingkat layanan yang berbeda?
Hapus paket dari antrian yang berbeda dengan cara yang berbeda.

Dispatcher terlibat dalam hal ini.

Kami akan mempertimbangkan mayoritas pengirim hari ini, dimulai dengan yang paling sederhana:

• FIFO - hanya satu baris, semuanya dalam BE, C - ketidakadilan.
• PQ - jalan menuju oligarki, antek memberi jalan.
• FQ - semua sama.
• DWRR - semua sama, tetapi beberapa lebih merata.

FIFO - First In, First Out

Kasus paling sederhana, sebenarnya tidak adanya QoS, adalah bahwa semua lalu lintas ditangani dengan cara yang sama - dalam satu antrian.

Paket meninggalkan antrian persis sesuai urutan mereka sampai di sana, maka namanya: pertama kali dimasukkan - pertama dan kiri .

FIFO bukanlah pengirim dalam arti penuh kata, atau mekanisme DiffServ secara umum, karena ia tidak benar-benar memisahkan kelas.

Jika antrian mulai terisi, penundaan dan jitter mulai tumbuh, Anda tidak dapat mengelolanya karena Anda tidak dapat menarik paket penting dari tengah antrian.

Sesi TCP agresif dengan ukuran paket 1.500 byte dapat menempati seluruh antrian, menyebabkan paket suara kecil menderita.

Di FIFO, semua kelas bergabung ke CS0.



Namun, terlepas dari semua kekurangan ini, beginilah cara kerja Internet sekarang.

Sebagian besar vendor FIFO sekarang menjadi dispatcher default dengan satu antrian untuk semua lalu lintas transit dan satu lagi untuk paket layanan yang dihasilkan secara lokal.
Sederhana, sangat murah. Jika salurannya lebar dan ada sedikit lalu lintas, semuanya baik-baik saja.
Inti dari gagasan bahwa QoS - untuk orang miskin - perluas band, dan pelanggan akan puas, dan gaji Anda akan meningkat beberapa kali lipat.

Hanya dengan cara ini peralatan jaringan pernah bekerja.
Tetapi segera dunia dihadapkan dengan fakta bahwa itu tidak akan berhasil.
Dengan tren jaringan konvergensi, menjadi jelas bahwa berbagai jenis lalu lintas (layanan, suara, multimedia, selancar internet, berbagi file) memiliki persyaratan jaringan yang berbeda secara fundamental.

FIFO tidak cukup, sehingga mereka membuat beberapa antrian dan mulai menghasilkan skema penjadwalan lalu lintas.

Namun, FIFO tidak pernah meninggalkan kehidupan kita: di dalam setiap antrian, paket selalu diproses sesuai dengan prinsip FIFO.

PQ - Antrian Prioritas

Mekanisme kedua yang paling rumit dan upaya untuk membagi layanan ke dalam kelas adalah antrian prioritas .

Lalu lintas sekarang ditata dalam beberapa antrian sesuai dengan prioritas kelasnya (misalnya, meskipun tidak harus, BE yang sama, AF1-4, EF, CS6-7). Dispatcher melewati antrian satu demi satu.

Pertama, ia melompati semua paket dari antrian prioritas tertinggi, lalu dari kurang, lalu dari kurang. Dan dalam lingkaran.

Dispatcher tidak mulai mengambil paket prioritas rendah sampai antrian prioritas tinggi kosong.



Jika, pada saat memproses paket prioritas rendah, sebuah paket tiba dalam antrian prioritas yang lebih tinggi, operator akan beralih ke paket itu dan hanya setelah mengosongkannya kembali ke paket lainnya.



PQ bekerja hampir sebaik FIFO.

Ini bagus untuk jenis lalu lintas seperti paket protokol dan suara, di mana penundaan sangat penting dan total volume tidak terlalu besar.

Nah, Anda harus mengakui, Anda tidak boleh menyimpan BFD Halo karena fakta bahwa beberapa potongan video besar dari YouTube telah datang?

Tapi di sini letak kurangnya PQ - jika antrian prioritas dimuat dengan lalu lintas, operator tidak akan pernah beralih ke yang lain sama sekali.

Dan jika beberapa Dokter Jahat, dalam mencari metode menaklukkan dunia, memutuskan untuk menandai semua lalu lintas jahatnya dengan tanda hitam tertinggi, semua yang lain akan dengan patuh menunggu dan kemudian dibuang.

Tidak perlu berbicara tentang jalur yang dijamin untuk setiap jalur.
Antrian prioritas tinggi dapat dipotong oleh kecepatan lalu lintas yang diproses di dalamnya. Maka orang lain tidak akan kelaparan. Namun, mengendalikan ini tidak mudah.

---

Mekanisme berikut berjalan melalui semua antrian pada gilirannya, mengambil dari mereka sejumlah data, sehingga memberikan kondisi yang lebih jujur. Tetapi mereka melakukannya secara berbeda.

Antrian FQ-Fair

Pesaing berikutnya untuk peran dispatcher yang ideal adalah mekanisme antrian yang adil .

FQ - Antrian yang Adil

Sejarahnya dimulai pada tahun 1985, ketika John Nagle menyarankan untuk membuat antrian untuk setiap aliran data. Dalam semangat, ini dekat dengan pendekatan IntServ dan mudah dijelaskan oleh fakta bahwa gagasan kelas layanan, seperti DiffServ, tidak ada saat itu.

FQ mengekstraksi jumlah data yang sama dari setiap antrian secara berurutan.

Kejujuran terletak pada kenyataan bahwa operator tidak beroperasi dengan jumlah paket, tetapi dengan jumlah bit yang dapat ditransmisikan dari setiap antrian.

Jadi aliran TCP yang agresif tidak dapat membanjiri antarmuka, dan semua orang mendapat peluang yang sama.
Secara teori. FQ tidak pernah diimplementasikan dalam praktik sebagai mekanisme untuk mengirimkan antrian dalam peralatan jaringan.

Ada tiga kelemahan:
Yang pertama - jelas - sangat mahal - untuk memulai antrian untuk setiap aliran, menghitung bobot setiap paket dan selalu khawatir tentang bit yang akan dilewati dan ukuran paket.
Yang kedua - kurang jelas - semua utas mendapatkan peluang yang sama dalam hal bandwidth. Dan jika saya ingin tidak setara?
Yang ketiga - tidak jelas - kejujuran FQ adalah mutlak: setiap orang memiliki penundaan yang sama, tetapi ada utas yang lebih penting daripada penundaan daripada band.
Misalnya, di antara 256 aliran ada yang bersuara, yang berarti masing-masing hanya akan mencapai dari 256 utas.
Dan apa yang harus dilakukan dengan mereka tidak jelas.



Di sini Anda dapat melihat bahwa karena ukuran besar paket di tahap ke-3, dalam dua siklus pertama kami memproses satu paket dari dua paket pertama.

Deskripsi mekanisme bit-by-bit dari Round Robin dan GPS sudah di luar cakupan artikel ini, dan saya merujuk pembaca ke studi independen .

WFQ - Antrian Cukup Tertimbang

Kelemahan kedua dan sebagian ketiga dari FQ mencoba untuk menutup WFQ, yang diterbitkan pada tahun 1989.
Setiap antrian diberkahi dengan berat dan, karenanya, hak untuk memberikan lalu lintas dalam beberapa berat untuk satu siklus.
Berat dihitung berdasarkan dua parameter: masih relevan kemudian IP Precedence dan panjang paket.

Dalam konteks WFQ, semakin berat, semakin buruk.
Oleh karena itu, semakin tinggi IP Precedence, semakin rendah berat paket.
Semakin kecil ukuran paket, semakin kecil bobotnya.
Dengan demikian, paket kecil prioritas tinggi mendapatkan sumber daya terbanyak, sementara raksasa prioritas rendah menunggu.
Dalam ilustrasi di bawah, paket menerima bobot sedemikian sehingga pada awalnya satu paket dari antrian pertama dilewati, kemudian dua dari yang kedua, lagi dari yang pertama dan hanya kemudian yang ketiga diproses. Jadi, misalnya, bisa terjadi jika ukuran paket di tahap kedua relatif kecil.



Tentang rekayasa keras WFQ, dengan waktu penyelesaian paketnya, waktu virtual dan Teorema Wig, Anda dapat membaca dalam dokumen warna yang aneh .

Namun, ini tidak menyelesaikan masalah pertama dan ketiga. Pendekatan Flow Based sama merepotkannya, dan aliran yang membutuhkan penundaan singkat dan jitter stabil tidak menerimanya.
Namun, ini tidak mencegah WFQ digunakan di beberapa perangkat Cisco (sebagian besar sudah tua). Ada hingga 256 antrian di mana utas ditempatkan berdasarkan hash header mereka. Kompromi antara paradigma Berbasis Aliran dan sumber daya yang terbatas.

CBWFQ - WFQ Berbasis Kelas

CBWFQ membuat pendekatan untuk masalah kompleksitas dengan munculnya DiffServ. Agregat Perilaku mengklasifikasikan semua kategori lalu lintas ke dalam 8 kelas dan, karenanya, harus antri. Ini memberinya nama dan antrian sangat disederhanakan.

Berat dalam CBWFQ telah memperoleh arti yang berbeda. Bobot ditugaskan ke kelas (bukan utas) secara manual dalam konfigurasi atas permintaan administrator, karena bidang DSCP sudah digunakan untuk klasifikasi.

Artinya, DSCP menentukan antrian mana yang akan dimasukkan, dan bobot yang dikonfigurasi - berapa banyak jalur yang tersedia untuk antrian ini.

Yang paling penting, ini secara tidak langsung membuat hidup dan latensi rendah mengalir sedikit lebih mudah, yang sekarang dikumpulkan menjadi satu (dua-tiga ...) antrian dan menerima poin tinggi mereka jauh lebih sering. Hidup menjadi lebih baik, tetapi masih tidak baik - tidak ada jaminan sama sekali - secara umum, di WFQ semuanya masih sama dalam hal keterlambatan.

Dan kebutuhan untuk memonitor ukuran paket secara konstan, fragmentasi dan defragmentasi, belum hilang.

CBWFQ + LLQ - Antrian Latensi Rendah

Pendekatan terakhir, puncak dari pendekatan sedikit demi sedikit, adalah penyatuan CBWFQ dengan PQ.
Salah satu antrian menjadi yang disebut LLQ (antrian latensi rendah), dan sementara semua antrian lainnya diproses oleh manajer CBWFQ, manajer PQ berjalan antara LLQ dan yang lainnya.

Artinya, sementara ada paket di LLQ, antrian yang tersisa sedang menunggu, penundaan mereka meningkat. Segera setelah paket di LLQ habis, kami pergi untuk memproses sisanya. Paket muncul di LLQ - mereka lupa sisanya, dikembalikan ke sana.

FIFO juga berfungsi di dalam LLQ, jadi Anda tidak harus mendorong semuanya tanpa sampai di sana, meningkatkan pemanfaatan buffer dan menunda pada saat yang sama.

Namun demikian, agar antrian non-prioritas tidak kelaparan, ada baiknya untuk menetapkan batas bandwidth dalam LLQ.



Jadi, domba penuh dan serigala aman.

RR - Round-Robin

Bergandengan tangan dengan FQ dan RR .
Yang satu jujur, tapi tidak sederhana. Yang lainnya justru sebaliknya.



RR melewati antrian, mengekstraksi jumlah paket yang sama dari mereka. Pendekatan ini lebih primitif daripada FQ, dan karena itu tidak jujur ​​dalam kaitannya dengan berbagai aliran. Sumber agresif dapat dengan mudah membanjiri strip dengan paket berukuran 1500 byte.

Namun, itu sangat sederhana untuk diterapkan - Anda tidak perlu mengetahui ukuran paket dalam antrian, memecahnya, dan kemudian mengumpulkannya kembali.

Namun, ketidakadilannya dalam alokasi strip memblokir jalannya ke dunia - di dunia jaringan, Round-Robin murni tidak diimplementasikan.

WRR - Robin Round Tertimbang

Nasib yang sama adalah dengan WRR, yang menambah bobot antrian berdasarkan IP Precedence. Di WRR, tidak ada jumlah paket yang sama diambil, tetapi kelipatan dari berat antrian.

Adalah mungkin untuk memberikan bobot lebih kepada antrian dengan paket yang lebih kecil, tetapi untuk melakukan ini secara dinamis tidak mungkin.

DWRR - Round Round Weighted Defisit

Dan tiba-tiba, pendekatan yang sangat aneh pada tahun 1995 diusulkan oleh M. Shreedhar dan G. Varghese.
Setiap baris memiliki batas kredit terpisah dalam bit.

Ketika melewati dari antrian, banyak paket dikeluarkan karena ada cukup kredit.

Ukuran paket di kepala antrian dikurangi dari jumlah pinjaman.
Jika perbedaannya lebih besar dari nol, paket ini dihapus dan yang berikutnya dicentang. Jadi sampai selisihnya kurang dari nol.

Jika bahkan paket pertama tidak memiliki kredit yang cukup, well, sayang sekali, aliran lumpur, dia tetap dalam antrian.
Sebelum lulus berikutnya, kredit setiap baris dinaikkan dengan jumlah tertentu, yang disebut kuantum .

Untuk antrian yang berbeda, kuantum berbeda - semakin besar band yang perlu Anda berikan, semakin besar kuantum.

Dengan demikian, semua antrian menerima bandwidth yang dijamin, terlepas dari ukuran paket di dalamnya.



Dari penjelasan di atas, tidak akan jelas bagi saya cara kerjanya.


Dengan DWRR, pertanyaannya tetap dengan jaminan keterlambatan dan jitter - bobot tidak menyelesaikannya dengan cara apa pun.
Secara teoritis, Anda dapat melakukan hal yang sama dengan CB-WFQ, menambahkan LLQ.

Namun, ini hanya salah satu skenario yang mungkin dari popularitas yang berkembang saat ini.

PB-DWRR - DWRR Berbasis Prioritas

Sebenarnya, arus utama hari ini adalah PB-DWRR - Round Round Weighted Defisit Berbasis Prioritas.

Ini adalah DWRR jahat lama yang sama, di mana antrian lain ditambahkan - prioritas, di mana paket diproses dengan prioritas yang lebih tinggi. Ini tidak berarti bahwa dia diberi strip yang lebih besar, tetapi paket akan diambil dari sana lebih sering.



Ada beberapa pendekatan untuk mengimplementasikan PB-DWRR. Dalam beberapa dari mereka, seperti dalam PQ, paket apa pun yang tiba di antrian prioritas segera dihapus. Di tempat lain, ini diakses setiap kali operator bergerak di antara antrian. Ketiga, kredit dan kuantum diperkenalkan untuk itu, sehingga antrian prioritas tidak dapat menekan seluruh strip.
Tentu saja, kami tidak akan menganalisisnya.

Ringkasan singkat tentang mekanisme pengiriman

Selama beberapa dekade, umat manusia telah berusaha untuk memecahkan masalah yang paling sulit yaitu memastikan tingkat layanan yang tepat dan distribusi band yang adil. Antrian adalah alat utama, satu-satunya pertanyaan adalah bagaimana mendapatkan paket dari antrian, mencoba mendorong mereka ke dalam satu antarmuka.

Dimulai dengan FIFO, ia menemukan PQ - suara itu bisa hidup berdampingan dengan selancar, tetapi tidak ada pertanyaan untuk menjamin band.

Beberapa FQ mengerikan, WFQ muncul, yang bekerja jika tidak per-aliran, maka hampir seperti itu. CB-WFQ datang ke masyarakat kelas, tetapi tidak menjadi lebih mudah.

Sebagai alternatif, ia mengembangkan RR. Itu menjadi WRR, dan kemudian DWRR.
Dan di kedalaman masing-masing dispatcher tinggal FIFO.

Namun, seperti yang Anda lihat, tidak ada operator universal yang menangani semua kelas yang mereka butuhkan. Itu selalu merupakan kombinasi dari operator, salah satunya memecahkan masalah memastikan keterlambatan, jitter dan kurangnya kerugian, dan yang lainnya mengalokasikan band.
CBWFQ + LLQ atau PB-WDRR atau WDRR + PQ.

Pada peralatan nyata, Anda dapat menentukan antrian mana yang akan diproses dengan operator mana.

CBWFQ, WDRR dan turunannya adalah favorit saat ini.
PQ, FQ, WFQ, RR, WRR - kami tidak bersedih dan tidak ingat (kecuali, tentu saja, kami sedang mempersiapkan CCIE Clipper).

---

Jadi, operator dapat menjamin kecepatan, tetapi bagaimana cara membatasinya dari atas?

8. Batas kecepatan

Kebutuhan untuk membatasi kecepatan lalu lintas pada pandangan pertama sudah jelas - jangan biarkan klien keluar dari bandnya sesuai perjanjian.

YaTapi tidak hanya itu. Misalkan ada rentang RRL 620 Mb / s lebar terhubung melalui port 1Gb / s. Jika Anda memasukkan seluruh gigabit ke dalamnya, maka di suatu tempat di RRL, yang, kemungkinan besar, tidak tahu tentang antrian dan QoS, tetesan mengerikan yang bersifat acak akan dimulai, tidak terikat dengan prioritas sebenarnya dari lalu lintas.

Namun, jika Anda mengaktifkan pembentukan hingga 600 Mb / s pada router, maka EF, CS6, CS7 tidak akan dibuang sama sekali, dan di BE, AFx, pita dan tetesan akan didistribusikan sesuai dengan bobotnya. RRL akan mencapai 600 Mb / s dan kami akan mendapatkan gambar yang dapat diprediksi.

Contoh lain adalah Kontrol Penerimaan. Misalnya, dua operator sepakat untuk mempercayai tanda masing-masing, kecuali untuk CS7 - jika ada yang datang di CS7 - buang. Untuk CS6 dan EF - berikan antrian terpisah dengan jaminan keterlambatan dan tanpa kehilangan.

Tapi, bagaimana jika pasangan licik itu mulai menuangkan torrents ke jalur ini? Selamat tinggal Telephony. Dan protokol kemungkinan besar akan berantakan.

Adalah logis dalam hal ini untuk setuju dengan mitra tentang strip. Segala sesuatu yang sesuai dengan kontrak dilewati. Apa yang tidak cocok - buang atau transfer ke antrian lain - BE, misalnya. Dengan demikian, kami melindungi jaringan dan layanan kami.

Ada dua pendekatan yang berbeda secara mendasar untuk pembatasan kecepatan: memoles dan membentuk. Mereka memecahkan satu masalah, tetapi dengan cara yang berbeda.

Pertimbangkan perbedaan menggunakan contoh profil lalu lintas seperti itu:

Pemolisian lalu lintas

Pemolisian membatasi kecepatan dengan menjatuhkan lalu lintas berlebih.
Segala sesuatu yang melebihi nilai yang ditetapkan, poliser memotong dan membuang.



Apa yang dipotong dilupakan. Gambar menunjukkan bahwa paket merah tidak dalam lalu lintas setelah polyser.

Dan inilah tampilan profil yang dipilih setelah polyser:



Karena tingkat keparahan tindakan yang diambil, ini disebut Hard Policing .
Namun, ada beberapa kemungkinan tindakan lain.
Polisi biasanya bekerja bersama dengan pengukur lalu lintas. Meteran warna tas, seperti yang Anda ingat, hijau, kuning atau merah.
Dan atas dasar warna ini, polyser mungkin tidak membuang paket, tetapi menempatkannya di kelas lain. Ini adalah tindakan lunak - Soft Policing .
Ini dapat diterapkan baik untuk lalu lintas masuk dan lalu lintas keluar.
Fitur khas dari polyser adalah kemampuan untuk menyerap ledakan lalu lintas dan menentukan kecepatan maksimum yang diijinkan berkat mekanisme Token Bucket.
Kenyataannya, segala sesuatu yang tidak di atas nilai yang ditetapkan tidak terpotong - ia diizinkan untuk sedikit melampaui itu - ledakan singkat atau kelebihan kecil dari pita yang dialokasikan dilewati.

Nama "Pemolisian" ditentukan oleh rasio alat yang agak ketat terhadap lalu lintas berlebih - membuang atau menurunkan pangkat ke kelas bawah.

Pembentukan lalu lintas

Membentuk membatasi kecepatan dengan melindungi lalu lintas yang berlebih.

Semua lalu lintas masuk melewati buffer. Pembentuk menghapus paket dari buffer ini dengan kecepatan konstan.

Jika tingkat kedatangan paket ke buffer lebih rendah dari output, mereka tidak ditunda dalam buffer - mereka terbang menembus.

Dan jika tingkat kedatangan lebih tinggi dari output, mereka mulai menumpuk.
Kecepatan output selalu sama.
Dengan demikian, ledakan lalu lintas ditambahkan ke buffer dan akan dikirim ketika mereka mencapai antrian.
Oleh karena itu, bersama dengan penjadwalan dalam antrian, membentuk adalah alat kedua yang berkontribusi terhadap keterlambatan total .



Ilustrasi dengan jelas menunjukkan bagaimana paket tiba pada waktu buffer t2 tiba pada waktu t3 pada output. t3-t2 adalah penundaan yang diperkenalkan oleh pembentuk.

Pembentuk biasanya diterapkan pada lalu lintas keluar.

Ini adalah bagaimana profil terlihat setelah pembentuk.



Nama "Shaping" menunjukkan bahwa alat memberikan bentuk lalu lintas profil, melicinkannya.

Keuntungan utama dari pendekatan ini adalah penggunaan optimal dari band yang ada - daripada menjatuhkan lalu lintas yang berlebihan, kami menundanya.

Kelemahan utama adalah penundaan tak terduga - ketika buffer penuh, paket akan merana di dalamnya untuk waktu yang lama. Karena itu, pembentukan tidak cocok untuk semua jenis lalu lintas.
Membentuk menggunakan mekanisme Bucket Leaky.

Membentuk versus polising

Pekerjaan polyser mirip dengan pisau, yang, bergerak di sepanjang permukaan minyak, memotong sisi tajam tubercle.
Pekerjaan pembentuk mirip dengan roller, yang menghaluskan tubercles, mendistribusikannya secara merata di atas permukaan.
Pembentuk mencoba untuk tidak menjatuhkan paket saat mereka buffered dengan biaya keterlambatan yang meningkat.
Pemoles tidak menyebabkan penundaan, tetapi lebih mudah membuang paket.

Aplikasi yang tidak sensitif terhadap penundaan, tetapi yang kerugiannya tidak diinginkan, harus dibatasi pada pembentuk.

Bagi mereka yang terlambat menerima paket yang sama dengan yang hilang, lebih baik langsung menjatuhkannya - kemudian dipoles.

Pembentuk tidak mempengaruhi header paket dan nasib mereka di luar node, sementara setelah memoles perangkat dapat mengklasifikasikan kelas di header. Sebagai contoh, pada input, paket memiliki kelas AF11, meteran mengecatnya kuning di dalam perangkat, pada output yang ditandai ulang kelasnya pada AF12 - pada node berikutnya ia akan memiliki kemungkinan menjatuhkan yang lebih tinggi.

---

Berlatih Polishing dan membentuk

Skemanya sama:



file konfigurasi. Kami

mengamati gambar ini tanpa menerapkan batasan:



Kami akan melanjutkan sebagai berikut:

• Pada antarmuka input, Linkmeup_R2 (e0 / 1) kami akan mengonfigurasi pemolesan - ini akan menjadi kontrol input. Berdasarkan perjanjian tersebut, kami memberikan 10 Mb / s.
• Pada antarmuka output, Linkmeup_R4 (e0 / 2), konfigurasikan shaping pada 20 Mb / s.

Mari kita mulai dengan pembentuk pada Linkmeup_R4 .

Cocokkan semuanya:

  class-map match-all TRISOLARANS_ALL_CM match any 

Bentuk hingga 20Mb / s:

  policy-map TRISOLARANS_SHAPING class TRISOLARANS_ALL_CM shape average 20000000 

Berlaku untuk antarmuka output:

  interface Ethernet0/2 service-policy output TRISOLARANS_SHAPING 

Segala sesuatu yang harus meninggalkan (output) antarmuka Ethernet0 / 2, bentuk hingga 20 Mb / s.

File konfigurasi pembentuk.

Dan inilah hasilnya:



Ternyata garis yang cukup datar dari total throughput dan grafik robek untuk setiap aliran individu.

Faktanya adalah bahwa kita membatasi pembentuk pada band umum. Namun, tergantung pada platform, aliran individual juga dapat dibentuk secara individual, sehingga memperoleh peluang yang sama.

---

Sekarang konfigurasikan pemolesan pada Linkmeup_R2.

Kami akan menambahkan polyser ke kebijakan yang ada.

  policy-map TRISOLARANS_ADMISSION_CONTROL class TRISOLARANS_TCP_CM police cir 10000000 bc 1875000 conform-action transmit exceed-action drop 

Kebijakan telah diterapkan ke antarmuka:

  interface Ethernet0/1 service-policy input TRISOLARANS_ADMISSION_CONTROL 

Di sini kami menunjukkan kecepatan rata-rata yang diizinkan CIR (10Mb / s) dan burst Bc yang diizinkan (1,875.000 byte sekitar 14,6 MB).

Kemudian, menjelaskan bagaimana polyser bekerja, saya akan memberi tahu Anda apa CIR dan Bc dan bagaimana menentukan nilai-nilai ini.

File konfigurasi polyser.

Gambar ini diamati dengan polysing. Perubahan mendadak pada tingkat kecepatan langsung terlihat:

---

Tapi gambar yang menarik diperoleh jika kita membuat ukuran burst yang diijinkan terlalu kecil, misalnya, 10.000 byte.

  police cir 10000000 bc 10000 conform-action transmit exceed-action drop 

Kecepatan keseluruhan segera turun menjadi sekitar 2Mb / s.
Hati-hati dengan pengaturan semburan :)

Tabel uji.

---

Bucket Leaky dan Token Bucket

Kedengarannya mudah dan jelas. Tetapi bagaimana cara kerjanya dalam praktik dan diimplementasikan dalam perangkat keras?

Sebuah contoh

Apakah batas 400 Mb / s banyak (atau sedikit)? Rata-rata, klien hanya menggunakan 320. Tapi kadang-kadang naik menjadi 410 selama 5 menit. Dan terkadang hingga 460 per menit. Dan terkadang hingga 500 selama setengah detik.
Sebagai linkmeup penyedia kontrak dapat katakan - 400 dan hanya itu! Jika Anda menginginkan lebih, sambungkan ke tarif 1Gb / dtk + 27 saluran anime.
Dan kami dapat meningkatkan loyalitas pelanggan jika ini tidak mengganggu orang lain dengan memungkinkan lonjakan tersebut.
Bagaimana mengizinkan 460 Mb / s hanya untuk satu menit, dan bukan 30 atau selamanya?
Bagaimana memungkinkan 500 Mb / s, jika band ini gratis, dan tekan ke 400, jika konsumen lain telah muncul?

Sekarang istirahat, tuangkan seember yang kuat.

Mari kita mulai dengan mekanisme sederhana yang digunakan oleh pembentuk - ember bocor.

Algoritma ember bocor

Leaky Bucket adalah ember bocor.



Kami memiliki ember dengan lubang ukuran tertentu di bagian bawah. Paket menuangkan / menuangkan ke dalam ember ini dari atas. Dan dari bawah, mereka mengalir pada laju bit yang konstan.

Ketika ember sudah penuh, paket-paket baru mulai dibuang.

Ukuran lubang ditentukan oleh batas kecepatan yang ditentukan, yang untuk Leaky Bucket diukur dalam bit per detik.

Volume bucket, kepenuhan dan kecepatan keluarannya menentukan penundaan yang diperkenalkan oleh pembentuk.
Untuk kenyamanan, volume bucket biasanya diukur dalam ms atau μs.

Dalam hal implementasi, Leaky Bucket adalah buffer reguler berdasarkan SD-RAM.

Bahkan jika pembentukan tidak dikonfigurasikan secara eksplisit, di hadapan semburan yang tidak masuk ke antarmuka, paket-paket sementara buffered dan ditransmisikan saat antarmuka menjadi bebas. Ini juga membentuk.

Bucket Leaky hanya digunakan untuk membentuk dan tidak cocok untuk memoles.

Algoritma Token Bucket

Banyak orang berpikir bahwa Token Bucket dan Leaking Bucket adalah hal yang sama. Hanya Einstein yang jauh lebih keliru, menambahkan konstanta kosmologis.

Mengganti chip tidak benar-benar mengerti jam berapa, mereka menjadi semakin buruk berapa bit yang ditransmisikan per unit waktu. Pekerjaan mereka adalah mengirik.

Apakah ini mendekati sedikit 400.000.000 bit per detik, atau sudah 400.000 001?



Pengembang ASIC memiliki tantangan rekayasa non-sepele.

Itu dibagi menjadi dua subtugas:

1. Sebenarnya membatasi kecepatan dengan membuang paket yang tidak perlu berdasarkan kondisi yang sangat sederhana. Dilakukan saat mengganti chip.
2. Menciptakan kondisi sederhana ini, yang berhubungan dengan chip yang lebih kompleks (lebih terspesialisasi), melacak waktu.

Algoritma yang memecahkan masalah kedua disebut Token Bucket. Idenya elegan dan sederhana (tidak).

Tugas Token Bucket adalah untuk melewatkan lalu lintas jika masuk dalam batasan dan membuang / mengecat merah jika tidak.

Penting untuk mengizinkan ledakan lalu lintas, karena ini normal.
Dan jika dalam Leaky Bucket burst buffer-buffered, maka Token Bucket tidak buffer apa pun.

Single Rate - Dua Warna Menandai

Untuk saat ini, jangan memperhatikan nama =)
Kami memiliki ember yang koinnya jatuh dengan kecepatan konstan - 400 megamonet per detik, misalnya.

Volume ember adalah 600 juta koin. Artinya, diisi dalam satu setengah detik.

Di dekatnya ada dua ban berjalan: satu mengirimkan paket, yang kedua membawa pergi.
Untuk sampai ke conveyor, paket harus membayar.
Untuk ini, ia mengambil koin dari ember sesuai dengan ukurannya. Secara kasar - berapa banyak bit - begitu banyak koin.





Jika ember kosong dan tidak ada cukup koin di dalam tas, ember itu dicat dengan warna merah dan dibuang. Sial, Selyava. Dalam hal ini, koin tidak dihapus dari ember.



Paket koin berikutnya mungkin sudah cukup - pertama, paket mungkin lebih kecil, dan, kedua, itu menyerang lebih banyak koin selama waktu ini.

Jika ember sudah penuh, semua koin baru akan dibuang.



Itu semua tergantung pada tingkat kedatangan paket dan ukurannya.
Jika secara stabil lebih rendah atau sama dengan 400 MB per detik, maka akan selalu ada cukup koin.
Jika lebih tinggi, maka beberapa paket akan hilang.

Contoh yang lebih spesifik dengan gif, seperti yang kita semua suka.

• Ada ember dengan kapasitas 2.500 byte. Pada awalnya, ini berisi 550 token.
  Ada tiga paket 1000 byte pada pipa yang ingin dikirim ke antarmuka.
  Pada setiap slot waktu, 500 byte jatuh ke dalam ember (500 * 8 = 4.000 bit / slot waktu - batas polyser).
• 500 . . 1000 , 1050 — . . 1000 .
  50 .
• 500 — 550. — 1000 — .
  , .
• 500 — 1050. — 1000 — .
  , .

2500 , 2500 — . MTU , , , 1,5-2 .

:

CBS = CIR ( )*1,5 ()/8 ( )

, (Bc), , (1 875 000 ) . (10 000 ), , MTU, .

Mengapa volume ember? Bitstream tidak selalu seragam, ini jelas. Batas 400 Mb / s bukan merupakan asimtot - lalu lintas dapat melintasinya. Volume koin yang disimpan memungkinkan semburan kecil untuk terbang tanpa dibuang, tetapi pertahankan kecepatan rata-rata pada 400Mb / s.

Misalnya, aliran stabil 399 Mb / s dalam 600 detik akan memungkinkan bucket terisi penuh.
Selanjutnya, lalu lintas dapat naik hingga 1000Mb / dtk dan tetap pada level ini selama 1 detik - 600 Mm (Megamonet) stok dan 400 Mm / dtk jaminan band.

Atau, lalu lintas dapat mencapai 410 Mb / s dan tetap seperti itu selama 60 detik.



Artinya, persediaan koin memungkinkan Anda sedikit melampaui batasan untuk waktu yang lama atau membuang lonjakan pendek namun tinggi.
Sekarang untuk terminologi.
Tingkat penerimaan koin dalam ember - CIR - Tingkat Informasi yang Diterapkan (Kecepatan rata-rata yang dijamin). Diukur dalam bit per detik.
Jumlah koin yang dapat disimpan dalam ember - CBS - Ukuran Burst yang Dikerjakan . Diizinkan ukuran burst maksimum. Diukur dalam byte. Kadang-kadang, seperti yang Anda perhatikan, ini disebut Bc .
Tc - Jumlah koin (Token) dalam ember C (CBS) saat ini.

" Tc ", , RFC 2697 ( A Single Rate Three Color Marker ).
Tc, , .
.
, , Token Bucket, TDM (Time-Division Multiplexing) — .
— , , .
CIR . .
, — , — , — .
, .
( Cisco) Tc , — Bc . Bc = CIR*Tc .
Tc Bc .

Ini adalah skenario paling sederhana. Ini disebut Tingkat Tunggal - Dua Warna .
Single Rate berarti hanya ada satu kecepatan rata-rata yang diperbolehkan, dan Two Color - Anda dapat mewarnai lalu lintas dalam satu dari dua warna: hijau atau merah.

1. Jika jumlah koin (bit) yang tersedia dalam ember C lebih besar dari jumlah bit yang perlu dilewati saat ini, paket tersebut berwarna hijau - kemungkinan jatuh yang rendah di masa depan. Koin dikeluarkan dari ember.
2. Jika tidak, paket dicat merah - probabilitas tinggi drop (atau, lebih sering, drop sesaat). Koin sehingga ember C ditarik .

Digunakan untuk memoles di PHB CS dan EF, di mana kecepatan tidak diharapkan, tetapi jika itu terjadi, lebih baik segera membuangnya.

Selanjutnya kami akan mempertimbangkan lebih sulit: Tingkat Tunggal - Tiga Warna.

Single Rate - Tiga Warna Menandai

Kerugian dari skema sebelumnya adalah hanya ada dua warna. Bagaimana jika kita tidak ingin kehilangan segalanya di atas kecepatan rata-rata yang diperbolehkan, tetapi ingin menjadi lebih loyal?
TCM-sr ( Single Rate - Tiga Warna The Menandai ) memasuki bucket kedua di - E . Pada saat ini, koin tidak ditempatkan dalam ember penuh dengan C , yang dituangkan ke dalam E . EBS



ditambahkan ke CIR dan CBS - Ukuran Kelebihan Berlebihan - Ukuran burst yang diizinkan selama puncak. Te - jumlah koin dalam ember E .



Katakanlah paket ukuran B datang sepanjang pipa. Lalu

1. C , . C B (: Tc — B).
2. C , E . , ( ), E B .
   
   
   
3. E , , .
   
   
   

Perhatikan bahwa untuk paket tertentu, Tc dan Te tidak kumulatif .
Artinya, paket dengan ukuran 8000 byte tidak akan lulus, bahkan jika ada 3000 koin dalam ember C , dan dalam koin E - 7000. Dalam C itu tidak cukup, di E itu tidak cukup - kita beri tanda merah - shurai dari sini.

Ini adalah desain yang sangat elegan. Semua lalu lintas yang termasuk dalam batasan CIR + CBS rata-rata (penulis tahu bahwa tidak mungkin untuk menambahkan bit / s dan byte secara langsung) - berwarna hijau. Pada saat-saat puncak, ketika klien kehabisan koin dalam ember C , ia masih memiliki persediaan Te dalam ember E yang terakumulasi selama waktu henti .

Artinya, Anda dapat melewati sedikit lebih banyak, tetapi dalam kasus kemacetan, mereka lebih cenderung dibuang.

sr-TCM dijelaskan dalam RFC 2697 .
Digunakan untuk memoles di PHB AF.

Nah, sistem terakhir adalah yang paling fleksibel dan karena itu kompleks - Dua Tingkat - Tiga Warna.

Dua Tingkat - Tiga Warna Menandai

Model Tr-TCM lahir dari gagasan bahwa itu tidak merugikan pengguna lain dan jenis lalu lintas, mengapa tidak memberi klien kesempatan yang lebih menyenangkan, atau penjualan yang lebih baik.
Mari kita beri tahu dia bahwa dia dijamin 400 Mb / s, dan jika ada sumber daya gratis, maka 500. Apakah Anda siap untuk membayar 30 rubel lebih banyak?

Ember P lainnya ditambahkan .

Jadi:

CIR - kecepatan rata-rata terjamin.
CBS adalah ukuran percikan yang diperbolehkan yang sama (volume ember C ).
PIR - Peak Information Rate - kecepatan rata-rata maksimum.
EBS - ukuran burst yang diizinkan selama puncak (Bucket Volume P ).

Tidak seperti sr-TCM, di tr-TCM, koin sekarang dikirim secara independen ke kedua ember. Di C - dengan kecepatan CIR, di P - PIR.



Apa aturannya?

Paket ukuran B byte tiba .

1. Jika tidak ada cukup koin dalam ember P , paket ditandai dengan warna merah. Koin tidak ditarik . Jika tidak:
2. Jika tidak ada cukup koin dalam ember C , paket ditandai kuning, dan koin B dikeluarkan dari ember P. Jika tidak:
3. Paket ditandai dengan warna hijau dan koin B diambil dari kedua ember .

Artinya, aturan dalam tr-TCM berbeda.

Selama lalu lintas jatuh dalam kecepatan yang dijamin, koin dihapus dari kedua ember. Berkat ini, ketika koin habis dalam ember C , mereka akan tetap di P , tetapi cukup agar tidak melebihi PIR (jika mereka dihapus hanya dari C , maka P akan mengisi lebih banyak dan memberikan kecepatan yang jauh lebih tinggi).

Dengan demikian, jika di atas dijamin, tetapi di bawah puncak, koin hanya dihapus dari P , karena di C sudah tidak ada.

Monitor tr-TCM tidak hanya meledak, tetapi juga kecepatan puncak konstan.

tr-TCM dijelaskan dalam RFC 2698 .
Juga digunakan untuk memoles di PHB AF.

---

Ringkasan batas kecepatan

Sambil membentuk menghambat lalu lintas saat terlampaui, memoles membuangnya.
Membentuk tidak cocok untuk aplikasi sensitif latensi dan jitter.
Untuk menerapkan pemolesan dalam perangkat keras, algoritma Token Bucket digunakan, untuk membentuk - Leaky Bucket.

Token Bucket dapat:

• Dengan satu ember - Satu Tingkat - Dua Penandaan Warna. Mengizinkan semburan yang valid.
• Dengan dua ember - Tingkat Tunggal - Tiga Penanda Warna (sr-TCM). Surplus dari bucket C (CBS) dituangkan ke dalam ember E. Memungkinkan gelombang yang diizinkan dan berlebihan.
• Dengan dua ember - Dua Tingkat - Tiga Penanda Warna (tr-TCM). Bucket C dan P (PBS) diisi ulang secara independen pada kecepatan yang berbeda. Mengizinkan kecepatan puncak dan semburan yang diijinkan dan berlebihan.

sr-TCM berfokus pada jumlah lalu lintas yang melebihi batas. tr-TCM - dengan kecepatan kedatangannya.

Polishing dapat digunakan pada input dan output dari perangkat. Pembentukan didominasi di pintu keluar.
Untuk PHB CS dan EF, Single Rate Two Color Marking digunakan.
Untuk AF, sr-TCM atau tr-TCM.

Untuk pemahaman yang lebih baik, saya sarankan merujuk ke RFC asli atau membaca di sini .

Token Bucket . , , , , .
, — , . , , , — .
, . — . .

---

Di atas, saya menjelaskan semua mekanisme dasar QoS, jika tidak masuk jauh ke QoS hierarkis. Sistem canggih dengan banyak bagian yang bergerak.
Semuanya baik-baik saja (kan?) Terdengar sejauh ini, tetapi apa yang terjadi di bawah panel eksternal vanilla router?

Selama bertahun-tahun, vendor telah menambahkan semakin banyak kontur, mengembangkan chip canggih, buffer yang diperluas, di satu sisi, untuk mengikuti peningkatan volume lalu lintas dan kategori baru, dan di sisi lain, untuk memecahkan masalah yang berkembang yang disebabkan oleh paragraf pertama.
Perlombaan yang sedang berlangsung. Paket tidak boleh hilang jika pesaing tidak kehilangannya. Anda tidak dapat menolak fungsi jika lawan berdiri di bawah pintu pelanggan.
Ida ke sarang kepemilikan!

9. Implementasi perangkat keras QoS

Dalam bab ini, saya mengambil tugas yang tidak tahu berterima kasih. Jika Anda menggambarkannya sesederhana mungkin, akan selalu ada orang-orang yang mengatakan bahwa semuanya tidak begitu dalam kenyataan.

Jika Anda menggambarkannya apa adanya, pembaca akan menjatuhkan artikel karena akan berubah menjadi gambar kapal selam, lebih tepatnya, gambar tiga kapal dengan pensil warna berbeda pada satu lembar.

Secara umum, saya akan membuat pernyataan bahwa dalam kenyataannya semuanya tidak sama dengan pada kenyataannya, dan saya akan mengikuti versi presentasi yang sederhana.

Maafkan saya sesama perfeksionis.

Apa yang mengontrol perilaku node dan memicu mekanisme yang sesuai dalam kaitannya dengan paket? Prioritas yang disandangnya di salah satu judul? Ya dan tidak



Seperti disebutkan di atas, di dalam perangkat jaringan, header switching standar biasanya tidak ada lagi.



Segera setelah sebuah paket tiba di chip switching, header dihapus dari itu dan dikirim untuk analisis, dan payload merana dalam semacam buffer sementara.

Berdasarkan header, klasifikasi (BA atau MF) terjadi dan keputusan dibuat tentang penerusan.

Setelah beberapa saat, tajuk internal dengan metadata tentang paket digantung pada paket.
Metadata ini membawa banyak informasi penting - alamat pengirim dan penerima, chip output, nomor seri sel, jika ada fragmentasi paket dan penandaan kelas (CoS) dan Drop Precedence adalah wajib. Hanya menandai dalam format internal - itu mungkin bertepatan dengan DSCP, atau mungkin tidak.

Pada prinsipnya, di dalam kotak Anda dapat menetapkan panjang tanda yang sewenang-wenang tanpa terikat dengan standar, dan menentukan tindakan yang sangat fleksibel dengan paket.

Di Cisco, penandaan internal disebut QoS Group, di Juniper - Forwarding Class, Huawei belum memutuskan: di suatu tempat ia menyebut prioritas internal, suatu tempat prioritas lokal, suatu tempat Kelas Layanan, dan suatu tempat yang hanya CoS. Tambahkan nama untuk vendor lain di komentar - Saya akan menambahkan.

Penandaan internal ini diberikan berdasarkan klasifikasi yang dilakukan node.
Penting bahwa kecuali dinyatakan sebaliknya, pelabelan internal hanya berfungsi di dalam node, tetapi kemudian tidak muncul pada pelabelan di header paket yang akan dikirim dari node - itu akan tetap sama.

Namun, di pintu masuk ke domain DS setelah klasifikasi, biasanya ada penandaan ulang di kelas layanan tertentu yang diterima di jaringan ini. Kemudian pelabelan internal dikonversi ke nilai yang diterima untuk kelas ini di jaringan, dan dicatat di header paket yang dikirim.

CoS dan Drop Precedence internal labeling mendefinisikan perilaku hanya dalam node yang diberikan dan tidak secara eksplisit diteruskan ke tetangga, kecuali untuk pelabelan kembali header.

CoS dan Drop Precedence menentukan PHB, mekanisme dan parameternya: pencegahan kemacetan, manajemen kemacetan, penjadwalan, dan pemberian label ulang.

---

Lingkaran apa yang dilewati paket antara antarmuka input dan output? Saya mengulas di artikel sebelumnya . Sebenarnya, ternyata tidak terjadwal, karena pada titik tertentu menjadi jelas bahwa tanpa memahami arsitektur itu terlalu dini untuk berbicara tentang QoS.

Namun, mari kita ulangi.

1. Sinyal mengenai antarmuka input fisik dan chip (PIC). Aliran bit mengalir darinya dan kemudian sebuah paket dengan semua header.
2. Di sebelah input switching chip (FE), di mana header dipisahkan dari tubuh paket. Klasifikasi terjadi dan ditentukan di mana paket perlu dikirim lebih lanjut.
3. Di sebelah antrian input (TM / VOQ). Sudah di sini paket diletakkan dalam antrian yang berbeda berdasarkan kelas mereka.
4. Lebih lanjut ke pabrik switching (jika ada).
5. Di sebelah antrian keluaran (TM).
6. (FE), .
7. (, ) (PIC).

Dalam hal ini, router harus menyelesaikan persamaan yang kompleks.
Perluas semuanya ke dalam kelas, berikan band lebar kepada seseorang, seseorang dengan latensi rendah, seseorang memastikan tidak ada kerugian.
Dan pada saat yang sama punya waktu untuk melewati semua lalu lintas jika memungkinkan.
Selain itu, Anda perlu membuat, mungkin memoles. Jika kelebihan beban tiba-tiba terjadi, maka atasi.
Dan ini tidak termasuk pencarian, pemrosesan ACL, penghitungan statistik.
Pangsa yang tidak enak. Tapi robot menyuntikkan, bukan manusia.

Bahkan, hanya ada dua tempat di mana mekanisme QoS bekerja - chip switching dan chip / antrian Manajemen Lalu Lintas.

Pada saat yang sama, operasi terjadi pada chip switching yang memerlukan analisis atau tindakan dengan header.

• Klasifikasi
• Polishing
• Pelabelan kembali

TM mengurus sisanya. Pada dasarnya, ini adalah operasi rutin dengan algoritma yang telah ditentukan dan parameter khusus:

• Pencegahan Kemacetan
• Manajemen kemacetan
• Membentuk

TM adalah buffer pintar, biasanya berdasarkan SD-RAM.

Dia pintar karena, a) dapat diprogram, b) dia dapat melakukan segala macam hal rumit dengan antrian.
Itu sering didistribusikan - chip SD-RAM terletak di setiap papan antarmuka, dan bersama-sama mereka digabungkan menjadi VOQ (Virtual Output Queue), yang memecahkan masalah Head of Line Blocking.
Faktanya adalah bahwa jika chip switching atau antarmuka output tersendat, mereka meminta chip input untuk melambat dan tidak mengirim lalu lintas untuk beberapa waktu. Jika hanya ada satu antrian di semua arah, sangat mengecewakan bahwa semua yang lain menderita dari satu antarmuka keluaran. Ini adalah Head of Line Blocking.

VOQ, pada papan antarmuka input, membuat beberapa antrian output virtual untuk setiap antarmuka output yang ada.

Terlebih lagi, garis-garis pada peralatan modern ini mempertimbangkan pelabelan paket.
Tentang VOQ dijelaskan secara cukup rinci dalam serangkaian catatan di sini .

Omong-omong, mereka benar-benar ditempatkan dalam antrian, mereka sedang dipromosikan, bukan paket-paket itu sendiri yang ditarik dari mereka, tetapi hanya catatan tentang mereka. Tidak masuk akal untuk melakukan begitu banyak gerakan dengan array bit yang besar. Sementara QoS sedang diejek atas catatan, paket-paket itu benar-benar ada dalam ingatan mereka dan diambil dari sana di alamat.

VOQ adalah antrian perangkat lunak (Antrian Perangkat Lunak istilah bahasa Inggris lebih akurat). Setelah itu, segera sebelum antarmuka ada juga antrian perangkat keras, yang selalu, benar-benar berfungsi sesuai dengan FIFO. Hampir tidak mungkin untuk mengontrol salah satu parameternya (misalnya, Cisco memungkinkan Anda untuk mengkonfigurasi hanya kedalaman dengan perintah tx-ring-limit).

Hanya di antara antrian perangkat lunak dan perangkat keras, Anda dapat menjalankan dispatcher yang sewenang-wenang. Ada dalam antrian program yang bekerja Head / Tail-drop dan AQM, memoles dan membentuk.

Ukuran antrian perangkat keras sangat kecil (unit paket), karena operator melakukan semua pekerjaan menumpuk tarif baris.

Sayangnya, di sini Anda dapat membuat banyak reservasi, dan memang mencoret semuanya dengan pena merah dan mengatakan "vendor X tidak begitu."

---

Saya ingin membuat satu komentar lagi tentang paket layanan. Mereka ditangani secara berbeda dari paket pengguna transit.

Dihasilkan secara lokal, mereka tidak diperiksa untuk kesesuaian dengan aturan ACL, dan batas kecepatan.

Paket-paket dari luar yang dimaksudkan untuk CPU dari chip switching keluaran jatuh ke antrian lain - ke CPU - berdasarkan pada jenis protokol.

Misalnya, BFD memiliki prioritas tertinggi, OSPF dapat menunggu lebih lama, dan ICMP umumnya tidak menakutkan untuk turun. Artinya, semakin penting paket untuk jaringan untuk bekerja, semakin tinggi kelas layanannya saat mengirim ke CPU. Itulah sebabnya mengapa normal untuk melihat berbagai keterlambatan transit hop di ping atau tracing - ICMP bukan lalu lintas prioritas untuk CPU.
Selain itu, paket protokol diterapkanCoPP - Control Plane Protection (atau Policing) - pembatas kecepatan untuk menghindari penggunaan CPU yang tinggi - sekali lagi, penurunan yang lebih baik dalam antrian dengan prioritas rendah sebelum masalah dimulai.
CoPP akan membantu baik dari DoS yang ditargetkan dan dari perilaku jaringan yang tidak normal (misalnya, loop) ketika banyak lalu lintas siaran mulai datang ke perangkat.

---

Tautan yang bermanfaat

• Buku terbaik tentang teori dan filosofi QoS: QOS-Enabled Networks: Tools and Foundations .
  Beberapa kutipan darinya dapat dibaca di sini , tetapi saya akan merekomendasikan membacanya dari dan ke, bukan bertukar.
• QoS Huawei: Special Edition QoS(v6.0) . PHB .
• sr-TCM tr-TCM : Understanding Single-Rate and Dual-Rate Traffic Policing .
• VOQ: What is VOQ and why you should care?
• QoS MPLS: MPLS and Quality of Service .
• QoS Juniper: Juniper CoS notes .
• QoS TCP UDP. : The TCP/IP Guide
• , , : TCP .
• , FQ: Queuing and Scheduling .
  , , An Introduction to Computer Networks , , Introduction, . .
  
• WFQ , , , , , : Weighted Fair Queueing: a packetized approximation for FFS/GP.
  
• Ada juga mekanisme LFI, yang tidak saya sentuh, karena sulit dalam realitas kami dari seratus antarmuka gigabyte juga, tetapi mungkin menarik untuk membiasakan diri dengan: Fragmentasi Tautan dan Interleaving .

Kesimpulan

Rilis ini telah memiliki banyak pengulas.
Terima kasih
Alexander Fatin ( LoxmatiyMamont ) untuk kata pengantar dan saran yang berharga tentang ekspresif dan kejelasan teks.
Alexander Clipper (@ metallicat20) untuk ulasan sejawatnya.
Alexander Klimenko (@ v00lk) untuk kritik keras dan perubahan paling masif dalam beberapa hari terakhir.
Andrey Glazkov (@glazgoo) untuk komentar tentang struktur, terminologi, dan koma.
Artyom Chernobay untuk KDPV.
Anton Klochkov (@NAT_GTX) untuk kontak dengan Miran.
Miran (miran.ru) untuk mengatur server dengan Eva dan siaran. Secara tradisional, keluarga saya, yang, bagaimanapun, kali ini paling menderita karena ketidakhadirannya dekat pada saat-saat paling sulit.