Advertisements
Home

Calculating Bandwidth for Voice Call

Leave a comment

Prerequisite:

  • Knowledge of Voice over IP (like CCNA Voice)

==========================

Pertanyaannya adalah:

Kalau gw mau membuat panggilan (calling) ke suatu tempat, berapa sih actual bandwidth yang dipake?

4 hal yang penting:

  • Codec: jenis format “kompresi” suara yang kita gunakan
  • Samples: seberapa banyak voice (analog) yang kita mau “digitalisasikan” per-packet
  • Overhead: kek IP, RTP, dan UDP Header
  • (Optional) Tunneling: klo punya tunneling protocol atau VPN…nambah overhead lagi

Wokeh…lets explore those topic in 1 by 1

==========================

Codec

Pertama2…apa sih Codec itu? Kalau gw mau kirim suara lewat medium digital (kek IP protocol), berarti harus ada teknik atau format untuk bagaimana caranya bikin data analog jadi data digital

Format kompresi alias encoding/decoding analog ke digital itulah yang disebut Codec

Dalam banyak hal format encoding/decoding ini di proses di supervisor-nya Router (CPU klo kata orang IT Support bilang)

Ada yang proses formatting-nya detail banget (jadi menghasilkan suara digital semirip mungkin analog voice) dengan konsekuensi makan bandwidth per-streaming voice (kbps – KiloBit Per Second)

Ada juga dengan proses dibuat sedemikian rupa sehingga ga makan bandwidth per-streaming, tapi dengan konsekuensi high CPU/supervisor processing (compressing)

Nah, yang proses encoding/decoding yang paling umum (dan detail) untuk VoIP adalah Codec G.711 yang menghasilkan Voice Streaming sebesar 64 kbps

Itu baru 1 call, klo 10 call?? 64 x10 = 640 kbps, klo bandwidth WAN kita Cuma 1mbps (1024 kbps)…sisa Cuma setengah-nya aja, itu aja kurang…ouch

Akhirnya para akademisi (ya…Akademisi, bukan Engineer yang cuma bisa implementasi, Akademisi yang nge-riset) bikin beberapa variant Codec

Contohnya:

  • G.729: teknik kompresi yang sangat bagus, bisa menghasilkan voice call sebesar 8 kbps (wew…kecil bener), dengan konsekuensi High CPU Processing, yang artinya semakin lama call berarti semakin delay (1 packet belum selesai di compress, packet yang laen udah antri dibelakang (Queue), plus karena dikompress sedemikian rupa…jenis Codec ini ga cocok untuk nganterin Rich and High Quality Voice (contohnya?? Music)
  • Atau G.726: aga sedikit diatas G.729 untuk soal voice call (yang skrg bisa 16 kbps), tapi lebih more CPU/supervisor friendly
  • Dan list codec2 yang lain (now you know why codec variant exist so many)

Berikut adalah list codec yang disupport Router C3640-IK9O3S-M dengan versi update 12.4(25a))

Klo ada codec yang ga ada disitu? Ya update IOS-nya…klo ga bisa ya pake Server Call Manager, klo ga bisa juga…update Router-nya (yang paling ampuh sih ini hahaha)

Trus klo “digitizing” analog voice ini makan resource CPU, berarti riskan dong diimplementasikan? There’s a hero named DSP (Digital Signaling Processor)

klo prosessing voice ini di router supervisor ternyata makan resource…why don’t we move it to specialized CPU for Voice processing?!”

Itulah DSP…ini gambarnya (taken from cisco.com)

kasusnya kek kita pake PC, CPU intel (yang di motherboard) bisa mengolah grafis, tapi akan lebih baik klo grafis pake CPU tersendiri (GPU – graphics processing unit) sendiri, kek nVidia atau AMD ATi, supaya bisa offload CPU processing Intel-nya

DSP ini bisa ditaro di module…yang module nya di pasang di router (klo diamati…DSP ini mirip RAM yah aha)

nah, klo kita liat…tipe DSP pun banyak, kok bisa? Sama seperti tipe graphic card…kok bisa macem2? Jawabannya tergantung kebutuhan kan?

Begitu pula DSP…semakin bagus DSP, semakin banyak call processing yang bisa dia handle

Trus tipe DSP apa yang bagus untuk perusahaan saya? Well, ada beberapa hal yang harus diperhatikan…seperti mau pake codec apa…high atau low complexity (baca: kompresi codec…G.711 itu low sedangkan G.729 itu high) trus berapa banyak call yang mau keluar masuk router…dsb

LUCKILY…THERE IS…A DSP CALCULATOR (in Cisco), cocok buat elu2 yang jadi voice network engineer terutama pre-sales nya

(lo harus punya CCO login dulu baru bisa masuk) Caranya:

  • Pertama, pilih model router-nya
  • Kedua, pilih model IOS-nya
  • *Ketiga, lo mau pasang langsung DSP-nya (Interface Card)
  • *Keempat, atau lo mau pasang di Network Modules
  • Note: step ke 3 dan ke 4 tergantung tipe/model router-nya

Nah, abis itu baru klik next…

Disini kita diminta memasukkan akan ada berapa banyak call processing yang mau di transcoding (NAT versi voice…contohnya dari G.711 dijadiin G.729)

Trus ada voice conference kaga, pake Enkripsi kaga itu voice (Secure IP Services)

Next lagi…

Ada berapa banyak profile untuk Conference dan Transcoding-nya, next…

Yaks…kata Cisco, klo Cuma butuh buat 10 call pake G.711 dan ga ada fitur2 lain….pake DSP module yang PVDM3-16: 1 aja (“:1” maksudnya 1 buah aja)

*Note: PVDM3 (Packet-to-Voice Digital Signal) sudah bisa transcoding dan conferencing (yang PVDM2 kaga), dan hanya di support di ISR G2 Router Series (29XX dan 39XX), PVDM3-16…16 artinya hanya 16 channel (call) yang disupport

(sorry guys…gw ga bahas teknik kompresi G.711 yang make Pulse Code Modulation, atau teknik2 lain, atau macem2 format codec, terlalu banyak dan out of my scope)

=========================

Voice Samples

Okeh…contoh kita fix pake G.711, seberapa banyak voice yang mau kita transmisikan per packet (this called Sampling)

Penjelasan:

  • Klo kita Cuma ketik codec g711 <enter>, default voice payload-nya (bytes per frame) 160 bytes
  • G.711 ada yang tipe u-law dan tipe a-law (beda teknik pensinyalan aja, u-law dipake di US dan a-law di eropa dan rest of the world)
  • Codec G.711 support 3 voice payload (80, 160, dan 240)

Apa hubungannya voice payload dengan sampling?  voice payload inilah yang menentukan hasil sampling, tau ga hasil sampling dari payload ini berapa? engga..wkwkw

Ini artinya kita harus ngitung lagi !!

Hmph…fine

Rumusnya: Bytes per sample = (sample size x codec bandwidth in bps) /8

  • Kita tau Bytes per-sample nya (contoh gw pake 240)
  • Kita tau pake codec apa (G.711 = 64kbps = 64000 bps)
  • Dibagi 8 (/8) karena kita pake bytes bukan bit (1 bytes = 8 bit), so…

Jadi dalam 1 packet terdapat voice yang “berdurasi” 30ms

Klo pake 160 bytes per sample? 20ms, pake 80 bytes? 10ms

Berarti klo gw punya suara “berdurasi” 90ms dengan sampling 30ms, berarti itu voice packet dipecah 3 kali alias ada 3 packet yang dikirim, klo pake sampling 10ms? 9 packet yang dikirim…lebih banyak makan bandwidth

Kok bisa? Bukannya semakin kecil size-nya semakin ga makan bandwidth? Lha iki piye toh…sampling di”carry” pake apa?? IP, UDP, dan RTP (semuanya total 40 bytes)

Klo kita dikirim 3 packet berarti 3×40 alias 120 kbytes, coba klo 9 packet yang dikirim 360 kbytes

Oooo

Kesimpulannya = more sampling, more bandwidth saving….but more processing delay (klo bisa semua dianterin pake truk, ngapain make motor, buang2 tenaga)

=========================

L2, L3, dan L4 Overhead

Well, Header Ethernet berapa bytes? 18 bytes

Header IP? 20 bytes

Header UDP? 8 bytes

Header RTP? 12 bytes

Lets say kita pake PPP bukan ethernet (mau ke WAN ceritanya), berapa bytes? 6 bytes

Now lets calculate some of this header

note: kita juga bisa pake cRTP (compress RTP) yang bisa bikin L3+L4 overhead dari 40 bytes jadi 2-4 bytes

berikut contohnya:

cRTP

 

sadly, gw ga pernah nemu command buat cRTP di ethernet (disaraninnya pake QoS aja klo ga ada cRTP)

*Tunneling Overhead

Bisa engga bisa iya, tapi anggeplah kita pake juga…biar lebih real gituh loh…

MPLS = 4 bytes

GRE/L2TP = 24 bytes

IPSec = 50-57 bytes (depend on encryption and hashing used)

So…lets say kita pake VPN (common IPSec – 50 bytes)…berarti 286 +50 = 336 bytes

So…ACTUAL Voice Packet Size nya sebesar 336 bytes

==========================

PPS (Packet Per Second)

Now, we’re getting near here…the question is…how much EXACTLY pps for voice payload

Packets….per….second, alias dalam 1 detik, berapa banyak packet yang dikirim

Itung2annya adalah:

PPS = 1000 ms / voice sample

Karena 1 detik itu 1000 ms dan kita pake 30ms sample (240 voice payload) berarti: 1000ms / 30ms = 33.3 pps

Nah, ACTUAL pps-nya berapa…tinggal Packet Size x PPS

336 x 33.3 = 11,188.8 bytes per second

Itu kan dalam bytes…klo dalam bit? Tinggal x8

11,188.8 x8 = 89,510.4 bps alias 90 kbps (gw bulletin keatas)

90 kbps…for 1 call ONLY (udah plus IPSec VPN ituh), Klo pake MPLS…pake GRE juga…ya tambahin sendiri…

Makanya…biasanya untuk call dengan requirement normal, ekspektasi kita siapin 100kbps (1 call)

10 call….1 mpbs, klo dipikir2 dari codec yang tadinya “Cuma” 64kbps trus bengkak jadi 100kbps, lu-manyun juga (bukan lumayan lagi)

=========================

Reference:

Codec @http://en.wikipedia.org/wiki/Codec

G.711 codec @http://en.wikipedia.org/wiki/G.711

Digital Signaling Processor @http://en.wikipedia.org/wiki/Digital_signal_processor

Jeremy Ciohara #11747 CBt Nuggets CVOICE video

Cisco Docs, PVDM @http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/voice-modules-interface-cards/qa_c67_553073.html

Cisco Docs, Voice over IP – Per Call Bandwidth Consumption @http://www.cisco.com/c/en/us/support/docs/voice/voice-quality/7934-bwidth-consume.html

RFC 2508 – cRTP @http://www.ietf.org/rfc/rfc2508.txt?number=2508

 

Advertisements

Route Policy Language (RPL)

Leave a comment

Prerequisite:

  • BGP Knowledge
  • IOS XR (or XRv, find that IOS yourself)

=========================================

RPL di dalam IOS-XR adalah command pengganti Route Map, tolong cam kan ini baik2 nak…lol

Contoh pentingnya penggunaan RPL dalam IOS-XR adalah sebagai berikut

Scenario:

  • Setiap router jalanin BGP
  • R1 pake AS 11, R3 pake AS 3, dan XR pake AS 1 (1 oruter untuk 1 AS)
  • IOS-XR punya loopback 192.168.1.1/32
  • Semua loopback dari masing2 AS di advertise (keyword network x.x.x.x mask x.x.x.x)

BGP Config di IOS-XR

Aga beda konfig BGP di IOS-XR, yang krusial ada 4:

  • Pertama lo harus aktifin BGP-nya ada di IPv4 ato IPv6 (address-family di bgp global config)
  • Mau unicast atau multicast
  • Di setiap neighbor juga harus dikasi tau mau pake IPv4 BGP atao mau pake IPv6 BGP (address-family di bgp neighbor sub-config)
  • Dan BGP Router-id…ga ada ini kaga jalan BGP Peering-nya

nah, kita liat BGP table-nya di R1:

Kalau dalam normal condition, harusnya R1 punya prefix dari IOS-XRv (harusnya dapet 192.168.1.1)…ini adanya rute dari R3 aja

Note: Prefix 3.3.3.1 dan 3.3.3.2 itu punya AS 3 (router R3)

Why is this happen? Because in IOS-XR has default routing policy that set all prefix dropped, lets take a look at picture below

Now, lets take the basic example of RPL (seeed…kesurupan bahasa inggris gw)

(nanti dibawah gw jelasin detail-nya) trus kita taro di BGP neighbor sub-config

Jgn lupa di commit, nah…kita liat sekarang di R1:

There is 192.168.1.1 route from AS 1 (IOS-XR) showed up!!

================================

RPL, how to make the magic happen *lol*

Seperti yang gw bilang diatas…IOS XR ga ada route-map, penggantinya adalah RPL ini

Kenapa harus route-map diganti? Aga susah dibaca dan ga flexible

Contoh: gw pengen klo AS 1 mau ke 3.3.3.1 lewat AS 11, tapi klo mau ke 3.3.3.2 lewat AS 12, dan klo bukan ke salah satunya ya jangan dilewatin

Klo pake route-map:

Dimana kita buat ACL dengan nama “KE3.3.3.1” dan “KE3.3.3.2” (tentunya permit ke masing2 alamat itu/destination-nya)

Trus setting next-hop nya berdasarkan ACL di match ip address nya

Kelemahannya dari route-map ini adalah override routing table (termasuk BGP table), so susah ngebaca arah tujuan hidup loe *ehm* maksud nya arah tujuan networknya…karena kata Routing Table/BGP Table harusnya lewat A, gara2 PBR (route-map ini termasuk PBR – Policy Based Routing) malah lewat B…

loh kok bisa beda…loh kok malah lewat sini…harusnya lewat situ…di routing table nya ga bilang gitu… (pas dibaca show run-nya)…ohhhh ada Route-Map toooh

Nah, klo Pake RPL:

Lebih mudah dibaca kan?!? Jika source ip dari 192.168.1.1 dan tujuannya ke 3.3.3.3 maka pake next-hop 11.11.11.1 dst, hampir2 ga perlu ACL

Wait…if-then-else, are you telling me we can type of some sort programming here?!? Yes we can lol

Makanya disebut route policy LANGUAGE, easier to understand

Kita bisa pake if-then-else, trus bisa pake and, or, dan not, bisa pake le ge (less than-greater than) dan teman2nya, bisa pass dan drop the packet, dan bisa pake nested if (if dalam if)…lebih flexible dari route-map

Contoh le ge:

Contoh Nested if-Nested Policies:

Route-map bisa begini ga? Ga bisa…

=================================

Nyok kita coba…

Scenario-nya dari gambar diatas:

Dari IOS-XR, gw pengen klo mau ke 3.3.3.1 di R3…weight ke R1 digedein jadi lewat AS 11, tapi klo mau ke 3.3.3.2 di R3…weight ke R2 yang digedein jadi lewat AS 12

(untung gw pernah ikut programming class….ga sia2 hahaha)

Pasang di BGP Neighbor sub-config

Nyok kita cek…

HEY LOOOK…klo mau ke 3.3.3.1 lewat AS 11…nah klo mau ke 3.3.3.2 lewat AS 12, route-map bisa gini ga?? Sulit memang untuk bersaing di dunia persilatan inih… *ngawur*

Eh, klo contoh pertama ada route-policy PASS in dan route-policy PASS out, kok disini ga ada in dan out-nya…trus ga ada statement “pass“nya?

Oh iya…dalam RPL terdapat implicit pass (best you remember that), kebalikan dari implicit deny-nya ACL

Syaratnya adalah: harus ada statement alias kata2 “set” didalamnya…klo ga ya sama kek ACL…implicit deny

Klo ada statement set didalam suatu RPL, sisanya di pass (makanya gw ga setting in dan out trus ga ada statement pass-nya di RPL-to-AS11 dan RPL-to-AS12)

========================

Editing RPL

RPL di IOS-XR punya validity checking, like this:

Begitu kita commit, di cek…bisa engga-nya RPL itu di implementasikan

Klo kita mau edit yang udah jadi gimana? here it is…

Woops….bukan edit ini mah, NIBAN ceritanya ini hahaha

Untuk itu kita harus keluar dari global configuration mode dulu, di privilege mode…ketik edit

Kita ketik edit route-policy [nama RPL]

Nah, begitu kita enter, nanti kek gini tampilannya:

Maap gw ga bisa nyontohin cara delete, Cut Text, dll karena…

CURSOR-NYA GA ADAAAAAA (mungkin karena IOS-XRv), pusing gw ngeraba2 uda sampe mana cursor gw…

Nah, diatas itu adalah GNU Nano RPL Editor, ada 3 cara untuk edit RPL ini:

  • GNU Nano (yang kita liat diatas)
  • Emacs
  • Vim

======================

Reference

BGP IOS-XR Configuration @http://www.fryguy.net/2012/09/24/ios-xr-ibgp-and-ebgp/

Cisco Instructor Guide ebook for CCNP SP Course: (642-883) – Deploying Cisco Service Provider Network Routing (SPROUTE)

Older Entries