Ihtuorai2010 05

Ez az oldal a korábbi SCH wikiről lett áthozva.

Ha úgy érzed, hogy bármilyen formázási vagy tartalmi probléma van vele, akkor, kérlek, javíts rajta egy rövid szerkesztéssel!

Ha nem tudod, hogyan indulj el, olvasd el a migrálási útmutatót.

Infokommunikációs hálózatok tervezése és üzemeltetése

5. óra

INFO: ZH jövő hét hétfőn: márc 1!!!

Védett hálózatok jellemzése (ism.)

• hibaállapotban a viselkedés
• milyen jellemzői vannak a viselkedésnek?
• milyen alapon lehet összahasonlítani hálózati változatokat?
• tervezési/architekturális jellemzők
• Nézőpontok
  • Egy adott hibára mi történik
  • Adjuk meg az össes hibára a működést
  • összefüggő marad-e az egyszerű gráf modellnél

Alapmodellek a számításokhoz

• él/csomópont típusú hibák e
• függő vagy független
• két/többállapotú elemek
• speciális/általános gráfok
• max flow/fix/relatív útvonalválasztás
• összefüggőség/kapacitás/forgalmi mérőszámok
• nagyon sokféle analízis technika

Teljesítőképesség index

• a várható teljesítmény a névlegeshez
• teljesítmény eloszlás
• minden paraméter kifejezhető ezen paramétereken keresztül
• $NPI={\frac {E(Perf)}{Perf_{max}}}={\frac {\sum _{y\subset Y}Perf(y)*Pr(y)}{Perf_{max}}}$
• Perf: egy egy paraméter, aminek a hatékonyságára kíváncsiak vagyunk
• $g(y)=1-{\frac {Perf(y)}{Perf_{max}}}$

Védelmi megoldások teljesítménye

• egy adott y hálózati állapotra a sikeresen kiszolgált igények kapacitásának összege
• $d_{i,j}^{c}$: az i,j pontok közti igény a c igényosztályban

*

• ... breakpoint

• $D^{c}=...$ Nagy képlet

Dedikált védelmek teljesítménye

• $p_{i,j,y}^{c}$ működik, ha a hibáls hálózatelemen eredetileg nem halat át
• egy hiba:
  • nem befolyásol - $d_{i,j}^{c}$
  • a két (1+1) út ...

Osztott védelmek teljesítménye

• $p_{i,j,y}^{c}$ működik, ha a hibáls hálózatelemen eredetileg nem halat át
• egy hiba:
  • nem befolyásol - $d_{i,j}^{c}$
• két vagy több hiba:
  • nem befolyásol - $d_{i,j}^{c}$
  • versenyhelyzet: $\leq d_{i,j}^{c}$
• hibafüggőség: sorrendfüggő

védett összeköttetés jellemzése

• pont-pont összeköttetésre
• szolgáltatási jellemző
• alapesetben nem védett, dedikált tartalék alapozott védelmű:
  • klasszikus megbízhatóság-elméleti modell (soros, párhuzamos elemek)
• osztott védelem és helyreállításakor többszörös hibák esetén önmagában nem kiértékelhető
  • (a versenyhelyzet miatt kölcsönhatás más összeköttetésekkel)

Védelmi alapszerkezetek hálózati alkalmazása

• lineáris multiplex szakasz védelem: (egy link hibáját kell kiküszöbölni, elég, ha a link pontok tudnak róla)
  • csomóponti hibák ellen nem véd
  • kisebb terhelés a menedzsment rendszernek (kevesebb esemény)
• osztott multiplex szakaszvédelem (például gyűrűben): közös tartalékkapacitásból oldjuk meg a problémát
  • egy csomóponti vagy szakaszhiba ellen véd
  • öngyógyító gyűrű
• útvédelem
  • közbülső csomópontok hibáitól is véd
  • sokkal több esemény
  • speciális technológiai feltételei is lehetnek
  • itt jött két kép az útvédelemről, meg az osztott multiplex védelemről
  • jött egy kép az útvédett gyűrű
  • SNCP: Sub Network Cycle Protection
    • védelem visszahurkolással
    • ha sok kapacitást foglalok osztott multiplexeset, akkor drágább lesz sokkal, mint az útbiztosításos
  • korlátozott együttműködés esetén kritikus pontok alakulnak ki
  • kapcsolódási alapesetek
    • szövevény
    • gyűrű szövevény
  • kép az 1+1 gyűrű szövevényről
  • MSSP gyűrűk együttműködése

Védelem csomagalapú esetben

• Előre bekonfigolt nem feltétlenül jelenti az erőforrások pazarlását
• hiba esetén szüksége a hozzáférés a védelemre lefoglalt erőforrásokhoz
• alapesetek:
  • csomag alapú gyűrű
  • csomat alapú szövevény

Csomagkapcsolt gyűrű

• valami RPR ring
• MAC cím alapú gyors csomagtovábbbítás
• csak három művelet:
  • kivesz cím vagy ttl mező alapján
  • betesz
  • továbbküld
• automatikus topológia felderítés
  • periodikus üzenetküldés (topology message)
  • minden csomópont hozzákapcsolja a saját MAC címét és továbbküldi
  • a forrás visszakap egy címlistát
  • elsődleges és másodlagos utak
  • ARP az IP-MAC címillesztéshez

-- Liba - 2010.02.22.