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