Hvordan fungerer DSLmon? I dette dokument finder du oplysninger om værktøjet DSLmon, som kan bruges til at overvåge DSL-linjer. Du finder en beskrivelse af værktøjet og kan læse om, hvordan du etablerer XML- DSLmon for en operatør. Du kan også læse om strukturen for XML/KAREN-kald og finde ud af, hvordan du starter og stopper DSLmon-streamingtjenesten. Genveje DSLmon hvad er det? XML/KAREN-kald sådan bruger du dem Målinger hvilke scenarier er der? Indhold Hvordan fungerer DSLmon?...1 1. Hvilke forkortelser findes der ved brug af DSLmon?...1 2. Hvad er DSLmon?...2 Hvilke scenarier er der for målinger?...5 Hvordan etablerer jeg XML-DSLmon for en operatør?...6 3. Sådan bruger du XML/KAREN-kald...7 Hvordan er kaldsstrukturen?...7 Hvordan starter jeg DSLmon-streamingtjenesten? (på engelsk)...7 Hvordan stopper jeg DSLmon-streamingtjenesten? (på engelsk)...8 1. Hvilke forkortelser findes der ved brug af DSLmon? Forkortelse DSLmon Beskrivelse Et værktøj, som giver mulighed for at overvåge DSL-linjer ved løbende aflæsning af udvalgte parametre fra TDC DSLAM for de linjer, hvor funktionen er aktiveret. De TDC Wholesale produkter, der er omfattet af DSLmon, og derved kan overvåges, er vore kobberbaserede DSL-produkter produceret på TDC DSLAM: Ethernet BSA, IPConnect, Ethernet VPN DSL, VULA og VULA Uncontended. Bemærk, at der i DSLmon ikke er funktioner, der er relevante i forhold til vores Rå Kobber og Delt Rå Kobber produkter TDC-GUI-DSLmon HTML-baseret værktøj, som TDC Wholesale Fejlservice benytter til at styre DSLmon.
XML-DSLmon XML-baseret værktøj, som stilles til rådighed for Wholesales operatører, og som giver adgang til rådatamålinger fra DSLmon. Rådatamålinger modtaget fra XML-DSLmon kan integreres i operatørens egne databaser/ systemer og benyttes sammen med operatørens egne HTML værktøjer. 2. Hvad er DSLmon? XML-DSLmon giver mulighed for, at en operatør selv kan implementere en overvågning af en given linje i egne systemer. De TDC Wholesale-produkter, der er omfattet af XML- DSLmon og derved kan overvåges, er vore kobberbaserede DSL-produkter produceret på TDC DSLAM: Ethernet BSA, IPConnect, Ethernet VPN DSL, VULA og VULA Uncontended. Bemærk, at der i vores anvendelse af XML-DSLmon ikke er funktioner, der er relevante i forhold til vores Rå Kobber- og Delt Rå Kobber-produkter. Figur 1: Skitse af XML-DSLmon-konfiguration Det overordnede formål med XML-DSLmon er, at operatøren løbende modtager aflæsninger af specifikke DSLAM-porte for operatørens egne slutkunder, så operatøren
selv kan opbevare og behandle data i sit eget system til overvågninger. XML-DSLmon giver ikke adgang til HTML GUI. Kun operatørens egne slutkunder kan overvåges, og denne validering sker i forbindelse med XML-kald, der går via KAREN. Der er lukkede skodder mellem alle operatører (ISP er), hvilket gør sig gældende for alle indgange i Wholesale. Figur 1 viser de TDC-systemer, som sikrer, at operatøren kan styre XML-DSLmon: - Operatøren kan starte og stoppe målingen. - DSLmon ved fra KAREN, hvilken måling der er knyttet til en given operatør/isp. - Måleresultater sendes ikke via KAREN, men direkte fra DSLmon Collector Manager til operatøren. - DSLmon Collector Manager er en spooler-funktion, hvor informationer med DSLAM-port data sendes over netværket som XML POST / HTTP beskeder til operatøren IP-adresse. Streamingdata Når data sendes til operatøren, vil operatørens konkrete IP-adresse blive slået op i en DSLmon ISP tabel. Data vil blive sendt via HTTP POST med en XML-struktur på TCP/IP til den specifikke IP-adresse. Operatøren skal oprette en Webserver (servlet) til at modtage data on-the-fly. De transmitterede data til operatøren vil findes i et XML-format dokument, herunder oplysninger om: - Tidsstempel - LID - DSLAM-port - Port-typen - Access-port - <specifikke parametre læst fra DSLAM-port> - <specifikke trafiktællere> Port-type parameteren fortæller, om dette er en access-port som benyttes i forbindelse med Pair-Bonding/G.SHDSL eller en linjeport. Data sendes kontinuerligt (indenfor en 15/5 minutters interval for hver operatør) til operatørens dedikerede IP-adresse. Hvis en slutkunde bliver flyttet Hvis en slutkunde bliver flyttet til en anden port, mens en overvågning er i gang, vil aflæsningerne fortsætte på den "nye" port. Oplysningerne videregives til operatøren som en HTTP-anmodning med oplysninger om LID og nye DSLAM-port. En læsning vil blive startet på denne nye port, og den "gamle" læsning vil blive stoppet. Hvis porten er en access-port som benyttes i forbindelse med Pair-Bonding/G.SHDSL, vil alle involverede porte blive startet/stoppet.
Antal samtidige aflæsninger for specifik operatør Antallet af porte, som en given operatør kan starte overvågning på, er individuelt og begrænset til en værdi, svarende til ca. 10 % af operatørens kundebase. Hvis denne grænse overskrides, vil en anmodning om start læsning returnere en fejl og blive afvist. Grænsen vil være et absolut nummer, som vil blive opsat i forbindelse med at TDC implementerer operatørens adgang til XML-DSLmon. Ændres operatørens samlede mængde af kunder, kan antallet af samtidige overvågninger ændres efter anmodning fra operatøren. Aflæste DSLAM-port parametre Liste af parametre, der aflæses på overvåget DSLAM-port: Parameter adslaturcurrsnrmgn adslatuccurrsnrmgn adslaturcurrattainablerate adslatuccurrattainablerate adslaturperfess adslatucperfess adslatucchancurrtxrate adslaturchancurrtxrate adslatuccurratn adslaturcurratn adslatucchanuncorrectblks adslaturchanuncorrectblks adslatucchancorrectedblks adslaturchancorrectedblks adslatucperfstatsesl adslaturperfstatsesl adslatucperfstatuasl adslaturperfstatuasl adslatucperfinits adslatuccurroutputpwr adslaturcurroutputpwr adslatucperflofs adslaturperflofs adslatucperfloss adslaturperfloss adslatucperflols adslaturperflprs Beskrivelse Noise Margin (remote) Noise Margin (CO) Max attainable bitrate (remote) Max attainable bitrate (CO) Counter Errored seconds (remote) Counter Errored seconds (CO) Current datarate (CO) Current datarate (remote) Current attenuation (CO) signal or line Current attenuation (remote) signal or line Counter Uncorrected Blocks (CO) Counter Uncorrected blocks (remote) Counter Corrected Blocks (CO) Counter Corrected Blocks (remote) Counter Severely errored seconds (CO) Counter Severely errored seconds (remote) Counter Unavailable seconds (CO) Counter Unavailable seconds (remote) Counter Retrains Transmit power (CO) Transmit power (remote) Counter Los of frame (CO) Counter Loss of frame (remote) Counter Loss of signal (CO) Counter Loss of signal (remote) Counter loss of link Counter Loss of power
For hver aktiv SIK/kanal relateret til DSLAM-porten aflæses følgende: Parameter downstreambytecount upstreambytecount Description Traffic counter Traffic counter Endvidere aflæses uplink-interface tællere, ventilatorhastighed, temperatur m.v. Regler for TDC-GUI-DSLmon- og XML-DSLmon-aktiveringer DSLmon kan via TDC-GUI-DSLmon aktiveres af bl.a. TDC Wholesale Fejlservice. Operatøren har også via XML-DSLmon mulighed for at styre overvågningen. Nedenfor er vist en beskrivelse af reglerne for brugen og dermed også input i forbindelse med implementering af en operatørs eget system. Regler for TDC-GUI-DSLmon målinger: - En igangværende TDC-GUI-DSLmon måling kan ikke stoppes af en XML-DSLmon initieret måling Regler for XML-DSLmon målinger: - En XML-DSLmon initieret måling kan ikke stoppes af en TDC-GUI-DSLmon måling - En XML-DSLmon måling kan ikke blive forlænget. - En XML-DSLmon måling udløber automatisk efter 21 dage. - En XML-DSLmon måling kan blive stoppet af operatøren selv via XML/KAREN. - En XML-DSLmon måling, vil gennem standard LS og PC parametre i TDC database, således at TDC Wholesale Fejlservice kan se relaterede grafer i TDC- GUI-DSLmon. Måleperioder - Måleperioden er 21 dage. - Måleperiodes længde er identisk uanset om den initieres via TDC-GUI-DSLmon eller data streames via XML-DSLmon. De ekstra parametre, der streames til operatøren, gemmes ikke i TDC database i forbindelse med TDC-GUI-DSLmon. Her gemmes udelukkende standardparametrene. Hvilke scenarier er der for målinger? I det følgende skitseres, hvorledes målinger influerer på hinanden, når TDC Wholesale Fejlservice starter dem via TDC-GUI-DSLmon, og når operatøren starter dem via XML- DSLmon. Scenario 1: Start TDC-GUI-Monitor Det følgende scenarie viser målingen såfremt TDC-GUI-DSLmon benyttes. Start GUI Monitor GUI MONITOR running Expire GUI Monitor ------- --------------------------------------------------- --------------------------------------- ------------------- 1 2 Time Scenario 2: Start XML-Monitor Det følgende scenarie viser målingen såfremt XML-DSLmon benyttes. Her er der samtidig mulighed for at stoppe en måling.
Start XML- Monitor XML MONITOR running Stop/Expire XML Monitor ------- --------------------------------------------------- --------------------------------------- ------------------- 1 2 Time Scenario 3: Start af TDC-GUI-Monitor umiddelbart efterfulgt af start XML-Monitor Det følgende scenarie viser hvorledes en måling kan startes fra henholdsvis TDC-GUI- DSLmon og XML-DSLmon. TDC-GUI-DSLmon starter først. Start GUI-Monitor GUI -Monitor running Expire GUI-Monitor ------- <--------------------------------------- --------------------------------> ---------- 1 21 dage GUI 2 Time Start XML -Monitor XML-Monitor running Stop/Expire XML-Monitor -------------------------- <------------------------------------------------------- --------------> ----- 10 dage 3 21 dage 4 Time Scenario 4: Start af en XML-Monitor umiddelbart efterfulgt TDC-GUI-Monitor Følgende scenarie viser, hvordan en måling kan startes og stoppes fra henholdsvis XML- DSLmon og TDC-GUI-DSLmon. XML-DSLmon starter først. Start XML-Monitor XML-Monitor running Stop/Expire XML-Monitor ------- -------------------------------------------------- --------------------> ------------------------------------ 1 21 dage 2 Time Start GUI-Monitor GUI -Monitorrunning Expire GUI Monitor ----------------------------- -------------------------------------------------- -----------------------------> ------------- 10 dage GUI 3 21 dage GUI 4 Time Hvordan etablerer jeg XML-DSLmon for en operatør? Operatøren bestiller adgang til DSLmon streaming på XML-API via KAREN adgang gennem sin account manager eller Wholesale kunde- service på wholesale@tdc.dk. Her skal bl.a. oplyses: - Brugeroplysninger, herunder e-mail adresse - IP- adresse (entydig IPv4 adresse) request sendes fra både når der skal testes og i produktion - IP-adresse (entydig IPv4 adresse) stream-data skal sendes til både når der skal testes og i produktion - Det absolutte antal streaming overvågninger der samtidig kan være igangsat. Dette aftales med Wholesale kundeservice/account manageren og sættes normalt til 10 % af operatørens base af DSL-forbindelser. Ændres basen kan det absolutte tal ændres efter operatørens anmodning. Herefter etableres operatøren på to felter: - Adgang til KAREN og DSLmon-tjenesterne - DSLmon streaming Operatøren skal først teste funktionaliteten i testmiljøet, KAREN DEMO, inden der åbnes op for produktionsmiljøet, KAREN PROD. Når operatøren er oprettet, kan der kaldes op via en browser til testmiljøet: https://karendemo.tdc.dk/wsdl Her fremgår det, hvilke services som certifikatet har adgang til; hvilke IP-adresser, der tillades kald fra og hvilke IP-adresser, der streames til.
Forskellen på test og produktion er, at KAREN router mod DSLmon-streaming i prodmiljø og i testmiljø routes via DSLmon Streaming testmiljø. Operatøren får først adgang i KAREN PROD (og dermed DSLmon Streaming prod), når der er gennemført et acceptabelt forløb i testmiljø. Bemærk: Operatøren skal bruge følgende format: Destination ISP URL: http://<ip Address of ISP>:80/dslmon/input [ex: http://85.233.225.94:80/dslmon/input]. Operatøren skal i sit eget miljø udvikle et værktøj, som kan modtage streaming fra DSLmon, og det er vigtigt, at URL en har ovenstående format ellers vil det ikke fungere. 3. Sådan bruger du XML/KAREN-kald Hvordan er kaldsstrukturen? Strukturen der benyttes til styring af XML-DSLmon er følgende: - Input: Line ID (LID) - Start/Stop reading - Output: Line ID, OK / Not OK. Not OK er fx hvis det maksimale antal monitorerede linjer for operatøren nås. Hvis stop-reading ikke aktiveres indenfor en periode på 3 uger, genererer systemet automatisk stop af læsningerne. KAREN services/xml Inden der kan gives adgang til XML-DSLmon skal operatøren åbnes for de relevante services i KAREN, se næste afsnit. Når etableringen er foretaget, gives adgang til XML-tjenesterne, startdslmon og stopdslmon. Hvordan starter jeg DSLmon-streamingtjenesten? (på engelsk) 1) The service can be called from KAREN Client or SOAPUI only after the certificate has been properly installed in that system. The steps for opening the WSDL https://karen.tdc.dk/wsdl?itsb can be referred from comments in point 4. 2) Use the above KeyStore and TrustStore files to establish SSL handshake betweeen the KAREN client and KAREN apache webgate. For SOAPUI client, please import the certificate. 3) Use the URL https://karen.tdc.dk/wsdl?itsb to download the KAREN WSDL which contains the service startdslmon. 4) Following is the request XML for startdslmon. <?xml version="1.0" encoding="utf-8"?> <soapenv:envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/xmlschema" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance"> <soapenv:body>
<StartDslmon xmlns=""> <start_reading_dslmon_request1 xsi:type="xsd:string"><iht:start_reading_dslmon_request_consolid ated xmlns:iht="ihtsoawholesale"> <iht:header userid=" userid " useremail=" useremail " trackingid="" versionid="" companyid=" TDC " forceresult="?" replytimestamp="?" statuscode="?" severitylevel="?" statusmessage="?" transactionduration="?" serverid="?"/> <iht:start_reading_dslmon_request lid="lid" dslam="dslam" port="port" stream="1" store="1"/> </iht:start_reading_dslmon_request_consolidated></start_readi ng_dslmon_request1> </StartDslmon> </soapenv:body> </soapenv:envelope> where userid = operator userid, useremail = operator email LID= operator LID Dslam = to be provided by Operator Port = to be provided by Operator Note: Never change the format of the above XML request. Only change the parameter value. a) Some Web Service clients take request XML as input parameter b) Some clients (those that are using Java) have request objects which are generated from the WSDL. For case a, the input parameters are set in the XML document. And in response it will get a XML document, which has a single attribute with value as start success fully OR failed to start. For case b, the required input parameters are set in the request object and the request objects is passed as start DSLMON() mthod parameter and in response it will get a response object, which have a single field with value as start success fully OR failed to start. Hvordan stopper jeg DSLmon-streamingtjenesten? (på engelsk) 1) The service can be called from KAREN Client or SOAPUI only after the certificate has been properly installed in that system. The steps for opening the WSDL https://karen.tdc.dk/wsdl?itsb can be referred from comments in point 4. 2) Use the above KeyStore and TrustStore files to establish SSL handshake betweeen the KAREN client and KAREN apache webgate, as described in the architecture part. For SOAPUI client, please import the certificate. 3) Use the URL https://karen.tdc.dk/wsdl?itsb to download the KAREN WSDL which contains the service StopDSLMON.
4) Following is the request XML for StopDSLMON. <?xml version="1.0" encoding="utf-8"?> <soapenv:envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/xmlschema" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance"> <soapenv:body> <StopDslmon xmlns=""> <stop_reading_dslmon_request1 xsi:type="xsd:string"><iht:stop_reading_dslmon_request_consolid ated xmlns:iht="ihtsoawholesale"> <iht:header userid="userid" useremail="useremail" trackingid="" versionid="" companyid=" TDC" forceresult="?" replytimestamp="?" statuscode="?" severitylevel="?" statusmessage="?" transactionduration="?" serverid="?"/> <iht:stop_reading_dslmon_request lid="lid" dslam="dslam" port="port" stream="1" store="1"/> </iht:stop_reading_dslmon_request_consolidated></stop_readin g_dslmon_request1> </StopDslmon> </soapenv:body> </soapenv:envelope> where userid=operator userid, useremail=operator email. LID= operator LID Dslam = to be provided by Operator Port = to be provided by Operator Note: Never change the format of the above XML request. Only change the parameter value. a) Some Web Service clients take request XML as input parameter b) Some clients (those that are using Java) have request objects which are generated from the WSDL. For case a, the input parameters are set in the XML document. And in response it will get a XML document, which has a single attribute with value as stop success fully OR failed to stop. For case b, the required input parameters are set in the request object and the request objects is passed as StopDSLMON() mthod parameter and in reponse it will get a reponse object, which have a single field with value as stop success fully OR failed to stop.