Di dua bagian sebelumnya kita sudah mendiskusikan banyak hal tentang arsitektur router. Apa yg harus kita lakukan sekarang? Mari kita melihat fitur dan aplikasi yg berkaitan dgn arsitektur hardware yg sudah kita diskusikan sebelumnya. Gue gak punya lagi gambar-gambar yg bisa ditemui di google untuk menjelaskan topik ini. Dan tentunya gue tidak boleh menggunakan materi dari internal dokumen perusahaan. Jadi biarkan bagian ini menjadi tulisan tanpa gambar sama sekali.
Berikut adalah beberapa contoh fitur dan aplikasi yg harus dimiliki oleh modern dan next generation router:
High Availability (HA) and Fast Convergence
Router pasti gagal suatu ketika. Kegagalan mungkin terjadi di modul route processor, di power supply, switch fabric, line card, atau di keseluruhan chassis. Poin utamanya adalah bukan di cara menghindari kegagalan, tapi bagaimana caranya mengatasi kegagalan tersebut dgn cara meminimalkan waktu yg diperlukan untuk mengarahkan traffic ke modul atau path yg lain.
Buat yg masih suka melihat network sbg suatu koleksi router atau node yg terkoneksi satu sama lain, kegagalan bisa terjadi di link antar node atau di node itu sendiri. Untuk kedua kasus ini, vendor router sudah lama mengenalkan konsep Fast Convergence (FC) seperti IGP FC dan MPLS Traffic Engineering Fast Re-Route (FRR) untuk mengurangi waktu yg diperlukan konvergensi network menjadi minimal. Kunci utamanya adalah kemampuan mendeteksi kegagalan secepat mungkin. Jika node-node tadi terhubung secara langsung, maka kita bisa menggunakan Loss of Signal (LoS) yg terjadi di fisik dari link untuk memberi tahu protokol di layer atas spt IGP. Jika node terkoneksi bukan secara langsung, misal ada layer 2 switch di tengah atau yg lain spt DWDM network, maka suatu node bisa menggunakan fitur Bidirectional Forwarding Detection (BFD) yg mengirimkan paket hello untuk mengetahui status dari node sebelahnya.
Ketika hardware gagal, kita kemungkinan akan melihat paket yg hilang (packet loss) dari network traffic selama beberapa waktu. Dalam banyak kasus ini tidak bisa dihindari dan yg bisa kita lakukan hanya meminimalkan jumlah packet loss dgn cara mereduksi waktu yg diperlukan network untuk meraih konvergensi. Untuk router yg memiliki router processor lebih dari satu, yg di set untuk menyediakan redudancy, fitur Non-Stop Forwarding (NSF) bisa digunakan selama waktu peralihan (switch over) dari primary route processor ke secondary route processor, sebelum secondary bisa mengambil alih sepenuhnya. NSF memberikan transparansi ke level tertentu, karena ketika satu node gagal dia bisa memberi tahu node lain yg terkoneksi bahwa dia akan gagal
tapi membuat janji bahwa dia akan kembali lagi online (dgn menggunakan secondary route processor) jadi tolong para node yg lain jgn mem-flush routes yg ada di routing table mereka dan tetap mem forward traffic ke node yg gagal tadi.
Node yg gagal itu sendiri harus menggunakan konsep modular spt dijelaskan di tulisan bagian-bagian sebelumnya. Jadi forwarding plane harus dilakukan di lokasi lain selain di route processor, misal di line card. Sebelum terjadi kegagalan, router harus menjalankan fitur Stateful Switchover (SSO) untuk memastikan terjadi sinkronisasi antara primary route processor, secondary route processor, switch fabric dan line card. Selama switch over, sambil menunggu proses initialisasi secondary route processor sebelum bisa mengambil alih, forwarding paket masih bisa dilakukan di line card dgn menggunakan kondisi terakhir di line card forwarding table yg masih terupdate sampai di saat terjadi kegagalan. Jadi kalo node yg gagal masih bisa mem forward paket, meskipun dgn menggunakan forwarding table terakhir sebelum kegagalan, dan node-node lain yg terkoneksi masih mau untuk tetap mem forward paket ke node yg gagal tadi karena sebelumnya sudah diberitahu kalo node itu akan kembali online lagi, maka tidak seharusnya kita melihat ada packet loss sama sekali. Nantinya fitur SSO/NSF ini harus bisa men sinkronisasikan forwarding table ke status terakhir ketika secondary route processor sudah mengambil alih dan node yg gagal sudah berfungsi kembali.
Konsep baru yg sedang sering dibicarakan adalah fitur Non Stop Router (NSR). NSR diharapkan bisa memberi tranparansi penuh kepada node yg lain ketika terjadi kegagalan di satu node. Jika pada NSF meskipun node yg lain masih mau mem forward paket ke node yg gagal sampai jangka waktu yg disetujui, tapi hubungan IGP sudah dinyatakan berhenti. Sedangkan dgn NSR hubungan IGP tetap dipertahankan seolah-olah node yg gagal yg sedang melakukan switch over masih berfungsi seperti biasa.
Jika kita kembali ke diskusi design dan arsitektur hardware, bisa terlihat bahwa komponen utama untuk bisa menyediakan HA dan FC adalah kemampuan secondary route processor untuk selalu sinkron dgn primary route processor, fabric dan line card. Jika ini tidak bisa tercapai maka kita akan melihat packet loss selama proses switch over. Dan tentunya kita semua mengeri bahwa kegagalan di line card maupun fabric, ketika traffic sedang melewatinya, akan menyebabkan packet loss walaupun kita menjalankan fitur HA apa saja. Dan dgn konsep switch fabric yg modular, kita harus memiliki beberapa modul dan jika terjadi kegagalan pada satu modul tidak akan mengurangi kapasitas forwarding paket dari keseluruhan switch fabric.
Quality of Services
Quality of Services (QoS) fitur untuk bisa memberikan perlakuan yg berbeda terhadap paket adalah kebutuhan utama ketika terjadi congestion di network. Yang menjadi pertanyaan, di mana sebenarnya congestion bisa terjadi?
Jika kita menggunakan arsitektur carrier class router di tulisan bagian kedua sebagai referensi, terlihat bahwa congestion bisa terjadi di komponen yg berbeda:
- Egress queue, tempat queue di egress line card sebelum interface fisik: ketika menunggu paket untuk dikirimkan ke media fisik, karena di media fisiknya sendiri sudah terjadi congestion
- Fabric queue, queue untuk menerima paket dari switch fabric di egress line card: karena harus melakukan normalisasi dari paket misalnya kalau paket dikonversi ke cell dgn ukuran yg sama maka harus dikembalikan ke format dan ukuran aslinya. Atau bisa jadi karena di egress queue sudah terjadi congestion maka queue ini juga terkena dampaknya
- Ingress queue, queue sebelum mengirim paket ke switch fabric di ingress line card: sebagai konsekuensi terjadinya congestion di fabric queue atau di fabric, maka queue inipun bisa mengalami congestion
Congestion bisa terjadi di dalam switch fabric itu sendiri. Tapi biasanya untuk kelas carrier-class router design switch fabric sudah dibuat dgn kapasitas yg sangat besar untuk bisa mengakomodasi jika chassis router tadi penuh dgn line card. Kecuali jika switch fabric terdiri dari beberapa modul dan ada modul yg gagal sehingga mengurangi total kapasitas secara keseluruhan.
Jadi kunci utamanya di sini adalah kita harus bisa memberikan QoS atau perlakuan yg berbeda ke paket di berbagai titik di dalam router. Misal, jika di port fisik terjadi congestion maka kita harus bisa membuat paket dgn prioritas tinggi di egress queue untuk dikirimkan terlebih dahulu ke media network. Sama halnya dgn fabric queue. Dan bahkan di dalam fabric sendiri kita harus bisa memberikan prioritas kepada paket ketika terjadi congestion di fabric queue, atau congestion di dalam fabric itu sendiri. Dan ketika terjadi congestion di egress queue, harus ada mekanisme untuk memberi tahu ke fabric queue, yg akan memberi tahu ingress queue untuk memperlambat jumlah paket yg dikirim ke fabric. Mekanisme ini dikenal dgn nama back pressure, dan komunikasi antara fabric queue ke ingress queue bisa dilakukan di bypass link, seperti dijelakan di tulisan bagian kedua. Fabric biasanya hanya mem forward paket dgn satu arah, dari ingress ke egress, dan tidak sebaliknya. Memperlambat jumlah paket yg dikirim ke fabric sebenarnya dilakukan oleh ingress packet engine, karena di sana paket dgn prioritas rendah bisa di drop, sehingga paket yg dikirim ke ingress queue menjadi berkurang.
Sekarang jelas bahwa kita harus menjalankan fitur QoS yg tepat di lokasi yg tepat juga di dalam router. Policing, misalnya, biasa dilakukan di ingress packet engine. Egress queue bisa menggunakan shaping atau mekanisme queuing ataupun congestion avoidance. Fabric queue mungkin hanya perlu memberi tahu ingress queue ketika terjadi congestion di egress line card.
Btw, penandaan paket utk QoS yg biasa disebut marking ketika paket berada di dalam router biasanya diturunkan dari marking yg dilakukan di luar router ke paket dgn menggunakan nilai seperti CoS, DSCP atau EXP. Dan ketika paket berada di dalam router maka yg digunakan adalah internal marking, yg kemudian digunakan oleh fitur QoS di setiap komponen. Adalah tugas dari ingress line card untuk mengkonversi QoS marking dari luar menjadi internal marking.
Satu hal lain yg penting dari fitur QoS adalah kemampuan untuk mensupport QoS dgn model hirarki. Pada network yg biasa, paket yg datang ke line card mungkin hanya punya satu tag atau penanda paket dgn QoS marking yg harus dilakukan ke paket tsb misalnya MPLS EXP bit, atau CoS dan DSCP di IP network. Jadi hanya ada satu perlakuan QoS yg bisa dilakukan ke tipe paket yg memiliki marking yg sama. Tapi bagaimana jika ada paket yg memiliki beberapa tag, dan diperlukan untuk memberikan perlakuan yg berbeda berdasarkan tag yg berbeda-beda tsb? Misal di network Carrier Ethernet di mana suatu paket bisa datang dgn membawa dua 802.1q tag, yg paling atas disebut S-tag untuk mengindentifikasi dari aggregation router mana paket itu datang, dan yg kedua disebut C-tag yg digunakan untuk membedakan VLAN dari customer (ini biasa disebut teknologi Q-in-Q). Kita mungkin ingin memberi perlakukan QoS yg berbeda, jadi di satu hal ingin melakukan QoS untuk semua paket yg memiliki S-tag yg sama, tapi di lain hal kita juga ingin membedakan jika paket datang dgn C-tag yg berbeda atau dari customer yg berbeda. Ini berarti router (dan line card) harus mensupport model QoS secara hirarki, dimana QoS main class akan mempengaruhi semua paket dan kita bisa membuar QoS child class yg spesifik untuk setiap customer.
Multicast
Untuk sebuah network yg berisi beberapa node yg saling terkoneksi, traffic multicast berarti satu paket datang dari satu sumber atau source dan direplikasikan ke beberapa node lain tergantung dari request untuk join multicast group tsb. Sekarang saatnya kita untuk melihat lebih dalam dan bertanya: siapa yg melakukan proses replikasi paket di dalam router?
Paket multicast bisa dibedakan dgn cara melihat tujuan IP address yg merupakan multicast group address. Di dalam router replikasi paket bisa dilakukan di ingress line card, disebut ingress replication, atau di egress line card, disebut egress replication. Dgn menggunakan multicast control plane protokol seperti PIM, ingress line card mengetahui egress line card tujuan untuk setiap multicast group address. Contoh ada dua port di ingress line card, dan multicast paket (S,G) diterima di satu port. Dari lookup di ingress packet engine atau network processor bisa diketahui yg tertarik dgn multicast group itu dan menjadi tujuan adalah port lain di ingress line card yg sama dan juga line card yg lain. Ingress line card bisa melakukan ingress replication untuk memperbanyak paket dan mengirimkannya ke port yg berada di line card yg sama, dan juga ke line card yg lain melalui backplane atau switch fabric.
Jika kita selalu melakukan ingress replication ada isu performance yg bisa terjadi. Ambil contoh ada multicast traffic yg diterima oleh ingress line card dgn rate sebesar X Gbps. Dan ada 10 ports di engress line card yg tertarik untuk join multicast group itu. Jika kita melakukan ingress replication make ingress line card harus menperbanyak setiap multicast paket menjadi 10 kali, yg berarti total mutlicast traffic rate yg harus dikirimkan ke fabric menjadi 10 X Gbps. Untuk skenario spt ini tentu lebih baik menggunakan egress replication dimana ingress line card hanya perlu mengirim satu paket ke tiap egress line card yg tertarik. Dan jika ada beberapa port di egress line card itu yg tertarik utk join multicast group yg sama, maka replikasi bisa dilakukan oleh si egress line card utk mengirim paket ke semua port tadi. Jadi egress replication dalam hal ini digunakan untuk menghindari pengiriman multicast traffic yg tinggi oleh ingress line card ke switch fabric.
Di carrier-class router, switch fabric bahkan jauh lebih pintar sehingga bisa melakukan replikasi paket multicast di dalam fabric. Sehingga ingress line card hanya perlu mengirim satu paket saja ke fabric, kemudian fabric lah yg akan mereplikasi paket dan mengirimkan nya ke egress line card yg tertarik, kemudian egress line card bisa melakukan replikasi lagi jika ada beberapa port di line card yg sama yg tertarik ke multicast group itu.
Performance and Scalability
Setelah membaca sampai sini, harusnya kita semua sudah mulai selalu menanyakan ketika melihat suatu fitur atau protokol: apakah itu dilakukan di software atau di hardware? Apakah central CPU yg melakukannya atau di distribusikan ke line card? Apakah dilakukan di ingress line card atau egress? Jika iya, bagus, akhirnya sudah mulai kelihatan apa manfaat untuk mengetahui ini semua.
Sebelum melanjutkan gue mau menjelaskan secara singkat satu komponen penting lagi di hardware untuk forwarding plane, yaitu Ternary Content Addressable Memory (TCAM). Intinya sih TCAM ini adalah high speed memory yg digunakan untuk menyimpan data-data forwarding table atau fitur lain seperti access control list, misalnya, sehingga router bisa melakukan switching di hardware dgn performance tinggi. Masih ingat konsep forwarding table di push dari central processor ke line card, untuk kemudian dari line card processor ke hardware? TCAM digunakan untuk menyimpan informasi tsb. Jadi sekarang kita tahu bahwa harus ada memory yg cukup untuk menyimpan semua informasi itu, dgn kata lain TCAM merupakan salah satu yg membatasi forwarding path. Jika route processor mem push data lebih banyak dari yg TCAM bisa tangani, maka kita akan berada di kondisi yg tidak konsisten antara route processor dan line card. Sehingga meskipun route processor tahu apa yg harus dilakukan ke paket, tapi hardware bisa jadi tidak memiliki data tsb dan akan men drop paket yg lewat itu.
Dengan melihat arsitektur modular dari suatu next generation router, jelas sekarang jika kita ingin mendapat performance non-blocking atau line rate switching paket maka kita harus memastikan setiap komponen di forwarding path untuk mendukung performance line rate. Ini berarti jika kita mau mem forward X Gbps traffic tanpa ada congestion, maka tiap komponen dari ingress processor dan queue di ingress line card, kapasitas fabric, fabric queue, egress processor dan egress queue di line card harus mampu memproses X Gbps atau lebih. Jadi jika kita ingin tahu di mana terjadi bottleneck di dalam router, periksa kapasitas dan kemampuan memproses paket di tiap komponen. Jika kita tahu kemampuan dari ingress line card ke fabric hanya X Gbps, tapi kita memiliki beberapa port di line card itu dgn total kapasitas lebih dari X, ini berarti kita melakukan sesuatu yg disebut over subscription. Dan dengan mengetahui dimana terjadinya congestion maka kita bisa menjalankan fitur QoS yg tepat di komponen yg tepat juga. Misalnya, jika terjadi congestion seperti di atas maka penggunaan QoS egress queue tidak akan membantu karena masalahnya adalah di queue ke switch fabric.
Mungkin ada yg bertanya, mengapa kita harus memikirkan kapasitas dan performance dari route processor, jika kita tahu kemampuan router yg sebenarnya adalah di forwarding plane yg berarti ada di line card? Karena kita masih tetap membutuhkan route processor untuk menjalankan fungsi control plane. Kita butuh CPU yg bagus untuk bisa memproses banyaknya paket control dan routes dari IGP dan BGP. Kita masih tetap butuh memory yg besar di route processor karena ini adalah tempat menyimpan informasi yg diterima dari router lain, yg kemudian baru bisa di push ke line card. Kita juga masih memerlukan flash disk atau storage lainnya yg cukup untuk menyimpan image dari router software beserta file-file lain seperti logging dan crash dump.
NGN Multi-Service Features and Application
Sangat wajar di next generation network untuk membawa tipe servis dan aplikasi yg berbeda-beda. Aplikasi yg paling seri digunakan selain multicast untuk IPTV, adalah MPLS L3VPN untuk customer bisnis, Internet, L2VPN point-to-point atau multipoint dgn VPLS dan lain-lain. Kompleksitas menjadi bertambah ketika kita harus menggabungkan dan menjalankan beberapa fitur secara bersamaan.
Sebagai contoh, jika kita mempunyai network yg menjalankan teknologi MPLS, maka penambahan label atau imposition terjadi di ingress line card setelah lookup. Tapi bagaimana jika kita menjalankan fitur lain seperti salah satu tipe L2VPN yg bisa dijalankan di software atau di central route processor? Ini berarti kita membutuhkan label imposition untuk dilakukan di egress line card.
Dan bagaimana jika line card harus melakukan lookup beberapa kali untuk paket yg sama? Misalnya, jika kita harus membuang dua label MPLS sekaligus di router MPLS terakhir jika fitur Penultimate Hop Popping (PHP) tidak digunakan di MPLS L3VPN network. Biasanya ini dilakukan supaya router MPLS terakhir itu tetap mendapat EXP bit di MPLS label teratas untuk QoS. Lookup pertama yg harus dilakukan adalah dgn melihat tag MPLS teratas. Kemudian lookup berikutnya dilakukan untuk melihat MPLS VPN tag supaya bisa diasosiasikan dgn VRF. Kemudian setelah kedua MPLS tag tadi dibuang, router masih harus melakukan lookup lagi di IP forwarding table untuk menentukan ke egress interface mana paket harus dikirim. Melakukan lookup beberapa kali utk paket yg sama ini memperkenalkan kita akan konsep recirculation, dimana paket akan di loop di dalam ingress line card. Jadi setelah lookup yg pertama paket tidak dikirim ke fabric, tapi akan mendapat informasi layer 2 yg baru dan di re-write namun dikirimkan kembali ke line card yg sama seolah-olah ini adalah paket berikutnya yg harus diproses.
Multicast VPN bisa memberikan kita tantangan yg lain. Untuk sekedar menyimpulkan, dgn mengetahui bagaimana protokol dan fitur bekerja, dan digabungkan dgn pengetahuan tentang arsitektur hardware berikut komponen apa yg melakukan hal tertentu, kita bisa mencoba melihat masalah-masalah apa yg mungkin timbul pada saat suatu design di implementasikan. Dan kita mungkin sudah bisa memikirkan apa yg harus kita lakukan untuk mengatasinya.
Jujur saja, gue sudah sangat sulit untuk mendiskusikan hal ini secara lebih detil, karena berbagai alasan. Pertama, karena sekarang sudah jam 4 pagi. Dan gue belum tidur selama 2 hari untuk menulis Trilogi ini sambil mengerjakan hal yg lain juga. Apakah gue pernah bilang betapa berterima kasihnya gue kepada mereka yg menemukan Red Bull? Tapi untuk sekarang ini, minuman energi spt apa juga tidak akan bisa membuat gue tetap bangun.
Yang kedua, walaupun gue masih mau menulis lebih banyak tentang topik ini tapi kemungkinan sulit untuk bicara lebih detil tanpa mendiskusikan beberapa informasi internal dari perusahaan gue, yg tidak boleh gue lakukan. Well, kita lihat saja nanti. Mungkin gue akan dapet ide baru setelah tidur yg benar.
Selamat malam.
Akhir dari trilogi tulisan.