Tuesday, January 1, 2008

[Future] Preemptive Routing - Antisipasi Routing sebelum Gangguan Terjadi

Routing protocol sampai saat ini hanya melakukan traffic routing setelah jalurnya putus. Hal ini menimbulkan traffic drop. Banyaknya drop tergantung pada banyak hal, seperti kecepatan link, banyaknya data yang dikirim, dan kecepatan routingnya.

Pada beberapa kasus, drop seperti ini tidak menjadi masalah, apalagi jika protokol yang digunakan adalah TCP. TCP selalu melakukan resending, sehingga paket drop akan diresend kembali dengan kecepatan yang lebih rendah (dengan TCP window yang lebih kecil). Btw., mekanisme ini kemudian dipakai beberapa perangkat bandwidth limiter untuk mengontrol bandwidth.

Pada kasus2 yang langka, drop satu paketpun akan menyebabkan masalah besar. Misalnya ada beberapa aplikasi yang tidak mengantisipasi drop ini, sehingga jika ada link yang drop, kehilangan beberapa paket akan menyebabkan data terkirim menjadi corrupt karena aplikasi tidak mengerti konsep resending paket dari TCP tadi.

Aplikasi semacam ini biasanya dikembangkan di dalam lingkungan LAN yang memang sangat aman dan reliable, sehingga programmer lupa memperhitungkan kemungkinan link drop...

Routing protocol yang umum biasanya melakukan recovery dalam hitungan detik. Artinya kalau ada link yang jatuh, ada kemungkinan bahwa ada sekian detik komunikasi putus dan sekian paket akan hilang (impactnya sangat significant untuk aplikasi2 yang tidak proper spt tadi).

Salah satu teknik untuk mempersingkat downtime ini adalah dengan MPLS TE FRR (Multiprotocol Label Switching Traffic Engineering dengan Fast Re-Route). FRR bisa mempersingkat downtime sampai 50 milidetik.

Jika 50 milidetik downtime tidak cukup - nah saatnya kita memikirkan routing protocol yang bisa melakukan routing SEBELUM linknya jatuh.

Preemptive routing ini sebenarnya sudah menjadi wacana di Cisco semenjak saya bergabung tahun 1995. Konsepnya adalah router mengetahui apa yang akan terjadi pada network, sehingga bisa melakukan routing sebelum ada masalah pada network.

Ada cukup banyak juga penelitian bagaimana membuat hal ini menjadi kenyataan.

Pada prinsipnya adalah perangkat di layer 1 (OSI layer) harus memberi tahun ke perangkat di atasnya tentang apa yang terjadi di layer 1. Misalnya kualitas signal yang diterima seperti apa. Jika kualitas signal berada di bawah ambang batas, artinya router harus segera mengantisipasinya dengan cara memindahkan traffic ke link lain yang lebih baik. Kunci routing di sini adalah menentukan seberapa besar ambang batas ini. Jika terlalu rendah, akibatnya adalah network putus duluan baru router bereaksi. Jika terlalu tinggi akibatnya network akan tidak stabil karena router menjadi terlalu sering melakukan routing yang tidak perlu.

Kalau saya lihat sendiri, cara seperti ini sebenarnya sudah bisa diterapkan sekarang, apalagi dengan adanya konsep G-MPLS di mana perangkat router (aware terhadap L2 ke atas) menjadi satu dengan perangkat transport DWDM (aware terhadap L1). Perangkat DWDM menjadi satu dengan router dengan adanya framework ini, dan segala sesuatu yang terjadi di level DWDM (optic) akan diketahui oleh router di atasnya, shg router bisa segera melakukan preemptive routing.

Contoh router yang mampu melakukan hal seperti ini adalah CRS-1 dengan perangkat IPoDWDM atau ROADM dari ONS 15454.

Jika ONS 15454 mendeteksi bahwa kekuatan signal yang diterima melemah di bawah ambang batas, maka CRS-1 segera mengetahuinya dan melakukan routing SEBELUM link DWDM benar2 mati.

Secara teoritis mustinya semua router dan switch yang memiliki kemampuan IPoDWDM (seperti Catalyst 6500 atau Router Cisco 7600) bisa melakukan preemptive routing ini. Kalaupun belum, itu tinggal masalah waktu saja, karena secara hardware semua perangkat2 ini sudah mampu mendeteksi kekuatan signal di level DWDMnya.

Keuntungan yang kita dapatkan sudah jelas, yaitu router bereaksi sebelum link jatuh sehingga tidak ada lagi packet drop, dan tidak ada lagi packet resending.... Artinya tidak ada lagi kerugian2 perusahaan yang diakibatkan oleh aplikasi2 payah yang ditulis tanpa antisipasi jatuhnya network karena suatu hal (apalagi kita tinggal di Indonesia, semua bisa terjadi di negara ini)....


4 comments:

Anonymous said...

Halo Pak,

Blog yang menarik, bagaimana bila interface-nya bukan DWDM (fiber), apakah mekanismenya tetap sama? Bagaimana tepatnya preemptive routing ini bekerja, sinyal diukur berdasarkan apa? apakah ada threshold yang sudah ditentukan? Maaf kalo newbie question :-)

BR,
Davy

Tony Seno Hartono said...

Itu bukan newbie question - tapi pertanyaan yang cukup canggih tanda menyimak hehe :)

Untuk jenis interface fiber ataupun elektrik, mekanismenya sama. Perangkat L1 yang terhubung akan mampu memberikan informasi seberapa bagus signal yang lewat. Kualitasnya diukur dari threshold yang ditentukan sebelumnya. Kekuatan signal (elektrik/optic) yang melorot ke bawah threshold akan memicu suatu alarm.

Pada kondisi ini frame2 data dari L2 ke atas masih bisa lewat dengan baik, hanya saja mulai melemah.

Untuk DWDM, kebetulan sekarang sudah ada framework IPoDWDM yang memungkinkan integrasi yg tight antara router dengan DWDM switch, shg preemptive routing dimungkinkan.

Untuk kasus no optic, perangkat TDM (misalnya E1-E3) sebenarnya juga mampu mendeteksi level signal yang lewat, dan bisa mengeluarkan alarm juga jika signal tersebut melemah di bawah suatu threshold tertentu. Namun sampai saat ini belum ada protokol standard di router yang bisa melakukan antisipasi routing (preemptive)..... Technically possible untuk kita membuat script yang memonitor kondisi ini dan melakukan preemptive routing, tapi ini mungkin cocoknya buat tesis saja :p

Anonymous said...

Thanks Pak jawabannya :-)

"Namun sampai saat ini belum ada protokol standard di router yang bisa melakukan antisipasi routing (preemptive)....." ---> Kalo gitu Cisco harus mulai (atau sudah namun blom dipublikasikan?) nulis RFC buat preemptive routing hehehe

BR,
Davy

Tony Seno Hartono said...

Percakapan tentang preemptive routing ini sendiri sudah lama di dalam Cisco. Sekarang sudah terealisasi dengan adanya IPoDWDM. Tapi kalau implementasi di copper wire rasanya tidak akan ada, soalnya belum ada cukup banyak permintaan untuk hal ini, jadi tidak justified secara bisnis