[논문 리뷰] tinyNBI: Distilling an API from essential OpenFlow abstractions

C. Jasson Casey, Andrew M. Sutton외 1명|arXiv (Cornell University)|2014. 03. 26.

Software-Defined Networks and 5G참고 문헌 4인용 수 4

한 줄 요약

이 논문은 다섯 개의 OpenFlow 버전에서 핵심 OpenFlow 추상화를 추출하여 깔끔하고 저수준의 C API로 구현한 최소 크기의, 버전에 구애받지 않는 북상 인터페이스(tinyNBI)를 제안한다. 버전별로 다름을 추상화함으로써 다양한 스위치에서 흐름 테이블, 매칭 조건, 액션, 지시어의 신뢰성 있고 이식 가능한 설정을 가능하게 하여 애플리케이션의 복잡성을 줄이고 SDN 개발자의 유지보수성을 향상시킨다.

ABSTRACT

If simplicity is a key strategy for success as a network protocol OpenFlow is not winning. At its core OpenFlow presents a simple idea, which is a network switch data plane abstraction along with a control protocol for manipulating that abstraction. The result of this idea has been far from simple: a new version released each year, five active versions, com- plex feature dependencies, unstable version negotiation, lack of state machine definition, etc. This complexity represents roadblocks for network, software, and hardware engineers. We have distilled the core abstractions present in 5 existing versions of OpenFlow and refactored them into a simple API called tinyNBI. Our work does not provide high-level network abstractions (address pools, VPN maps, etc.), instead it focuses on providing a clean low level interface that supports the development of these higher layer abstractions. The goal of tinyNBI is to allow configuration of all existing OpenFlow abstractions without having to deal with the unique personalities of each version of OpenFlow or their level of support in target switches.

연구 동기 및 목표

• OpenFlow의 점점 증가하는 복잡성과 버전 분열 문제를 해결하여, 개발자가 프로토콜 및 스위치의 다양성에 대응하기 위해 애로를 겪지 않도록 하기 위해.
• 모든 버전에서 공통되는 핵심 OpenFlow 추상화만을 노출하는 최소 크기이자 안정적인 API를 설계하기 위해.
• 애플리케이션 로직을 OpenFlow 버전 간의 차이와 스위치별 기능 지원에서 분리하기 위해.
• 이질적인 OpenFlow 스위치 간에 흐름 테이블, 액션, 매칭 조건, 지시어의 설정을 신뢰성 있고 이식 가능하게 가능하게 하기 위해.
• 저수준 프로토콜 복잡성을 다시 구현하지 않고도 고수준 네트워크 추상화를 구축할 수 있는 기반을 제공하기 위해.

제안 방법

• 저자들은 다섯 개의 OpenFlow 버전(1.0부터 1.3.1까지)에서 핵심 추상화를 추출하여, 데이터패스, 흐름 테이블, 매칭 조건, 액션, 지시어, 포트, 그룹, 큐, 메터 등 공통된 원소를 식별하였다.
• 흐름 구성 및 스위치 설정을 위해 ofp_add, ofp_del, ofp_build_match, ofp_build_action, ofp_build_instruction 등의 기능을 포함한 소수의 함수를 가진 C 기반 API를 설계하였다.
• API는 흐름 구성이 매칭 조건 및 지시어 집합을 바인딩하는 구조화된 데이터 타입(예: ofp_flow)을 통해 표현되는 스위치 독립적 모델을 강제한다.
• 요구사항을 통한 기능 선언을 지원하여, 응용 프로그램이 실행 전에 필요한 원소와 기능을 선언할 수 있도록 한다.
• 실험자 확장 기능은 바이너리 데이터 블록을 통해 처리되며, OFP_EXTENSION은 벤더 전용 메시지의 선택자로 사용된다.
• 표준화된 작업(예: ofp_get 및 ofp_stats)을 통해 쿼리, 설정, 통계 수집을 지원함으로써 다양한 스위치 간 일관된 상호작용을 보장한다.

실험 결과

연구 질문

• RQ1 여러 개의 OpenFlow 버전에서 핵심 추상화를 추상화할 수 있는 최소 크기의, 버전에 구애받지 않는 API는 어떻게 설계할 수 있는가?
• RQ2 모든 OpenFlow 1.x 버전에서 공통되는 핵심 추상화는 무엇이며, 이를 통해 SDN 애플리케이션 개발의 안정적인 기반을 만들 수 있는가?
• RQ3 어떻게 하면 애플리케이션 개발자가 OpenFlow 스위치의 버전별 기능 지원 및 협상 복잡성에서 보호받을 수 있는가?
• RQ4 저수준 NBI를 통해 각 스위치 유형이나 OpenFlow 버전에 맞는 여러 애플리케이션 버전이 필요로 하는 정도를 줄일 수 있는가?
• RQ5 간소화되고 이식 가능한 API 내에서 실험자 확장 기능을 어떻게 균일하게 지원할 수 있는가?

주요 결과

• tinyNBI는 다섯 개의 OpenFlow 버전에서 핵심 추상화를 하나의 일관된 C API로 추상화하여, 응용 프로그램 내에서 버전별 로직을 제거하였다.
• API는 매칭 조건 및 지시어 집합을 바인딩하는 구조화된 데이터 타입(예: ofp_flow)을 통해 흐름 구성이 가능하게 하여, 흐름 설치 및 삭제를 단순화하였다.
• 응용 프로그램은 이제 실행 전에 필요한 기능과 기능을 선언할 수 있어, 실행 중 오류를 줄이고 호환성을 보장할 수 있다.
• 실험자 확장 기능은 검증 없이 바이너리 데이터 블록을 통해 균일하게 지원되며, 추상화를 깨뜨리지 않고 벤더 전용 기능을 제공할 수 있다.
• 인터페이스는 구성, 쿼리, 통계, 수정과 같은 OpenFlow의 주요 기능을 소수의 일관된 함수 집합을 통해 지원한다.
• OpenFlow 버전 관리 및 스위치 다양성에서 애플리케이션 로직을 분리함으로써, tinyNBI는 코드 복잡성을 줄이고 유지보수성을 향상시켰다.