Parimet e funksionimit të protokollit PIM

Protokolli PIM është një grup protokollesh për transmetimin e multicast-it në rrjet midis ruterëve. Marrëdhëniet e fqinjësisë ndërtohen në mënyrë të ngjashme si te protokollet dinamike të rutimit. PIMv2 dërgon mesazhe Hello çdo 30 sekonda në adresën e rezervuar multicast 224.0.0.13 ( All-PIM-Routers ). Mesazhi përmban Hold Timers — zakonisht është i barabartë me 3.5*Hello Timer, pra 105 sekonda si parazgjedhje.

PIM përdor dy mënyra kryesore pune — Dense dhe Sparse mode. Le të fillojmë me Dense mode.
Pemët e shpërndarjes të bazuara te burimi.
Regjimi Dense-mode është i përshtatshëm kur ka një numër të madh klientësh të grupeve të ndryshme multicast. Kur ruteri merr trafik multicast, gjëja e parë që bën është ta kontrollojë sipas rregullit RPF. RPF — ky rregull përdoret për të verifikuar burimin e multicast-it ndaj tabelës së rutimit unicast. Është e nevojshme që trafiku të vijë në atë interfejs pas të cilit ndodhet ky host sipas tabelës së rutimit unicast. Ky mekanizëm zgjidh problemin e krijimit të lakut gjatë transmetimit të multicast-it.

Nga mesazhi multicast, R3 identifikon burimin e multicast-it ( Source IP ) dhe kontrollon dy flukset nga R1 dhe R2 sipas tabelës së vet të rutimit unicast. Fluksi nga ai interfejs të cilit i referohet tabela ( R1 te R3 ) do të përcillet më tej, ndërsa fluksi nga R2 do të hidhet poshtë, sepse për të arritur te burimi i multicast-it, paketat duhet të dërgohen përmes S0/1.
Po çfarë ndodh nëse keni dy rrugë ekuivalente me të njëjtën metrikë? Në këtë rast, ruteri do të zgjedhë sipas next-hop të këtyre rrugëve. Fiton ai që ka adresën IP më të lartë. Nëse duhet ndryshuar kjo sjellje, mund të përdoret ECMP. Më shumë detaje këtu.
Pas verifikimit të rregullit RPF, ruteri dërgon paketën multicast te të gjithë fqinjët e tij PIM, me përjashtim të atij nga i cili u mor kjo paketë. Ruterët e tjerë PIM e përsërisin këtë proces. Rruga që ka përshkuar paketa multicast nga burimi deri te marrësit përfundimtarë formon një pemë që quhet — source-based distribution tree, shortest-path tree (SPT), source tree. Tre emërtime të ndryshme, zgjidhni cilindo.
Si zgjidhet problemi kur disa ruterë nuk kanë fare nevojë për një fluks të caktuar multicast dhe nuk kanë kujt t’ia dërgojnë, ndërsa ruteri në nivel më të lartë vazhdon t’ua nisë? Për këtë është krijuar mekanizmi Prune.
Mesazhi Prune.
Për shembull, R2 do të vazhdojë t’i dërgojë multicast R3, edhe pse R3, sipas rregullit RPF, e hedh poshtë atë. Pse të ngarkohet kanali? R3 dërgon një mesazh PIM Prune dhe R2, pasi ta marrë këtë mesazh, do ta heqë ndërfaqen S0/1 nga lista ( outgoing interface list ) për këtë rrjedhë, pra nga lista e ndërfaqeve ku duhet të dërgohet ky trafik.

Më poshtë është një përkufizim më formal i një mesazhi PIM Prune:
Mesazhi PIM Prune dërgohet nga një router te një router i dytë për të bërë që routeri i dytë të heqë lidhjen në të cilën është marrë Prune nga një (S,G) SPT i caktuar.

Pas marrjes së mesazhit Prune, R2 vendos një kohëmatës Prune prej 3 minutash. Pas tre minutash, ai do të nisë sërish të dërgojë trafik, derisa të marrë një tjetër mesazh Prune. Kjo vlen për PIMv1.
Në PIMv2 është shtuar kohëmatësi State Refresh ( si parazgjedhje 60 sekonda ). Sapo dërgohet mesazhi Prune nga R3, ky kohëmatës niset në R3. Me përfundimin e këtij afati, R3 do të dërgojë një mesazh State Refresh, i cili do të rivendosë kohëmatësin 3-minutësh Prune në R2 për këtë grup.
Arsyet për dërgimin e një mesazhi Prune:

• Kur paketa multicast nuk e kalon kontrollin RPF.
• Kur nuk ka klientë të lidhur lokalisht që kanë kërkuar grupin multicast ( IGMP Join) dhe nuk ka fqinjë PIM të cilëve mund t’u dërgohet trafiku multicast ( Non-prune Interface).

Mesazhi Graft.
Le të supozojmë se R3 nuk e donte trafikun nga R2, dërgoi Prune dhe po merrte multicast nga R1. Por papritur, lidhja mes R1-R3 bie dhe R3 mbetet pa multicast. Mund të pritet 3 minuta derisa në R2 të skadojë Prune Timer. Të presësh 3 minuta është shumë, ndaj për të mos pritur, duhet të dërgohet një mesazh që e nxjerr menjëherë këtë ndërfaqe S0/1 në R2 nga gjendja pruned. Ky mesazh është mesazhi Graft. Pas marrjes së mesazhit Graft, R2 do të dërgojë si përgjigje Graft-ACK.
Prune Override.

Le ta shohim këtë skemë. R1 dërgon multicast në segmentin ku ka dy routerë. R3 e merr dhe e shpërndan trafikun, ndërsa R2 e merr, por nuk ka kujt t’ia shpërndajë më tej. Ai dërgon një mesazh Prune te R1 në këtë segment. R1 duhet ta heqë Fa0/0 nga lista dhe të ndalojë së shpërndari në këtë segment, por çfarë ndodh me R3? Edhe R3 ndodhet në të njëjtin segment, e mori po ashtu këtë mesazh Prune dhe e kuptoi seriozitetin e situatës. Para se R1 të ndalojë shpërndarjen, ai vendos një timer prej 3 sekondash dhe do ta ndërpresë transmetimin pas 3 sekondash. 3 sekonda janë pikërisht koha që ka R3 për të mos humbur multicast-in e vet. Prandaj R3, sa më shpejt të jetë e mundur, dërgon një mesazh Pim Join për këtë grup dhe R1 nuk mendon më të ndalojë shpërndarjen. Për mesazhet Join më poshtë.
Mesazhi Assert.

Le të imagjinojmë këtë situatë: në të njëjtin rrjet po shpërndajnë njëkohësisht dy routerë. Ata marrin të njëjtin rrjedhë nga burimi dhe të dy e shpërndajnë atë në të njëjtin rrjet pas ndërfaqes e0. Prandaj duhet të përcaktojnë se cili do të jetë i vetmi shpërndarës për këtë rrjet. Për këtë përdoren mesazhet Assert. Kur R2 dhe R3 zbulojnë duplikim të trafikut multicast, pra kur në R2 dhe R3 mbërrin multicast-i që ata vetë po e shpërndajnë, routerët kuptojnë se diçka nuk është në rregull. Në këtë rast, routerët dërgojnë mesazhe Assert, ku përfshihen Administrative Distance dhe metrika e rrugës përmes së cilës arrihet burimi i multicast-it — 10.1.1.10. Fituesi përcaktohet kështu:

1. Ai që ka AD më të ulët.
2. Nëse AD janë të barabarta, fiton ai që ka metrikën më të ulët.
3. Nëse edhe këtu ka barazi, fiton ai që ka IP më të lartë në rrjetin ku po e shpërndajnë këtë multicast.

Routeri që fiton këtë votim bëhet Designated Router. Për zgjedhjen e DR përdoren gjithashtu mesazhet Pim Hello. Në fillim të artikullit u paraqit mesazhi PIM Hello, ku mund të vihet re fusha DR. Fiton ai që ka adresën IP më të lartë në këtë link.
Një tabelë e dobishme:

Tabela MROUTE.
Pas shqyrtimit fillestar të funksionimit të protokollit PIM, duhet të kuptojmë se si të punojmë me tabelën e rutimit multicast. Në tabelën mroute ruhet informacioni se cilët flukse janë kërkuar nga klientët dhe cilët flukse vijnë nga serverët multicast.
Për shembull, kur merret një IGMP Membership Report ose një PIM Join në një ndërfaqe të caktuar, në tabelën e rutimit shtohet një hyrje e tipit ( *, G ):

Ky regjistrim do të thotë se është marrë një kërkesë për trafik nga adresa 238.38.38.38. Flamuri DC tregon se multicast do të funksionojë në modalitetin Dense mode, ndërsa C do të thotë se marrësi është i lidhur drejtpërdrejt me router-in, pra router-i ka marrë një IGMP Membership Report, jo një PIM Join.
Nëse ka një regjistrim të tipit (S,G), kjo do të thotë se kemi një rrjedhë multicast:

Në fushën S — 192.168.1.11, është përcaktuar adresa IP e burimit të multicast-it; pikërisht ajo do të kontrollohet nga rregulli RPF. Në rast problemesh, gjëja e parë që duhet kontrolluar është tabela unicast për rrugën drejt burimit. Fusha Incoming Interface tregon ndërfaqen në të cilën mbërrin multicast-i. Në tabelën e rutimit unicast, rruga drejt burimit duhet t'i referohet ndërfaqes së treguar këtu. Te Outgoing Interface tregohet se ku do të përcillet multicast-i. Nëse është bosh, kjo do të thotë se router-i nuk ka marrë kërkesa për këtë trafik. Informacion më të detajuar për të gjithë flamujt mund ta gjeni këtu.
PIM Sparse-mode.
Strategjia Sparse-mode është e kundërta e Dense-mode. Kur Sparse-mode merr trafik multicast, ai do ta dërgojë trafikun vetëm përmes atyre ndërfaqeve ku ka pasur kërkesa për këtë rrjedhë, për shembull mesazhe Pim Join ose IGMP Report me kërkesë për këtë trafik.
Elementet e ngjashme te SM dhe DM:

• Marrëdhëniet e fqinjësisë ndërtohen njësoj si në PIM DM.
• Rregulli RPF funksionon.
• Përzgjedhja e DR është e njëjtë.
• Mekanizmi Prune Overrides dhe mesazhet Assert janë të ngjashme.

Për të kontrolluar se kujt, ku dhe çfarë trafiku multicast i nevojitet në rrjet, duhet një qendër e përbashkët informacioni. Kjo qendër është Rendezvous Point ( RP ). Të gjithë ata që duan një trafik të caktuar multicast ose që kanë filluar të marrin trafik multicast nga burimi, e dërgojnë atë te RP.
Kur RP të marrë trafik multicast, ai do ta dërgojë te ata router-a që e kanë kërkuar më parë këtë trafik.

Le të imagjinojmë një topologji të tillë ku RP është R3. Sapo R1 të marrë trafik nga S1, ai do ta enkapsulojë këtë paketë multicast në një mesazh unicast PIM Register dhe do ta dërgojë te RP. Si e di ai se kush është RP? Në këtë rast, ai është konfiguruar statikisht, ndërsa për konfigurimin dinamik të RP do të flasim më vonë.

ip pim rp-address 3.3.3.3

RP do të kontrollojë nëse ka pasur informacion nga ndokush që dëshiron ta marrë këtë trafik. Le të supozojmë se nuk ka pasur. Atëherë RP do t'i dërgojë R1 mesazhin PIM Register-Stop, që do të thotë se askujt nuk i nevojitet ky multicast dhe regjistrimi refuzohet. R1 nuk do të dërgojë multicast. Por hosti-burim i multicast-it do të vazhdojë ta dërgojë atë, prandaj pasi të marrë Register-Stop, R1 do të nisë timer-in Register-Suppression, me vlerë 60 sekonda. 5 sekonda para skadimit të këtij timer-i, R1 do të dërgojë një mesazh bosh Register me bit-in Null-Register (pra, pa paketë multicast të inkapsuluar) drejt RP. Nga ana e vet, RP do të veprojë kështu:

• Nëse marrësit ende nuk ekzistojnë, ai do të përgjigjet me mesazhin Register-Stop.
• Nëse janë shfaqur marrës, ai nuk do t'i përgjigjet fare. Nëse R1 nuk merr refuzim për regjistrimin e tij brenda 5 sekondash, do ta konsiderojë këtë si konfirmim dhe do të dërgojë te RP një mesazh Register me multicast të inkapsuluar.

Tani që e kuptuam si arrin multicast te RP, le të përpiqemi t'i përgjigjemi pyetjes se si RP ua çon trafikun marrësve. Këtu duhet të prezantojmë një koncept të ri — root-path tree (RPT). RPT është një pemë me rrënjë në RP, që zgjatet drejt marrësve dhe degëzohet në çdo router PIM-SM. RP e krijon atë duke marrë mesazhe PIM Join dhe duke shtuar një degë të re në pemë. Të njëjtën gjë bën edhe çdo router i nivelit më të ulët. Rregulli i përgjithshëm duket kështu:

• Kur një router PIM-SM merr një mesazh PIM Join në cilindo interfejs, me përjashtim të interfejsit pas të cilit ndodhet RP, ai shton një degë të re në pemë.
• Gjithashtu, një degë shtohet kur një router PIM-SM merr një IGMP Membership Report nga një host i lidhur drejtpërdrejt.

Le të supozojmë se kemi një klient multicast në routerin R5 për grupin 228.8.8.8. Sapo R5 të marrë një IGMP Membership Report nga hosti, R5 dërgon një PIM Join në drejtim të RP dhe njëkohësisht shton në pemë interfejsin që sheh nga hosti. Më pas, R4 merr PIM Join nga R5, shton në pemë interfejsin Gi0/1 dhe dërgon PIM Join në drejtim të RP. Më në fund, RP (R3) merr PIM Join dhe shton Gi0/0 në pemë. Kështu kryhet regjistrimi i marrësit multicast. Formohet një pemë me rrënjë R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Pas kësaj, do të dërgohet një PIM Join te R1 dhe R1 do të nisë të dërgojë trafikun multicast. Është e rëndësishme të theksohet se nëse hosti ka kërkuar trafik para se të fillojë transmetimi multicast, RP nuk do të dërgojë PIM Join dhe në përgjithësi nuk do të dërgojë asgjë në drejtim të R1.
Nëse gjatë transmetimit multicast hosti nuk dëshiron më ta marrë atë, sapo RP të marrë PIM Prune në interfejsin Gi0/0, ai menjëherë do të dërgojë PIM Register-Stop direkt te R1 dhe më pas edhe një mesazh PIM Prune përmes interfejsit Gi0/1. PIM Register-Stop dërgohet me unicast në atë adresë nga e cila është marrë PIM Register.
Siç e thamë më parë, sapo një router i dërgon PIM Join një tjetri, për shembull R5 te R4, në R4 shtohet regjistrimi i mëposhtëm:

Dhe niset një timer; që ky timer të mos skadojë, R5 duhet të dërgojë vazhdimisht mesazhe PIM Join, përndryshe R4 do ta heqë nga outgoing list. R5 do të dërgojë mesazhe PIM Join çdo 60 sekonda.
Kalimi në Shortest-Path Tree.
Do të shtojmë një interfejs midis R1 dhe R5 dhe do të shohim si do të rrjedhë trafiku në këtë topologji.

Le të supozojmë se trafiku dërgohej dhe merrej sipas skemës së vjetër R1-R2-R3-R4-R5, dhe më pas ne lidhëm dhe konfiguruam interfejsin midis R1 dhe R5.
Së pari, në R5 do të rindërtohet tabela e rutimit unicast dhe tani rrjeti 192.168.1.0/24 arrihet përmes interfejsit Gi0/2 të R5. Tani, kur R5 merr multicast në interfejsin Gi0/1, ai kupton se rregulli RPF nuk përmbushet dhe se multicast do të ishte më logjike të merrej në Gi0/2. Ai duhet të shkëputet nga RPT dhe të ndërtojë një pemë më të shkurtër, e cila quhet Shortest-Path Tree ( SPT ). Për këtë, përmes Gi0/2 ai dërgon PIM Join te R1 dhe R1 nis të dërgojë multicast edhe përmes Gi0/2. Tani R5 duhet të çabonohet nga RPT, që të mos marrë dy kopje. Për këtë ai dërgon një mesazh Prune duke specifikuar adresën IP të burimit dhe duke vendosur një bit të veçantë — RPT-bit. Kjo do të thotë: mos më dërgo trafik këtu, unë kam një pemë më të mirë. RP gjithashtu dërgon mesazhe PIM Prune në drejtim të R1, por nuk dërgon mesazh Register-Stop. Një veçori tjetër është se R5 tani do të dërgojë vazhdimisht PIM Prune te RP, sepse R1 vazhdon t’i dërgojë RP-së PIM Register çdo minutë. RP, për sa kohë nuk ka kërkues të rinj për këtë trafik, do t’i përgjigjet me refuzim. R5 e njofton RP-në se vazhdon ta marrë multicast përmes SPT.
Zbulimi dinamik i RP.
Auto-RP.
Kjo teknologji është pronësore e Cisco-s dhe nuk gëzon ndonjë popullaritet të veçantë, por ende përdoret. Funksionimi i Auto-RP përbëhet nga dy faza kryesore:
1) RP dërgon mesazhe RP-Announce në adresën e rezervuar 224.0.1.39, duke deklaruar veten si RP ose për të gjitha grupet, ose për grupe të caktuara. Ky mesazh dërgohet çdo minutë.
2) Kërkohet një RP mapping agent, i cili do të dërgojë mesazhe RP-Discovery duke treguar se për cilat grupe duhet përdorur cili RP. Pikërisht nga ky mesazh, routerat e zakonshëm PIM do të përcaktojnë RP-në për veten e tyre. Mapping Agent mund të jetë si vetë routeri RP, ashtu edhe ndonjë router i veçantë PIM. RP-Discovery dërgohet në adresën 224.0.1.40 me një interval prej një minute.
Le ta shohim procesin më në detaje:
Le të konfigurojmë R3 si RP:

ip pim send-rp-announce loopback 0 scope 10

R2 si mapping agent:

ip pim send-rp-discovery loopback 0 scope 10

Ndërsa në të gjithë të tjerët do të presim RP përmes Auto-RP:

ip pim autorp listener

Sapo të konfigurojmë R3, ai do të fillojë të dërgojë RP-Announce:

Ndërsa R2, pas konfigurimit si mapping agent, do të fillojë të presë mesazhet RP-Announce. Vetëm kur të gjejë të paktën një RP, do të fillojë të dërgojë RP-Discovery:

Kështu, sapo routerat e zakonshëm ( PIM RP Listener ) ta marrin këtë mesazh, ata do të dinë ku ta kërkojnë RP-në.
Një nga problemet kryesore të Auto-RP është se, për të marrë mesazhet RP-Announce dhe RP-Discovery, duhet të dërgohet PIM Join në adresat 224.0.1.39-40, ndërsa për ta dërguar këtë kërkesë, duhet ditur se ku ndodhet RP. Problemi klasik i vezës dhe pulës. Për ta zgjidhur këtë problem, u krijua modaliteti PIM Sparse-Dense-Mode. Nëse routeri nuk e njeh RP-në, ai punon në modalitetin Dense-mode; nëse e njeh, punon në modalitetin Sparse-mode. Kur në ndërfaqet e routerave të zakonshëm konfigurohen PIM Sparse-mode dhe komanda ip pim autorp listener, routeri do të punojë në modalitetin Dense-mode vetëm për multicast-in e vetë protokollit Auto-RP ( 224.0.1.39-40 ).
BootStrap Router (BSR).
Ky funksion punon në mënyrë të ngjashme me Auto-RP. Çdo RP i dërgon një mesazh mapping agent-it, i cili mbledh informacionin e mapimit dhe më pas ua shpërndan të gjithë routerave të tjerë. Le ta përshkruajmë procesin njësoj si te Auto-RP:
1) Sapo të konfigurojmë R3 si kandidat për RP, me komandën:

ip pim rp-candidate loopback 0

R3 nuk do të bëjë asgjë, sepse që të fillojë të dërgojë mesazhe të posaçme, fillimisht duhet të gjejë mapping agent-in. Prandaj kalojmë te hapi i dytë.
2) Konfigurojmë R2 si mapping agent:

ip pim bsr-candidate loopback 0

R2 fillon të dërgojë mesazhe PIM Bootstrap, ku e deklaron veten si mapping agent:

Ky mesazh dërgohet në adresën 224.0.0.13, të cilën protokolli PIM e përdor edhe për mesazhe të tjera. Ai i dërgon në të gjitha drejtimet, prandaj këtu nuk ka problemin e "pulës dhe vezës", siç ndodhte me Auto-RP.
3) Sapo RP të marrë mesazhin nga ruteri BSR, ai menjëherë dërgon një mesazh unicast në adresën e ruterit BSR:

Më pas, pasi BSR të marrë informacionin për RP, ai do ta shpërndajë atë me multicast në adresën 224.0.0.13, të cilën e dëgjojnë të gjithë ruterët PIM. Prandaj, një analog i komandës ip pim autorp listener nuk ekziston për ruterët e zakonshëm në BSR.
Anycast RP me Multicast Source Discovery Protocol (MSDP).
Auto-RP dhe BSR na lejojnë të shpërndajmë ngarkesën në RP në këtë mënyrë: çdo grup multicast ka vetëm një RP aktiv. Nuk është e mundur të bëhet shpërndarja e ngarkesës për një grup multicast të vetëm midis disa RP-ve. MSDP e realizon këtë duke u caktuar RP-ve të njëjtën adresë IP me maskën 255.255.255.255. MSDP e merr këtë informacion përmes një prej metodave: statikisht, me Auto-RP ose me BSR.

Në figurë kemi një konfigurim Auto-RP me MSDP. Të dy RP-të janë konfiguruar me adresën IP 172.16.1.1/32 në ndërfaqen Loopback 1 dhe ajo përdoret për të gjitha grupet. Gjatë RP-Announce, të dy ruterët njoftojnë për veten duke iu referuar kësaj adrese. Mapping agent i Auto-RP, pasi merr informacionin, dërgon RP-Discovery për RP me adresën 172.16.1.1/32. Për rrjetin 172.16.1.1/32, ne i njoftojmë ruterët përmes IGP-së. Si rezultat, ruterët PIM kërkojnë ose regjistrojnë rrjedhat te ai RP që shfaqet si next-hop në rrugën drejt rrjetit 172.16.1.1/32. Vetë protokolli MSDP shërben për RP-të, që të shkëmbejnë mesazhe me informacion për multicast-in.
Le të shqyrtojmë këtë topologji:

Switch6 dërgon trafik në adresën 238.38.38.38 dhe për të aktualisht di vetëm RP-R1. Ndërkohë, Switch7 dhe Switch8 e kanë kërkuar këtë grup. Ruterët R5 dhe R4 do të dërgojnë PIM Join te R1 dhe R3, përkatësisht. Pse? Rruga drejt 13.13.13.13 te R5 do të tregojë te R1 sipas metrikës IGP, po ashtu edhe te R4.
RP-R1 e njeh rrjedhën dhe do të fillojë ta transmetojë atë në drejtim të R5, ndërsa R4 nuk di asgjë për të, sepse R1 nuk do ta dërgojë pa arsye. Prandaj nevojitet MSDP. E konfigurojmë atë në R1 dhe R5:

ip msdp peer 3.3.3.3 connect-source Loopback1 në R1

ip msdp peer 1.1.1.1 connect-source Loopback3 në R3

Ata do të krijojnë një sesion mes njëri-tjetrit dhe, kur të marrin çfarëdo rrjedhe, do ta njoftojnë për të fqinjit të tyre RP.
RP-R1, sapo të marrë stream-in nga Switch6, menjëherë do të dërgojë me unicast një mesazh MSDP Source-Active, i cili do të përmbajë informacion të tipit (S, G) — të dhëna për burimin dhe destinacionin e multicast-it. Tani, kur RP-R3 ta dijë se ekziston një burim i tillë si Switch6, me të marrë kërkesën nga R4 për këtë stream, do të dërgojë një PIM Join në drejtim të Switch6, duke u bazuar në tabelën e rutimit. Si rrjedhojë, R1, pasi të marrë një PIM Join të tillë, do të nisë të dërgojë trafikun në drejtim të RP-R3.
MSDP punon mbi TCP; RP-të i dërgojnë njëri-tjetrit mesazhe keepalive për të kontrolluar disponueshmërinë. Timer-i është 60 sekonda.
Mbetet e paqartë funksioni i ndarjes së peer-ve MSDP në domene të ndryshme, pasi në mesazhet Keepalive dhe SA nuk tregohet përkatësia ndaj ndonjë domeni. Gjithashtu, në këtë topologji u testua edhe konfigurimi me specifikimin e domeneve të ndryshme — nuk pati asnjë ndryshim në funksionim.
Nëse dikush mund të sjellë më shumë qartësi, do ta lexoj me kënaqësi në komente.

Burimi: habr.com