Modéliser et simuler (M&S) un système cyber-physique (SCP) peut nécessiter de représenter des éléments provenant de trois domaines d'expertise à la fois : systèmes physiques, systèmes d'informations et réseaux de communication (IP). Le simulateur universel disposant de toutes les compétences nécessaires n'existant pas, il est possible de regrouper des modèles issus des différentes communautés, à l'aide d'un multi-modèle. Les défis sont alors 1) intégrer toute l'hétérogénéité du multi-modèle (formalismes, représentations, implémentations), 2) intégrer des modèles IP de façon à ce qu'ils soient en capacité de représenter le transport de données applicatives produites par des modèles externes et 3) les intégrer de façon à ce qu'ils puissent se compléter, pour représenter ensemble les réseaux IP parfois hétérogènes d'un SCP. Pour parvenir à répondre à ces défis, nous nous inscrivons dans la continuité des travaux de M&S autour de MECSYCO, une plateforme de co-simulation basée sur la notion de wrapping DEVS. Nous proposons de définir un cadre général pour réussir à wrapper en DEVS des modèles IP, avec 1) une structuration des différents niveaux de problèmes pour l'intégration de modèles IP dans une co-simulation (délimitation des objectifs et contraintes du wrapping), et 2) une proposition de stratégie de wrapping DEVS de modèles IP et leurs simulateurs. Nous évaluerons notre approche à travers la démonstration de l'intégration de deux simulateurs IP populaires, et d'exemples concrets de M&S de SCP (avec notamment une interconnexion de modèles entre NS-3 et OMNeT++/INET, et une application industrielle utilisée par EDF R&D) / Modeling and simulation (M&S) of cyber-physical systems (CPS) can require representing components from three expertise fields: physics, information systems, and communication networks (IP). There is no universal simulator with all of the required skills, but we can gather and interconnect models provided by the communities, with a multi-model. The challenges are 1) integrating all heterogeneities in a multi-model (formalisms, representations, implementations), 2) integrating IP models in a way enabling them to represent the transport of application data produced by external models, and 3) integrating IP models in a way enabling them to complete each other, to be able to represent CPS heterogeneous IP networks. In order to meet these challenges, we relied our solution on the works around MECSYCO, a co-simulation platform based on the DEVS wrapping principle. We propose to define a comprehensive framework enabling to achieve DEVS wrapping of IP models, with 1) a structuration of different issue levels when integrating IP models in a co-simulation (goals and constraints of the wrapping) and 2) a proposition of a DEVS wrapping strategy for IP models and their simulators. We propose some evaluations of our approach, through the integration of two popular IP simulators, and concrete examples of CPS M&S (inter alia, with an example of a models interconnection between NS-3 and OMNeT++/INET, and an industrial application used by EDF R&D)

Made available in DSpace on 2016-04-04T18:31:19Z (GMT). No. of bitstreams: 1 Alexandre David Medeiros-1.pdf: 2241104 bytes, checksum: 2474b0cdd4a080e937967b0552c2b175 (MD5) Previous issue date: 2007-06-23 / The telecommunications services quality, as well as several other products in the telecommunications area, is strongly linked to the suppliers services levels quality. These services levels can, however, be measured andevaluated by objective criteria and from a service level agreement between service supplier and customer, this agreement is called SLA. In this study a methodology is proposed for the elaboration of the SLA documentation model, that takes care the business model necessity.This methodology is structuralized in the politics and processes of service quality described by the international norms and standards like Management Forum, ITU, IETF and ITIL. The modeling of the SLA documentation was applied in a practical case of multi-service networks, based in IP networks, resulting in the system specification of the quality service level to be contracted with services supplier. The application of this methodology resulted in improvements for both sides, regarding the reduction in operational costs, the correction of processes and procedures, and a high reliability and transparency in the commercial relation. / A qualidade dos servi?os de telecomunica??es, assim como a de v?rios outros produtos da ?rea de telecomunica??es, est? fortemente ligada aos n?veis de qualidade de servi?os prestados pelos fornecedores. Esses n?veis de servi?os podem, no entanto, ser medidos e avaliados por meio de fatores e crit?rios objetivos, a partir de um N?vel de Servi?o acordado entre o provedor do servi?o e o cliente, chamado de SLA. Neste estudo ? proposta uma metodologia para elabora??o de modelo de documenta??o SLA. Essa metodologia est? estruturada na pol?tica e nos processos de qualidade de servi?o descritos nas normas e padr?es internacionais do TeleManagement Forum, ITU ,IETF e ITIL. A modelagem da documenta??o SLA foi aplicada em um caso pr?tico de rede de multiservi?os, baseada em redes IP, resultando na especifica??o do sistema de n?vel de qualidade de servi?o a ser contratado do provedor de servi?os. Na aplica??o dessa metodologia obteve-se ganhos para ambos os lados, com refer?ncia a redu??o de custo operacional, na corre??o de processos e procedimentos e uma alta confiabilidade e transpar?ncia na rela??o comercial.

Ett icke trivialt IP-nätverk består av många noder som är förbundna med varandra genom olika typer av transmissionsmedier. Man kan föreställa sig nätverket som ett moln av noder och förbindelser. Nätverksvisualisering handlar om att kika in i molnet och snabbt få en övergripande bild över de komplexa relationer som finns i det. Genom att skapa nätverkskartor som grafiskt beskriver ett IP-nätverk kan arbetet med att övervaka och felsöka det underlättas. Telenors svenska nätverksövervakning har utvecklat ett system för att automatiskt generera nätverkskartor i formatet SVG. De har ställt frågan om det går att göra dessa interaktiva och koppla ihop dem med befintliga verktygsprogram. Denna rapport visar exempel på tekniker, baserade på öppen källkod och öppna standarder, som kan användas för att utveckla ett system som gör nätverkskartor i dokumentformatet SVG interaktiva i en webbläsare. Problemet att göra nätverkskartorna interaktiva analyseras och olika lösningsalternativ tas fram och jämförs med varandra. Ett system baserat på öppen mjukvara och öppna standarder utvecklas för att visa hur de redovisade teknikerna kan användas i praktiken. Systemets arkitektur beskrivs i tre systemvyer. Nätverkskartorna berikas med bindningar mellan händelser i webbläsaren och JavaScript-funktioner genom att transformera dem med XSLT. Användargränssnittet utgörs av SVG-objekt och JavaScript varifrån det går att asynkront anropa program på en webbserver. Systemet saknar kopplingar till Telenors verktygsprogram. Flera CGI-skript skapas som visar att det från webbservern går att anropa externa program. Det finns inga funktionella begränsningar som hindrar systemet från att kopplas ihop med verktygsprogrammen. Det implementerade systemet kan användas som en grund för att vidareutveckla ett mer komplett system för interaktiv visualisering av IP-nätverk. Systemets funktionalitet avgränsades och har enabart utvecklats för att fungera väl i webbläsaren Firefox. Om systemet ska användas i skarp miljö måste det impementeras stöd för de populäraste webbläsarna. Systemet innehåller inga funktioner rörande säkerhet, till exempel saknas krypterad förbindelse mellan klient och server. Rapporten avslutas med test och utvärdering av systemet och förslag ges på hur det kan förbättras.

With increasing access to interconnected IP networks, people demand a faster response time from Internet services. Traffic from web browsing, the second most popular service, is particularly time-sensitive. This demands reliability and a guarantee of delivery with a good quality of service from ISPs. Additionally, the majority of the population do not have the technical background to monitor the delay themselves from their home networks, and their ISPs do not have a vantage point to monitor and diagnose network problems from the users’ perspective. Hence, the aim for this research was to characterise the “in-protocol” network delay encountered during web browsing from within a LAN. This research presents TCP traffic monitoring performed on a client device as well as TCP traffic monitoring over both the client-end and the server-end devices separately observing an automated web client/server communication. This was followed by offline analysis of the captured traces where each TCP flow was dissected into: handshake, data transfer, and teardown phases. The aim behind such extraction was to enable characterisation of network round-trip delay as well as network physical delay, end host processing delay, web transfer delay, and packets lost as perceived by the end hosts during data transfer. The outcome of measuring from both end devices showed that monitoring from both ends of a client/server communication results to a more accurate measurement of the genuine delay encountered when packets traverse the network than when measuring from the client-end only. Primarily, this was concluded through the ability to distinguish between the pure network delay and the kernel processing delay experienced during the TCP handshake and teardown. Secondly, it was confirmed that the two RTTs identified in a TCP handshake are not symmetrical and that a TCP teardown RTT takes longer than the TCP handshake RTT within the same TCP flow since a server must take measures to avoid SYN flooding attacks. Thirdly, by monitoring from both end devices, it was possible to identify routing path asymmetries by calculating the physical one-way delay a packet using the forward path in comparison to the physical delay of a packet using the reverse path. Lastly, by monitoring from both end devices, it is possible to distinguish between a packet that was actually lost and a packet that arrived with a higher delay than its subsequent packet during data transfer. Furthermore, utilizing TCP flows to measure the RTT delay excluding end host processing gave a better characterisation of the RTT delay as opposed to using ICMP traffic. / Med ökande tillgång till den sammankopplade IP-nätet, krävs det en snabbare responstid från Internettjänster. Trafik från surfning, den näst mest populära tjänsten är särskilt tidskänsliga. Detta kräver tillförlitlighet och en garanti för data leverans med en god servicekvalitet från Internetleverantörer. Dessutom har de flesta av befolkningen inte den tekniska bakgrunden för att övervaka fördröjning sig från sina hemmanätverk, och deras Internetleverantörer har ingen utsiktspunkt för att övervaka och diagnostisera nätverksproblem från användarnas perspektiv. Därför syftet med denna forskning är att karakterisera “in-protokoll”  fördöljingen i nätet, som påträffas under surfning inifrån ett LAN. Denna forskning visar TCP-trafik monitoring som utförs på en klientenhet, samt separat TCP-trafik monitoring över både klient-end och serve-end enheter, för att observera en automatiserad webbklient / server-kommunikation. Detta följs av offline analys av de infångade tracer där varje TCP flöde dissekerades in: handskakning, dataöverföring, och nedkoppling faser. Syftet bakom sådan utvinning är att möjliggöra karakterisering av nätverk fördröjning samt nätverkets fysiska fördröjning, behandlingsfördröjning, webböverföringsfördröjning och förlorade paket som uppfattas av end-device under dataöverföring. The outcome of measuring from both end devices showed that monitoring from both ends of a client/server communication results to a more accurate measurement of the genuine delay encountered when packets traverse the network than when measuring from the client-end only. Primarily, this was concluded through the ability to distinguish between the pure network delay and the kernel processing delay experienced during the TCP handshake and teardown. Secondly, it was confirmed that the two RTTs identified in a TCP handshake are not symmetrical and that a TCP teardown RTT takes longer than the TCP handshake RTT within the same TCP flow since a server must take measures to avoid SYN flooding attacks. Thirdly, by monitoring from both end devices, it was possible to identify routing path asymmetries by calculating the physical one-way delay a packet using the forward path in comparison to the physical delay of a packet using the reverse path. Lastly, by monitoring from both end devices, it is possible to distinguish between a packet that was actually lost and a packet that arrived with a higher delay than its subsequent packet during data transfer. Furthermore, utilizing TCP flows to measure the RTT delay excluding end host processing gave a better characterisation of the RTT delay as opposed to using ICMP traffic. Resultatet av mätningarna från både slut-enheter visar att övervakning från båda ändar av en klient / server-kommunikation resulterar  en noggrannare mätning av fördröjningar som uppstår när paketen färdas över nätverket än vid mätning från den enda klienten. Främst avslutades detta genom förmågan att skilja mellan den rena nätfördröjningen och kernel bearbetning under TCP handskakning och nedkoppling. För det andra bekräftades att de två RTT som identifierats i en TCP handskakning inte är symmetriska och att TCP nedkoppling RTT är längre än TCP handskakning RTT inom samma TCP flödet, eftersom servern  måste vidta åtgärder för att undvika SYN översvämning attacker. För det tredje, genom att övervaka från båda avancerade enheter, var det möjligt att identifiera path asymmetrier genom att beräkna den fysiska envägsfördröjningen av ett paket på framåtriktade banan i jämförelse med den fysiska fördröjningen för ett paket på den omvända banan. Slutligen genom att övervaka från båda end enheter, är det möjligt att skilja mellan ett paket som faktiskt förlorades och ett paket som kom med en högre fördröjning än dess efterföljande paket under dataöverföring. Dessutom utnyttjande av TCP flöden för att mäta RTT exkluderat end-nod porocessering gav en bättre karakterisering av RTT fördröjning jämfört med att ICMP-trafik.