The dependability of an IP network how to assess it? Ilkka Norros, Urho Pulkkinen, Pertti Raatikainen and Eija Myötyri - PDF

The dependability of an IP network how to assess it? Ilkka Norros, Urho Pulkkinen, Pertti Raatikainen and Eija Myötyri The final report of the IPLU project January 9, (39) Contents: 1 Introduction...3

Please download to get full document.

View again

of 23
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.


Publish on:

Views: 44 | Pages: 23

Extension: PDF | Download: 0

The dependability of an IP network how to assess it? Ilkka Norros, Urho Pulkkinen, Pertti Raatikainen and Eija Myötyri The final report of the IPLU project January 9, 2007 2(39) Contents: 1 Introduction About this document and the IPLU project IPLU's approach to the dependability of a ubiquitous IP infrastructure The structure of this document Definitions Networking Actors Dependability A system look at the dependability of IP networks Dependability indices and requirements General remarks Qualitative requirements Criticality of services Qualitative redundancy requirements Security Personnel qualification Indices and quantitative requirements Downtime-frequency curves On/off-availability and quality-availability Focused availability indices Component level reliability Other network dependability indices Security Robustness Traffic statistics Indices related to operating personnel Reliability analysis Qualitative reliability analyses Failure modes, effects and criticality analysis (FMECA, FMEA) Operating experience analysis Quantitative reliability analysis Elements of system reliability modelling Challenges of IP-network reliability analysis Prerequisites of quantitative reliability modelling of IP-networks Example Dependability case Background and general principles Elements of a dependability case Implementation of dependability case for IP-networks An example of dependability case Conclusions and suggestions...37 References...38 3(39) 1 Introduction 1.1 About this document and the IPLU project This document is the final report of the Finnish IPLU project in 2006 (see IPLU's task was to create a conceptual framework for considering the complex problem Can one rely on IP technology? and to identify and develop methods for assessing the dependability of IP networks. This report presents the conclusions and recommendations of IPLU. Other major deliverables of the project are the following: IPLU's baseline paper The dependability of an IP network what is it? IP-verkkojen luotettavuus - mitä se on? A public seminar organized by IPLU on May 17, 2006 (in Finnish) Dependability of All-IP networks A multidisciplinary international workshop organized by IPLU on May 18-19, 2006 Kari Seppänen: Resiliency in Ethernet Based Transport Networks Pertti Raatikainen: Next Generation Network and Reliability 1.2 IPLU's approach to the dependability of a ubiquitous IP infrastructure A project like IPLU was felt necessary because of the deep changes that are now happening in the telecommunications infrastructure when legacy networks are being replaced by IP networks. Classical telephone networks and television broadcasting are vitally important infrastructures, and with all the grandeur of IP technology, stability and reliability have not belonged to its foremost attributes. The following theses, debatable of course, present our concerns in more detail: the significance of IP networking has already grown tremendously, but the convergence towards All-IP is making it a still more critical infrastructure in longer run, everybody should have a reliable IP connection at a reasonable price the slogan that the network would disappear from the user's perception is deeply misleading - the future user also needs network literacy dependability is the Achilles' heel of the All-IP vision the present situation is not a stable one but one of deep-going changes A broad, multidisciplinary approach was considered necessary from the start, because the number of relevant aspects and points of view to the problem is large, and we wanted to see more specific problem areas within a holistic map. The following picture from IPLU's baseline paper presents the aspects of dependability (ovals) that were found most relevant in this context, together with the generic actors (rectangles) who are concerned with or taking care of these aspects. 4(39) Regulator User Provider availability reliability mai ntainability controllability Designer failures errors attacks invulnerability robustness The notion of dependability and the somewhat unusual selection of its main aspects adopted here are discussed in detail in the baseline paper. The following remarks explain the main activities that the picture hints to: the User's basic requirement is the availability of connectivity to the global Internet the Provider, who in this picture combines the roles of Operator and Manufacturer, makes his best to provide this availability by taking care of the reliability and maintainability of the networks, utilizing also the existing degree of controllability of network traffic behaviour the Designer is the collective acronym for the research and standardization activities that create the network protocols aiming at robustness and invulnerability the Regulator imposes rules to the Provider that force the latter to maintain the dependability of the networks at a level considered sufficient These additional remarks clarify our focus further: security is seen mainly as an enabler for invulnerability quality and availability do not have a sharp boundary, sufficiently bad quality can be considered as unavailability the reason for traffic congestion causing bad quality or unavailability may be the Provider's bad dimensioning or a lack of controllability to which the Designer is responsible also Multidisciplinarity was needed to combine the expertises in telecommunications technologies with those in safety and reliability. As its main (though tentative) proposal, IPLU developed the Dependability Case methodology that makes it possible to combine a heterogeneous set of relevant requirements, facts, tools, techniques etc. into an organized whole around a claim about a network. The methodology is an adaptation of the Safety Case methodology used in contexts like nuclear power but new in the world of networking. In the next phase, the multidisciplinarity should be further extended to include the expertises related to human activity, the users' (see [8]) as well as the telecom operators', and media theory (e.g. [17], [12]), considering global IP connectivity as a generic medium of future. 5(39) 1.3 The structure of this document Chapter 2 specifies the terminology used in the sequel Chapter 3 discusses the character of the IP infrastructure from a system analytic point of view Chapter 4 considers different kinds of requirements and computable indices for formulation of quantitative requirements Chapter 5 gives an overview of various techniques and procedures of dependability analysis Chapter 6 proposes a general method for setting and verifying dependability requirements in the multi-actor scenario Chapter 7 summarizes IPLU's conclusions and suggestions 6(39) 2 Definitions In this document we use the following terminology. Interpretations of central terms also define the scope of the IPLU project. 2.1 Networking IP network: a network that uses Internet Protocol to carry data Internet: the globally connected set of autonomously operated IP networks Access network: the part of a transport network that connects the end-user devices to the network IP connectivity: ability to have an end-to-end connection from an IP interface to another IP interface between two terminals: IP packets are transmitted correctly; of one user: the user's access transmits IP packets correctly to and from the Internet Virtual Private Network: a set of layer 2 and/or layer 3 tunnels that provide connectivity between sites of a user organisation separated from connectivity of other organisations Transport: in this document all functionality that transfers an IP packet from an IP interface to another without inspecting the IP header; in practice, transport involves protocol layers below the IP layer, i.e. physical signal transport, MAC and link layers as well as possible intermediate layers, such as MPLS Telephone: (i) POTS, GSM, UMTS; (ii) various VoIP services Television: public audiovisual broadcast service 2.2 Actors Individual user: human individual, possibly with several IP access potentials and home network Corporate user: organization with IP access; may have corporate network and/or VPN Telecom operator: an organisation providing carrier service for end-users or virtual operators Internet service provider: an organisation that provides Internet access to end-users Content provider: an organisation that provides services to end-users or telecom operators; examples of possible services are shopping, web surfing, chat rooms, playing games, accessing data, music or books, TV programs; from the network point of view, content provider is a corporate user Regulator: authority with law-enforced power to set requirements on networks and their operation practices Manufacturer: producer of (i) networking equipment, (ii) terminal equipment, (iii) networking software 7(39) Designer: research, standardization (generic term for people and institutions who create network algorithms and protocols; non-standard term) 2.3 Dependability Dependability: An integrating concept encompassing several attributes. In this report we apply the approach developed in [2], see Section 1.2 above. Some variations: Avizienis et al [4]: availability, reliability, safety, integrity, maintainability ASC, IEC [1]: reliability performance, maintainability performance and maintainability support performance Villemeur [30]: reliability, availability, maintainability, safety Dependence: dependence of system A on system B represents the extent to which System A s dependability is or would be affected by that of System B [4] Trust: accepted dependence [4] Availability: readiness for correct service [4] Reliability: (i) wide sense: about same as dependability; (ii) continuity of correct service [4] Maintainability: ability to undergo modifications and repairs [4] Robustness: a property of algorithms and protocols, meaning stability with respect to arbitrary inputs; more generally [4]: dependability with respect to external faults Vulnerability: possibility of behaviour that leads to serious degradation of performance by a cause that comes from outside of the system s normal constituents Controllability: in our context, characterized by the possibilities of single agents (mainly the telecom operators) to accept, reject, or route traffic offered to the network, and to open and close individual services or the whole network Security: integrity of information and confidentiality, absence of unauthorized disclosure of information, and availability for authorized actions [4] Redundancy: system s property to possess multiple, more or less independent ways to realise its service Failure: transition of a component or system to a state where it does not any more deliver its correct service (a failure is rather on the surface, its cause being somewhere deeper ) [4] Error: deviation of a state of the system from its correct service state (need not be manifested) [4] Fault: cause of an error [4] Resilience: fault tolerance [4] 8(39) 3 A system look at the dependability of IP networks This chapter presents some general facts and thoughts about what kind of system we are studying when we want to consider the dependability of IP networks as a whole. First, the basic service provided by this system is to transfer a data packet from any access point to any other access point. This task is conceptually very simple and natural. Whatever developments we shall meet in future telecommunications, it is hard to think that the global packet transfer service now realised by the Internet would ever become obsolete. Second, the service of the system is provided by the collaboration of autonomously owned and operated subsystems that are connected in a highly complex way. The topology of the network of autonomous systems was characterized as soft hierarchy by Reittu and Norros [23]. The autonomous systems share a few common resources like the Domain Name System and authorities like the Internet Assigned Numbers Authority. The dependability of this supersystem is a complex problem with technical, commercial and political dimensions. From a purely topological point of view however, the soft hierarchy structure is extremely resilient (Reittu [24]). Third, coming to the national level in Finland, the system consists of a few independently owned and operated transport networks and a larger number of additional Internet Service Providers who mainly hire the transmission links from the previously mentioned ones. The ISPs exchange traffic mostly within a single institution, the national exchange point Ficix. International connections are not provided by Ficix, but all major ISPs maintain their own international links. National regulations are issued by Finnish Communications Regulatory Authority (Ficora). Fourth, at the level of a major IP telecom operator, the network can be clearly divided into a core network and access networks attached to it (the higher parts of access networks may also be called by more specific terms, for example metropolitan area networks). The core networks have redundant topology, whereas the access networks have typically, perhaps with the exception of their higher, metropolitan level, a tree topology. The IP traffic carried by a mobile telephone network is typically carried within the mobile network infrastructure to one (or a few) router(s) connected with an IP core network. Fifth, the usage of the IP service requires a variable number of auxiliary services that are implemented in servers and must be available as well as properly configured: DNS, DHCP, authentication. Sixth, the transmission networks and link layers of user access technologies are and will be very heterogeneous and have further layered structures. They are complicated systems that are configured by the telecom operators' highly qualified personnel. The increasingly popular Ethernet networking seems to be a particularly error-prone and vulnerable technology (Seppänen [26]). Seventh, the use of IP packet transfer to real-time services like telephony and television requires not only the functioning of the respective application layer systems but also the availability of quality at the IP layer in terms of bandwidth and delay. It is important to realise that the basic design of IP networking does not include quality provisioning as an inherent feature. IP routing protocols and 9(39) TCP traffic control have built-in robustness in their design, whereas quality provisioning is essentially more complicated and usually limited within autonomous systems. Eighth, all digital networking requires electricity. Without dedicated efforts, the IP networking vanishes together with electricity, unlike the traditional telephone network which carries the needed power to the terminals. From this description, we can draw some characterizations of the system: is it a hard or soft system, is it complex, and what are its control mechanisms like? 1. The system is not a single though huge machine in the sense in which such a characterization might still have applied to the world-wide POTS. The dependability concerns of pure telephone networks focus on protection switching, reliability of switches and components, and the availability and securing of electricity supply. IP networking should rather be analysed as a soft system in terms of Checkland [9], driven by a large number of organizations and renewing continuously its technological base. New protocols are introduced and existing ones have frequent version updates. Traditional reliability analysis and hard system theory are meaningful for various technological subsystems, but for the total system, which also contains several relevant human activity systems: the users' activities where universal IP connectivity is used as a generic medium: the dependability requirements depend on the actual usage of different applications that pose different requirements on the IP network, and in this respect the situation is continuously changing in unpredictable ways the reflection of users' requirements in legislation and regulations the telecom operators' competition and collaboration the human operators' work 2. Is our system complex? The answer is not as unconditional yes in every respect as one might think at first sight. Despite the huge size of the system, the system seems to have so much hierarchy and modularity that meaningful reliability analyses of abstracted subsystems are possible. As a purely technical system, the TCP/IP layer network is not an extremely complex system, if all components, including software components, are modelled as binary ones (functioning or not). Indeed, the fulfilment of a set of conditions that are all necessary is logically simple and corresponds to a series system. Possibly the transmission networks are in fact more complex than the IP layer. Interworking for connecting services is greatly facilitated by concentrating it on IP layer. On the other hand, routers are sophisticated computers with complicated potential behaviours, and detailed analysis of failure modes of distributed software components of IP networking would be a very complex task. Thus, the question on the complexity of the IP networks depends on the level of detail. 3. As regards control, the total system is obviously not operatively controlled by anybody. In longer timescale, the system develops in complex ways and surprises abound. Main dynamic control tools available for an operator are traffic engineering on one hand and traffic filtering, i.e. the removal of unwanted traffic from the network on the other hand. 10(39) 4 Dependability indices and requirements 4.1 General remarks Dependability requirements set for a telecommunication network (or part of it) are requirements set on observable characteristics of various aspects of the dependability of that (part of the) network. Requirements can be set by the User, by the Regulator or by the network Provider itself. They may be specified in regulations or in agreements between User and Provider or between two Providers. Dependability requirements can be either qualitative or quantitative. We discuss below both types and suggest some for further consideration. By a dependability index for a telecommunication network (or part of it) we mean a summarizing quantitative characteristic of some aspect of the dependability of that (part of the) network. Obviously, quantitative dependability requirements should concern only indices that are measurable. The following table shows what actor (column) is expected to set requirements on what aspect of dependability (row) to what actor (table entry). User Operator Manufacturer Designer Regulator Availability Operator Operator 2 Operator Reliability Manufacturer (terminal) self Manufacturer Maintainability Manufacturer (terminal) self Manufacturer Manufacturer 2 Robustness Designer Designer self Operator Operator Controllability Operator Manufacturer Designer self Operator Invulnerability Operator User Operator Manufacturer Designer self Operator Manufacturer Designer 4.2 Qualitative requirements Criticality of services It is natural to require that the most critical functions of the society should be best protected and secured. Various critical infrastructures tend to become more and more tightly interlinked with the communication infrastructure (for the status of critical information infrastructure research in Europe, see [10]). The development of the latter is in turn characterized by the growing role of IP networking. This prospect poses serious concerns, because the regulations can only follow the actual developments with the delay of a few years. 11(39) IP-based services appear that are in the beginning more like a curiosity or just fun, but because of their cheapness and often good quality they have the potential to grow within a short time to dominant role. Toys become serious tools, and legacy tools get antiquated. A big part of the users can well accept services that have inferior de
Related Search
Similar documents
View more...
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks