Ontwerp van een downstream (Euro-)DOCSIS protocol analyser

Faculteit Ingenieurswetenschappen Vakgroep Informatietechnologie, Voorzitter: Prof. Dr. Ir. P. LAGASSE Onderzoeksgroep Wireless & Cable, Directeur: Prof. Dr. Ir. L. MARTENS

Ontwerp van een downstream (Euro-)DOCSIS protocol analyser door Maarten STEENHUYSE

Promotor: Prof. Dr. Ir. L. MARTENS Scriptiebegeleider: Ir. J. DE BRUYNE

Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen

Academiejaar 2005–2006

Voorwoord Hier wil ik alle mensen bedanken die het mogelijk gemaakt hebben om mij een jaar toe te leggen op deze thesis. In de eerste plaats wil ik mijn promoter Prof. Dr. Ir. L. Martens bedanken voor het interessante onderwerp en de begeleiding. Uiteraard kan ook hier mijn begeleider Ir. Jeffrey De Bruyne niet ontbreken die me altijd bijstond met raad en daad wanneer het nodig was. Verder heb ik ook veel te danken aan de deskundige hulp van Ir. W. De Ketelaere. Mijn ouders, zus en vrienden verdienen hier ook een vermelding. Bij hen kon ik stoom afblazen wanneer mijn drukke thesisjaar eventjes teveel werd.

Maarten Steenhuyse, mei 2006

Toelating tot bruikleen “De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie.”

Maarten Steenhuyse, mei 2006

Ontwerp van een downstream (Euro-)DOCSIS protocol analyser door Maarten STEENHUYSE Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen Academiejaar 2005–2006 Promotor: Prof. Dr. Ir. L. MARTENS Scriptiebegeleider: Ir. J. DE BRUYNE Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Informatietechnologie, Voorzitter: Prof. Dr. Ir. P. LAGASSE Onderzoeksgroep Wireless & Cable, Directeur: Prof. Dr. Ir. L. MARTENS

Samenvatting Deze thesis heeft als doel het ontwerpen van een downstream (Euro-)DOCSIS protocol analyser. Er werd software ontwikkeld met een flexibele grafische gebruikersinterface waarmee het mogelijk is om een filterconfiguratie in te voeren onder de vorm van een regelset en logische operatoren. Voor het ontwerp viel de keuze op een client–server architectuur en een combinatie van de talen C++ en Java. Enkele realistische testen tonen aan dat realtime analyse met een complexe filterconfiguratie zeker haalbaar is.

Trefwoorden (Euro-)DOCSIS, netwerk-monitoring, HFC-netwerken

Design of a downstream (Euro-)DOCSIS protocol analyser Maarten Steenhuyse Supervisor(s): Ir. J. De Bruyne, Prof. Dr. Ir. L. Martens Abstract— (Euro-)DOCSIS (Data Over Cable Service Interface Specification) is the standard used to enable high bandwidth internet access over HFC (Hybrid Fiber/Coax) networks in Europe [2]. We designed a flexible protocol analyser that is able to analyse and filter an (Euro-)DOCSIS downstream channel in realtime. This article will delve deeper into the design en will give some test results to proof it’s practical use. Keywords—HFC networks, (Euro-)DOCSIS, sniffer, protocol analyser

I. I NTRODUCTION

II. (E URO -)DOCSIS The (Euro-)DOCSIS standards define how to enable internet access over a HFC network [2]. For this master thesis only the (Euro-)DOCSIS downstream HFC interface is of particular importance. A downstream channel has a bandwidth of 8 MHz and the data is encapsulated in a continuous stream of MPEG2 transport stream packets, that is broadcasted by a CMTS (Cable Modem Termination System).

N

OWADAYS high bandwidth internet access is very popular. The two main access networks used to provide fast internet access are the twisted pair telephone network (ADSL) and HFC networks, both have the advantage to be widespread. For this work, we focus on the latter. HFC evolved from the traditional coaxial CATV networks. Most coax is replaced by fiber optic, which improves the reliability and capacity, while preserving coax in ‘the last mile’ saves a lot of digging costs. Figure 1 shows the typical tree-andbranch structure of HFC networks. The individual houses are connected by coax, further upwards the head station fiber optic is used. Optical nodes are responsible for the electrical/optical conversion.

Fig. 1. HFC network structure

When problems occur in modern networks, engineers typically search for the cause using some kind of sniffer. Advanced software sniffers, such as Ethereal, are able to apply realtime filtering in Ethernet networks. For (Euro-)DOCSIS there aren’t software tools available, there only exist some expensive hardware solutions with a lot of restrictions. The developed downstream protocol analyser is an answer to this need. M. Steenhuyse is with the Cable&Wireless Department of Intec for his master thesis, Ghent University (UGent), Gent, Belgium. E-mail: [email protected] .

Fig. 2. Example of mapping data to MPEG-stream

Figure 2 shows a typical MPEG2 transport stream fragment. All packets have a fixed size of 188 bytes, where the payload consists of (Euro-)DOCSIS MAC frames. When it is possible a new MAC frame starts in the current MPEG packet, a pointer field must be present as first byte of the payload. (Euro-)DOCSIS specifies several types of MAC frames: MAC specific and data frames. The latter can be supported by ATM or Ethernet frames, MAC specific messages manage, control, and synchronize the cable modems (CM) in the HFC network. For example, before a CM gets online it has to undergo a complex initialisation procedure, supported by these MAC specific messages. The designed application is able to analyse all these MAC frames in realtime and a flexible filter component allows to save specific messages for further analysis. III. T HE A PPLICATION In this section we will elaborate on the design of the downstream (Euro-)DOCSIS protocol analyser. Performance is an obvious quality goal since we strive for realtime analysis. Furthermore we pursue the following quality goals: • Usability: The application must be user friendly and flexible, generic filters must be easily constructed with the aid of a clear graphical interface. • Extendability: The code base should be easy to extend, for example to support more filtering options in the future. • Platform Independence: The design should be easy portable to different operating systems.

C. Client The client exists mainly of the interface to the user and is written entirely in Java. It has a clear, flexible GUI to change the filter configuration of the server and start/stop the filter proces. IV. P ERFORMANCE TESTS

Fig. 3. Architecture protocol analyser

Figure 3 shows the high level Client-Server architecture of the protocol analyser. The following paragraphes focus on the main three components: server, client and communication. A. Client-Server communication When we split up the protocol analyser in a client and server, some form of communication must be used to glue them together. In an object oriented world, technologies such as CORBA, that enable remote object access, are very appealing. We chose the similar Java RMI technology because of our experience with it. The defined interface allows to operate the filter core, operations include starting and stopping the filter process, adding and deleting filter rules.

We executed three performance tests that examine the limits of the analyser. The test environment had more or less 100 modems lined up, a traffic generator made sure a full 256-QAM modulated downstream channel was filled up with data, this means a raw bandwidth of 55,6 Mbps. We give a short description of the three tests: • Test 1: The traffic consists of 64 bytes Ethernet packets and we filter on non existing MAC addresses. Because of the small sized packets, the frames must be parsed very fast. We gradually add new MAC adress filter rules that will never cause a match. The change of CPU usage is monitored. • Test 2: Now we add filtering rules with existing MAC addresses. This allows us to measure the influence of IO traffic of the hard disk where frames are stored. • Test 3: Here traffic consists of 300 bytes Ethernet packets and as in test 1 the filter looks for non existing MAC addresses. This test allows us to observe the influence of packet sizes. Intu¨ıtively it is clear that bigger sized packets demand less processing power then smaller ones.

B. Server Figure 3 shows two hardware components. A demodulator converts a downstream (Euro-)DOCSIS channel to an MPEG2transportstream, the output is fed to a PCI MPEG capture card. Next to the hardware we can distinguish four software components: 1. Realtime filtering: This constitutes the core of the software. It is written in C++ and is highly optimized. The first task is to parse the incoming MPEG packets, fragmentized MAC frames must be reconstructed from the MPEG payloads. In a second step the frame headers are analysed, when a filter rule match is found, the frame is passed to the Storage component. 2. Storage: The goal of this component is to save the frames in a format that is readable by Ethereal, the so called libpcap file format [4]. 3. Ethereal: This well known open source application can interpret saved filter files. The powerful interface allows to further analyse the data and even supports further filtering [3]. 4. Communication: Around the C++ core we find a Java module that constitutes a remote accessible server object. The remote Java object sole duty is to pass the requests to the C++ core and off cousce return the result after completion.

Fig. 4. Test results

Figure 4 plots the results. We observe an approximate linear relationship between the number of filter rules and cpu usage. In the first two performance tests, we increased the number of filter rules until realtime filtering wasn’t possible anymore, in the third test we quitted at 160 rules. In the second test the analyser turns out to be slightly more performant then in the first one in terms of CPU usage. This can easily be explained by the fact that from the moment a match is found, the investigation of other rules can be skipped for the current frame, where as in the first case an iteration over all rules is necessary every time, a match is never found. Another result of test two is the observation that disk IO traffic causes the CPU to be used less efficiently, approximately 20 % processing power is wasted. The graph also shows that parsing already takes 20 % of the processing power in the first two tests. Test three finally, learns us that packet size largely impacts the performance in a positive way. Here we see that parsing takes 10 % of the processing power.

V. C ONCLUSIONS With this extended abstract we tried to give an impression on the design of the developed downstream protocol analyser. Some performance tests proof the application is actually practically usable, reasonable complex filter operations are within range. R EFERENCES [1]

Data-Over-Cable Service Interface Specifications (DOCSIS) 2.0, Radio Frequency Interface Specification, http://www.cablemodem.com/downloads/specs/CM-SPRFI2.0-I10051209.pdf. [2] DOCSIS, http://www.cablemodem.com/. [3] Ethereal, network protocol analyser, http://www.ethereal.com/. [4] TCPDump, Open source capturing API, http://www.tcpdump.org/.

INHOUDSOPGAVE

i

Inhoudsopgave 1 Inleiding 1.1

6

Situering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

1.1.1

Digital Subscriber Line (DSL) netwerken . . . . . . . . . . . . . . .

6

1.1.2

Hybrid Fiber/Coax (HFC) netwerken . . . . . . . . . . . . . . . . .

8

1.2

Probleemstelling

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3

Doelstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.4

Overzicht thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 (Euro-)DOCSIS

9

14

2.1

(Euro-)DOCSIS architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2

(Euro-)DOCSIS protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.2.1

Downstream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.2

Upstream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3

‘Downstream Transmission Convergence’ downstream sublaag . . . . . . . 18

2.4

‘Cable Media Access Control’ sublaag . . . . . . . . . . . . . . . . . . . . . 20

2.5

2.4.1

MAC header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.4.2

MAC specifieke berichten

2.4.3

MAC Management header . . . . . . . . . . . . . . . . . . . . . . . 21

2.4.4

MAC Management payload . . . . . . . . . . . . . . . . . . . . . . 22

2.4.5

Allocatie minislots voor upstream verkeer . . . . . . . . . . . . . . . 22

2.4.6

(Euro-)DOCSIS CM initialisatieprocedure . . . . . . . . . . . . . . 24

. . . . . . . . . . . . . . . . . . . . . . . 21

HFC-testnetwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

INHOUDSOPGAVE

3 Ontwerp applicatie

ii

29

3.1

Java Remote Method Invocation (RMI) . . . . . . . . . . . . . . . . . . . . 30

3.2

Java Native Interface (JNI) . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.3

Server-client interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.4

Ontwerp server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.4.1

3.5

Filter bibliotheek . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Ontwerp client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4 Grafische gebruikersinterface

41

4.1

Gebruiksvriendelijkheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2

GUI-onderdelen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.2.1

Connectie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2.2

Hoofdvenster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.2.3

Filteren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.2.4

Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.2.5

Analyse in Ethereal . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5 Onderzoek 5.1

49

Prestatietesten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.1.1

Test 1: 64 bytes Ethernet pakketten, onbestaande MAC-adressen . 50

5.1.2

Test 2: 64 bytes Ethernet pakketten, bestaande MAC-adressen . . . 51

5.1.3

Test 3: 300 bytes Ethernet pakketten, onbestaande MAC-adressen . 52

5.1.4

Algemeen besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6 Conclusies

54

6.1

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.2

Uitbreidingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

A Open System Interconnection (OSI)

57

A.1 Applicatielaag (Laag 7) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 A.2 Presentatielaag (Laag 6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 A.3 Sessielaag (Laag 5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

INHOUDSOPGAVE

iii

A.4 Transportlaag (Laag 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 A.5 Netwerklaag (Laag 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 A.6 Datalinklaag (Laag 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 A.7 Fysische laag (Laag 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 B MAC Management berichttypes

60

C Tutorial: Installatie protocol analyser

62

C.1 Structuur software DVD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 C.2 Installatie server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 C.2.1 Vereisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 C.2.2 Installatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 C.3 Installatie client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 D Tutorial: Toevoegen van een filterniveau en operatie

65

D.1 FilterSettings.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 D.2 Structuur software DVD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 D.3 Toevoegen filterniveau en -operatie . . . . . . . . . . . . . . . . . . . . . . 67 Bibliografie

69

LIJST VAN FIGUREN

1

Lijst van figuren

1.1

ADSL-technieken om beschikbare bandbreedte te verdelen. . . . . . . . . .

8

1.2

Structuur van een HFC-netwerk. . . . . . . . . . . . . . . . . . . . . . . . .

9

1.3

De algemene architectuur. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1

(Euro-)DOCSIS architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2

(Euro-)DOCSIS protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3

MPEG-pakket formaat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4

MAC frame die meerdere MPEG-pakketten overspant . . . . . . . . . . . . 20

2.5

MAC header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.6

MAC Management header velden . . . . . . . . . . . . . . . . . . . . . . . 22

2.7

Allocatie van timeslots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.8

CM initialisatieprocedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.9

HFC-testnetwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1

Architectuur applicatie - Technologieën . . . . . . . . . . . . . . . . . . . . 29

3.2

Java Remote Method Invocation (RMI) . . . . . . . . . . . . . . . . . . . . 31

3.3

Frame constructie: De twee mogelijkheden . . . . . . . . . . . . . . . . . . 34

3.4

UML-klassendiagram frame constructie . . . . . . . . . . . . . . . . . . . . 35

3.5

UML-structuurdiagram: Implementatie frame filtering . . . . . . . . . . . . 38

3.6

Model-View-Controller paradigma . . . . . . . . . . . . . . . . . . . . . . . 39

LIJST VAN FIGUREN

2

4.1

Connectie dialoogvenster . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2

Hoofdvenster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.3

Filter dialoogvenster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.4

Statusvenster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.5

Analyse in Ethereal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.1

Resultaten prestatietesten . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

C.1 Inhoud software DVD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 D.1 Inhoud software DVD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

LIJST VAN FIGUREN

Lijst met afkortingen

(Euro-)DOCSIS

Europese variant van DOCSIS

ADSL

Asymmetric Digital Subscriber Line

ANSI

American National Standards Institute

API

Application Programming Interface

ASI

Asynchronous Serial Interface

ATM

Asynchronous Transfer Mode

BPI

Baseline Privacy Interface

CATV

Community Antenna TeleVision

CM

Cable Modem

CMTS

Cable Modem Termination System

CORBA

Common Object Request Broker Architecture

CPE

Customer Premises Equipment

DA

Destination Address

DDR

Double Data Rate

DHCP

Dynamic Host Configuration Protocol

DLL

Dynamic Link Library

DOCSIS

Data Over Cable Service Interface Specificationx

DSL

Digital Subscriber Line

FDM

Frequency Division Multiplexing

FEC

Forward Error Correction

FTP

File Transfer Protocol

GUI

Graphical User Interface

3

LIJST VAN FIGUREN

HFC

Hybrid Fiber/Coax

HT

Hyper Threading

HTTP

HyperText Transfer Protocol

IE

Information Element

IP

Internet Protocol

ISP

Internet Service Provider

ITU-T

International Telecommunication Union - Telecom

IUC

Interval Usage Code

JNI

Java Native Interface

LLC

Logical Link Layer

MAC

Medium Access Control

MAP

Medium Access Packet

MPEG

Moving Pictures Experts Group

MPEG-

MPEG2-transportstroom

4

datastroom MPEG-pakket

MPEG2-transportstroompakket

MVC

Model-View-Controller design pattern

NTSC

National Television System Committee, TV-standaard vooral in VS en Japan gebruikt

OSI

Open System Interconnection

PAL

Phase Alternating Line, Europese TV-standaard

PCI

Peripheral Component Interconnect

PID

Packet Identifier

PMD

Physical Media Dependent

POTS

Plain Old Telefone System

QAM

Quadrature Amplitude Modulation

QoS

Quality of Service

RAID

Redundant Array of Inexpensive Disks

RF

Radio Frequency

RMI

Remote Method Invocation

LIJST VAN FIGUREN

SA

Source Address

SATA

Serial ATA, protocol voor onder andere harde schijven

SCSI

Small Computer System Interface

SID

Session Identifier

TCP

Transmission Control Protocol

TDM

Time Division Multplexing

TFTP

Trivial File Transfer Protocol

UCD

Upstream Channel Descriptor

UML

Unified Modeling Language

USB

Universial Serial Bus

VM

Virtual Machine

WAN

Wide Area Network

xDSL

Verzamelnaam voor DSL-technieken

XML

eXtensible Markup Language

5

INLEIDING

6

Hoofdstuk 1 Inleiding 1.1

Situering

Het internet is niet meer weg te denken uit onze moderne samenleving. Mede ten gevolge van de digitalisering van traditioneel analoge telecommunicatie wordt de bandbreedte honger steeds groter. Denken we maar bijvoorbeeld aan de recente lancering van digitale televisie in België. Het spreekt voor zich dat bewegend beeld en geluid heel wat meer eisen stelt aan netwerkapparatuur dan het geval was in de begindagen van het internet. Internet was immers oorspronkelijk ontwikkeld met het oog op relatief eenvoudige tekstgeoriënteerde diensten zoals bijvoorbeeld HTTP-verkeer (surfen) en email. We onderscheiden vandaag twee belangrijke technologieën waarmee consumenten en bedrijven breedbandtoegang verkrijgen tot het internet: Digital Subscriber Line (DSL) en Hybrid Fiber/Coax (HFC), in de volksmond beter bekend als kabel. Die twee hebben hun populariteit te danken aan het feit dat ze gebruik maken van bestaande netwerken (vooral dan de ‘last mile’, het stuk dichtst bij de eindgebruiker), zodat de kost voor de uitrol van het breedbandnetwerk enigszins binnen de perken blijft.

1.1.1

Digital Subscriber Line (DSL) netwerken

Deze technologie gebruikt de bestaande twisted-pair telefoonbekabeling voor datatransport tussen eindgebruiker en een zogenaamde Internet Service Provider (ISP). Een

1.1 Situering

7

ISP is een bedrijf dat internettoegang aanbiedt tegen betaling. Belgacom en Telenet zijn twee bekende voorbeelden van ISPs in België. xDSL slaat op een aantal gelijkaardige, maar competitieve vormen van DSL, waarvan de meest gekende ongetwijfeld ADSL is. xDSL biedt een ‘point-to-point’ toegang tot het internet met een gegarandeerde bandbreedte. In de volgende paragraaf wordt ADSL verder toegelicht.

Asymmetric Digital Subscriber Line (ADSL) Zoals de naam het zegt, is de bandbreedte hier asymmetrisch verdeeld. Het downstream verkeer — verkeer van de ISP naar de eindgebruiker — krijgt een groter stuk van de koek dan het verkeer in de omgekeerde richting. Dit maakt het dus heel geschikt voor internettoepassingen zoals surfen en video-on-demand. Bij dergelijke toepassingen wordt er typisch veel meer gedownload dan dat er verstuurd wordt naar het internet. ADSL steunt op geavanceerde digitale signaalverwerking en algoritmen om zoveel mogelijk informatie door de twisted-pair koperdraadjes te knijpen. Aan het uiteinde van de twisted-pair telefoonkabel bevindt zich een ADSL-modem. Deze verdeelt de beschikbare bandbreedte in kanalen. Dit kan met behulp van twee technieken gebeuren: frequencydivision multiplexing (FDM) en echo cancellation. FDM wijst een band toe aan het downstream verkeer en een andere aan het upstream verkeer. Deze banden worden dan nog eens verder verdeeld in kanalen door middel van time-division multiplexing (TDM). Echo cancellation is een techniek die ook al werd gebruikt bij de oude V.32 en V.34 modems (33 kbps en 56 kbps modems) en laat de upstream band overlappen met het downstream gedeelte. Figuur 1.1 geeft dit grafisch weer. In beide gevallen blijft de eerste 4 kHz gereserveerd voor het traditionele telefoonverkeer, ook wel Plain Old Telephone System of POTS-verkeer genoemd. De modem multiplext een aantal van deze kanalen samen tot blokken. Samen met een foutcorrigerende code verkrijgen we zo een datastroom. ADSL kan theoretisch downloadsnelheden aanbieden tot 8 Mbps. Dit neemt echter snel af met de afstand tot een centrale. Andere factoren die hier een belangrijke rol spelen zijn: kabels in een ander metaal dan koper en de lijnimpedantie. Dit laatste kan zelfs dynamisch

1.1 Situering

8

Figuur 1.1: ADSL-technieken om beschikbare bandbreedte te verdelen.

variëren naargelang van bijvoorbeeld de weercondities. Vooral bij oudere bekabeling van slechte kwaliteit treden dergelijke problemen op. Recenter verscheen een nieuwe variant ten tonele, ADSL2, die hogere snelheden toelaat. Dit wordt onder andere mogelijk gemaakt door meer flexibele configuratiemogelijkheden voor foutcorrigerende codes en frame fragmentering. Hierdoor kan de overhead dus beperkt blijven als de kwaliteit van de lijn dit toelaat. Indien de afstand tussen gebruiker en centrale maximaal 1,5 km bedraagt, kan de snelheid zelfs (theoretisch) opgetrokken worden tot 24 Mbps door de downstream band te verdubbelen tot 2,2 MHz.

1.1.2

Hybrid Fiber/Coax (HFC) netwerken

De tweede populaire technologie maakt gebruik van het ander kabelnetwerk waar huisgezinnen en bedrijven traditioneel zijn op aangesloten: het coaxiaal kabelnetwerk. Dit netwerk is geëvolueerd uit het CATV1 netwerk wat oorspronkelijk bedoeld was voor de broadcasting van videobeelden van een kopstation naar een groot aantal eindgebruikers. De meest gebruikte netwerktopologie is een boomstructuur, om hierover internetverkeer mogelijk te maken, werden een aantal aanpassingen doorgevoerd: het kopstation is via een glasvezelnetwerk verbonden met de verschillende nodes. Enkel de ‘last mile’ blijft coaxiaal. Optische nodes zorgen voor de conversie van elektrische naar lichtsignalen en omgekeerd. Glasvezel verhoogt de betrouwbaarheid en capaciteit van het netwerk, terwijl het gedeeltelijke behoud van de coaxkabel een aanzienlijke besparing op graafkosten 1

Community Antenna TeleVision of kortweg kabel

1.2 Probleemstelling

9

betekent. Op figuur 1.2 werd de structuur van een HFC -netwerk geschetst. Het coaxi-

Figuur 1.2: Structuur van een HFC-netwerk.

aal gedeelte verbindt 100-2000 huizen met elkaar. Een typisch aantal is 500. Er is dus een Medium Access Control (MAC) protocol nodig om het verkeer over het gedeeld medium in goede banen te leiden. Hiervoor werden de (Euro-)DOCSIS (Data Over Cable Service Interface Specification) standaarden ontwikkeld [1]. Deze technologie wordt uitgebreid behandeld in het volgende hoofdstuk.

1.2

Probleemstelling

Netwerken worden steeds groter, complexer en sneller. Bij het optreden van problemen kan men teruggrijpen naar monitoring tools die de datapakketjes opvangen en opslaan voor latere analyse. Dit vereist vanzelfsprekend al snel enorme hoeveelheden schijfruimte, ook de analyse van dergelijke grote datasets is verre van vanzelfsprekend. Om de aandacht hierop te vestigen een kleine berekening. Downstream data wordt in

1.3 Doelstelling

10

het 256-QAM modulatieformaat verstuurd aan een snelheid van 55,6 Mbps of 6,63 MBps (inclusief overhead). Eén uur monitoring vereist dus meer dan 23 GB opslagruimte! Tools zoals het bekende Ethereal2 ondersteunen echter ook realtime filtering [3], zodat het mogelijk is om enkele relevante pakketjes te bewaren voor latere analyse. Men kan bijvoorbeeld enkel ge¨ınteresseerd zijn in de gegevens bestemd voor een bepaalde netwerknode (bijvoorbeeld computer) met een Ethernet interface. Het unieke Ethernet MAC-adres kan aangewend worden om enkel relevante datapaketten te herkennen. Het probleem is nu dat dergelijke tools niet overweg kunnen met de signalen op een coaxiale kabel, ook commerciële toestellen schieten hierin te kort: Ze zijn zeer duur of niet geschikt voor monitoring over een lange tijd.

1.3

Doelstelling

Deze thesis heeft als doelstelling de ontwikkeling van een softwarematige oplossing voor de realtime analyse van (Euro-)DOCSIS signalen. We beperken ons echter tot downstream verkeer, dat wordt immers als een continue stroom data verstuurd waarmee gemakkelijk kan gesynchroniseerd worden. Het upstream verkeer daarentegen, vindt plaats onder de vorm van korte ‘bursts’, wat de demodulatie van de data sterk bemoeilijkt. Dit kon niet behandeld worden binnen het tijdsbestek van deze thesis. Er werden een aantal kwaliteitseisen voorop gesteld: • De prestaties zijn heel belangrijk, aangezien we het doel nastreven om complexe realtime analyses toe te passen op snel binnenstromende data. • Bruikbaarheid: we willen een intu¨ıtieve en krachtige grafische gebruikersinterface om de applicatie te bedienen. Complexe filterregels moeten op een gebruiksvriendelijke manier kunnen samengesteld worden en daarna toegepast worden. Een andere vereiste onder deze categorie is dat we een client–server architectuur voorop stellen. Het is namelijk handig om netwerkapparatuur vanop afstand te monitoren. 2

Open source netwerk protocol analyser.

1.3 Doelstelling

11

• Uitbreidbaarheid streven we eveneens na. Het moet mogelijk zijn om zonder veel aanpassingen gebruik te maken van een andere hardware-interface die ons data aanlevert. Verder moet het mogelijk zijn om eenvoudig nieuwe filterparameters toe te voegen, zonder al te veel aanpassingen van de broncode. • Portabililiteit: we wensen een oplossing te ontwerpen die werkt onder verschillende besturingssystemen. In datacentra zijn de Unix varianten, naast Windows, immers courant voorkomende besturingssystemen. Het zou dus handig zijn als er zowel een Windows als Linux variant van de protocol analyser beschikbaar is. In het licht van deze eisen werd gekozen voor een combinatie van Java en C++. Zo kunnen we de voordelen van beide talen combineren: C++ maakt het mogelijk om zeer efficiënte code te schrijven. Java schiet hierin te kort aangezien het een ge¨ınterpreteerde taal is. Anderzijds is het grote voordeel van Java de platformonafhankelijkheid. Omdat we ook C++ gebruiken, vervalt dit voordeel natuurlijk wel gedeeltelijk, echter werd enkel de kern (het filteren) in standaard C++ ontwikkeld. Alles daarrond, zoals de gebruikersinterface, is opgebouwd uit Java code. Ook maken we gebruik van ‘third–party’ componenten die volledig portabel zijn. Om een voorbeeld te geven, voor de XML-ondersteuning maken we geen gebruik van de in Windows ingebouwde XML-API3 maar van Apache’s Xerces-C bibliotheek [8]. Een tweede belangrijke reden om Java zoveel als mogelijk te gebruiken, is de ontwikkelefficiëntie. Zo is het bijvoorbeeld mogelijk om met relatief weinig code krachtige gebruikersinterfaces te ontwerpen. Ook is de taal minder foutgevoelig, onder andere omdat de programmeur zich geen zorgen moet maken over geheugenbeheer. In een dergelijke ambitieuze lijst van kwaliteitseisen is het onvermijdelijk dat er een aantal tegenstrijdigheden optreden. Zo zal een gestructureerd ontwerp enigszins de prestaties nadelig be¨ınvloeden. Het is dan een kwestie van prioriteiten te stellen en/of een compromis te zoeken zodat het prestatieverlies door een objectgeoriënteerde aanpak tot een minimum kan beperkt worden. 3

Application Programming Interface; gestandaardiseerde interface waarmee de programmeur toegang

krijgt tot bepaalde functionaliteit.

1.3 Doelstelling

12

Figuur 1.3 toont een grafische voorstelling van de algemene structuur van het ontwerp. We zien dat naast software er ook hardware aan te pas komt. Een downstream kanaal moet gedemoduleerd worden en vervolgens komt het signaal terecht op een ASI-interface.

Figuur 1.3: De algemene architectuur.

ASI staat voor Asynchronous Serial Interface. Een dergelijke interface stuurt een bitstroom, ondergebracht in opeenvolgende MPEG2-transportstroompakketten, over een coaxiale kabel. Een PCI-kaart verwerkt deze ASI-stroom en maakt de bitstroom toegankelijk via een C++ API. Daarna is het de beurt aan een softwarecomponent die de bitstroom analyseert. Enkel de datapakketten die voldoen aan minstens één filterregel worden opgeslagen in het zogenaamde libpcap4 bestandsformaat [7]. Dit bestandsformaat kan geopend worden in Ethereal voor verdere analyse. De client bestaat uit een grafische gebruikersinterface waarmee de gebruiker onder andere kan connecteren naar een server, nieuwe filterregels kan toevoegen en het analyseproces 4

Open source capturing API.

1.4 Overzicht thesis

13

kan starten/stoppen.

1.4

Overzicht thesis

Zoals al verschillende keren aangehaald, gaan we in het volgende hoofdstuk dieper in op de (Euro-)DOCSIS-technologie. Speciale aandacht gaat uit naar de gebruikte protocollen aangezien één van de belangrijkste taken van de servercomponent het distilleren is van de nuttige data uit de aangeleverde bitstroom, die geordend is in pakketten. In het derde hoofdstuk wordt de architectuur van de ontwikkelde software uitgebreid en in detail toegelicht. Het vierde hoofdstuk toont de mogelijkheden van het programma, hiervoor rijkelijk voorzien van screenshots. Vervolgens komt het onderdeel onderzoek van mijn thesis aan bod. Er werd vooral onderzocht tot in hoeverre de applicatie het aankan om met een groot aantal filterregels een drukbezet downstream kanaal te analyseren. We sluiten af met de conclusies van deze thesis. Er wordt een antwoord gegeven op de doelstelling van dit werk en enkele uitbreidingen worden gesuggereerd.

(EURO-)DOCSIS

14

Hoofdstuk 2 (Euro-)DOCSIS DOCSIS is een internationale standaard ontwikkeld door CableLabs [2]. Er zijn ondertussen drie versies verschenen. Versie 1.0 dateert van maart 1997, versie 1.1 volgde in april 1999. Versie 2.0 werd tenslotte vrijgegeven in januari 2002. ITU-T1 heeft deze laatste twee standaarden overgenomen [4]. DOCSIS staat voor Data Over Cable Service Interface Specification en definieert, zoals de naam al doet vermoeden, de interfaces voor kabelmodems en ondersteunende apparatuur. Met DOCSIS wordt het mogelijk om breedband internettoegang te verlenen over een HFC -netwerk. Omdat de frequentietoewijzingen verschillen tussen Europese en Amerikaanse CATV2 systemen, werd een Europese variant ontwikkeld van de Amerikaanse standaard, (Euro)DOCSIS, die volledig conform is met de Europese PAL-standaard. De bandbreedte van een kanaal is 8 MHz, tegenover 6 MHz voor de Amerikaanse NTSC-standaard. Dit brengt met zich mee dat er hogere bandbreedtes kunnen ondersteund worden in het downstream3 pad. (Euro-)DOCSIS 1.0 biedt enkel ondersteuning voor best-effort data services. Versie 1

International Telecommunications Union Telecommunications Standardization Sector. Community Antenna TeleVision of kortweg kabel 3 Net zoals in het vorige hoofdstuk en verder in dit werk bekeken vanuit het oogpunt van de eindge2

bruiker: ‘downstream’ wordt gebruikt om data te ontvangen, ‘upstream’ om data te versturen naar het internet

2.1 (Euro-)DOCSIS architectuur

15

1.1 voegt de ondersteuning voor QoS of Quality of Service toe. Daarmee wordt het mogelijk om bepaalde garanties te bieden wat betreft kwaliteit (vb. gegarandeerde bandbreedte). Dit is bijvoorbeeld belangrijk voor Voice over IP. Ook werden geavanceerde beveiligingsmogelijkheden (authentificatie) toegevoegd. In (Euro-)DOCSIS 2.0 worden symmetrische download- en uploadsnelheden ondersteund. (Euro-)DOCSIS is zo opgebouwd dat nieuwere versies achterwaarts compatibel zijn met oudere.

2.1

(Euro-)DOCSIS architectuur

Op figuur 2.1 wordt de (Euro-)DOCSIS architectuur weergegeven. De verschillende componenten worden hieronder verder verklaard:

Figuur 2.1: (Euro-)DOCSIS architectuur

• CM: Cable Modem, de kabelmodem die bij de eindgebruiker thuis staat en de RF downstream signalen demoduleert en voor het upstream pad data moduleert. Bij het ontvangen en versturen van data wordt een protocol-stack doorlopen. Dit komt verder aan bod in paragraaf 2.2. • CMTS: Cable Modem Termination System, apparatuur die bij de ISP in het datacentrum opgesteld staat. Met deze ‘server’ communiceren verschillende CM ’s over het HFC-netwerk. Anderzijds is de CMTS ook verbonden met een Wide Area Network (WAN), het internet. De interface tussenin werd vastgelegd op Ethernet. Ook hier is het moduleren en demoduleren van RF-signalen een belangrijke taak. Binnen een HFC-netwerk verhouden de CMTS en de CM zich als ‘master en slave’.

2.2 (Euro-)DOCSIS protocol stack

16

Indien een modem iets wenst te versturen over het upstream pad, dan moet de CM eerst de benodigde bronnen aanvragen bij de CMTS. De ‘payload’ die over HFC-netwerken verstuurd wordt, kan volgens de specificaties bestaan uit Ethernet- of ATM -pakketten. • CPE: Customer Premises Equipment, typisch de computer die breedbandtoegang tot het internet krijgt via de CM. De specificaties voorzien drie interfaces tussen CM en CPE : Ethernet, USB en de PCI-bus.

2.2

(Euro-)DOCSIS protocol stack

Figuur 2.2: (Euro-)DOCSIS protocol stack

Om de ruwe bitstroom om te vormen tot de nuttige data zijn er heel wat bewerkingen nodig. Het is gebruikelijk om complexe protocollen op te splitsen in verschillende lagen. Iedere laag kan de diensten van de laag eronder gebruiken en voert een bepaalde bijkomende bewerking uit op de data (vb. header toevoegen met routeringsdata). Een populair model is het OSI-model. OSI staat voor Open System Interconnection, zie bijlage A.

2.2 (Euro-)DOCSIS protocol stack

17

We splitsen deze paragraaf verder op in downstream en upstream. In de downstream richting wordt door de CMTS een continue stroom van data gebroadcast naar verscheidene CM ’s. Het upstream pad is echter onderhevig aan contentie, waarmee we bedoelen dat een upstream kanaal moet gedeeld worden door verschillende modems, die eerst moeten navragen bij de CMTS wanneer en hoe ze data kunnen versturen.

2.2.1

Downstream

• De CMTS Ethernet poort ontvangt externe data via de OSI fysische en datalink laag. • IP of Internet Protocol laag: De CMTS en CM krijgen een IP-adres toegewezen. Data wordt vervolgens naar de HFC-interface stack gestuurd via bridging 4 of routering 5 . • Logical Link Layer (LLC): Hier worden de bron en bestemming ge¨ıdentificeerd gebruik makende van de Ethernet standaard (MAC-adressen). • BPI of Baseline Privacy Interface encrypteert de data zodat veilige transmissie tussen CMTS en CM mogelijk wordt. • Cable MAC: Via deze laag kan de CM onder andere tijdslots toegewezen krijgen voor de transmissie van data. • Transmission Convergence: Deze laag komt enkel voor in de downstream richting. Downstream data wordt geëncapsuleerd in zogenaamde MPEG2-transportstroompakketten (in vervolg afgekort als MPEG-pakketten). Dit maakt de multiplexing van video en dataservices over één kanaal mogelijk. • Physical Media Dependent (PMD) laag: Deze fysische sublaag biedt services aan zoals RF-(de)modulatie, signaalversterking, codering, transmissie van data 4 5

Zenden naar een specifieke locatie. Zenden naar verschillende locaties. Via meegeleverde routeringsinformatie wordt bepaald op welke

locatie de data moet worden afgeleverd.

2.3 ‘Downstream Transmission Convergence’ downstream sublaag

18

en Forward Error Correction (FEC). De standaard voorziet twee modulatieschema’s: 64-QAM en 256-QAM. Bij dergelijke technieken worden een aantal bits (bitvectoren), 6 en 8 bits respectievelijk, omgezet naar een analoge golfvorm. Deze technieken laten datasnelheden (inclusief overhead) toe van 41,7 en 55,6 Mbps respectievelijk. Aangezien enkele lagen van bijzonder belang zijn voor deze thesis worden ze vanaf paragraaf 2.3 meer in detail besproken.

2.2.2

Upstream

Het upstream pad moet gedeeld worden tussen verschillende kabelmodems. Ondanks dit grote verschil wordt dezelfde stack doorlopen, enkel de Transmission Convergence laag ontbreekt. CM’s versturen hun data hier in korte bursts na toestemming van de CMTS. De zogenaamde downstream MAP-berichten maken de modems duidelijk wanneer er zich een zendopportuniteit voordoet, zie paragraaf 2.4.5. Ook de PMD-diensten verschillen, zo worden onder meer andere modulatietechnieken aangewend in het terugkeerpad.

2.3

‘Downstream Transmission Convergence’ downstream sublaag

Zoals reeds vermeld is de taak van deze laag het mappen van data op MPEG-pakketten. Op figuur 2.3 wordt de structuur van een dergelijke pakket afgebeeld. Voor we beginnen aan de beschrijving van de header velden worden eerst wat terminologieafspraken gemaakt. Als we het hebben over MPEG-pakketten, bedoelen we dus het 188 byte grote pakket dat in een continue stroom verstuurd wordt. MAC frames bevatten daarentegen de nuttige data en worden op één of meer MPEG-pakketten gemapt. We korten deze af als respectievelijk pakket en frame.

2.3 ‘Downstream Transmission Convergence’ downstream sublaag

19

Figuur 2.3: MPEG-pakket formaat

De eerste byte is de zogenaamde sync byte en heeft de waarde 0x47. Vervolgens vinden we een bit die aangeeft of er een fout opgetreden is tijdens de transmissie van het pakket. Deze bit wordt gezet tijdens het demodulatieproces, met behulp van de FEC-code. De volgende bit geeft aan of de eerste databyte een pointer veld is. Indien aanwezig, verwijst dit veld (tellen vanaf 0) naar de eerste databyte die het pakket bevat of naar een stuff byte (0xff ). Indien een gedeelte van een MPEG-pakket geen nuttige data bevat, moeten er stuff bytes verstuurd worden. Ook MOET er een pointer veld aanwezig zijn als het mogelijk is dat er een nieuw datapakket zal verstuurd worden in het betreffende MPEG-pakket. Anders gezegd is dit veld aanwezig als er minstens één staartstukje van een MAC frame vervat zit in het pakket. Het PID-veld (Packet IDentifier) geeft aan wat de payload van het pakket inhoudt. (Euro-)DOCSIS heeft de PID 0x1ffe gekregen. Indien de CMTS op een bepaald moment geen data kan versturen, worden nulpakketten uitgestuurd waarvoor de PID-waarde 0x1fff werd voorzien. Figuur 2.4 toont een mogelijke mapping van 2 frames op een MPEG-transportstroom. In de eerste lijn begint een frame, dus er is een pointer veld aanwezig dat als waarde 0 heeft. De rest van frame 1 vind je terug in lijn 2. Er is terug een pointer veld dat nu wijst naar de eerste stuff byte na frame 2. Het derde pakket bevat geen pointer veld aangezien dat helemaal ingenomen wordt door het middenstuk van frame 2. Het laatste pakket tenslotte, omvat het staartstuk van frame 2 en een stukje van het volgende frame. Ook hier moet dus een pointer veld te vinden zijn.

2.4 ‘Cable Media Access Control’ sublaag

20

Figuur 2.4: MAC frame die meerdere MPEG-pakketten overspant

2.4

‘Cable Media Access Control’ sublaag

2.4.1

MAC header

De verschillende header velden worden afgebeeld op figuur 2.5. Het Frame Control (FC)-veld is opgebouwd uit drie subvelden: 1. FC TYPE geeft aan welk type payload er ingesloten is: ATM-, Ethernet- of MAC specifieke frames. De eerste twee dienen om data te versturen. Het laatste maakt het mogelijk om bepaalde afspraken te maken tussen CMTS en CM. 2. De betekenis van FC PARM is afhankelijk van FC TYPE. 3. EHDR ON heeft de waarde 1 als er een uitgebreide header aanwezig is, aangeduid met EHDR op de figuur.

Figuur 2.5: MAC header


21

MAC PARM wordt onder andere gebruikt om de lengte van de uitgebreide header aan te geven, indien aanwezig. LEN (SID) bevat de lengte van het frame, wat gedefinieerd is als de som van het aantal bytes in de uitgebreide header en het aantal bytes na het HCS header veld. Bij het upstream Request bericht (zie paragraaf 2.4.5) moet dit veld ge¨ınterpreteerd worden als een Service ID. Ten slotte kan aan de hand van het HCS-veld nagegaan worden of er een fout is opgetreden tijdens de transmissie van de header bytes.

2.4.2

MAC specifieke berichten

Er zijn vijf types, aangeduid door het MAC PARM veld: 1. Timing: Een dergelijk bericht bevat de globale tijdsreferentie waarmee alle CM’s synchroniseren (SYNC berichten). 2. MAC-Management: MAC Management berichten zijn van bijzonder belang voor deze thesis, we wijden er verder over uit in paragraaf 2.4.3. 3. Request Frame: Dit type komt enkel voor in het upstream pad en wordt gebruikt door de CM om minislots aan te vragen voor upstream transmissie. 4. Fragmentation: Voorziet het basismechanisme om in het upstream pad grote datapakketten op te splitsen en terug te construeren in de CMTS. 5. Concatenation: Het omgekeerde van het voorgaande type, hiermee is het mogelijk om verschillende MAC frames samen te smelten zodat heel wat overhead vermeden wordt.

2.4.3

MAC Management header

Bovenop de MAC header komt nog eens de MAC Management overhead bij dit type bericht. De structuur van de header wordt afgebeeld op figuur 2.6. De belangrijkste velden bespreken we terug kort. SA en DA staan respectievelijk voor Source Address en Destination Address en bevatten de MAC-adressen van de bron en bestemming respectievelijk. Dit kan dus de


22

Figuur 2.6: MAC Management header velden

CMTS of een CM zijn. msg LEN specificeert de lengte van het bericht startend vanaf het DSAP-veld. Version en Type geven tenslotte aan over welk soort bericht het gaat. In appendix B werd een volledige lijst opgenomen van de in (Euro-)DOCSIS 2.0 gedefinieerde waarden.

2.4.4

MAC Management payload

Aangezien het niet de bedoeling is om hier de volledige specificaties te reproduceren en omdat dit van minder belang is voor het softwaregedeelte willen we de ge¨ınteresseerde lezer hiervoor verwijzen naar de specificaties [1]. Wel willen we het in de volgende paragraaf hebben over de belangrijkste functie van de MAC-laag: de toewijzing van minislots.

2.4.5

Allocatie minislots voor upstream verkeer

In de upstream richting wordt er Time Division Multiple Access gebruikt om de beschikbaare capaciteit te verdelen, een upstream kanaal wordt immers toegewezen aan verschillende kabelmodems. Om dit in goede banen te leiden, verstuurt de CMTS periodisch MAP-berichten (Medium Access Packet). Deze berichten beschrijven het


23

toekomstig upstream gebruik in termen van minislots. Een minislot is het kleinste tijdsinterval beschikbaar voor de CM. Typisch is het de tijd nodig om 16 bytes te versturen, wat afhangt van de modulatieparameters. Een MAP-bericht bevat een Channel ID en een aantal Information Elements (IE). Het Channel ID specifieert een upstream kanaal en werd vooraf gedefinieerd door een UCD of Upstream Channel Descriptor bericht. Ieder IE beschrijft een minislot als volgt: • Wie? Een Service Identifier (SID) geeft aan voor wie de informatie bestemd is. Hiervoor worden geen MAC-adressen gebruikt omdat die om uniciteit te garanderen veel te lang zijn. SIDs zijn echter maar uniek binnen een upstream kanaal, zodat 14 bits ruim voldoende zijn. Een SID kan een broadcast of multicast bericht aangeven. • Wat? Dit wordt beschreven door zes Interval Usage Codes (IUCs), zie verder. • Wanneer? Het IE bevat een minislot offset waarmee de CM samen met de starttijd van het MAP-bericht de tijd kan berekenen wanneer de gegeven informatie actief wordt. De continue stroom van dergelijke berichten beschrijft grondig de beschikbare bandbreedte. Indien een CM data wil verzenden moet hij eerst een Request bericht versturen in een minislot bestemd voor dergelijke berichten. De CMTS zal vervolgens minislots reserveren en een MAP-bericht uitsturen om de CM hiervan op de hoogte te stellen.

Interval Usage Codes Deze codes definiëren hoe de upstream bandbreedte kan ingezet worden als volgt: 1. Request: De modem berekent hoeveel minislots nodig zijn om een bepaald datapakket te versturen. Een Request minislot kan gebruikt worden om een aanvraag voor dat aantal slots te verzenden. 2. Request/Data: Een dergelijk type kan gebruikt worden om een aanvraag te versturen of er kan geprobeerd worden om data te versturen. Er worden echter geen


24

garanties geboden, er kan een botsing optreden met andere modems waardoor de data dus verloren gaat. 3. Initial Maintenance: De CM gebruikt dit interval om initiële Ranging aanvragen te sturen (zie paragraaf 2.4.6). Het interval is voldoende lang zodat signalen die niet gesynchroniseerd zijn, toch kunnen ontvangen worden binnen het interval. 4. Station Maintenance: De modem moet altijd een Ranging-aanvraag sturen in dit interval als de SID overeenkomt met zijn toegewezen waarde. 5. Short Data Grant: Kan gebruikt worden om kleine datapakketjes te versturen. Het maximaal aantal toegelaten tijdslots wordt gedefinieerd in het Upstream Channel Descriptor (UCD) bericht dat het betreffende upstream kanaal beschrijft. 6. Long Data Grant: In een dergelijk interval kunnen dan logischerwijs grotere datafragmenten verstuurd worden. Figuur 2.7 geeft schematisch weer hoe het mapping systeem werkt.

Figuur 2.7: Allocatie van timeslots

2.4.6

(Euro-)DOCSIS CM initialisatieprocedure

In deze paragraaf bespreken we een belangrijke taak van de MAC specifieke berichten: De CM-initialisatieprocedure die doorlopen wordt na het aanschakelen van het toestel. In dit hoofdstuk hadden we het tot nu toe vooral over de structuur van de berichten omdat


25

dit nu eenmaal belangrijk is voor het softwaregedeelte. Hier leggen we de nadruk op de functie van de verschillende berichten. Na het aanschakelen, doorloopt een CM een complexe initialisatieprocedure om de modem af te stellen. De modem hangt immers aan een actief netwerk en mag geen oorzaak zijn van storingen. Figuur 2.8 toont de verschillende stappen van de procedure.

Figuur 2.8: CM initialisatieprocedure

Synchronisatie Na de inschakeling van de kabelmodem, begint die te zoeken naar een 64 QAM of 256 QAM gemoduleerd signaal in het downstream spectrum. De modem stemt af op dit signaal en initialiseert FEC. Vervolgens worden SYNC berichten geanalyseerd. Zo’n bericht bestaat uit een 32 bit representatie van de 10,24 MHz interne


26

klok van de CMTS. SYNC berichten worden periodisch verstuurd en zijn nodig om een betrouwbare upstream transmissie te garanderen.

Ranging Downstream Upstream Channel Descriptor (UCD) berichten bevatten alle transmissiekarakteristieken (zoals het modulatieschema) van het upstream kanaal dat het beschrijft. De kabelmodem kiest een kanaal voor een Ranging poging en de transmitter van de CM wordt ingesteld met behulp van de UCD-gegevens. Nu wacht de CM op een MAP met een Initial Maintenance IUC. Wanneer het tijdsinterval dan aanbreekt, verstuurt de CM een Ranging Request bericht met een minimaal zendvermogen en wacht op antwoord. Aangezien het een contentie-interval betreft, kan een retransmit noodzakelijk. Bij iedere nieuwe poging wordt het voltageniveau opgedreven. Een Ranging Request bevat onder andere een Service ID (SID). Initieel wordt dit op 0 ingesteld. De CMTS stuurt als antwoord een Ranging Response met een voorlopige SID. De modem gebruikt de andere informatie zoals frequentie en zendvermogen om de transmitter verder af te regelen. Ook wordt een timing offset meegegeven. Deze beschrijft de vertraging die optreedt door de geografische afstand tussen CM en CMTS. Bij verdere transmissies wordt de aangepaste tijd gebruikt. Als volgende stap wacht de modem op een Station Maintenance MAP met de voorlopige SID. In dit interval mag normaal geen botsing optreden. De CM stuurt, als dit interval er aankomt, een nieuwe Ranging Request en wacht op antwoord. Dit proces kan nog een tijdje doorgaan tot de CM volledig naar wens van de CMTS ingesteld is. Periodiek stuurt de CMTS MAPs met een Station Maintenance IUC waarop de modem verplicht moet reageren met een Ranging Request. Indien het antwoord uitblijft, bijvoorbeeld omdat de CM inmiddels werd uitgeschakeld, wordt die verwijderd uit de lijst binnen de CMTS en worden er geen nieuwe Station Maintenance berichten meer verstuurd bestemd voor deze modem.

2.5 HFC-testnetwerk

27

Registration Dan is het de beurt aan initialisatie op laag 3, IP-niveau. Als eerste stap krijgt de modem een IP-adres toegewezen door een DHCP-server. Daarna wordt een configuratiebestand opgevraagd via het TFTP-protocol6 . Hiermee kan onder andere de modem naar een ander downstream- of upstream kanaal geleid worden. Een andere belangrijke parameter is of Baseline Privacy al dan niet moet geactiveerd worden. Ook geeft dit bestand aan hoeveel toestellen met een MAC-adres verbonden mogen worden met de modem en bevat het de ’Time of Day’. Vervolgens wordt een Registration Request bericht verstuurd met als informatie onder andere de technische mogelijkheden van de modem. Tenslotte antwoordt de CMTS met een Registration Response. In dit bericht is de permanente SID terug te vinden. Ook bevat het een volledige beschrijving van de service (o.a. bandbreedte) die de CM zal genieten. Alles is nu in orde en de modem is klaar voor gebruik.

2.5

HFC-testnetwerk

In het labo van de onderzoeksgroep ‘Cable & Wireless’ bevindt zich een HFC-testnetwerkje waar de ontwikkelde applicatie werd uitgetest. Dit netwerkje is weergegeven op figuur 2.9. De specificaties van de ‘(Euro-)DOCSIS Analyser’ testcomputer zijn de volgende: • Processor: Intel Xeon HT 3 GHz • RAM-geheugen: 2 GB DDR2 • Harde schijf: Maxtor SATA 80 GB • Besturingssysteem: Windows XP

6

Eenvoudig UDP-protocol voor bestandsoverdracht.

2.5 HFC-testnetwerk

28

Figuur 2.9: HFC-testnetwerk

ONTWERP APPLICATIE

29

Hoofdstuk 3 Ontwerp applicatie Op figuur 3.1 wordt de architectuur van de applicatie weergegeven. In tegenstelling tot de figuur van paragraaf 1.3, ligt hier de focus op technologie.

Figuur 3.1: Architectuur applicatie - Technologieën

Het hart van de server bestaat uit een C++ bibliotheek die een MPEG-datastroom kan parsen en analyseren. Het is mogelijk om filters te specifiëren om zo data waarin men ge¨ınteresseerd is op te slaan voor latere analyse. De bibliotheek maakt gebruik van een API die toegang verschaft tot het stuurprogramma van de PCI-insteekkaart.

3.1 Java Remote Method Invocation (RMI)

30

Boven dit alles bevindt zich een Java laagje dat de interface naar de client verzorgt. De client bestaat uit de grafische gebruikersinterface waarmee de gebruiker de protocol analyser kan bedienen. Een zogenaamd ‘stub’ object doet zich voor als de filter, terwijl de eigenlijke implementatie zich in werkelijkheid op een andere computer bevindt, waarmee de stub communiceert. Een belangrijke ontwerpbeslissing was de keuze op welke manier de client-server communicatie plaatsgrijpt. In een objectgeöriënteerd paradigma zijn technologiëen zoals CORBA en het vergelijkbare Java RMI zeer interessant. Ze laten immers communicatie toe op het niveau van objecten. De client kan een ‘remote’ object — een object dat ‘fysisch’ aanwezig is in een andere computer — gebruiken alsof het een lokale referentie betreft. Er wordt bijna volledig abstractie gemaakt van de onderliggende netwerkcommunicatie. De keuze is gevallen op Java RMI omdat we daar al behoorlijk wat ervaring mee hadden. Aangezien de analyser code in C++ geschreven werd, brengt dit met zich mee dat er een koppeling moet gelegd worden tussen de Java RMI-server en deze code. Voor dergelijke gevallen heeft Sun de Java Native Interface (JNI) technologie ontwikkeld [6]. Vooraleer we ons verdiepen in de architectuur, geven we een klein woordje uitleg over RMI en JNI voor de lezer die hiermee niet bekend is.

3.1

Java Remote Method Invocation (RMI)

Java RMI is een vorm van middleware waarmee netwerkcommunicatie op een hoog niveau tussen verschillende computersystemen mogelijk wordt. De middleware zorgt dat de netwerkcommunicatie (bijna) volledig transparant plaatsvindt. De objecten die op afstand zichtbaar moeten zijn, implementeren een zogenaamde Remote interface. Iedere ‘remote’ methode van deze interface moet ook ‘remote’ excepties afhandelen, het is immers mogelijk dat er een netwerkfout optreedt, of dat er iets foutloopt binnen het serverproces. Voor de thesis werd er een interface ontworpen die de analyser functionaliteit voorstelt, zie ook paragraaf 3.3 Figuur 3.2 toont de RMI architectuur. Client en server communiceren niet rechtstreeks

3.2 Java Native Interface (JNI)

31

met elkaar, maar met een stub en skeleton respectievelijk. Deze verbergen samen met de transportlaag de onderliggende TCP-communicatie. Dan is er nog een derde proces van belang, het RMI register, dat meestal op de server draait, maar dit kan even goed op een derde computer. Dit proces houdt verschillende ‘remote’ objectreferenties bij. De server geeft een object onder een bepaalde naam op, clients kunnen dan later dit object terug opvragen met behulp van een lookup operatie die als argument de naam van het object meedraagt.

Figuur 3.2: Java Remote Method Invocation (RMI)

3.2

Java Native Interface (JNI)

Deze SUN-technologie slaat een brug tussen Java code die op een virtuele machine uitgevoerd wordt en echte machinecode. Concreet wordt het mogelijk om binnen een Java proces ‘native’ bibliotheken (DLLs) aan te spreken. Ook kunnen Java objecten binnen een normaal ‘native proces gemanipuleerd worden. De JNI API is echter lastig te hanteren, daarom zijn er inmiddels een aantal ‘third-party’ bibliotheken beschikbaar die een eenvoudigere interface voor de JNI API implementeren. Voor de thesis werd Jace ingeschakeld [5].

3.3 Server-client interface

3.3

32

Server-client interface

Hier vermelden we de interface van de protocol analyser die tot de beschikking van de client staat. Het betreft een ‘remote’ interface die door de RMI-server ge¨ımplementeerd wordt. De client vraagt aan het RMI register een referentie op naar het object dat beantwoordt aan deze interface. Merk ook op dat deze interface volledig overeenkomt met de JNI-interface van de C++ filter bibliotheek: Het serverobject zal alle aanvragen onmiddelijk verder dirigeren naar de bibliotheek. public interface DOCSISanalyserRemote extends Remote { public void start(String fileName) throws RemoteException; public void stop() throws RemoteException; public RuleType[] getRuleTypes() throws RemoteException; public Rule[] getRules() throws RemoteException; public void addRule(Rule rule) throws RemoteException; public void removeRule(int index) throws RemoteException; public analyserStats getStatistics() throws RemoteException; }

De eerste twee methoden laten toe om de realtime filtering te starten en stoppen. getRuleTypes en getRules worden ingezet om de gebruiker op de hoogte te stellen van de huidige filterconfiguratie. Verder kan de gebruiker regels toevoegen en verwijderen. AnalyserStats laat ten slotte toe om realtime statistieken op te vragen als de filterdraad (thread) actief is. Zo wordt bijvoorbeeld de verstreken analysetijd en het aantal geanalyseerde en bewaarde frames bijgehouden.

3.4

Ontwerp server

Zoals reeds aangehaald bestaat het hart van de server uit C++ code. Daarnaast werd er een Java Remote interface geschreven die meteen via JNI de C++ bibliotheek aanroept.

3.4 Ontwerp server

3.4.1

33

Filter bibliotheek

We kunnen dit verder opsplitsen in drie onderdelen: frame constructie, frame filtering en opslag.

Frame constructie Als eerste stap van het analyseproces moet de inkomende MPEG-datastroom geparset worden, het komt erop neer dat de MAC frames opnieuw geconstrueerd moeten worden uit de fragmenten aanwezig binnen 188 bytes grote MPEG-pakketten. We kunnen dit op twee manieren aanpakken: 1. Alle frames herconstrueren terwijl de data binnenstroomt. Dit betekent dus dat voor ieder frame geheugen moet gereserveerd worden en er een aantal geheugenoperaties noodzakelijk zijn. Het voordeel hiervan is dat de data nadien eenvoudig te benaderen is voor analyse. Na constructie hoeft men geen rekening meer te houden met de MPEG-transportlaag (headers e.d.), maar helaas heeft dit dus een aantal ‘dure’ geheugenbewerkingen als kost. 2. De frames enkel samenstellen indien ze moeten worden bewaard. We ontwerpen immers een filter die een beperkt aantal frames met welbepaalde karakteristieken zal behouden. Op deze manier kunnen we heel wat kostbare geheugenoperaties uitsparen. De complexiteit van de code verhoogt echter gevoelig want we moeten nu bij de analyse rekening houden met het feit dat de frame data gefragmenteerd is en geëncapsuleerd wordt door MPEG-pakketten. Het onderscheid tussen de twee aanpakken geven we grafisch weer op figuur 3.3. Bovenaan vinden we de eerste aanpak, onderaan de tweede. Het constructieproces vindt plaats via een aantal tussenstappen. In het eerste geval worden de eerste drie lagen fysisch in het geheugen bijgehouden. MACFrame en MPEGPacket encapsuleren dus een blokje geheugen en bevatten methoden om eenvoudig de header data te kunnen interpreteren. In het tweede geval wordt enkel de MPEG-transportstroom (blok per blok) fysisch in het geheugen geladen. De lagen erboven laten toe om dezelfde data op een andere manier te

3.4 Ontwerp server

34

interpreteren. Indien de gebruiker een Ethernet (EthernetFrame) databyte opvraagt, zal die aanvraag verder propageren naar onder tot uiteindelijk de byte teruggevonden wordt in de MPEG-stroom. Het is duidelijk dat er hier zorgvuldig moet op worden toegezien dat er geen bronnen worden vrijgegeven als die nog nodig zijn. Zo kunnen verschillende MPEGPacket objecten afhankelijk zijn van dezelfde buffer (blok in het geheugen). Pas als al deze objecten vrijgegeven worden, mag ook de buffer verwijderd worden.

Figuur 3.3: Frame constructie: De twee mogelijkheden

Er werd geopteerd voor de tweede optie omwille van de prestatievoordelen, dit was immers een vooropgestelde kwaliteitseis. De verhoogde complexiteit kan voldoende opgevangen worden door een objectgeoriënteerd ontwerp. Figuur 3.4 toont een UML-schema van het ontwerp.

3.4 Ontwerp server

35

Figuur 3.4: UML-klassendiagram frame constructie

MACLayer maakt het mogelijk om opeenvolgende MAC frames (MACFrame) op te vragen. Hiervoor maakt het gebruik van de diensten van een MPEGStream object. Deze klasse analyseert de MPEG-transportstroom en geeft objecten (MPEGPacket) terug die MPEG-pakketten voorstellen. Ook is het mogelijk om te filteren op Process Identifier (PID). MACLayer gebruikt deze functie om enkel (Euro-)DOCSIS data op te vragen. Daaronder vinden we het type MACFrame terug. Hier zijn heel wat functies voorzien die informatie verschaffen over de verschillende headervelden. Deze ‘getters’ kunnen gebruikt worden om te filteren op MAC frame niveau. Een MACFrame object houdt een aantal verwijzingen bij naar MPEGPacket objecten die de (gedeeltelijke) frame data bevatten als payload.

3.4 Ontwerp server

36

Een frame kan verder ge¨ınterpreteerd worden als een MACManagementMessage of EthernetFrame. Deze bieden een abstractie voor een MAC Management bericht of Ethernet pakket respectievelijk.

Frame filtering Eerst wensen we wat terminologie-afspraken te maken: Als we het hebben over filterregels of regels dan bedoelen we de uitdrukkingen die een booleaanse waarde opleveren bij het matchen met een frame. Bij ‘TRUE’ of ‘ALLOW’ zeggen we dat er een match optreedt en dat het frame voldoet aan de regel en dus zal bewaard worden voor verdere analyse. In het andere geval, door ons aangeduid met‘DENY’, negeren we het betreffende frame. De objectgeoriënteerde voorstelling van MAC frames, Ethernet en MAC Management berichten maken het mogelijk om header velden en de data te analyseren. Er werd getracht om filterregels zo generiek mogelijk te ontwerpen zodat gemakkelijk nieuwe regels en zelfs filterniveaus (bijvoorbeeld IP) kunnen toegevoegd worden. Ook werd er nauw op toegezien dat dergelijke wijzigingen weinig extra code vereisen, zie ook appendix D voor meer details. De client vraagt bijvoorbeeld na connectie met de server de lijst van niveaus en regels op zodat de client zonder codewijzigingen kan blijven functioneren na de implementatie van nieuwe niveaus en operaties in de server. Een filterregel is opgebouwd uit drie delen: 1. Niveau: De huidige implementatie ondersteunt drie niveaus: MACFRAME, MACMANAGEMENTMESSAGE en ETHERNET. Het eerste niveau laat filtering toe op basis van de headervelden van een frame. De andere twee ondersteunen filtering met bepaalde eigenschappen van de payload als parameter. Deze niveaus representeren dus in feite een OSI-laag. 2. Operatie: specifieert een bepaald header veld. Zo is het bijvoorbeeld mogelijk om enkel data met een bepaalde bestemming te selecteren. Iedere modem heeft immers een uniek MAC-adres en dus kan de getDA operatie op het ETHERNET niveau hiervoor aangewend worden.

3.4 Ontwerp server

37

3. Waardebereik: Ofwel moet een frame headerveld beantwoorden aan een exacte waarde of er wordt een interval opgegeven. Met deze laatste optie is het bijvoorbeeld mogelijk om alle berichten bestemd voor modems van een bepaalde fabrikant te monitoren. De MAC-adressen zullen immers typisch met dezelfde bytes starten, stel bijvoorbeeld ‘00:11:22:33’. Dan kan het bereik ‘[00:11:22:33:00:00, 00:11:22:33:ff:ff]’ opgegeven worden om dit doel te bereiken. Met een waarde(bereik) is ook een type geassocieerd. Ondersteunde datatypes zijn: tekst, getal, groot getal (64 bits unsigned) en booleaanse waarde. Daarnaast bestaan nog de speciale types ‘null’ en ‘fout’. Regels worden logisch aan elkaar gebonden met de logische operatoren: OR, AND en NOT. Standaard worden alle frames geweigerd. Indien een frame echter aan minstens één regel voldoet, wordt het bewaard. De verschillende regels worden dus gescheiden door de logische OR-operator. Een regel kan opgesplitst worden in verschillende subregels die aaneengehecht worden via de AND-operator. Bij een (sub)regel kan men ook de NOT-operator toepassen. Dit zal alle frames toelaten, behalve deze die aan de (sub)regel voldoen. Dit alles zal duidelijker worden met twee voorbeeldjes: Regel 1: NOT MACFrame.getFCType = 0 Regel 2: MACManagementMessage.getType = 5 AND MACManagementMessage.getVersion = 1

De eerste regel zal alle datapakketten wegfilteren. Ethernet frames worden namelijk gekenmerkt door de FC TYPE waarde 0. De tweede regel zal enkel Ranging Response MAC Management berichten doorlaten, zie ook appendix B. De beide filterregels, tezamen actief, zullen hetzelfde effect hebben als regel 1 afzonderlijk aangezien regel 1 ook regel 2 insluit. Figuur 3.5 toont een UML-diagram van de implementatie van het bovenstaande.

3.4 Ontwerp server

38

Figuur 3.5: UML-structuurdiagram: Implementatie frame filtering

Opslag Opslag gebeurt in het zogenaamde libpcap bestandsformaat. Dit binair formaat bevat de frame data, telkens voorafgegaan door een korte header, bestaande uit de totale en opgeslagen lengte. Enkel frames die matchen met minstens één filterregel, worden bewaard. Ethereal kan dergelijke bestanden openen en heeft een handige interface om de data verder te analyseren. Paragraaf 4.2.5 geeft een impressie van de uitgebreide mogelijkheden.

3.5 Ontwerp client

3.5

39

Ontwerp client

Het gros van de Java client code bestaat uit GUI (Graphical User Interface) gerelateerde logica. De applicatielogica wordt zorgvuldig afgescheiden met behulp van het GUI-Model-Controller paradigma.

Figuur 3.6: Model-View-Controller paradigma

Dit model bestaat, zoals op figuur 3.6 zichtbaar, uit drie componenten. Model bevat de applicatielogica, de toestand van de applicatie. View is hetgeen de gebruiker te zien krijgt, bij gebruiksvriendelijke systemen typisch een grafische gebruikersinterface. Als er iets aan de toestand verandert, kan het model de view hiervan op de hoogte brengen zodat de wijziging zichtbaar wordt. De view kan ook het model bevragen over de huidige toestand. Na connectie zal onze client bijvoorbeeld willen weten of er een analyse aan de gang is zodat de GUI hierop kan afgestemd worden. Indien de gebruiker een actie onderneemt (bijvoorbeeld klikken op een knop), wordt deze doorgespeeld aan de controller. Die moet dan beslissen welke acties er verder moeten ondernomen worden. Typisch treedt er een toestandsverandering op, wat dus gebeurt binnen het model. Op de figuur stellen de streepjeslijnen ’callbacks‘ voor. Dit is een concept dat veelvuldig gebruikt wordt in Java. Als een gebruiker bijvoorbeeld op een knop klikt, wordt iedere luisteraar hiervan op de hoogte gebracht via een gebeurtenis. Deze laatste moet aan

3.5 Ontwerp client

40

een bepaalde interface beantwoorden en zich vooraf registreren als ge¨ınteresseerde bij het model. De thesisapplicatie maakt gebruik van een vereenvoudigd MVC-model. Zo zal het model ook de controller functionaliteit voor zijn rekening nemen. De toestand is hier drieledig: de connectie-, analysing en filterconfiguratietoestand. Verder communiceert het model met de server via een Remote Java RMI-serverobject waarvan we de interface besproken hebben in paragraaf 3.3. Tot slot sommen we de belangrijkeste view componenten op: • MainFrame: Het hoofdvenster van de applicatie, hiermee kan onder andere de filterconfiguratie aangepast worden, kan men statistieken opvragen en kan de server filterdraad gestart en gestopt worden. • ConnectDialog: Hiermee kan de gebruiker de benodigde gegevens invullen om een serverconnectie op te zetten. • FilteringDialog: Voor een filteroperatie gestart wordt, moet de gebruiker onder andere een bestandsnaam opgeven. De server zal een bestand aanmaken met die naam. Nadien kan dit bestand verder geanalyseerd worden met Ethereal. • StatsFrame: Dit venster toont allerlei serverkarakteristieken, zoals bijvoorbeeld het aantal geanalyseerde MAC frames. De client wordt in het volgende hoofdstuk verder uitgebreid besproken.

GRAFISCHE GEBRUIKERSINTERFACE

41

Hoofdstuk 4 Grafische gebruikersinterface In dit hoofdstuk bespreken we de GUI van de client. Waar de nadruk in het vorige hoofdstuk op de structuur lag, willen we hier een duidelijk beeld scheppen van de mogelijkheden van de applicatie. De client leent zich hier goed toe, het is immers de interface naar de gebruiker en maakt het mogelijk om alle functies in te stellen en te gebruiken.

4.1

Gebruiksvriendelijkheid

De applicatie bevat naast de basisfunctionaliteit een aantal functies die de gebruiksvriendelijkheid sterk ten goede komen. We sommen ze hier op: • De client vraagt de regeltypes (niveaus en operaties), nodig om filterregels op te bouwen, op aan de server. Enkel de regelstructuur zit in de client ingebakken (niveau - methode - waarde), de GUI is hier immers op afgestemd. De verschillende niveaus en methodes worden opgeladen na het succesvol opzetten van een connectie. Zoals reeds vermeld in hoofdstuk 3 heeft dit als voordeel dat er geen nodeloze afhankelijkheden bestaan, de client kan perfect blijven verder functioneren indien er nieuwe niveaus of operaties op serverniveau toegevoegd worden. Een klein nadeel is dat er geen filterconfiguraties kunnen aangemaakt worden zonder serverconnectie.

4.1 Gebruiksvriendelijkheid

42

• Er werd een importeer/exporteer mogelijkheid voorzien. De filterconfiguratie kan op ieder moment geëxporteerd worden naar een XML-bestand. Nadien kunnen regels via dit bestand terug ge¨ımporteerd worden. Ook handig is dat de connectieinformatie eveneens bewaard wordt. De gebruiker kan in het connectie dialoogvenster een XML-bestand importeren en indien dit bestand de correcte structuur heeft, zal hierdoor automatisch de connectie met de server opgezet worden. Dergelijke XML-bestanden worden op de client PC opgeslagen. Indien de server herstart wordt, gaat de actieve filterconfiguratie verloren. De client kan dus de toestand eenvoudig herstellen met behulp van deze functie. • De gebruiker kan ervoor kiezen om slechts een gedeelte van de frames op te slaan. Dit kan bijvoorbeeld handig zijn in een situatie waar men ge¨ınteresseerd is in datapakketten, maar men niet de volledige payload nodig heeft voor analyse achteraf. Op die manier kan heel wat schijfruimte bespaard worden. • Er zijn een aantal extra filteropties, zo kan men naast een bestandsnaam ook een tijdsduur en maximale bestandsgrootte opgeven. Op die manier voorkomt men dat de analyser alle resterende schijfruimte inneemt en de server laat crashen. • De filterdraad (indien gestart) blijft actief nadat de client wordt afgesloten. • Communicatie met de server wordt zoveel mogelijk vermeden, de server houdt hiervoor bij welke wijzigingen er zijn aangebracht aan de servertoestand. Pas als de gebruiker hiervoor expliciet de opdracht geeft, via de ‘apply’ knop, worden de filterwijzigingen ook daadwerkelijk doorgevoerd onder de vorm van toevoegen verwijderoperaties. • Getallen (type ‘Number’ of ‘Big Number’) kunnen op drie manieren ingevoerd worden: 1. decimaal: Vb. ‘123456’ 2. hexadecimaal: Vb. ‘0xabcdef’ 3. hexadecimaal met de bytes gescheiden door ‘:’: Vb. ‘12:34:56:78:9A:BC’. MAC-adressen worden meestal in dit formaat beschreven.

4.2 GUI-onderdelen

4.2

43

GUI-onderdelen

In deze paragraaf bespreken we de verschillende GUI-onderdelen en bespreken stap voor stap hoe een filteractie opgezet wordt, dit alles toegelicht aan de hand van screenshots.

4.2.1

Connectie

Figuur 4.1 toont de situatie net na het opstarten van de applicatie. Er wordt de gebruiker gevraagd om connectiegegevens in te vullen. Een andere manier is om deze, samen met een filterconfiguratie, te importeren met behulp van de ‘Import’ knop.

Figuur 4.1: Connectie dialoogvenster

4.2 GUI-onderdelen

4.2.2

44

Hoofdvenster

Vervolgens krijgt de gebruiker het hoofdvenster te zien waar nu links een boomstructuur zichtbaar is. Deze situatie is zichtbaar op figuur 4.2. De verschillende operaties worden gegroepeerd onder hun bijhorende niveau.

Figuur 4.2: Hoofdvenster

Het Value/Bounds paneel past zijn inhoud dynamisch aan, naargelang de geselecteerde tak in de boom. Op de figuur is het regeltype ‘ETHERNET.getDA’ geselecteerd. De gebruiker kan dan kiezen om een waarde of een bereik in te geven. Deze moeten allebei beantwoorden aan het datatype van het regeltype. In de afgebeelde situatie is dit ’Big Number’, een positief geheel getal dat binnen een 64 bits representatie past. Het Rule Settings paneel maakt het mogelijk om logische operatoren te selecteren. De standaardoperatie is OR, die de regel als een nieuwe lijn toevoegt in de Rules tabel. De

4.2 GUI-onderdelen

45

AND optie koppelt de gedefinieerde regel met een andere met een logische en. De laatst vernoemde regel wordt bepaald door een selectie in de tabel. Verder kan ook de NOT operator aangevinkt worden en kan de gebruiker aangeven dat er een beperkt aantal bytes per frame bewaard moet worden bij een match met de betreffende regel. Pas toegevoegde regels krijgen het label ‘NEW’ in de derde kolom van de tabel. Indien de gebruiker de veranderingen vastlegt met behulp van de ‘Apply knop, wordt de toestand ‘ACTIVE’. Het verwijderen van actieve regels zal deze toestand wijzigen naar ‘DELETED’. Na de ‘Apply’ worden dergelijke regels dan ook daadwerkelijk verwijderd. Dit in tegenstelling met nieuwe filterregels (toestand ‘NEW’), deze worden onmiddelijk verwijderd uit de tabel. Vanuit het oogpunt van de server bekeken, is er in het laatste geval niets gebeurd. De ‘Reset’ knop herstelt de client toestand terug naar de huidige servertoestand. Dit komt neer op het verwijderen van alle nieuwe regels en die met status DELETED’ terug te brengen in de actieve toestand.

4.2.3

Filteren

De ‘START filtering’ knop presenteert aan de gebruiker het dialoogvenster afgebeeld op figuur 4.3. Indien er wijzigingen zijn aangebracht aan de filterconfiguratie, wordt de gebruiker eerst nog gevraagd om ze toe te passen in de server. Het afgebeelde dialoogvenster vraagt om een bestandsnaam in te geven, ook kan het analyseren beperkt worden in tijd of schijfruimte. Indien de gebruiker de ‘OK’ optie kiest, krijgt de server de opdracht om het filteren te starten. De regels worden toegepast op ieder MAC frame. Bij een match wordt het frame (of een gedeelte ervan) bewaard op de server.

4.2.4

Status

De gebruiker kan de servertoestand opvragen, tijdens een filtering toont dit realtime statistieken. In het ander geval wordt informatie verschaft over de recenste filteroperatie

4.2 GUI-onderdelen

46

Figuur 4.3: Filter dialoogvenster

(indien beschikbaar). Op figuur 4.4 zien we het status dialoogvenster. Ook valt de rode ’STOP filtering’ knop linksonder op. Dit geeft aan dat er een filteroperatie in uitvoering is. Het dialoogvenster voorziet een vinkje waarmee de inhoud automatisch periodisch vernieuwd kan worden. We vinden achtereenvolgens: • Status: Geeft aan of de filterdraad actief is. • File: Bestand dat de gefilterde informatie bevat. • Frames analyzed: Aantal frames reeds behandeld in de huidige of laatste filteroperatie. • Frames saved: Aantal gefilterde frames, vastgelegd in een bestand. • Bytes saved: Aantal bytes bewaard, libpcap headerdata niet meegerekend. • MPEG packets analyzed: Aantal MPEG pakketten reeds onderschept. • Buffer filling percentage: Een indicatie van de serverbelasting. Dit geeft aan in hoeverre de hardware buffer op de ASI-insteekkaart gevuld is. Het percentage zal oplopen als de analyser de binnenkomende datastroom niet kan bijhouden. Uiteindelijk zal de buffer overlopen en zullen de meeste MPEG-pakketten niet meer behandeld worden, wat uiteraard tot ongewenste resultaten zal leiden.

4.2 GUI-onderdelen

47

• Time elapsed: Geeft aan hoelang de huidige filterlus al loopt of de tijdsduur van de laatste operatie.

Figuur 4.4: Statusvenster

4.2.5

Analyse in Ethereal

Het libpcap bestand kan geopend worden in Ethereal voor verdere analyse. Figuur 4.5 geeft een impressie van de mogelijkheden. In het voorbeeldje van de figuur is er een bestand geopend met enkel Ethernet pakketten. We zien dat Ethereal gedetailleerde informatie verschaft over de datapakketten, ook is het mogelijk om verder filters toe te passen op het bestand.

4.2 GUI-onderdelen

48

Figuur 4.5: Analyse in Ethereal

ONDERZOEK

49

Hoofdstuk 5 Onderzoek In dit hoofdstuk gaan we na of de downstream (Euro-)DOCSIS protocol analyser ook praktisch bruikbaar is. Een mooi ontwerp die amper de binnenkomende datastroom kan bijhouden, heeft immers weinig praktisch nut. De belangrijkste kwaliteitseis was een prestatiegericht ontwerp. Hier zal blijken of dit vruchten heeft afgeworpen. De performantie van software is uiteraard sterk afhankelijk van de specificaties van de computer waarop de applicatie (server) draait. De specificaties van de testcomputer staan beschreven in paragraaf 2.5. De hardware waarop de client draait daarentegen, is uiteraard niet van belang, aangezien die enkel commando’s uitdeelt en dient als doorgeefluik voor filterconfiguraties. Het onderzoek werd uitgevoerd in het testlabo van TComLabs 1 . Er stonden een honderdtal modems opgesteld, allemaal ingesteld op hetzelfde downstream kanaal. Een signaalgenerator genereerde voldoende Ethernet data om de volledige capaciteit van het downstream kanaal in te nemen. De CMTS moduleerde data volgens het 256-QAMschema, wat een downstream bandbreedte van 55,6 Mbps betekent. We kunnen dit een ‘worst-case scenario’ noemen. Operatoren zoals Telenet gebruiken immers voorlopig nog geen 256-QAM en ook zal erop worden toegezien dat een downstream kanaal niet overbelast geraakt. Typisch zal dus niet het volledige kanaal bezet zijn om piekmomenten op te vangen. 1

De certificatie-authoriteit voor Euro-DOCSIS hardware. Zie ook http://www.tcomlabs.com/

5.1 Prestatietesten

5.1

50

Prestatietesten

Er werden drie testen uitgevoerd met als doel het vinden van de beperkingen van de software. We maten telkens het processorgebruik van een filteroperatie met behulp van ’Windows Taakbeheer’ over een tijdsperiode van ongeveer één minuut, de geschatte gemiddelde waarden werden bijgehouden. Het geheugengebruik varieert van 15 MB tot 17 MB naargelang er een client geconnecteerd is en er een filteroperatie aan de gang is. De testen gebeuren steeds volgens hetzelfde principe: We voegen telkens filterregels toe van eenzelfde type en observeren in welke mate het processorverbruik toeneemt. Op figuur 5.1 werden de restultaten in een grafiek uitgezet. In de volgende paragrafen bespreken we de testsetups en geven een verklaring voor de observaties.

Figuur 5.1: Resultaten prestatietesten

5.1.1

Test 1: 64 bytes Ethernet pakketten, onbestaande MACadressen

De signaalgenerator maakt willekeurige datapakketten aan met een vaste grootte van 64 bytes. We filteren op het ‘ETHERNET’ niveau en kiezen de operatie ‘getDA’. Als waarden

5.1 Prestatietesten

51

worden onbestaande MAC-adressen opgegeven. In de grafiek volgen we de gele lijn. We zien dat die benaderend lineair is en behoorlijk steil omhoogklimt bij een toenemend aantal regels. De ‘bottleneck’ ligt bij 52 regels. Bij 53 actieve regels en dus MAC-adressen loopt de buffer van de ASI-kaart langzaam vol. Het valt op dat er bij de overgang van 0 naar 1 filterregel een sprongetje optreedt. Dit is te verklaren door het feit dat in het eerste geval slechts de frames worden geconstrueerd, er vindt geen verdere analyse plaats. Aangezien we echter op ‘ETHERNET’ niveau filteren, moet ook de Ethernet payload geparset worden in het ander geval. Bij meerdere regels daarentegen, hoeft dit niet opnieuw te gebeuren, enkel het bestemmingsveld wordt opnieuw gecontroleerd. Vandaar observeren we dus een kleinere stijging dan bij de overgang van 0 naar 1. We merken ook op dat het parsen van de MPEG-stroom (0 actieve regels) al 20 % van de processortijd in beslag neemt. Met parsen bedoelen we het vertalen van de datastroom naar een stroom MAC frames.

5.1.2

Test 2: 64 bytes Ethernet pakketten, bestaande MACadressen

Test 2 is gelijkaardig aan de vorige test, maar nu gebruiken we MAC-adressen die ook daadwerkelijk teruggevonden worden in de gegenereerde Ethernet frames. Het gevolg is dat we extra Input/Output-verkeer (IO) genereren omdat er data moet worden weggeschreven naar de harde schijf. Hiermee kunnen we dus nagaan of IO een ‘bottleneck’ vormt. In de grafiek komt deze test overeen met de blauwe lijn. Er is terug een benaderend lineair verband. De helling is nu echter iets minder steil. Dit is eenvoudig te verklaren door het feit dat de regels logisch verbonden worden met de ‘OR’ operator: Er hoeft slechts één match gevonden te worden. Indien een filterregel gevonden wordt waaraan een frame voldoet, heeft het geen zin om nog de andere regels te overlopen. Bij de eerste test wordt er echter nooit een match gevonden en moeten dus telkens alle regels getest worden, wat uiteraard meer tijd vergt.

5.1 Prestatietesten

52

De grens ligt nu bij 53 MAC-adressen. Wat opvalt is dat de processor niet volledig bezet is bij dit aantal, we observeren een gebruik van 82 %. Blijkbaar kan de processor de rest van de tijd geen nuttig werk verrichten omdat de harde schijf niet snel genoeg de gegevens kan opslaan. We kunnen dus besluiten dat IO wel degelijk een bottleneck is.

5.1.3

Test 3: 300 bytes Ethernet pakketten, onbestaande MACadressen

We vertrekken terug van de eerste test, het verschil hiermee is nu de grootte van een datapakket: 300 bytes. Op de grafiek zien we terug duidelijk het lineaire verband. Ook het sprongetje in het begin merken we terug op. De belangrijkste waarneming is hier echter dat de rechte veel minder sterk stijgt dan die van de andere testen. Dit is uiteraard logisch te verklaren door het feit dat de pakketten nu bijna vijf keer groter zijn en er dus ongeveer vijf keer minder snel MAC- en Ethernet frames moeten geparset worden.

5.1.4

Algemeen besluit

De testen tonen duidelijk aan dat de applicatie realtime analyse mogelijk maakt in een realistische situatie. In de praktijk heeft een complexe filter met meer dan vijftig regels immers geen nut. Daarbovenop komt nog eens dat een typische (Euro-)DOCSIS datastroom minder veeleisend zal zijn dan die van de testopstelling omwille van de volgende redenen: 1. De volledige downstream bandbreedte wordt meestal niet volledig benut, men moet immers piekmomenten kunnen opvangen. 2. De gemiddelde Ethernet pakketgrootte is typisch groter dan 64 bytes, hoe groot precies hangt af van de toepassing. Uit het onderzoek blijkt duidelijk dat de prestaties verbeteren bij toenemende groottes. 3. 256-QAM wordt in de praktijk voorlopig nog niet gebruikt.

5.1 Prestatietesten

53

Tenslotte willen we er nog op wijzen dat een prestatieprobleem kan opgelost worden door de aanschaf van een snellere computer. Zo valt bijvoorbeeld op in test 2 dat de schijfbenaderingen 20 % van de processortijd onbenut laten. De aanschaf van een RAIDconfiguratie of een SCSI-systeem zal dit percentage ongetwijfeld sterk naar beneden jagen.

CONCLUSIES

54

Hoofdstuk 6 Conclusies 6.1

Besluit

We hadden ons als doel gesteld om een softwareontwerp te ontwikkelen dat het mogelijk maakt om realtime een (Euro-)Docsis downstream kanaal te filteren. We zijn erin geslaagd om een applicatie af te leveren die beantwoordt aan behoorlijk strikte kwaliteitseisen en we hebben hierbij een voldoende evenwicht gevonden tussen prestaties, uitbreidbaarheid en gebruiksvriendelijkheid. ‘Worst case’ prestatietesten tonen aan dat realtime analyse met een realistische filterconfiguratie vast en zeker binnen bereik is.

6.2

Uitbreidingen

We durven te stellen dat onze applicatie voldoet aan de vooropgestelde kwaliteitseisen. Natuurlijk is het wel zo dat het tijdsbestek niet toeliet om een volledig afgewerkt product klaar te stomen. Hier suggereren we enkele uitbreidingen en zelfs (drastische) wijzigingen die interessant kunnen zijn voor verder onderzoek. Indien er een fout gedetecteerd wordt tijdens demodulatie van een MPEG2-transportstroom, wordt er een MPEG-headerbit aangezet, waarmee de protocol analyser echter nog geen rekening houdt. De server zou dit moeten detecteren en het deels opgebouwde MAC frame negeren, mogelijk samen met enkele opvolgende MPEG-pakketten totdat er terug

6.2 Uitbreidingen

55

een pointer veld gevonden wordt. Dit veld wijst immers gegarandeerd naar een nieuw MAC frame. Ook is er nog wat werk om de server applicatie beter te laten omgaan met excepties. Bepaalde fouten worden soms nog onvoldoende gerapporteerd zodat het moeilijk kan zijn om de oorzaak te achterhalen bij crashes. Verder zullen er bij het optreden van een buffer overflow bijna geen frames meer gedetecteerd worden omdat er voortdurend MPEG-pakketten verloren gaan. Een mogelijke oplossing hiervoor is het detecteren van een nakende overflow en het analyseren even te staken tot de situatie terug genormaliseerd is. Dit zou moeten leiden tot een kleiner verlies aan frames. De opgenoemde aanpassingen zijn behoorlijk belangrijk, daarnaast kunnen we nog een aantal handige functies vermelden die de gebruikerservaring van de gebruiker zullen verbeteren: • Als een gebruiker wil filteren op een bepaald frame type, hetgeen aangegeven wordt door een getalcode, dan moet hij/zij weten waarvoor elke code staat (datapakket, MAC specifiek, . . . ). Een handige uitbreiding bestaat erin om een logische naam met dergelijke codes te associëren. • Aangezien de client en server mogelijk communiceren over een een traag netwerk, kunnen bepaalde commando’s eventjes op zich laten wachten. In de huidige implementatie zullen GUI-elementen zoals knoppen hierdoor even blijven hangen, het zou dus interessant zijn om alle RMI-oproepen in een aparte draad uit te voeren. De gebruiker kan dan eventueel de actie onderbreken indien die te lang op zich laat wachten. • Voorlopig wordt de gefilterde informatie naast de programmabestanden bewaard op de server. Een mogelijke uitbreiding is de gebruiker de keuze te laten waar het moet bewaard worden. • De analyser code kan eenvoudig uitgebreid worden om filtering dieper in de OSIstack mogelijk te maken (bijvoorbeeld op IP-niveau). Zie appendix D voor meer

6.2 Uitbreidingen

56

informatie. • De huidige tendens in de (Euro-)DOCSIS standaarden is het combineren van downstream kanalen om zo hogere snelheden te ondersteunen. De applicatie zou kunnen uitgebreid worden met de mogelijkheid om meerdere ASI-inputs tegelijk te verwerken. Tijdens een ontwerpfase moeten er altijd belangrijke knopen worden doorgehakt, hier suggereren we twee drastische ontwerpwijzigingen die interessant zijn om verder uit te werken, om zo te kunnen vergelijken met onze keuze: 1. Een andere mogelijke vertrekpiste is het schrijven van een Ethereal plugin. Ethereal ondersteunt standaard slechts analyse van data aangeleverd via een Ethernet interface. Aangezien de code vrij beschikbaar is, is het mogelijk om een uitbreiding te ontwikkelen die ASI-input kan verwerken. De rest van de benodigde functionaliteit zou reeds moeten aanwezig zijn aangezien Ethereal (Euro-)DOCSIS data kan interpreteren. 2. Voor de server-client interactie viel de keuze op RMI, een andere voor de hand liggende mogelijkheid is CORBA. RMI werd verkozen omdat we meer ervaring met deze technologie hebben, zodat de ontwikkeltijd beperkt kon blijven. CORBA ondersteunt interoperabiliteit tussen verschillende talen zodat op deze manier het gebruik van JNI zou kunnen vermeden worden. Het is moeilijk te zeggen welke keuze het meeste voordelen biedt zonder beide eerst uit te werken, wel valt op dat RMI samen met JNI behoorlijk sloom reageert. Het is dus goed mogelijk dat een CORBA-implementatie deze problemen zou verhelpen.

OPEN SYSTEM INTERCONNECTION (OSI)

57

Bijlage A Open System Interconnection (OSI) Het OSI-model definieert een geraamte om protocollen te implementeren in zeven verschillende lagen. Daarbij wordt de controle van de ene laag op de andere doorgegeven, startend in de applicatielaag en zo stelselmatig naar de onderste laag. De onderste laag zorgt er dan voor dat de data over een kanaal naar de bestemmeling getransporteerd wordt, waar opnieuw de zeven lagen worden doorlopen, weliswaar van onder naar boven nu. In de volgende paragrafen worden alle lagen kort besproken.

A.1

Applicatielaag (Laag 7)

Deze laag ondersteunt applicatie- en eindgebruikerprocessen. De laag ontdekt de communicerende processen, definieert de Quality of Service, past eventueel authentificatie en geheimhouding toe en ten slotte worden alle beperkingen qua syntax van de data vastgesteld. Alles op deze laag is applicatie-afhankelijk. De laag voorziet applicatiediensten voor bestandsoverdracht, email en andere netwerkdiensten. Email en het File Transfer Protocol (FTP) zijn voorbeelden van toepassingen die volledig draaien in de applicatielaag.

A.2 Presentatielaag (Laag 6)

A.2

58

Presentatielaag (Laag 6)

Deze laag voorziet onafhankelijkheid van verschillen in datarepresentatie (bijvoorbeeld bij encryptie) door de data te vertalen van applicatie- naar netwerkformaat, en omgekeerd. De presentatielaag zorgt ervoor dat de data omgevormd wordt in een formaat dat door de applicatielaag gelezen kan worden. De laag formatteert en versleutelt de data die over het netwerk verzonden moot worden, waarbij dan geen compatibiliteitsproblemen kunnen optreden. De laag wordt ook wel de syntaxlaag genoemd.

A.3

Sessielaag (Laag 5)

Deze laag creëert, onderhoudt en beëindigt verbindingen tussen verschillende applicaties. De sessielaag start, coördineert en beëindigt ook conversaties en uitwisselingen van data en dialogen tussen de applicaties van de eindsystemen. De laag behandelt de sessies en coördineert de verbinding.

A.4

Transportlaag (Laag 4)

Deze laag voorziet transparante overdracht van data tussen de eindsystemen (hosts), en is verantwoordelijk voor foutherstel en voortgangscontrole. De transportlaag garandeert een complete datatransfer.

A.5

Netwerklaag (Laag 3)

Deze laag ondersteunt switch- en routertechnologieën, waarbij logische paden (ook wel virtuele circuits genoemd) aangemaakt worden die de data van node tot node transporteren. Functies van deze laag zijn routering, adressering, werking van internet, foutbehandeling, behandeling van verkeersopstopping en de volgorde waarin pakketten worden verstuurd.

A.6 Datalinklaag (Laag 2)

A.6

59

Datalinklaag (Laag 2)

Op deze laag worden datapakketten geëncodeerd en gedecodeerd in bits. De laag voorziet kennis en beheer van het transmissieprotocol en behandelt fouten vanuit de fysieke laag, voortgangscontrole en synchronisatie tussen de frames. De datalinklaag is verdeeld in twee deellagen: De Media Access Control (MAC) laag en de Logische Link Controle (LLC) laag. De MAC-deellaag controleert hoe een computer van het netwerk toegang verkrijgt tot de data en toestemming krijgt om deze data dan te transporteren. De LLC-deellaag controleert framesynchronisatie, voortgangscontrole en foutcontrole.

A.7

Fysische laag (Laag 1)

Deze laag stuurt de bitstroom — een elektrische puls, een licht- of radiosignaal — door het netwerk op het mechanische niveau. De laag zorgt voor de hardwarevoorzieningen voor het versturen en ontvangen van data via een drager. De laag definieert dan ook kabels, kaarten en andere fysische aspecten.

MAC MANAGEMENT BERICHTTYPES

60

Bijlage B MAC Management berichttypes In onderstaande tabel staan ter referentie alle MAC Management berichttypes zoals ze gedefinieerd zijn in de specificaties van (Euro-)DOCSIS 2.0.

Type Version Message Name

Message Description

1 2

or

1

SYNC

Timing Synchronization

1 or 3

UCD

Upstream Channel Descriptor. A UCD for a

29

DOCSIS 2.0 Only Channel uses a type of 29 and a version of 3. All other UCDs use a type of 2 and a version of 1.

3

1

MAP

Upstream Bandwidth Allocation

4

1

RNG-REQ

Ranging Request

5

1

RNG-RSP

Ranging Response

6

1

REG-REQ

Registration Request

7

1

REG-RSP

Registration Response

8

1

UCC-REQ

Upstream Channel Change Request

9

1

UCC-RSP

Upstream Channel Change Response

10

1

TRI-TCD

Telephony Channel Descriptor [DOCSIS6]

11

1

TRI-TSI

Termination System Information [DOCSIS6]

12

1

BPKM-REQ

Privacy Key Management Request [DOCSIS8]

MAC MANAGEMENT BERICHTTYPES

61

13

1

BPKM-RSP

Privacy Key Management Response [DOCSIS8]

14

2

REG-ACK

Registration Acknowledge

15

2

DSA-REQ

Dynamic Service Addition Request

16

2

DSA-RSP

Dynamic Service Addition Response

17

2

DSA-ACK

Dynamic Service Addition Acknowledge

18

2

DSC-REQ

Dynamic Service Change Request

19

2

DSC-RSP

Dynamic Service Change Response

20

2

DSC-ACK

Dynamic Service Change Acknowledge

21

2

DSD-REQ

Dynamic Service Deletion Request

22

2

DSD-RSP

Dynamic Service Deletion Response

23

2

DCC-REQ

Dynamic Channel Change Request

24

2

DCC-RSP

Dynamic Channel Change Response

25

2

DCC-ACK

Dynamic Channel Change Acknowledge

26

2

DCI-REQ

Device Class Identification Request

27

2

DCI-RSP

Device Class Identification Response

28

2

UP-DIS

Upstream Transmitter Disable

29

3

30

3

INIT-RNG-REQ

Initial Ranging Request

31

3

TST-REQ

Test Request Message

32

3

DCD

Downstream Channel Descriptor [DSG]

33255

(See entry for UCD)

Reserved for future use

TUTORIAL: INSTALLATIE PROTOCOL ANALYSER

62

Bijlage C Tutorial: Installatie protocol analyser In dit hoofdstuk beschrijven we stap voor stap hoe de client- en serverapplicatie ge¨ınstalleerd moeten worden.

C.1

Structuur software DVD

Op figuur D.1 wordt de structuur van de software DVD die bij deze thesis hoort, weergegeven. Voor deze appendix is de bin map van belang, we zien 3 submappen: 1. client: Bevat de Java class bestanden waaruit de client is opgebouwd. 2. server: De bibliotheken en class bestanden waaruit de server is opgebouwd. Zthread.dll maakt het mogelijk om threads te gebruiken; het vormt een objectgeöriënteerde encapsulatie van de Windows API, ook bestaat er een Linux variant met precies dezelfde interface. Jace.dll bevat de Windows Jace implementatie die, ter herinnering, een vereenvoudigde interface tot JNI vormt. xerces-c 2 7.dll bevat de Apache XML-implementatie. Terug verkiezen we om geen gebruik te maken van de Windows API omdat we platformonafhankelijkheid nastreven. DOCSISAna-

C.2 Installatie server

63

Figuur C.1: Inhoud software DVD

lyzer.dll ten slotte, bestaat uit de filterfunctionaliteit en maakt hiervoor gebruik van de bovengenoemde hulpbibliotheken. 3. common: Deze map bevat class bestanden waarvan zowel de server als client afhankelijk zijn. 4. Jdk1.5.0 07: De ‘Java Development Kit’ waarmee de applicatie werd ontwikkeld.

C.2

Installatie server

C.2.1

Vereisten

• Een krachtige computer met een voldoende snelle processor en harde schijf. • Een Dektec PCI-kaart met ASI-input: DTA-120, DTA-122 of DTA-140. Installeer de kaart en de stuurprogramma’s. Eventueel is het ook mogelijk om een bestand als input te gebruiken. Op de DVD staat

C.3 Installatie client

64

er een bestand waarmee dit mogelijk is: 256QAMDOWNSTREAM.TRP. Hiervoor dienen nog de volgende stappen ondernomen te worden: 1. Kopieer de src map naar een plaats op de harde schijf en werk hiermee verder. 2. Open het bestand src/server/dll/config.h en decommentarieer lijn 34. Sla het bestand op en sluit het af. 3. Compileer de DLL. De eenvoudigste manier om dit te doen is om het projectbestand met Visual Studio 2003 te openen en de release versie te laten compileren. 4. Voer CP server.bat uit. Dit batch bestand zal een bin map naast src aanmaken. Deze mapstructuur bevat nu de vers gecompileerde versie. 5. Kopieer 256QAMDOWNSTREAM.TRP naast de executable in bin/server.

C.2.2

Installatie

1. Kopieer de mappen bin en common samen met Server.bat naar een plaats naar keuze. 2. Editeer Server.bat en pas codebase en library.path aan naar de absolute map waar de server binary ge¨ınstalleerd is. Vergeet niet de codebase af te sluiten met een ‘/’ ! 3. De applicatie is nu klaar voor gebruik: Voer Server.bat uit.

C.3

Installatie client

De installatie van de client is heel eenvoudig: Kopieer de mappen client, common en Jdk1.5.0 07 samen met client.bat naar een plaats naar keuze. De client applicatie kan vervolgens uitgevoerd worden via client.bat.

TUTORIAL: TOEVOEGEN VAN EEN FILTERNIVEAU EN OPERATIE

65

Bijlage D Tutorial: Toevoegen van een filterniveau en operatie Deze tutorial biedt een stap voor stap beschrijving hoe de software kan uitgebreid worden met nieuwe filterregels. Een filterregel bestaat uit drie onderdelen: niveau, operatie en waardebereik. In deze tutorial wordt er stap voor stap uitgelegd hoe een nieuw niveau met een operatie kan toegevoegd worden.

D.1

FilterSettings.xml

De server applicatie gebruikt een XML-configuratiebestand om de verschillende niveaus en operaties in te lezen. Hieronder een fragmentje:

0 1

D.2 Structuur software DVD

66

2 3

Per niveau wordt er een nieuw rule element gedefinieerd. Hiermee worden als attributen een naam en type geassocieerd. type duidt het niveau aan van de operatie. Verder bevat een realisation subelement een datatype en methode. Het is de bedoeling dat deze methode overeenkomt met een getter van een klasse die het niveau voorstelt. Ten slotte kunnen er een aantal constanten (constant elementen) opgegeven worden die een waarde associëren met een identifier die een betekenis heeft voor de gebruiker.

D.2

Structuur software DVD

Op figuur D.1 wordt de structuur van de software DVD die bij deze thesis hoort, weergegeven.

Figuur D.1: Inhoud software DVD

Voor deze appendix is de src map van belang. Kopieer deze map naar een locatie naar

D.3 Toevoegen filterniveau en -operatie

67

keuze op de harde schijf. Na hercompileren van de code kan het CP server.bat batch bestand gebruikt worden om een bin mapstructuur te genereren met de aanpassingen.

D.3

Toevoegen filterniveau en -operatie

In deze paragraaf leggen we stap voor stap uit hoe een nieuw niveau en operatie kunnen toegevoegd worden. We doen dit aan de hand van een voorbeeld waarbij we het IP niveau willen toevoegen en sourceIP als operatie. 1. Pas het XML-configuratiebestand aan. Paragraaf D.1 verschaft meer uitleg over de structuur van dit bestand. In ons voorbeeld zouden we het volgende element kunnen toevoegen:

2. Pas de enumeratie op regel 30 van src/server/dll/config.h aan met een identifier voor het toe te voegen niveau, bijvoorbeeld: IP 3. Maak een klasse aan die dit niveau voorstelt (IP.h en IP.cpp). Deze klasse zal een referentie nodig hebben naar de payload van een MACFrame, zie hiervoor bijvoorbeeld MACManagementMessage.h en MACManagementMessage.cpp. 4. Voorzie een methode, bijvoorbeeld int getSourceIP(), die de operatie implementeert. 5. Open src/server/dll/StringMethodMappings.h en pas dit bestand aan zodat de operatie correct gemapt wordt met een methodeoproep. Concreet moet de executeMethod methode aangepast worden: We voegen een ‘if’ toe voor het IP niveau, maken hierin een IP object aan en geven het resultaat van onze getter terug. 6. Compileer de server DLL. Dit kan eenvoudig gebeuren met behulp van het Visual Studio 2003 project.

D.3 Toevoegen filterniveau en -operatie

68

7. De DLL is nu klaar voor gebruik. Voer eventueel CP server.bat uit om automatisch de map op te bouwen met de server executable, vers gecompileerde core DLL en aangepaste XML-configuratie.

BIBLIOGRAFIE

69

Bibliografie [1] Data-Over-Cable Service Interface Specifications (DOCSIS) 2.0, Radio Frequency Interface Specification.

http://www.cablemodem.com/downloads/specs/CM-SP-

RFI2.0-I10-051209.pdf. [2] DOCSIS. http://www.cablemodem.com/. [3] Ethereal, network protocol analyser. http://www.ethereal.com/. [4] International Telecommunications Union Telecommunications Standardization Sector. http://www.itu.int/home/. [5] Jace. http://sourceforge.net/projects/jace/. [6] Java Native Interface. http://java.sun.com/j2se/1.5.0/docs/guide/jni/index.html. [7] TCPDump, Open source capturing API. http://www.tcpdump.org/. [8] Xerces-C, Apache open source XML-bibliotheek. http://xml.apache.org/xerces-c/. [9] Steven De Prest. Ontwerp van grafische user interface voor SNMP monitoring van een DOCSIS netwerk, 2005.

Ontwerp van een downstream (Euro-)DOCSIS protocol analyser

Recommend Documents