Inwentaryzacja UKE - SIIS - odplatne przerobki w LMS
A wiec, z uwagi ze sa juz jasne i ostateczne wytyczne co do zakresu raportu jaki wymagac bedzie od nas UKE juz za kilka tygodni, mozna by rozpoczac II etap przerobki lms'a.
Schemat raportu: https://form.teleinfrastruktura.gov.pl/help/ Za wiele sie jednak nie zmienilo w stosunku do roku poprzedniego wiec powinno byc z gorki, ale przerobki nalezy i tak wykonac by ulatwic sobie to na przyszlosc i wniesc cos nowego do lms'a.
Chcialbym wiec miec jasne info, kto chce/moze sie tym zajac? Finansowanie ze strony iNET Group zapewnione, choc jak "przerobka" sie rozrosnie to pewnie mile widziane beda dodatkowe "profity" dla developerow zajmujacych sie tym.
pozdrawiam
W dniu 04.02.2012 23:33, Andrzej Banach napisał(a):
A wiec, z uwagi ze sa juz jasne i ostateczne wytyczne co do zakresu raportu jaki wymagac bedzie od nas UKE juz za kilka tygodni, mozna by rozpoczac II etap przerobki lms'a.
Witam.
Schemat raportu: https://form.teleinfrastruktura.gov.pl/help/ Za wiele sie jednak nie zmienilo w stosunku do roku poprzedniego wiec powinno byc z gorki, ale przerobki nalezy i tak wykonac by ulatwic sobie to na przyszlosc i wniesc cos nowego do lms'a.
Dałoby radę w punktach przedstawić czego brakuje w LMS, aby można było potem wygenerować raport dla UKE (zakładam, że etap I jest skończony)?
Chcialbym wiec miec jasne info, kto chce/moze sie tym zajac? Finansowanie ze strony iNET Group zapewnione, choc jak "przerobka" sie rozrosnie to pewnie mile widziane beda dodatkowe "profity" dla developerow zajmujacych sie tym.
Jako, że Alek nie za bardzo ostatnimi czasy dysponuje wolnym czasem, to pewnie robota przypadnie mi (zresztą zgodnie z ustaleniami z poprzedniego roku).
pozdrawiam
Schemat raportu: https://form.teleinfrastruktura.gov.pl/help/
Dałoby radę w punktach przedstawić czego brakuje w LMS, aby można było potem wygenerować raport dla UKE (zakładam, że etap I jest skończony)?
I etap skonczony.
Co do punktow to z mojego punktu widzenia (nie programistycznego) wykreslajac to co juz zostalo zrobione w pierwszym etapie, brakuje ponizszych. Jednak wolalbym by ktos tez nad tym pomyslal i uproscil/rozbudowal ponizsze. Ogolnie chodzi o rozbudowe lms'a w kierunku systemu paszportyzacyjnego.
1. Najwazniejsze to stworzenie niejako nadrzednej kategorii nad urzadzeniami sieciowymi (wezlami) i polaczen miedzy nimi. Chodzi o to by mozna bylo wpisac do lms'a takie dane jak: - rodzaj zastosowanego medium pomiedzy wezlami; - rozpiska ile wlokien w kablu, gdzie roszycia itp - rodzaj traktu (nadziemny, rurociag etc); - technologia (swiatlowodowa, kablowa, radiowa itp); - typ (DSF, wimax itp);
Tak wiec calkowita robudowa obecnych "polaczen sieciowych", ale nie miedzy obecnymi "urzadzeniami sieciowymi", a pomiedzy tymi z nadrzednych kategorii. Bo takim elementem moze byc zarowno switch, nadajnik radiowy, jak i spliter optyczny czy zwykla szafka rozdzielcza. Dzieki takiemu nadrzednemu menu rysowanie tego na mapie tez bedzie zajebiscie przydatne. Jak ktos mozno zechce to moze naniesc kazda pierdolke w postaci studni kablowej, rurociagu itp i ma mega wypasna mape inwentaryzacyjna pokazujaca caly przebieg sieci. Obecnie polaczenia sieciowe sa tylko miedzy wezlami i na mapie (szczegolnie terenowej openlayers) srednio to wyglada.
2. 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. b) Dodanie opisow kazdego interfejsu wezla (portu): - medium transmisyjne portu (radiowe, swiatlowodowe zwielokrotnione, niezwielokrotnione, kablowe, optyczne w wolnej przestrzeni itp - mozliwosc update opisow) - technologia transmisyjna portu ( ethernet, atm, wimax, wifi itp - mozliwosc update opisow) - max przepustowosc interfejsu (10/100/1000/10000 - mozliwosc update) - przepustowosc wykorzystywana w warstwie szkieletowej, dystrybucyjnej i ile wolnego zostaje 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.
3) Komputery klienckie. (tu male przerobki by mozna bylo wygenerowac raport dotyczacy zasiegu danego wezla). Do raportu potrzebne sa takie dane jak: - technologie podpiecia do wezla (to w sumie mozna odczytac z portu wezla) - 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) - 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) - max przepustowosc jaka mozemy zaoferowac klientowi (teoretycznie szybkosc portu do ktorego podpiety jest klient, ale w niektorych technologiach moze byc ona uzalezniona od zasiegu itp.) - szybkosc do internetu sprzedana klientowi biznesowemu i indywidualnemu
Powyzsze zapewne nie jest kompletne, ale uzupelnie to jak ktos mi powie jak rozszyfrowac tego xml'a https://form.teleinfrastruktura.gov.pl/static/help/siis2.2-8.xsd do jakiejs czytelnej formy. Chodzi o pozostawienie tylko tego co nas interesuje (jakie dane sa potrzebne w obecnej wersji SIIS).
pozdrawiam
W dniu 06.02.2012 00:03, Andrzej Banach napisał(a):
Schemat raportu: https://form.teleinfrastruktura.gov.pl/help/
Dałoby radę w punktach przedstawić czego brakuje w LMS, aby można było potem wygenerować raport dla UKE (zakładam, że etap I jest skończony)?
I etap skonczony.
Co do punktow to z mojego punktu widzenia (nie programistycznego) wykreslajac to co juz zostalo zrobione w pierwszym etapie, brakuje ponizszych. Jednak wolalbym by ktos tez nad tym pomyslal i uproscil/rozbudowal ponizsze.
Właśnie o nie progamistyczny punkt widzenia chodzi ;-) Do tego dokładamy wątek realności wykonania wszystkiego w sensownym czasie i mamy ostateczne kompromisowe rozwiązanie. Poniżej przedstawiam swoje przemyślenia powstałe w oparciu o przygotowywanie raportów SIIS z poprzedniego roku.
Ogolnie chodzi o rozbudowe lms'a w kierunku systemu paszportyzacyjnego.
- Najwazniejsze to stworzenie niejako nadrzednej kategorii nad
urzadzeniami sieciowymi (wezlami) i polaczen miedzy nimi. Chodzi o to by mozna bylo wpisac do lms'a takie dane jak:
- rodzaj zastosowanego medium pomiedzy wezlami;
- rozpiska ile wlokien w kablu, gdzie roszycia itp
- rodzaj traktu (nadziemny, rurociag etc);
- technologia (swiatlowodowa, kablowa, radiowa itp);
- typ (DSF, wimax itp);
Tak wiec calkowita robudowa obecnych "polaczen sieciowych", ale nie miedzy obecnymi "urzadzeniami sieciowymi", a pomiedzy tymi z nadrzednych kategorii. Bo takim elementem moze byc zarowno switch, nadajnik radiowy, jak i spliter optyczny czy zwykla szafka rozdzielcza. Dzieki takiemu nadrzednemu menu rysowanie tego na mapie tez bedzie zajebiscie przydatne. Jak ktos mozno zechce to moze naniesc kazda pierdolke w postaci studni kablowej, rurociagu itp i ma mega wypasna mape inwentaryzacyjna pokazujaca caly przebieg sieci. Obecnie polaczenia sieciowe sa tylko miedzy wezlami i na mapie (szczegolnie terenowej openlayers) srednio to wyglada.
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.
- 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. Pewnie uproszczenie, ale pozwala w sprytny sposób wygenerować raport do UKE, który i tak jest w miarę sensowny, a wątpię, żeby urzędnicy to sprawdzali kabel po kablu (projekty UKE są informatycznie absurdalne). Poza tym na użytkownika LMS nie spada dodatkowa praca z oznaczaniem typów urządzeń np. checkboksami. Myślę, że tutaj lepiej przemyśleć sposób usprawnienia automatycznej klasyfikacji typów urządzeń jeśli chodzi o warstwę w której pracują (dostępowa, dystrybucyjna, szkieletowa) w oparciu o to co już zarysowałem.
b) Dodanie opisow kazdego interfejsu wezla (portu):
- medium transmisyjne portu (radiowe, swiatlowodowe zwielokrotnione,
niezwielokrotnione, kablowe, optyczne w wolnej przestrzeni itp - mozliwosc update opisow)
Tutaj trzeba będzie zrobić tak jak opisujesz. W pierwszej wersji zrobimy listę typów mediów definiowaną na poziomie kodu LMS, a potem dorobimy prosty edytor typów mediów.
- technologia transmisyjna portu ( ethernet, atm, wimax, wifi itp -
mozliwosc update opisow)
Tu widzę to podobnie jak w poprzednim punkcie.
- max przepustowosc interfejsu (10/100/1000/10000 - mozliwosc update)
Tu podobnie jak w poprzednich punktach. Tutaj chyba najlepiej byłoby dać możliwość wyboru szybkości portu z listy wyboru, a także ręcznego wpisania nietypowej szybkości portu. Moim zdaniem nie ma na razie potrzeby tworzenia tutaj możliwości edycji listy możliwych szybkości portu - pole w bazie i tak będzie polem liczbowym, a nie polem typu szybkości. Podsumowując max. przepustowość portu to po prostu szybkość portu.
- 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.
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).
Urządzeń sieciowych lepiej nie nazywać węzłami. Węzeł to po prostu zbiór elementów sieci.
- Komputery klienckie. (tu male przerobki by mozna bylo wygenerowac
raport dotyczacy zasiegu danego wezla). Do raportu potrzebne sa takie dane jak:
- technologie podpiecia do wezla (to w sumie mozna odczytac z portu
wezla)
Zgadza się. Zasięgi klienckie można wprost odczytywać z listy lokalizacji komputerów klienckich.
- 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.
- 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ą.
- max przepustowosc jaka mozemy zaoferowac klientowi (teoretycznie
szybkosc portu do ktorego podpiety jest klient, ale w niektorych technologiach moze byc ona uzalezniona od zasiegu itp.)
- szybkosc do internetu sprzedana klientowi biznesowemu i
indywidualnemu
To możemy ustalać na podstawie tego jaki typ klienta (osoba prywatna, firma) będącego właścicielem komputera podpiętego do urządzenia sieciowego.
Powyzsze zapewne nie jest kompletne, ale uzupelnie to jak ktos mi powie jak rozszyfrowac tego xml'a https://form.teleinfrastruktura.gov.pl/static/help/siis2.2-8.xsd do jakiejs czytelnej formy. Chodzi o pozostawienie tylko tego co nas interesuje (jakie dane sa potrzebne w obecnej wersji SIIS).
W całym projekcie SIIS daje po oczach mocna akademickość pomysłu i znaczne oderwanie od rzeczywistości ;-D
pozdrawiam
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
W dniu 2012-02-06 19:59, Andrzej Banach pisze:
Ogolnie chodzi o rozbudowe lms'a w kierunku systemu paszportyzacyjnego.
Ps. wkoncu wrzucili dzisiaj xls'a o ktorego prosilem (weryfikator vel genarator) w ktorym jasno widac jakie pola sa potrzebne i jakie wartosci powinny przyjmowac: https://form.teleinfrastruktura.gov.pl/static/help/SIIS_Generator_2_0.zip
pozdrawiam
W dniu 06.02.2012 20:11, Andrzej Banach napisał(a):
W dniu 2012-02-06 19:59, Andrzej Banach pisze:
Ogolnie chodzi o rozbudowe lms'a w kierunku systemu paszportyzacyjnego.
Ps. wkoncu wrzucili dzisiaj xls'a o ktorego prosilem (weryfikator vel genarator) w ktorym jasno widac jakie pola sa potrzebne i jakie wartosci powinny przyjmowac:
https://form.teleinfrastruktura.gov.pl/static/help/SIIS_Generator_2_0.zip
Przeglądałem właśnie to. Szkoda, że robią to w XLS. Przez to reguły warunkowo wypełniające pola są nieczytelne, a Microsoft Office na swoim komputerze akurat nie posiadam.
pozdrawiam
W dniu 2012-02-06 21:47, Tomasz Chiliński pisze:
https://form.teleinfrastruktura.gov.pl/static/help/SIIS_Generator_2_0.zip
Przeglądałem właśnie to. Szkoda, że robią to w XLS. Przez to reguły warunkowo wypełniające pola są nieczytelne, a Microsoft Office na swoim komputerze akurat nie posiadam.
Ja nie moglem sie z nimi dogadac by cokolwiek udostepnili to wczoraj zaczalem juz recznie wyciagac dane. Dzis wkleili co trzeba wiec juz zaniechalem robotki. Ale wkleje moze bedzie czytelniejsze (tylko wezly i interfejsy wezlow):
Wezel: Wezel: - oznaczenie (id z lms) - wlasnosc (wlasny / obcy) - typ obiektu (maszt / budynek / kontener / wieza / studzienka / szafka kablowa / skrzynka / wlasny opis) Obszar wezla: - wojewodztwo (teryt) - powiat (teryt) - gmina (teryt) - terc gminy (teryt) - miejscowosc (teryt) - simc miejscowosci (teryt) Adres wezla: - cecha (teryt) - nazwa ulicy (teryt) - ulic ulicy (teryt) - nr budynku - kod pocztowy Dzialka wezla: - nr dzialki Wspolrzedne wezla: - szerokosc geograficzna - dlugosc geograficzna Warstwa wezla: - wezel szkieletowy (tak / nie) - wezel dystrybucyjny (tak / nie) - wezel dostepowy (tak / nie) Kolokacja - oznaczenie budynku umozliwiajacego kolokacje (id budynku z kolokacji)
W_Interface: Interfejs: - nazwa interfejsu - oznaczenie wezla (id z lms'a) Warstwa (siec szkieletowa lub dystrybucyjna / siec dostepowa) Medium: - medium transmisyjne (swiatlowodowe niezwielokrotnione / swiatlowodwe zwielokrotnione / kablowe / radiowe / optyczne łącza w wolnej przestrzeni / wlasny opis) - zwielokrotnienie (liczba calkowita) Technologia transmisyjna: (ATM / PDH / SDH / Ethernet / .... / WiFi / FTTH / wlasny opis) Siec dostepowa: - przepustowosc calkowita Siec szkieletowa lub dystrybucyjna: - przepustowosc w szkielecie - przepustowosc w dystrybucji - przepustowosc wolna Liczba interfejsow: - laczna liczba interfejsow - liczba dla publicznej sieci - liczba nie zaalokowanych Udostepnianie interfejsow: - udostepnianie (tak / nie) - liczba udostepnionych - liczba udostepnionych w sieci publicznej
pozdrawiam
W dniu 2012-02-06 19:59, Andrzej Banach pisze:
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.
Miales to jednak racje - pomieszalo mi sie juz to nazwenictwo Wezly - budynki, kontenetry, studnie itp Interfejst wezla - to niejako same urzadzenia
pozdrawiam
W dniu 06.02.2012 20:44, Andrzej Banach pisze:
W dniu 2012-02-06 19:59, Andrzej Banach pisze:
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.
Miales to jednak racje - pomieszalo mi sie juz to nazwenictwo Wezly - budynki, kontenetry, studnie itp Interfejst wezla - to niejako same urzadzenia
pozdrawiam
lamerskie pytanie: wgrałem najnowszą wersję lms-a i jak mam wygenerować raport siis ?
W dniu 2012-02-04 23:33, Andrzej Banach pisze:
A wiec, z uwagi ze sa juz jasne i ostateczne wytyczne co do zakresu raportu jaki wymagac bedzie od nas UKE juz za kilka tygodni, mozna by rozpoczac II etap przerobki lms'a.
Ponizej planowane zmiany i nowe funkcjonalnosci w LMS bardzo wstepnie ustalone z Tomkiem. Prosze o uwagi, zmiany koncepcji itp, gdyz ponizsze jest powoli realizowane.
I. Raport do UKE. 1) Raport jako osobne podmenu "Raporty" w dziale "Osprzet sieciowy". 2) Wygenerowany raport powinien zawierac wszystkie dane dotyczace inwentaryzacji sieci szerokopasmowej wymagane przez UKE. 3) Wygenerowany plik musi byc gotowy do zaimportowania (akceptowany przez form.teleinfrastruktura.gov.pl).
II. Uzupelnienie UI i bazy LMS'a o potrzebne dane, bez ktorych wygenerowanie raportu byloby trudne lub niemozliwe. 1) Nadrzedny poziom "Wezly" (studnie, maszty, budynki, szafy itp). a) mozliwosc wlaczania do wezlow elementow sieciowych (np istniejacych urzadzen sieciowych z menu "osprzet sieciowy") b) modyfikacja "osprzetu sieciowego": - mozliwosc definiowania dowolnego osprzetu sieciowego (nie tylko urzadzenia ale tez np mufy swiatlowodowe, itp); - przesunac wspolrzedne gps, adresy urzadzen sieciowych do "wezlow"; - "urzadzeniom sieciowym" (vel interfejsom wg UKE) ustawic mozliwosc przypisywania: Interfejs: - nazwa interfejsu (jest w lms) - oznaczenie wezla (id wezla z lms'a) Warstwa (siec szkieletowa lub dystrybucyjna / siec dostepowa) Medium: - medium transmisyjne (swiatlowodowe niezwielokrotnione / swiatlowodwe zwielokrotnione / kablowe / radiowe / optyczne łącza w wolnej przestrzeni / wlasny opis) - zwielokrotnienie (liczba calkowita) Technologia transmisyjna: (ATM / PDH / SDH / Ethernet / .... / WiFi / FTTH / wlasny opis) Siec dostepowa: - przepustowosc calkowita Siec szkieletowa lub dystrybucyjna: - przepustowosc w szkielecie - przepustowosc w dystrybucji - przepustowosc wolna Liczba interfejsow: - laczna liczba interfejsow (liczba portow jest w lms) - liczba dla publicznej sieci - liczba nie zaalokowanych Udostepnianie interfejsow: - udostepnianie (tak / nie) - liczba udostepnionych - liczba udostepnionych w sieci publicznej c) mozliwosc przypisania wezlowi: Wezel: - oznaczenie (id z lms) - wlasnosc (wlasny / obcy) - typ obiektu (maszt / budynek / kontener / wieza / studzienka / szafka kablowa / skrzynka / wlasny opis) Obszar wezla: - wojewodztwo (teryt) - powiat (teryt) - gmina (teryt) - terc gminy (teryt) - miejscowosc (teryt) - simc miejscowosci (teryt) Adres wezla: - cecha (teryt) - nazwa ulicy (teryt) - ulic ulicy (teryt) - nr budynku - kod pocztowy Dzialka wezla: - nr dzialki (opcja gdy dany wezel nie ma numeru - studnia, maszt...) Wspolrzedne wezla: - szerokosc geograficzna - dlugosc geograficzna Warstwa wezla: - wezel szkieletowy (tak / nie) - wezel dystrybucyjny (tak / nie) - wezel dostepowy (tak / nie) Kolokacja - oznaczenie budynku umozliwiajacego kolokacje (ptaszek gdy dany wezel umozliwia kolokacje) d) polaczenia sieciowe (narazie pozostawic jak sa), ale zmiany dokonywac "na przyszlosc" tak by pozniej mozna bylo: - przypisywac poszczegolnym polaczeniom "urzadzen sieciowych" atrybuty w postaci zastosowanego medium itp - przypisywac poszczegolnym polaczeniom "wezlow" rodzaj traktu, technologie, typ... - dodawac wielokrotne polaczenia logiczne miedzy urzadzeniami sieciowymi, oraz wezlami (vlany... / rury rhdpe...)
Ustalenia z dotychczasowej wymiany maili (sorki za chaotycznosc, ale brak mi ostatnio czasu na wszystko):
Dodamy dwie nowe właściwości dla portu: - medium fizyczne, - szybkość połączenia.
Ustalanie warstwy możemy wykonywać automatycznie - moim zdaniem szkoda, żeby użytkownik musiał się naklikać przy jakichkolwiek zmianach.
Medium transmisyjne chyba raczej dla portu powinno być określane.
Moim zdaniem do połączeń już warto dodać typ medium. Zaczynam dochodzić do wniosku, że być może powinny być 2 ogólne rodzaje połączeń - fizyczne i logiczne. Przy fizycznym liczyłby się typ medium, przy logicznym, np. szybkość połączenia, znacznik podłączenia logicznego (np. na potrzeby VLAN-ów).
- przypisywac poszczegolnym polaczeniom "wezlow" rodzaj traktu,
technologie, typ...
- dodawac wielokrotne polaczenia logiczne miedzy urzadzeniami
sieciowymi, oraz wezlami (vlany... / rury rhdpe...)
No właśnie i tu największy problem - w jaki sposób wiązać połączenia logiczne z połączeniami fizycznymi. Połączenie fizyczne może składać się z wielu odcinków na którym występuje jedno połączenie logiczne...
pozdrawiam
W dniu 15.02.2012 18:18, Andrzej Banach napisał(a):
W dniu 2012-02-04 23:33, Andrzej Banach pisze:
A wiec, z uwagi ze sa juz jasne i ostateczne wytyczne co do zakresu raportu jaki wymagac bedzie od nas UKE juz za kilka tygodni, mozna by rozpoczac II etap przerobki lms'a.
Ponizej planowane zmiany i nowe funkcjonalnosci w LMS bardzo wstepnie ustalone z Tomkiem. Prosze o uwagi, zmiany koncepcji itp, gdyz ponizsze jest powoli realizowane.
Jako, że nie ma żadnych uwag (pewnie pojawią się jak będzie bliżej 15-tego marca ;-)) to ja opiszę krótko jak widzę małą rewolucję w samych urządzeniach. Obecnie do urządzenia możemy przypisywać porty (obecnie na sztywno określa się tylko ich liczbę i przy połączeniu typ połączenia). Jak widzę pierwszy etap prac? 1) Urządzenia stają się składowiskiem/zbiorem/grupą portów. 2) Każdy port posiadać będzie następujące właściwości: - medium fizyczne (np. koncentryk, skrętka, światłowód SM, światłowód MM, to samo tylko z WDM, etc.) - protokół L2 (np. ethernet, DSL, ATM, Frame Relay, inne...) - etykieta systemowa (chodzi o możliwość wpisania dla portu informacji systemowej, które potem można byłoby użyć np. do wiązania maców z portami, etc.; numer portu nie wystarczy - warto mieć np. informację zapisaną o identyfikatorze powiedzmy dla cisco to mogłoby być Fa0/3, Gi1/2, etc.) - pole memo z dodatkowymi, dowolnymi informacjami o porcie np. jakiś komentarz własny.
Myślałem, żeby jeszcze wprowadzić dodatkową warstwę pośrednią pomiędzy urządzeniami a portami zwaną roboczo modułami - moduł byłby grupą portów i można byłoby od razu grupami portów dołączać porty do urządzenia, ale z drugiej strony może to być zbędne gmatwanie schematu bazy danych, a w sumie jak ktoś "zaprojektuje" wzorcowy model danego urządzenia z przypisanymi portami to potem funkcja klonowania urządzeń pozwoli rozmnożyć cudownie kolejne egzemplarze danego urządzenia.
Ostatecznie na tym etapie mielibyśmy urządzenia z przypisanymi zbiorami portów.
Moim zdaniem nie warto ani urządzeniom, ani przygotowywanym w następnym etapie węzłom przypisywać informacji o warstwie, bo to urzędnicza bzdura. Warstwę będzie można ustalić automatycznie na podstawie tego jakie urządzenia są wpięte do portów urządzenia, np. czy tylko komputery, czy tylko urządzenia czy jedno i drugie.
Już teraz dodam, że przepływność połączenia widzę jako przypisywaną do połączenia, a nie do portu (to logiczne).
Co o tym myślicie? Jak to się ma do codziennej pracy związanej z zarządzaniem Waszymi sieciami?
W dniu 2012-02-15 21:41, Tomasz Chiliński pisze:
Jako, że nie ma żadnych uwag (pewnie pojawią się jak będzie bliżej 15-tego marca ;-)) to ja opiszę krótko jak widzę małą rewolucję w samych urządzeniach.
No no, widze ozywiona dyskusja w tym temacie. Jak rozumiem wszyscy robia copy+paste danych z tamtego roku?
I nikt nie chce pomoc wypracowac merytorycznie jakichs sensownych zmian dla dobra lms'a? To co wklejone zostanie wykonane, ale przydalaby sie dyskusja - jak wiadomo co 20 glow to nie dwie.
pozdrawiam
W dniu 2012-02-15 21:41, Tomasz Chiliński pisze:
Co o tym myślicie? Jak to się ma do codziennej pracy związanej z zarządzaniem Waszymi sieciami?
Mala uwaga przekazana na maila (warto rozwazyc): " Ja w jednym LMSie mam pare firm, bo jedna bilinguje ruch telefoniczny inna klientów indywidualnych, inna biznes. Spójrz poproszę na kwestie Inwentaryzacji przez wielooddziałowego LMSa poproszę. " Ogolnie wieloodzialowosc jest w lms, wiec i w raporcie dobrze by bylo o niej tylko nie zapominac.
pozdrawiam
W dniu 20.02.2012 10:25, Andrzej Banach napisał(a):
W dniu 2012-02-15 21:41, Tomasz Chiliński pisze:
Co o tym myślicie? Jak to się ma do codziennej pracy związanej z zarządzaniem Waszymi sieciami?
Mala uwaga przekazana na maila (warto rozwazyc): " Ja w jednym LMSie mam pare firm, bo jedna bilinguje ruch telefoniczny inna klientów indywidualnych, inna biznes. Spójrz poproszę na kwestie Inwentaryzacji przez wielooddziałowego LMSa poproszę. " Ogolnie wieloodzialowosc jest w lms, wiec i w raporcie dobrze by bylo o niej tylko nie zapominac.
Osprzęt sieciowy i tak trzymany jest dla wszystkich firm razem wziętych, więc z tym nie będzie problemu. Widzę, że większość czeka na wspaniałe, cudowne pojawienie się idealnie generowanych raportów w LMS ;-)
pozdrawiam
Widzę, że większość czeka na wspaniałe, cudowne pojawienie się idealnie generowanych raportów w LMS ;-)
doczekać się nie mogę, ale jak pomyślę o pracy którą jeszcze muszę wykonać przy zmianie wersji, to tak myśle czy nie podesłać im raportu z poprzedniego roku ze zmienionymi kilkoma pozycjami
Wojtek Świadkowski
__________ Informacja programu ESET NOD32 Antivirus, wersja bazy sygnatur wirusow 6901 (20120221) __________
Wiadomosc zostala sprawdzona przez program ESET NOD32 Antivirus.
uczestnicy (4)
-
Andrzej Banach -
Me -
Tomasz Chiliński -
Wojciech Świadkowski