Signalling of Point to Multipoint Trees in Metro Ethernet and Core Networks Tekijä: Mikko Kinnunen Valvoja: Prof. Raimo Kantola 11.10.2011 Espoo.

Esitys aiheesta: "Signalling of Point to Multipoint Trees in Metro Ethernet and Core Networks Tekijä: Mikko Kinnunen Valvoja: Prof. Raimo Kantola 11.10.2011 Espoo."— Esityksen transkriptio:

1 Signalling of Point to Multipoint Trees in Metro Ethernet and Core Networks Tekijä: Mikko Kinnunen Valvoja: Prof. Raimo Kantola 11.10.2011 Espoo

2 Esitelmän sisältö  Työn tausta  Ongelma ja tavoitteet  Arkkitehtuuri ja protokollat  Nykyinen ratkaisu  Uudet ratkaisut  Testien järjestely  Testien tulokset  Johtopäätökset ja jatkotutkimus

3 Työn tausta  IPTV  paljon kaistaa vaativa palvelu  vaatii tehokkaan kanavien jakelun -> monilähetys

4 Ongelma ja tavoitteet  Nykyinen monilähetyspuu on vaikea hoitaa  puuta muutetaan linkki kerrallaan -> epämiellyttävää ja kallista  Tavoitteena tutkia parempia ratkaisuja monilähetyspuiden signalointiin  laitevalmistajien esitteet  laitevalmistajien oppaat  Suunnitellut ratkaisut toteutetaan tietoliikennelaboratoriossa, jossa ratkaisut testataan

5 Arkkitehtuuri ja protokollat  Hierarkinen rakenne IP-verkossa  Runkoverkko  Reitittimet  Metro Ethernet-alueverkot  Palvelukytkimet  Yhdistetty toisiinsa runkoverkolla  Liityntäverkko  Digital Subscriber Line Access Multiplexer:t (DSLAM:t)  Liittää asiakkaat operaattorin verkkoon

6 Arkkitehtuuri ja protokollat  Reititysprotokolla  Lähettää ja vastaanottaa tietoja naapurireitittimiltä  Laskee lyhimmän reitin linkkimetriikkojen perusteella verkon jokaiseen solmuun  Reittitiedot reititystauluun  Internet Group Management Protocol (IGMP)  Kerää tietoja halukkaista monilähetysliikenteen vastaanottajista  IGMPv2: Any Source Multicast (*,G)  Asiakas lähettää Join-viestin liittyäkseen ryhmään  Asiakas lähettää Leave-viestin erotakseen ryhmästä  IGMPv3: Source Specific Multicast (S,G)  Join-/Leave-viestit lähettäjä- sekä ryhmäkohtaisia  IGMP Snooping  Ainoastaan ”haistelee” läpikulkevia IGMP Join-/Leave-viestejä  Protocol Independent Multicast (PIM)  Luo reititysprotokollan avulla monilähetysreititystaulun  Sparse Mode  Join-/Prune-viestit, joilla solmu liitetään monilähetyspuuhun  Lähettäjä ja vastaanottaja kohtaavat Rendezvous Point:ssa (RP)  Source Specific Multicast  Join-/Prune-viestit lähettäjä- sekä ryhmäkohtaisia  Ei RP:ia

7 Arkkitehtuuri ja protokollat  MultiProtocol Label Switching (MPLS)  Välittää liikennettä ennalta määriteltyjen leimojen perusteella  Vaatii signalointiprotokollan  Resource reSerVation Protocol-Traffic Engineering (RSVP-TE)  Lähettäjäpää aloittaa signaloinnin Path-viestillä haluttuun määränpäähän  Vastaanottaja vastaa Resv-viestillä, joka jakaa leimat polulle  Vastaanottaja siis kertoo millä leimalla se haluaa vastaanottaa paketteja  Point to MultiPoint laajennus RSVP-TE:iin  uusi toiminto laitteissa  Lähettää ja vastaanottaa useita Path- ja Resv-viestejä  Luo leimakytkentäisen polun (LSP) pisteestä moneen pisteeseen kerralla  Fast ReRoute (FRR)  Uusi toiminto laitteissa  Luo varareittejä LSP:lle  Linkki- ja solmusuojaus  Staattiset varareitit  Dynaamiset varareitit

8 Nykyinen ratkaisu  Runkoverkko  PIM-SSM  Kaikki kanavat tuodaan verkon laidalle  Liikennettä katsojista riippumatta  Metroverkko  RSVP-TE ja IGMP Snooping  Staattiset varareitit  Runkoverkon laidalta otetaan vain ne kanavat mitä asiakkaat haluavat katsoa  Ei katsojia, ei liikennettä

9 Uudet ratkaisut  Metroverkko  Lisänä FRR  Staattiset varareitit pois  Teoriassa lähes puolittaa verkonhallinnan työmäärän  Ei vaikuta runkoverkkoon

10 Uudet ratkaisut  Metroverkko ennallaan  Runkoverkossa P2MP RSVP-TE  Linkkisuojaukset FRR:lla  Teoriassa Metroverkon monilähetyspuun voisi paikoin toteuttaa myös P2MP RSVP- TE:lla, mutta uusien linjakorttien määrä ja yhteensopivuus vanhojen korttien kanssa rajoittaa käyttöönottoa

11 Testien järjestely  Tietoliikennelaboratorioon rakennettiin testiverkko /7 ME1 ME3 /8 ME2 BRAS e02 (Cisco) Core e05 (Cisco) Core c01(Juniper) Core e06 (Cisco) Core e01(Juniper) /10 /9 /6

12 Testien järjestely  Lähettäjä ja vastaanottajat emuloitiin  Kuvassa portti /10 on lähde ja loput ovat vastaanottajia  Lähettäjä on SSM-lähde  10000 pakettia / sekunti  Vastaanottajilla on IGMPv3 käytössä  Portti /7:sta on Virtual Local Area Network (VLAN) yhteys e02-reitittimelle  Kaikilla linkeillä sama metriikka

13 Testien järjestely  Linkkikatkaisutestit  Kaksi pääreittiä vastaanottajille  Yksi pääreitti vastaanottajille  Solmun uudelleenkäynnistystestit  Ilman overload-bittiä  Overload-bitin kanssa  Ilmoittaa naapureille, että ei ole käytettävissä  Kätevä suunnitelluissa muutoksissa

14 Testien tulokset  Nykyinen ratkaisu  Metroverkko  Linkkikatkaisu -> liikenne poikki n.1-2s  Liikenteen palatessa alkuperäiselle linkille -> liikenne poikki 0s  Runkoverkko  Linkkikatkaisu -> liikenne poikki n.0,2-0,5s  Liikenteen palatessa alkuperäiselle linkille -> liikenne poikki n.2s  Solmun uudelleen käynnistys -> uudelleen käynnistys kestää n.6min, 0,1ms häviö muille solmuille  Solmun prosessorikortin vaihto -> vaihto kestää n.3min, 0,1ms häviö muille solmuille

15 Testien tulokset  Metroverkko: IGMP Snooping ja FRR  Linkkikatkaisu -> n.20-30ms  Alle 50ms, mutta kyse laboratoriotestistä

16 Testien tulokset  Runkoverkko: P2MP RSVP-TE  Linkkikatkaisu -> n.1s  Liikenteen palatessa alkuperäiselle polulle, ei pakettihäviötä  Solmun uudelleen käynnistys  Liikenne reititetty yhdelle pääpolulle (e01:n kautta)  Liikenne uudelleenreitittyi n.1min jälkeen  Overload-bitin kanssa alle 50ms  Liikenne siirtyy välittömästi uudelle reitille kun bitti asetetaan  Liikenne palaa takaisin alkuperäiselle reitille käynnistyksen ja bitin poiston jälkeen ilman pakettihäviötä  Solmun prosessorikortin vaihto  Liikenne reititetty kuten edellä  Liikenne uudelleenreitittyi n.6s kuluttua  Overload-bitin kanssa alle 50ms  Liikenne siirtyy välittömästi uudelle reitille kun bitti asetetaan  Liikenne pysyy uudella reitillä prosessorikortin vaihdon ja bitin poiston jälkeen

17 Testien tulokset  Runkoverkko: linkkisuojaus  Linkkikatkaisu suojatulla linkillä -> n.40ms  Sivutuotteena reititysprotokollan ”heiluminen”  Reitit muuttuivat n.45s välein -> testit keskeytettiin

18 Johtopäätökset ja jatkotutkimus  Kokonaisuudessaan nykyinen ratkaisu on nykyisillä toiminnoilla toimivin ratkaisu  Vaihtoehtoja on niukasti  Metroverkko  FRR toimi testiverkossa nopeasti ja on helppo liittää konfiguraatiopohjaan  Testitulosten perusteella valmis pilottiin  Runkoverkko  P2MP RSVP-TE osoitti lupaavia tuloksia, mutta ei tällaisenaan ole vielä valmis tuotantoverkkoon  Nopeampi vikatilanteissa kuin PIM ilman linkkisuojaustakin  Liikenne ei aina palaudu alkuperäiselle polulle ilman MPLS session alustamista  Linkkisuojaus paljon nopeampi kuin PIM vikatilanteissa  Reititysprotokollan heiluminen

19 Johtopäätökset ja jatkotutkimus  Mistä reititysprotokollan heiluminen johtuu?  Ohjelmistoversio?  Viallinen rauta?  Uusien linjakorttien testaus Metroverkossa  Onko yhtenäinen P2MP-puu runkoverkosta Metroverkkoon mahdollinen/kannattava?

20 Kiitos  Kysymyksiä  Kommentteja