Download 12.[2014-286](제정). - TTA표준화 위원회

정보통신단체표준(영문표준)
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.
１
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.
２
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
３
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
４
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
５
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:
６
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
７
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.
８
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.
９
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.
１０
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.
１１
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
１２
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
１３
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
１４
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
１５
TTAx.xx.xxxx
정보통신단체표준(영문표준)
영문 표준 해설서
1. 문서 범위
본 표준은 SDN 응용 및 시스템을 구현, 개발 및 검증하기 위한 정형 기법을 기술하고,
이에 따른 기능적 요구사항을 정의한다.
2. 참고 문헌
본 표준에서 참조하는 참고 문헌을 나열한다.
3. 용어 정의
본 표준에 사용되는 주요 용어를 정의한다.
4. 약어
본 표준에서 사용되는 약어를 나열한다.
5. 문서 규칙
본 표준에서 사용되는 문서상 규칙을 나열한다.
6. 소개
소프트웨어 정의 네트워킹 정형 검증 기술의 배경, 정의, 기본 제공 기능 등을
기술한다.
7. 개요
소프트웨어 정의 네트워킹 정형 검증 기술의 기본 개념과 각 계층별 역할을 기술한다.
１６
TTAx.xx.xxxx
정보통신단체표준(영문표준)
8. 요구사항
소프트웨어 정의 네트워킹 정형 검증 기술을 제공하기 위한 기능 요구사항을
기술한다.
9. 환경 고려사항
본 기술에 대한 환경적 고려사항을 기술한다.
10. 보안 고려사항
본 기술의 보안 고려사항을 기술한다.
부록 1. 네트워킹 정형 검증 개요
네트워킹 정형 검증 기술에서 상세 동작 방법 및 예제를 기술한다.
１７
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
１８
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.