XML-DSLmon. Brugervejledning. Version maj Version 1.0

Transkript

1 28. maj 2015

2 Side 2 Indhold 1 Forkortelser Produktbeskrivelse Generelt Streaming data Flytning af en kunde Antal samtidig aflæsninger for specifik operatør Aflæste DSLAM-port parametre Regler for TDC-GUI-DSLmon og XML-DSLmon aktiveringer Scenarier Etablering af XML-DSLmon for en operatør XML/KAREN kald Kalds struktur KAREN services/xml Start DSLmon streaming service Stop DSLmon streaming service... 14

3 Side 3 1 Forkortelser 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. TDC-GUI-DSLmon XML-DSLmon 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 HTML-baseret værktøj, som TDC Wholesale Fejlservice benytter til at styre 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.

4 Side 4 2 Produktbeskrivelse 2.1 Generelt 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

5 Side 5 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 skotter mellem alle operatører (ISPer), hvilket gør sig gældende for alle indgange i Wholesale. Figur 1 viser de TDC involverede it-systemer som sikrer, at operatøren kan styre XML-DSLmon: Operatøren kan Starte måling og Stoppe måling. DSLmon véd 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. 2.2 Streaming data 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 XMLformat dokument, herunder oplysninger om: Tidsstempel LID DSLAM-port Port-typen Access-port <specifikke parametre læst fra DSLAM-port> <specifikke trafik tællere > Port-type parameteren fortæller, om dette er en access-port som benyttes i forbindelse med Pair-Bonding/G.SHDSL eller en linje-port. Data sendes kontinuerligt (indenfor en 15/5 minutters interval for hver operatør) til operatørens dedikerede IP-adresse.

6 Side Flytning af en kunde 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. 2.4 Antal samtidig 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.

7 Side Aflæste DSLAM-port parametre Liste af parametre, der aflæses på overvåget DSLAM-port: Parameter Description adslaturcurrsnrmgn Noise Margin (remote) adslatuccurrsnrmgn Noise Margin (CO) adslaturcurrattainablerate Max attainable bitrate (remote) adslatuccurrattainablerate Max attainable bitrate (CO) adslaturperfess Counter Errored seconds (remote) adslatucperfess Counter Errored seconds (CO) adslatucchancurrtxrate Current datarate (CO) adslaturchancurrtxrate Current datarate (remote) adslatuccurratn Current attenuation (CO) signal or line adslaturcurratn Current attenuation (remote) signal or line adslatucchanuncorrectblks Counter Uncorrected Blocks (CO) adslaturchanuncorrectblks Counter Uncorrected blocks (remote) adslatucchancorrectedblks Counter Corrected Blocks (CO) adslaturchancorrectedblks Counter Corrected Blocks (remote) adslatucperfstatsesl Counter Severely errored seconds (CO) adslaturperfstatsesl Counter Severely errored seconds (remote) adslatucperfstatuasl Counter Unavailable seconds (CO) adslaturperfstatuasl Counter Unavailable seconds (remote) adslatucperfinits Counter Retrains adslatuccurroutputpwr Transmit power (CO) adslaturcurroutputpwr Transmit power (remote) adslatucperflofs Counter Los of frame (CO) adslaturperflofs Counter Loss of frame (remote) adslatucperfloss Counter Loss of signal (CO) adslaturperfloss Counter Loss of signal (remote) adslatucperflols Counter loss of link adslaturperflprs 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, ventilator-hastighed, temperatur m.v.

8 Side 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.

9 Side Scenarier I det følgende skitseres, hvorledes målinger influerer på hinanden når henholdsvis TDC Wholesale Fejlservice starter dem via TDC-GUI-DSLmon samt 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 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 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 < > dage GUI 2 Time Start XML -Monitor XML-Monitor running Stop/Expire XML-Monitor < > dage 3 21 dage 4 Time Scenario 4 Start af en XML-Monitor umiddelbart efterfulgt TDC-GUI-Monitor Det følgende scenarie viser hvorledes 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 > dage 2 Time Start GUI-Monitor GUI -Monitorrunning Expire GUI Monitor > dage GUI 3 21 dage GUI 4 Time

10 Side 10 3 Etablering af 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 kundeservice på wholesale@tdc.dk. Her skal bl.a. oplyses: - Brugeroplysninger, herunder 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 DSLforbindelser. Æ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 DE- MO, 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: 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 prod-miljø og i test-miljø routes via DSLmon Streaming test-miljø. 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: Address of ISP>:80/dslmon/input [ex: 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.

11 Side 11 4 XML/KAREN kald 4.1 Kalds struktur 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. 4.2 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 afgang til XML tjenesterne, startdslmon og stopdslmon.

12 Side Start DSLmon streaming service i. 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 can be referred from comments in point 4. ii. 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. iii. Use the URL to download the KAREN WSDL which contains the service startdslmon. iv. Following is the request XML for startdslmon. <?xml version="1.0" encoding="utf-8"?> <soapenv:envelope xmlns:soapenv=" xmlns:xsd=" xmlns:xsi=" <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 " user =" user " 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>

13 Side 13 where userid = operator userid, user = operator 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.

14 Side Stop DSLmon streaming service i. 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 can be referred from comments in point 4. ii. 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. iii. Use the URL to download the KAREN WSDL which contains the service StopDSLMON. iv. Following is the request XML for StopDSLMON. <?xml version="1.0" encoding="utf-8"?> <soapenv:envelope xmlns:soapenv=" xmlns:xsd=" xmlns:xsi=" <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" user ="user " 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>

15 Side 15 where userid=operator userid, user =operator . 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.