Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Deep packet inspection wikipedia , lookup
Piggybacking (Internet access) wikipedia , lookup
Distributed firewall wikipedia , lookup
Computer network wikipedia , lookup
Wake-on-LAN wikipedia , lookup
Zero-configuration networking wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Network tap wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
List of wireless community networks by region wikipedia , lookup
정보통신단체표준(영문표준) TTAE.xx-xx.xxxx 제정일: 2014년 xx월 xx일 TTA 소프트웨어 정의 네트워킹을 위한 정형 명세 기법 요구사항 Standard Requirements for applying formal methods to software-defined networking 정보통신단체표준(영문표준) TTAE.xx-xx.xxxx 제정일: 2014년 xx월 xx 일 소프트웨어 정의 네트워킹을 위한 정형 명세 기법 요구사항 Requirements for applying formal methods to softwaredefined networking 본 문서에 대한 저작권은 TTA 에 있으며, TTA 와 사전 협의 없이 이 문서의 전체 또는 일부를 상업적 목적으로 복제 또는 배포해서는 안 됩니다. Copyrightⓒ Telecommunications Technology Association 2014. All Rights Reserved. 정보통신단체표준(영문표준) 서 문 1. 표준의 목적 본 표준은 ITU-T SG13 에서 Y.3320 으로 제정된 소프트웨어 정의 네트워킹을 위한 정형 명세 및 검증 요구사항을 정의한 것이다. 2. 주요 내용 요약 본 표준은 소프트웨어 정의 네트워킹 (Software-defined networking; SDN) 기술에서 SDN 응용 및 시스템을 구현, 개발 및 검증하기 위한 정형 기법을 기술하고, 이에 따른 기능적 요구사항을 정의한다. 아울러 본 표준에서는 정형 기법을 이용한 SDN 응용 검증 예제를 부록으로 제시한다. 3. 표준 적용 산업 분야 및 산업에 미치는 영향 본 표준은 소프트웨어 정의 네트워킹 (SDN) 기술에서 네트워크 정책을 정의하는 SDN 응용의 기술 및 검증을 소개하고 이에 따른 요구사항을 정의한다. 기존의 네트워크 기술은 분산된 하드웨어에 제어 기능이 개별 관리되는 비유연성 구조를 기반으로 하는데 반해, SDN 기술은 제어 기능을 별도로 분리하여 중앙 집중식으로 관리함으로써 데이터 전송만 담당하는 분산 하드웨어를 적시에 제어 가능한 유연한 네트워크 구조를 제공한다. SDN 기술을 이용하면 서비스 제공자가 가상적으로 분리된 네트워크 자원을 서비스의 특성과 상황에 따라 동적으로 제어할 수 있다. 이러한 네트워크 제어 정책은 개발자 및 관리자에 의해 SDN 응용으로 개발 및 적용되나 해당 응용의 오류에 의해 전체 네트워크가 통제 불능에 빠질 수 있다. 따라서, 본 표준에서 기술된 정형 명세 및 검증을 통해 SDN 응용의 적용 이전에 그 유효성과 안정성을 시험 및 검증하는 작업이 필요하다. 이를 통해 안정적이고 고품질의 서비스 제공이 가능해지고, 나아가 통신망 사업자와 서비스 제공자간의 새로운 비즈니스 생태계가 창출될 수 있다. 뿐만 아니라 통신망 사업자로 하여금 능동적이고 자동화된 네트워크 자원 통제 및 관리를 가능케 함으로써 통신망의 관리 비용 절감과 함께 돌발 상황 대응에 따른 민첩성 향상 효과를 얻을 수 있다. i TTAx.xx.xxxx 정보통신단체표준(영문표준) 4. 참조 표준(권고) 4.1. 국외 표준(권고) - ITU-T Recommendation Y.3320, ‘Requirements for applying formal methods to software-defined networking’, 2014. 4.2. 국내 표준 - 해당 사항 없음 5. 참조 표준(권고)과의 비교 5.1. 참조 표준(권고)과의 관련성 본 표준은 참조 표준을 영문 그대로 완전 수용하는 표준이다. 5.2. 참조한 표준(권고)과 본 표준의 비교표 TTAx.xx-xx.xxxx ITU-T Y3320 비고 1. 문서 범위 1. Scope 동일 2. 참고 문헌 2. References 동일 3. 용어 정의 3. Definitions 동일 4. 약어 4. Abbreviations and acronyms 동일 5. 문서 규칙 5. Conventions 동일 6. 소개 6. Introduction 동일 7. 개요 7. Overview 동일 8. 요구사항 8. Requirements 동일 9. 환경 고려사항 9. Environmental considerations 동일 10. 보안 고려사항 10. Security Considerations 동일 부록 I. 네트워킹 정형 검증 개요 Appendix I. Areas for further considerations in SDN standardization ii 동일 TTAx.xx.xxxx 정보통신단체표준(영문표준) 6. 지식 재산권 관련 사항 본 표준의 ‘지식 재산권 확약서’ 제출 현황은 TTA 웹사이트에서 확인할 수 있다. ※본 표준을 이용하는 자는 이용함에 있어 지식 재산권이 포함되어 있을 수 있으므로, 확인 후 이용한다. ※본 표준과 관련하여 접수된 확약서 이외에도 지식 재산권이 존재할 수 있다. 7. 시험 인증 관련 사항 7.1. 시험 인증 대상 여부 - 해당 사항 없음 7.2. 시험 표준 제정 현황 - 해당 사항 없음 8. 표준의 이력 정보 8.1. 표준의 이력 판수 제정·개정일 제정·개정 내역 제1판 2014.xx.xx 제정 TTAx.xx-xx.xxxx 8.2. 주요 개정 사항 - 해당 사항 없음 iii TTAx.xx.xxxx 정보통신단체표준(영문표준) Preface 1. Purpose of Standard This standard describes the requirements for applying formal methods to softwaredefined networking defined in ITU-T Recommendation Y.3320. This standard is intended to adopt the specification as TTA English standards. 2. Summary of Contents This standard describes requirements for using formal methods, mathematics-based techniques to specify, develop, and verify software and hardware systems, in the context of software-defined networking (SDN) for Future Networks. 3. Applicable Fields of Industry and its Effect This standard can be applied to SDN-enabled networks and applications that exploits programmability and resource abstraction capability of SDN. 4. Reference Standards(Recommendations) 4.1. International Standards(Recommendations) - ITU-T Recommendation Y.3320, “Requirements for applying formal methods to software-defined networking”, 2014. 4.2. Domestic Standards - None iv TTAx.xx.xxxx 정보통신단체표준(영문표준) 5. Relationship to Reference Standards(Recommendations) 5.1. Relationship of Reference Standards(Recommendations) This standard is fully equivalent to the ITU-T Recommendation Y.3320. 5.2. Differences between Reference Standard(Recommendation) and this Standard TTAx.xx-xx.xxxx ITU-T Y3320 Remarks 1. Scope 1. Scope equivalent 2. References 2. References equivalent 3. Definitions 3. Definitions equivalent 4. Abbreviations and acronyms 4. Abbreviations and acronyms equivalent 5. Conventions 5. Conventions equivalent 6. Introduction 6. Introduction equivalent 7. Overview 7. Overview equivalent 8. Requirements 8. Requirements equivalent 9. Environmental considerations 9. Environmental considerations equivalent 10. Security Considerations 10. Security Considerations equivalent Appendix I. considerations standardization Areas for in further Appendix I. SDN considerations Areas for further in SDN equivalent standardization 6. Statement of Intellectual Property Rights IPRs related to the present document may have been declared to TTA. The information pertaining to these IPRs, if any, is available on the TTA Website. No guarantee can be given as to the existence of other IPRs not referenced on the TTA website. And, please make sure to check before applying the standard. v TTAx.xx.xxxx 정보통신단체표준(영문표준) 7. Statement of Testing and Certification 7.1. Object of Testing and Certification - None 7.2. Standards of Testing and Certification - None 8. History of Standard 8.1. Change History Edition Issued date Outline The 1st edition 2014.xx.xx Established TTAx.xx-xx.xxxx 8.2. Revisions - None vi TTAx.xx.xxxx 정보통신단체표준(영문표준) 목 차 1. 문서 범위 ····················································································· 1 2. 참고 문헌 ····················································································· 1 3. 용어 정의 ····················································································· 2 4. 약어 ·························································································· 2 5. 문서 규칙 ···················································································· 2 6. 소개 ·························································································· 3 7. 개요 ···························································································· 4 8. 요구사항 ······················································································ 6 9. 환경 고려사항 ··············································································· 9 10. 보안 고려사항 ············································································ 10 부록 1. 네트워킹 정형 검증 개요 ··························································· 11 vii TTAx.xx.xxxx 정보통신단체표준(영문표준) Contents 1. Scope·························································································· 1 2. References ·················································································· 1 3. Definitions ···················································································· 2 4. Abbreviations and acronyms ····························································· 2 5. Conventions ················································································· 2 6. Introduction ················································································· 3 7. Overview ····················································································· 4 8. Requirements ··············································································· 6 9. Environmental considerations ···························································· 9 10. Security Considerations ·································································· 10 Appendix I. Areas for further considerations in SDN standardization ················· 11 viii TTAx.xx.xxxx 정보통신단체표준(영문표준) 소프트웨어 정의 네트워킹을 위한 정형 명세 및 검증 요구사항 (Requirements for applying formal methods to software-defined networking) 1. Scope This Recommendation describes requirements for using formal methods, mathematics-based techniques to specify, develop, and verify software and hardware systems, in the context of software-defined networking (SDN) for Future Networks. The scope of this Recommendation covers: - Overview of formal methods (formal specification and formal verification) for SDN, and - Requirements for applying formal methods to SDN In Appendix, an example of how to apply formal methods to SDN is provided. 2. References The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation. [ITU-T Y.3001] Recommendation ITU-T Y.3001 (2011), Future Networks: Objectives and Design Goals. [ITU-T Y.3011] Recommendation ITU-T Y.3011 (2012), Framework of network virtualization for Future Networks. 1 TTAx.xx.xxxx 정보통신단체표준(영문표준) [ITU-T Y.3300] Recommendation ITU-T Y.3300 (2014), Framework of software-defined networking. 3. Definitions 3.1 Terms defined elsewhere This document uses the following terms defined elsewhere: 3.1.1 future network (FN) [ITU-T Y.3001]: A network able to provide services, capabilities, and facilities difficult to provide using existing network technologies. 3.1.2 network virtualization [ITU-T Y.3011]: A technology that enables the creation of logically isolated network partitions over shared physical networks so that heterogeneous collection of multiple virtual networks can simultaneously coexist over the shared networks. This includes the aggregation of multiple resources in a provider and appearing as a single resource. 3.1.3 software-defined networking [ITU-T Y.3300]: A set of techniques that enables to directly program, orchestrate, control and manage network resources, which facilitates the design, delivery and operation of network services in a dynamic and scalable manner. 3.2 Terms defined in this document None. 4. Abbreviations and acronyms This document uses the following abbreviations and acronyms: FN Future Network SDN Software-Defined Networking 5. Conventions In this Recommendation, the following conventions are used: The keywords "is required" indicate a requirement which must be strictly followed and from which no deviation is permitted, if conformance to this Recommendation is to be claimed. The keywords "is recommended" indicate a requirement which is recommended but which is not absolutely required. Thus this requirement need not be present to claim conformance. 2 TTAx.xx.xxxx 정보통신단체표준(영문표준) The keywords "can optionally" indicate an optional requirement which is permissible, without implying any sense of being recommended. This term is not intended to imply that the vendor's implementation must provide the option and the feature can be optionally enabled by the network operator/service provider. Rather, it means the vendor may optionally provide the feature and still claim conformance with the specification. 6. Introduction Formal methods are software engineering techniques based on the mathematical representation and analysis of software programs and/or hardware. They include formal specification, analysis of specification, and formal verification of software and/or hardware behaviour [b-Clarke]. The formal specification describes semantics of a system using mathematical representation. The formal verification is the act of proving or disproving the correctness of designs or implementations with respect to formal specification. The Recommendation Y.3001 - “Future Networks: Objectives and Design Goals,” describes objectives and design goals for future networks identifying high-level capabilities and characteristics need to be supported by future networks [ITU-T Y.3001]. To design and implement systems that conform to the design goals of the Recommendation, the structure and behaviour of the systems need to be described in a way to prevent from misinterpreting of the intended meanings and to avoid inconsistency in the systems. FNs may be used for mission critical systems and/or other areas, such as private clouds and data centers, where those systems show strong requirements for reliability and consistency, otherwise catastrophic disaster could occur. On the other hand, the Recommendation Y.3300 – “Framework for softwaredefined networking” describes the fundamentals of SDN. It is a new networking approach that enables to directly program, orchestrate and control network resources, and network abstraction into their networks that manage the virtualization of the networks [ITU-T Y.3011] [ITU-T Y.3300]. SDN facilitates network operators introduce new capabilities by writing simple software programs that control their network in a programmable way. In SDN based networks, it becomes important to check the consistency and safety properties before the installation or deployment of these programs into the network. As described previously, an effective approach in order to increase reliability and reduce any misunderstanding or inconsistency of the meaning 3 TTAx.xx.xxxx 정보통신단체표준(영문표준) of the systems or programs is the adoption of formal methods. They help network operators and application developers protect their systems from unexpected errors that deployment process. 7. could not be caught during development and Overview of formal methods for software-defined networking Figure 1 illustrates the overall flow from informal description such as conceptual model, logical design, and domain specific network specification to implementation of a system using formal methods. Figure 1. Overall flow of formal methods Traditional methods of realizing network protocols and devices are based on community agreements of informal descriptions of such mechanisms [bGriffin]. As depicted in Figure 1, those methods can be improved by applying formal methods in the development process of software-defined networking [b-Wang]. Targets of specification can conceptually model components or mechanisms, logical switch/router models, network protocols, topologies of virtual networks, and so on. Informal descriptions of those targets can be encoded in formal specification languages that can reflect the features of targets of the existing methods. The formal specification can be textual or graphical form to represent their semantics. Once the specifications are described formally, system and network designer can check the existence of inconsistencies and possible errors in the 4 TTAx.xx.xxxx 정보통신단체표준(영문표준) specification with the help of formal methods experts and/or supporting tools. Various types of formal verification methods (e.g., theorem proving, model checking and static analysis) can be applied to the validation and verification process. The high-level architecture of SDN consists of four layers as defined in the Recommendation Y.3300 [ITU-T Y.3300]. - Application layer - SDN control layer - Resource layer, and - Multi-layer management functions In order to provide formal methods support in SDN, additional function named formal methods component becomes necessary to process for the formal specification and verification as illustrated in Figure 2. The formal specification function provides application-formal methods interface for SDN applications to express their semantics in a formal representation. The formal verification function provides control-formal methods interface for SDN controller to check whether new semantics can cause any errors or operational conflicts within the network. Management Application Application-formal methods interface Application Formal specification Application-control interface Application Support Formal Methods Component Orchestration Abstraction Control-formal methods interface Formal verification Resource-control interface Control Support Data Transport and Processing Figure 2. High-level SDN architecture with formal methods component The formal methods component supports different modes of operation which corresponds to off-line and on-line mode. In the off-line operation mode, the formal methods component receives a request from applications via application-formal methods interface and performs necessary functions to process the specification or verification without interactions with SDN controller. On the other hand, in the on-line operation mode, the formal 5 TTAx.xx.xxxx 정보통신단체표준(영문표준) methods component receives a request from SDN controller via control-formal methods interface during the runtime of the network. Figure 3 illustrates operational procedures of these different modes. SDN controller Application 1. Request verification applicationformal methods interface Formal Method Component 3. Reply verification result 1. Request verification controlformal methods interface Formal Method Component Formal verification 2. Process verification 3. Reply verification result 4. Install rules If verified successfully Formal verification 2. Process verification SDN resources (switchs) (a) off-line mode (b) on-line mode Figure 3. Two modes of formal verification 8. Requirements This section identifies a set of functional requirements that need to be supported by the formal methods component in SDN. 8.1 General Requirements GR-1: It is recommended that the formal methods component guarantees the design and implementation of programmable network resources conforms to the standards, correctness and safety properties. Note: -Programmable network resources can be customized in software or hardware, or combination of them, depending on the requirements from service providers, application/service developers, network operators, to produce optimal solution for their uses. GR-2: It is required that the formal methods component provides open interfaces to interact with application and/or SDN controller. Note: 6 TTAx.xx.xxxx 정보통신단체표준(영문표준) -Application and/or SDN controller sends requests to use formal specification and/or verification functions provided by the formal methods component. -After performing the specification or verification process, the formal methods component sends results back to application, and SDN controller. GR-3: It is recommended that the formal methods component supports policies or rules required by applications in heterogeneous network environments. Note: -Control and management entities that span across SDN-based networks which is owned by different stake-holders, management authorities, or vendors, need to be controlled in distributed environments by nature. Multiple entities may need to be coordinated to conform to the higher level requirements of heterogeneous networks. GR-4: It is recommended that the formal methods component supports the authentication and authorization to confirm the identity and access right of users. 8.2 Requirements of Formal Specification FS-1: It is recommended that the formal methods component supports formal syntax and semantics in high-level languages, APIs and underlying protocols for SDN. Note: -High-level languages that interface with control and management entities need to have formal semantics to avoid any confusion in the interpretation of underlying mechanism and/or network configuration. -Specifications of programmable network devices such as switches, and protocols for controlling those devices need to be proved safe and consistent to provide stable foundation of the SDN application and services. -Properties that need to be satisfied with SDN should be described in notations with formal semantics -Action or a set of actions associated with target properties need to be described in notations with formal semantics. Some examples of 7 TTAx.xx.xxxx 정보통신단체표준(영문표준) actions can be packet forwarding, packet modifications, group table or pipeline processing. FS-2: It is recommended the formal methods component supports a conceptual model to reason properties and behaviors about networks defined, configured, implemented by software and/or hardware for SDN. 8.3 Requirements of Formal Verification 8.3.1 Consistency and Safety FV-1: It is required that the formal methods component checks consistency and safety of network configurations, virtual/physical topologies, and network resources intended properties. Note: Examples of intended properties are the followings. -No routing loops and/or non-reachable points in the network -No conflicts between logical and physical networking resource assignment for applications, and -No conflicts in dynamic network update where new or update configurations conforms to properties of the network and do not break consistency of existing networks FV-2: It is required that the formal methods component checks consistency of application and policies against conflicts that can occur between SDN entities or in network configurations. Note: Examples of conflicts are the followings. -Rule or behaviour conflicts between multiple applications in a controller 8.3.2 Operations FV-3: It is recommended that the formal methods component supports different verification modes (e.g., off-line mode and on-line mode) and different verification methodologies (e.g., symbolic or nonsymbolic manners) FV-4: For the symbolic verification methodology, it is recommended that the formal methods component supports symbolic model checking technologies in order to verify whether the application meets the specification. 8 TTAx.xx.xxxx 정보통신단체표준(영문표준) FV-5: The formal verification component can optionally support the following operations. -Collecting the information of network topology and data forwarding paths (e.g., a flow table in OpenFlow [b-ONF]) from a SDN controller -Creating description code in a predefined formal language based on the collected information and generating a symbolic transition graph using the created description code in the formal language. -Applying verification operation to the created transition graph, and -Providing verification results in the formula based on the Boolean expression (e.g., binary decision diagram or conjunctive normal form). 8.3.3 Resource information discovery FV-6: It is required that the formal methods component obtains the information on network resources and SDN entities including static information (e.g., network topology and capability of SDN entities) and dynamic information (e.g., re-configured topology and status of SDN entities). FV-7: It is recommended that the formal methods component obtains the entire network topology information within an administrative domain from SDN controller(s). 8.4 Miscellaneous Mic-1: The formal methods component can optionally provide statistics about the verification process such as summary of verification results, processing time, and other performance data. 9 Environmental considerations The formal methods for SDN reduce any inconsistency or ambiguity of SDN applications by enabling the application specified and verified before an execution in the network. It can prevent malfunctions, misuses, and unexpected behaviour of SDN applications so that it is likely to optimize the resource usage, which reduces energy consumption. However, the verification process requires additional computational resources to examine SDN applications in the network, and its energy consumption may increase. 9 TTAx.xx.xxxx 정보통신단체표준(영문표준) 10 Security considerations SDN facilitates network operators control their networks in an automatic and programmable way. In other words, SDN network operators including application developers can introduce a new capability by writing a program. Many important properties such as programmability, reliability, flexibility, and customization of network resources, need to be supported by SDN. However, those properties can cause unexpected security problems in the SDN environments since incomplete or malicious programs can also be introduced easily into the networks. In this sense, these malicious programs need to be thoroughly examined before the installation to the networks. For SDN, therefore, the usage of formal methods can be an effective approach to check their correct operations and avoid possible inconsistency or misinterpretation of their networking behaviours. Security issues, therefore, should be considered and resolved during formal specification and verification stage. 10 TTAx.xx.xxxx 정보통신단체표준(영문표준) Appendix I Overview of formal methods for networking The objective of this clause is to give an example to show how formal specification and verification process can be applied to SDN. In SDN environments, consistency and safety are important to help ensure that errors or operational conflicts are not introduced into the networks. In this sense, formal methods are effective in specification and verification of applications or programs to avoid inconsistency or misinterpretation of their networking behaviours. In order to avoid implementation dependency to describe the example of this clause, logical functional descriptions are used to describe their behaviours and operations related to formal specification and verification. 1. High level operational model of SDN with formal methods Figure I.1 illustrates a high level operational model of SDN including the formal methods tool that provides the specification syntax and semantics for applications, and the verification procedures to check their operational behaviours within the networks. The following assumptions are considered in this example [b-Canini]. - It is an OpenFlow based SDN environment where the OpenFlow protocol (version 1.0 ~ 1.3) is used for communication between the controller and switches. - The controller manages the OpenFlow based global network information and it needs to provide this global network information when it receives a request from the formal methods tool. - The formal description code considered in this section is based on the fields defined in the OpenFlow protocol. 11 TTAx.xx.xxxx 정보통신단체표준(영문표준) App App App App Applicationformal methods interface Formal Methods Tool Formal specification Control-formal methods interface SDN controller Global network view (OF based flow entry) Formal verification OpenFLow protocol SDN switch SDN switch SDN switch SDN switch SDN switch Figure I.1 High level operational model 2. Formal Specification Tool Applications need to express their policies or rules in a formal specification supported by the formal methods tool. The formal specification is a representation expressed in a language whose semantics are formally defined based on logics and mathematics. (i.e., it is not a natural language) Figure I.2 shows the interaction between the application and the formal methods tool [b-Shin]. The application uses API of the formal specification to request the conversion of their rules and receive formal description code as a result. Appplication IP_src_address, IP_dest_address, action=loop 1. Request Conversion to formal specification Formal Methods Tool 2. Reply formal description code S1 := ch1?x.S11(x) + ch2?x.S12(x) + {}:S1 S11(x) := matchSrcIP(x,10)->{}:S13(x) + ~matchSrcIP(x,10)->{}:S1 // no rule to match S12(x) := matchSrcIP(x,10)->{}:S13(x) + ~matchSrcIP(x,10)->tau.S14(x) S13(x) := ch3!x.S1 S14(x) := matchSrcIP(x,11)->{}:S13(x) + ~matchSrcIP(x,11)->{}:S1 // no rule to match S2 := ch3?x.S21(x) + {}:S2 S21(x) := matchSrcIP(x,10)->{}:S23(x) + ~matchSrcIP(x,10)->tau.S22(x) S22(x) := matchSrcIP(x,11)->{}:S2 // drop + ~matchSrcIP(x,11)->{}:S2 // no rule to match S23(x) := ch4!x.S2 Formal specification S3 := ch4?x.S31(x) + {}:S3 S31(x) := matchSrcIP(x,10)->{}:S32(x) + ~matchSrcIP(x,10)->{}:S3 // no rule to match S32(x) := ch2!x.S3 E := ch1!x.E1 E1 := {}:E1 SDN := (S1 || S2 || S3 || E)/{ch1,ch2,ch3,ch4} Formal verification Formal description code Figure I.2 Formal specification tool with interfaces 12 TTAx.xx.xxxx 정보통신단체표준(영문표준) Figure I.3 describes more details how to process the formal specification. When the formal specification receives the request, it gathers the application policy and the global network information from the controller. Then, it converts these inputs to a formal description code using the formal language defined. Finally, it replies the formal description code to the application. 1. Request Conversion to formal specification 2. Reply formal description code Formal specification Get Application policy Get global network information from the controller Conversion application policy & global network inf. to formal description code Switch S1 gets packet from ch1 or ch2 and becomes S11 or S12, respectively. Otherwise, idle one time unit S1 := ch1?x.S11(x) + ch2?x.S12(x) + {}:S1 … S2 := ch3?x.S21(x) + {}:S2 S21(x) := matchSrcIP(x,10)->{}:S23(x) + ~matchSrcIP(x,10)->tau.S22(x) S22(x) := matchSrcIP(x,11)->{}:S2 + ~matchSrcIP(x,11)->{}:S2 S23(x) := ch4!x.S2 Switch S2 gets packet through ch3, otherwise, idle. Check if source IP of packet ‘x’ is matched with 10 Otherwise, try to match other rules Check if source IP of packet ‘x’ is matched with 11, and if so, drop it No rule to match, so become S2 … Egress packet ‘x’ through ch4 E := ch1!x.E1 E1 := {}:E1 Send packet ‘x’ to ch1 Idle forever Switch S1, S2, S3, and Environment E is running in parallel SDN := (S1 || S2 || S3 || E)/{ch1,ch2,ch3,ch4} Formal description code Figure I.3 Specification procedures and formal description code 3. Formal Verification Tool When the application gets the formal description code, it can request the verification tool to check whether any errors or operational conflicts may occur within the networks. Figure I.4 shows the verification procedures in more details. When the formal verification receives the request, it parses the formal description code received, builds a transition graph, and starts to traverse the transition graph created previously to check the consistency or correctness with respect to the application rules and the global network operations. Figure I.5 shows an example of transition graph built based on the formal description code. The transition graph is a directed graph with boolean, action, and assignments are labelled [b-Shin]. From each state, when boolean holds, action and assignments are performed, and current state proceeds to next state. In this transition graph, each field in a flow entry and also a packet can be represented symbolically such as binary decision diagram or conjunctive normal form. In order to verify the loop existence in this example, it can apply first search starting from the root state “S1||S2||S3”, and identify every loop. To find the loops that packet is looping, actions on the edge should be detected based on the 13 TTAx.xx.xxxx 정보통신단체표준(영문표준) rules defined for the loop detection. The red line in the figure I.5 indicates that the looping may occur in the networks. Finally, the formal verification tool sends back the verification results to the application. Appplication S1 := ch1?x.S11(x) + ch2?x.S12(x) + {}:S1 S11(x) := matchSrcIP(x,10)->{}:S13(x) + ~matchSrcIP(x,10)->{}:S1 // no rule to match S12(x) := matchSrcIP(x,10)->{}:S13(x) + ~matchSrcIP(x,10)->tau.S14(x) S13(x) := ch3!x.S1 S14(x) := matchSrcIP(x,11)->{}:S13(x) + ~matchSrcIP(x,11)->{}:S1 // no rule to match S2 := ch3?x.S21(x) + {}:S2 S21(x) := matchSrcIP(x,10)->{}:S23(x) + ~matchSrcIP(x,10)->tau.S22(x) S22(x) := matchSrcIP(x,11)->{}:S2 // drop + ~matchSrcIP(x,11)->{}:S2 // no rule to match S23(x) := ch4!x.S2 S3 := ch4?x.S31(x) + {}:S3 S31(x) := matchSrcIP(x,10)->{}:S32(x) + ~matchSrcIP(x,10)->{}:S3 // no rule to match S32(x) := ch2!x.S3 1. Request Verification 2. Reply verification results E := ch1!x.E1 E1 := {}:E1 SDN := (S1 || S2 || S3 || E)/{ch1,ch2,ch3,ch4} Formal description code Formal verification Formal Methods Tool Parsing the formal description code Build Transition Graph Traverse Transition Graph and check the application rules Figure I.4 Verification Procedures {} {} S1||S2||S3||E S1||S2||S3||E tau@ch1 S11||S2||S3||E1 m(x,10); {} tau@ch1 S11||S2||S3||E1 S13||S2||S3||E1 m(x,11); {} tau@ch3 ~m(x,10); {} S1||S21||S3|E1 S1||S2||S3||E1 ~m(x,10); tau ~m(x,11); {} m(x,10); {} S13||S2||S3||E1 S1||S22||S3||E1 S1||S21||S3|E1 S1||S2||S3||E1 S1||S23||S3||E1 {} tau@ch4 tau@ch4 S1||S2||S31||E1 S1||S2||S31||E1 m(x,10); {} m(x,10); {} S1||S2||S32||E1 S12||S2||S3||E1 S14||S2||S3||E1 S1||S2||S32||E1 tau@ch2 m(x,11); {} ~m(x,10); tau ~m(x,11); {} S1||S22||S3||E1 m(x,10); {} S1||S23||S3||E1 ~m(x,11); {} m(x,11); {} tau@ch3 ~m(x,10); {} m(x,10); {} {} ^ ab m(x,10); {} ~m(x,11); {} tau@ch2 m(x,11); {} S12||S2||S3||E1 ~m(x,10); tau S14||S2||S3||E1 ^ ab m(x,10); {} ~m(x,10); tau Figure I.5 Transition Graph and Traverse results 14 TTAx.xx.xxxx 정보통신단체표준(영문표준) Bibliography [b-Clarke] Edmund M. Clarke and Jeannette M. Wing, “Formal methods: state of the art and future directions,” ACM Comput. Surv. 28, 4, December 1996. [b-Griffin] Timothy G. Griffin. Do Formal Methodists have Bell-Shaped Heads?, Proceedings of the First Workshop on Automated Theory Engineering [b-Wang] Anduo Wang, et. al., FSR: Formal analysis and implementation toolkit for safe interdomain routing, ACM SIGCOMM Conference on Data Communication, 2011 [b-Bishop] Steve Bishop, et. al., Rigorous specification and conformance testing techniques for network protocols, as applied to TCP, UDP, and Sockets. ACM SIGCOMM 2005 [b-Canini] Marco Canini, et. al., A NICE way to applications, to appear in Proc. NSDI 2012 [b-ONF] Open Networking Foundation, test OpenFlow “OpenFlow/Software-Defined Networking (SDN),” https://www.opennetworking.org/. [b-Shin] M. Shin, H. Kwak, et. al., Process Algebra Based Symbolic Verification Framework for Software-Defined Networking. Telecommunications Review Vol. 23 No. 5, 2013 15 TTAx.xx.xxxx 정보통신단체표준(영문표준) 영문 표준 해설서 1. 문서 범위 본 표준은 SDN 응용 및 시스템을 구현, 개발 및 검증하기 위한 정형 기법을 기술하고, 이에 따른 기능적 요구사항을 정의한다. 2. 참고 문헌 본 표준에서 참조하는 참고 문헌을 나열한다. 3. 용어 정의 본 표준에 사용되는 주요 용어를 정의한다. 4. 약어 본 표준에서 사용되는 약어를 나열한다. 5. 문서 규칙 본 표준에서 사용되는 문서상 규칙을 나열한다. 6. 소개 소프트웨어 정의 네트워킹 정형 검증 기술의 배경, 정의, 기본 제공 기능 등을 기술한다. 7. 개요 소프트웨어 정의 네트워킹 정형 검증 기술의 기본 개념과 각 계층별 역할을 기술한다. 16 TTAx.xx.xxxx 정보통신단체표준(영문표준) 8. 요구사항 소프트웨어 정의 네트워킹 정형 검증 기술을 제공하기 위한 기능 요구사항을 기술한다. 9. 환경 고려사항 본 기술에 대한 환경적 고려사항을 기술한다. 10. 보안 고려사항 본 기술의 보안 고려사항을 기술한다. 부록 1. 네트워킹 정형 검증 개요 네트워킹 정형 검증 기술에서 상세 동작 방법 및 예제를 기술한다. 17 TTAx.xx.xxxx 정보통신단체표준(영문표준) 표준 작성 공헌자 표준 번호 : TTAE.xx-xx.xxxx/ 이 표준의 제정·개정 및 발간을 위해 아래와 같이 여러분들이 공헌하였습니다. 구분 성명 표준(과제) 제안 이승익 표준 초안 작성자 표준 초안 에디터 이승익 이승익 신명기 표준 초안 검토 위원회 및 직위 미래인터넷 프로젝트그룹 위원 미래인터넷 프로젝트그룹 위원 미래인터넷 프로젝트그룹 위원 미래인터넷 프로젝트그룹 의장 연락처 소속사 [email protected] ETRI [email protected] ETRI [email protected] ETRI [email protected] ETRI [email protected] KT CS 외 프로젝트그룹 위원 민경선 표준안 심의 통신망 기술위원회 의장 외 기술위원회 위원 사무국 담당 박정식 통신융합부 부장 [email protected] TTA 이민아 통신융합부 원 [email protected] TTA 18 TTAx.xx.xxxx 정보통신단체표준(영문표준) 소프트웨어 정의 네트워킹을 위한 정형 명세 및 검증 요구사항 (Requirements for applying formal methods to software-defined networking) 발행인 : 한국정보통신기술협회 회장 발행처 : 한국정보통신기술협회 463-824, 경기도 성남시 분당구 분당로 47 Tel : 031-724-0114, Fax : 031-724-0109 발행일 : 2014.xx.