W dniu 2012-02-06 15:38, Tomasz Chiliński pisze:
Ogolnie chodzi o rozbudowe lms'a w kierunku systemu paszportyzacyjnego.
To można nazwać elementami sieci. Nie wiem czy warto do tegorocznego raportu nastawiać się na tak duże zmiany w LMS. Moim zdaniem do wygenerowania raportu SIIS powinno wystarczyć staranne przemyślenie implementacji tego co opisałeś w punktach 2 i 3.
Raport ogolnie tak mocno sie nie zmienil w stosunku do zeszlego roku, wiec na dobra sprawe jakby sie uparl to mozna zrobic copy+paste rozwiazan zeszlorocznych. Moim zdaniem jednak jak mamy cokolwiek robic to zrobmy to tak by bylo pozyteczne dla samego lms'a. Dlatego optuje ze porzadnymi zmianami, nie zwazajac na czas do kiedy trzeba raport zrobic (najwyzej zrobi sie go tak jak w tamtym roku). Ogolnie chyba jak dobrze pamietam to do 30 marca jest czas to cos tam powinno sie udac chyba zrobic?
- Urzadzenia sieciowe (wezly).
a) Dodanie kategorii wezla, a wiec czy to wezel szkieletowy, dystrybucyjny czy dostepowy (kazdy wezel moze byc w kazdym ze stanow - moze byc tylko dystrybucyjny, albo zarazem szkieletowy, dystrybucyjny i dostepowy) - tu proponuje 3 checkboxy poprostu i jedno pole w bazie.
To robiłem w ten sposób, że urządzeniem dystrybucyjnym było to do którego są podłączone tylko komputery i max. jedno urządzenie (wiadomo, że potrzebny jest uplink). Gdy do urządzenia było podłączonych więcej niż jedno urządzenie urządzenie stawało się urządzeniem dystrybucyjnym. Węzeł zależnie od tego, jakie urządzenia zawierał, stawał się dostępowym, dystrybucyjnym lub jednym i drugim. Zakładałem, że jeśli urządzenie spina tylko urządzenia dystrybucyjne to jest urządzeniem szkieletowym.
Nie widze przeciwskazan by tak to realizowac.
- przepustowosc wykorzystywana w warstwie szkieletowej,
dystrybucyjnej i ile wolnego zostaje
Tutaj możemy wyliczyć w oparciu o automatyczną klasyfikację typów urządzeń przedstawioną powyżej, a także o dodanie szybkości portu. Możemy założyć np. że przepustowość w warstwie szkieletowej jest równa sumie wszystkich przepustowości w warstwie dystrybucyjnej, a jeśli przekracza szybkość w warstwie szkieletowej, to wtedy szybkość portu. Możemy również przyjąć, że przepustowość w warstwie dystrybucyjnej to suma wszystkich rate-ów klientów podłączonych w warstwie dostępowej. Myślę, że tu można dopracować sposób automatycznego wyliczania przepustowości na warstwę dystrybucyjną i szkieletową. Ponadto jeśli rozsądnie dopracujemy sposób wyliczania szybkości i przepustowości portów to może to być potem nawet przydatne do ustalania wąskich gardeł w sieci, a nie tylko na potrzeby UKE.
Ogolnie nastawiajmy sie nie tylko na raport do UKE, ale i na przydatnosc danego rozwiazania. O tych przepustowosciach to byla dluga dyskusja z Panami z teleinfrastuktury i koniec koncow mial to zostac wywalone calkowicie. Jednak jak przegladnelem obecny schemat xml'a to widzialem tam gdzies to.
c) Wezel musi posiadac jeszcze dane dotyczace:
- liczby interfejsow lacznie (ile portow ma urzadzenie lacznie - jest
w lms)
- liczby interfejsow dostepna dla klientow - (ile portow jest
zajetych przez klientow - jest w lms)
- liczba wolnych interfejsow - (wszystko co niepodlaczone jest wolne)
- jezeli to wezel wifi (nadajnik) to podajemy azymut, szerokosc
katowa i teoretyczny zasieg.
Azymut, szerokość kątowa i teoretyczny zasięg i ile widzę nie są wymagane przez SIIS (opcjonalne).
To akurat jest mocno przydatne dla 'wifiukowcow'. Sam osobiscie, choc klienci bezprzewodowi to ulamek moich klientow, doceniam informacje zawarte w lmsie na temat kierunku w ktorym strzela dany sektor. A w umysle widze juz mape, ktora rysuje "teoretyczny zasieg" takiego sektorka. Panienka z biura tylko wpisuje wspolrzedne klienta i juz wie do ktorej anteny go podpiac - a np moje systemy automatycznie przypisuja klienta tylko do nadajnika, do ktorego ma zostac podlaczony. Warto wiec dodac to jako opcjonalne pole.
Urządzeń sieciowych lepiej nie nazywać węzłami. Węzeł to po prostu zbiór elementów sieci.
Tu kwesta nazewnictwa - wg uke wezel, to jedno urzadzenie, do ktorego sa dopieci np klienci, o jednej technologii dostepu, o danej przepustowosci itp. Dlatego przydalaby sie ta nadrzedna kategoria (nazwijmy ja tymczasowo - skupisko urzadzen) ktora skupialaby by pod soba urzadzenia. Polaczenia reprezentowane na mapie defakto bylyby wlasnie miedzy takimi "skupiskami" i dopiero w tych polaczeniach latalyby normalne polaczenia miedzy pojedynczymi urzadzeniami. Ja to widze to tak ze mamy: - serwerownie (skupisko urzadzen) - szafe dystrybucyjna (skupisko urzadzen) - switch szkieletowy (urzadzenie sieciowe) - router (urzadzenie sieciowe) - switch dostepowy (urzadzenie sieciowe) - router klienta (komputer klienta)
I np laczymy serwerownie z szafa dystrybucyjna linkiem, ktory mozemy opisac jako swiatlowod 24J z opisem ze jest w rurociagu, kanalizacji, ze to przewieszka. A np switcha szkieletowego z dystrubucyjnym laczymy juz 2 wloknami z tego swiatlowodu w wyzszej warstwie. Tak wiec widzimy odrazu ile wlokien jest wykorzystanych, ile wolnych itp. Tu mozna by sie pokusic o przemyslenie tego systemu 'warstw' tak by mozna bylo dodawac taka hierarchie wyzej: - kanalizacja (opis z czego zbudowana itp) - wtornik rhdpe (opis jaka srednica itd) - medium (opis jaki kabel, czy to swiatlo, czy drut, czy czestostliwosc wifi, oraz opisy ile wlokien itd) - wlokna (kolorki, rozpiski, ktore porty w przelacznicy, szafce rozdzielczej) - kanal logiczny (np oddzielny vlan)
Wiem, ze to moze byc kosmicznie trudne do wdrozenia, ale wlasnie w tym kierunku widze rozwoj lms'a. Zobaczcie, ze nie istnieje na rynku zaden system paszportyzacyjny, ktory umozliwialby cos takiego (poza autorskimi za gruuuube pieniadze)
- pakiet sprzedanych uslug "komputerowi" (tu nie mam pomyslu jak to
zrealizowac - trzeba podac jaki pakiet uslug sprzedajemy - czy tylko internet, czy telefon i internet czy jeszcze tv itp)
Tutaj można ustalić typ usług na podstawie tego jakie taryfy są przypisane do komputera. W taryfie istnieje już właściwość typ usługi.
Ok, czyli to juz w samym raporcie sie "znajdzie".
- wlasnosc infrastruktury (czy polaczenie do klienta to nasze wlasne
polaczenie czy jakies wlr, llu, bsa itp - tu chyba taka informacja powinna pojawic sie w wezle - jak korzystamy z czyjejs infrastruktury to zapewne jest jakas szafka kablowa etc i to nalezy potraktowac jako oddzielny wezel i tam juz na podstawie opisu portu mozna dojsc co i jak)
Na razie dla uproszczenia proponuję przyjąć sztywną własność infrastruktury jako własną.
Narazie tak, ale docelowo mozna tez myslec by gdzies taka informacje (o wlasnosci danej kanalizacji, linka etc) gdzies miec. Ja widze to znow w tych nadrzednych hierarchiach, gdzie mozemy opisac np kanalizacje jako wlasnosc tpsa.
W całym projekcie SIIS daje po oczach mocna akademickość pomysłu i znaczne oderwanie od rzeczywistości ;-D
Ja przyznaje, ze o ile sam sposob zbierania danych, powod itp jest fatalny, to same dane o ktore pytaja sa bardzo przydatne przy ISP'owaniu. Pracujac u jednego z wiekszych ISP w Polsce, zauwazylem ze dodatki do programu sieciowego, ktore zostaly robione rok temu na potrzeby raportu, znalazly zastosowanie w samym programie i dzis ciezko byloby sie bez tego obyc pracownikom. Mam nadzieje ze wlasnie tak bedzie z dodatkami do LMS'a.
Ps. Odezwij sie Tomaszu na pw to ustalimy tam szczegoly umowy miedzy Toba, a iNET Group na wykonanie tych przerobek. Bo juz tez rok prawie minal i musze temat u nas ozywic :)
pozdrawiam