Intro
https://ieeexplore.ieee.org/document/6838228에 기재된 OpenNetMon: Network Monitoring in OpenFlow Software-Defined Networks의 내용에 대한 리뷰이다. 이름에서 알 수 있듯이 OpenNetMon은 POX OpenFlow Controller를 이용하여 수많은 network component로 이루어진 fine-grained Network에서 Traffic Engineering을 위한 QoS Metric을 flow 단위로 제공하는 것을 목표로 한다. 수집하는 데이터는 Throughput, Packet Loss, Delay를 측정한다.
Monitoring
Monitoring의 종류 그리고 OpenNetMon 이전의 Monitoring 방법론에 대한 소개를 먼저한다.
Type of Monitoring
세 가지 기준에서 Monitoring 방법들을 구분한다. 그 중에서 첫 번째로 제시된 것이 Active, Passive이다.
- Active : 추가적인 packet을 Network 상에 삽입하여, 해당 packet의 동작을 통해서 측정을 하는 방법으로 과도한 추가 packet은 Network에 영향을 주기 때문에 이에 유의해야 한다. 반대로 너무 적은 packet을 사용하는 경우에도 정확성과 실시간성이 떨어질 수 있다.
- Passiv : 추가적인 packet의 삽입없이 기존 traffic에 대한 관측만으로 측정하는 방법으로 모든 네트워크에 적용할 수 잇는 범용적인 방법은 사실상 불가능하다고 할 수 있으며 각 Network를 위한 전용 Hardware 장비가 필요할 수도 있다. 또한, Synchronization을 위한 별도의 방법 또한 필요하다.(각 Network 장비에서 관측한 Traffic이 서로 대응되는지 확인할 수 있어야 하기 때문)
두 번째는 어떤 Layer에서 Monitoring을 수행하는가이다. Application Layer에서 측정을 하게 된다면, 활용할 수 있는 데이터가 많아지고, 실제 user 입장에서의 최종 데이터를 얻는 것이 가능하다. 하지만, 실제 서비스 제공자 입장에서 모든 End Device에 대한 접근이 불가능한 경우가 많다. 반대로 Network Layer에서 측정을 수행하는 경우에는 사용할 수 있는 데이터가 각 Switch 와 같은 Network 장비에서 packet이 어느 port로 나갔는지와 같은 간단한 정보밖에 사용할 수 없다는 단점이 있었다.
세 번째로 제시되는 것이 OpenFlow를 이용하였는가 아니면 이를 사용하지 않았는가이다. OpenFlow가 등장하면서 결국 Network Layer에서의 측정이 더 큰 의미를 가지게 된다. 왜냐하면, Switch에 설정을 미리 주입하거나 새로운 traffic에 대한 정보를 실시간으로 추가할 수 있으며 Flow 단위로 통계치를 얻거나 임의의 packet을 추가하는 등의 작업을 수행할 수 있었기 때문에 Network Layer에서의 더 많은 Monitoring이 가능해졌다. 이것이 해당 논문이 OpenFlow를 통해서 구현하고자 하는 바이다. Network Layer에서 복잡한 네트워크에서도 보다 정확하고, 실시간의 통계 데이터를 추출할 수 있다는 것이다.
아래는 해당 논문에서 추가로 제시하는 OpenNetMon 이전에 존재했던 Monitoring 방법에 대한 정리이다.
| Active/Passive | Layer | OpenFlow 여부 | 설명 | |
|---|---|---|---|---|
| SNMP | Active | Network | X | port 단위의 packet counter 기능 제공 switch의 통계정보 제공(CPU, RAM) |
| NetFlow / cSamp | Passive | Network | X | switch를 통과하는 n개의 packet마다 임의의 1개의 packet을 선별하여 이를 대표값으로 하여 Network 상태를 측정하지만, 정확도가 많이 떨어질 수 있다. |
| Skitter | Active | Network | X | 전체적인 Network Delay를 측정하기 위해 대표지역에 측정기를 설치하여 실행한 project로, 이를 통해 대략적인 지연을 예측할 수는 있지만 정확하지는 않다. |
| IPMON | Passive | Network | X | TCP/IP packet header를 추출하여, timestamp와 함께 중앙 server로 전송하여 이를 분석하는 방식이다. Passive임에도 Synchronization을 맞추기 위해서 통신은 불가피하며 Network 크기가 커질 수록 비용이 커진다. |
| OpenTM | Passive | Network | O | 각 Flow의 통계 데이터를 일정 주기로 Query하여 수집한다. Flow의 시작과 끝 지점에서만 측정하는 Last-Switch 방식을 사용한다. |
| OpenSAFE | Passive | Network | O | SDN의 모든 새로운 Flow가 Controller로 이동하는 것을 이용하여 Monitoring 시스템으로 Controller가 이를 전달하도록 하는 방식이다. |
| OpenSketch | - | - | - | Monitoring을 위해 OpenFlow 자체를 재정의하자는 것으로 새로운 Protocol을 정의해서 더 나은 Monitoring을 수행하자는 방법이다. 하지만, 이렇게 새로운 Protocol을 만드는 것은 Risk가 너무 크다. |
OpenNetMon
기존의 Monitoring 방식들은 OpenFlow의 Packet 삽입을 이용한 방식을 제대로 사용하지 않았을 뿐만 아니라 Flow 측정에 있어 최적화에 한계가 있었을 뿐만 아니라 Throughput, Packet Loss, Delay을 통합하고자 하지 않았다. 따라서, OpenNetMon은 이를 수행하는 것을 목표로 한다.
각 측정 요소를 어떻게 수집할 것인지를 각 각 정리한다.
1. Throughput
OpenFlow의 FlowStatsReq(Controller에서 각 Switch로 전송하는 Request)를 주기적으로 호출하여 각 Switch에서 전송한 Byte의 양과 각 Flow의 지속 시간을 얻는다. 주기적 호출 싱레는 경로 상의 처음과 끝을 호출하는 Last Switch 방식을 사용하며, 이는 Round Robin이 대규모 네트워크 환경에서 비효율적일 뿐만 아니라 Packet Loss 측정 시에도 Last Switch는 필수적으로 필요한 요소이기에 최적 요소만을 사용하는 것이다.
또한, 이러한 호출 주기는 변동적으로 설정되었는데 이는 Link State Information에 기반한 Routing Discovery 시에 이를 교환 및 동기화하는 것은 Network Throughput에 많은 영향을 미치며 Throughput을 굉장히 큰 범위로 변동되게 한다. 이에 따라 아직 convergence(수렴)이 안된 시점에는 주기를 더 빈번하게 하고, 후에는 이를 되돌리도록 하는 설정이 필요하기에 이 또한 추가되었다.
2. Packet Loss
시작지와 목적지의 Switch에서 해당 Flow에 대한 Packet Counting을 수행하여 계산한다.
3. Delay
Packet을 하나 생성하여 출발 시간과 도착 시간을 통해 측정한다. 따라서, 다음과 같은 식으로 정리할 수 있다. 아래 RTT는 Controller와 각 Switch 간의 RTT를 의미한다.
Evaluation
실제 실험을 통해서 OpenNetMon에 대한 성능을 테스팅하였다. 이과정에서 총 4개의 OpenFlow를 지원하는 Switch를 일자로 연결하고 각 말단에 Server와 Client를 연결한 후에 각 Switch가 POX OpenFlow Controller에 직접적으로 연결되도록 구성하고, 각 말단과 Server/Client로의 연결은 1Gbps Ethernet로 연결하고, Switch간의 연결은 100Mbps에 1% loss, 1ms delay로 설정을 하였다. 실제 전송 데이터는 video stream traffic을 활용하여 복잡한 traffic 전송을 표현하고자 했다.
실제 그래프와 Topology는 직접적으로 가져오지는 않았다. 아무래도 저작권에 대해서 제대로 알 수 없어서 가져오지 않았다. 하지만, 논문과 같이 비교하면서 보면 도움을 받을 수 있을 것이다.
1. Throughput
Application Level에서 구현한 tcpstat과 비교했을 때, 16KB/s(1.2%) 정도 밖에 차이가 나지 않았다. 하지만, 초기에 17.8%까지 차이가 발생하는데 이는 초기 준비 기간으로 만약 초기 준비 기간을 준다면 해결 가능하다. 또한, 한 번씩 spike가 발생하는데 이는 polling 과정에서 이전 요청보다 현재 요청이 먼저 도착할 때 발생한다. 이를 위해 synchronization을 맞춰주기 위한 로직을 추가한다면 해결이 가능하다. 여기서는 sleep과 mutual exclusion을 이용하기를 권장한다.
2. Packet Loss
정확하지는 않지만 받아들일 수 있을 정도의 오차밖에 발생하지 않는다.
3. Delay
Control Plane에 기반하여 전송하는 방법과 VLAN을 기반으로 Data plane으로 전송하는 법 그리고 실제로 user가 체감하는 delay를 비교했을 때, Control Plane을 그대로 이용하는 경우에는 생각보다 큰 오차가 발생한다. 이는 Controller에서 Software Scheduling 과정에서 발생하는 에러이기에, VLAN을 기반으로 Data Plane을 이용하는 경우에는 실제 데이터와 비교해도 오차가 거의 없는 것을 볼 수 있다.
Review
해당 논문은 OpenFlow가 나오고 이를 이용해서 Monitoring을 수행하고자 했던 여러 ISP와 연구자들에게 도움을 주었다고 생각한다. 이를 통해서 OpenFlow를 이용한 여러 Monitoring 방식이 연구되었던 것 같다. 그래서 Network 논문임에도 261건 정도의 인용수를 획득한 것으로 보인다. 또한, OpenFlow를 이용한 Monitoring 방식을 사용한다는 것이 흥미로웠고, 기존의 Monitoring 방식을 OpenFlow를 통해서 적용해보는 것이 당시 연구에서 중요했던 포인트였던 것으로 보인다. 새로운 기술에 기존 기술의 아이디어를 접목하는 것도 고려해서 논문을 작성하는 것도 좋은 방법이라고 생각된다. 또한, 구현이 Github로 open되어있기 때문에 신뢰도도 높았던 것으로 보인다. 만약 해당 부분을 좀 더 확인하고 싶다면 인용 논문을 좀 더 탐색해보는 것도 좋은 방법이 될 것 같다.
작성자가 Posting을 작성하는 날짜를 기준으로 261 번의 인용수를 자랑하는 논문을 리뷰한 것이다. 앞으로도 NOMS 논문 중에서 인용수가 많았던 논문들을 위주로 한 번 Review를 진행할 예정이다.
Reference
- Niels L. M. van Adrichem, Christian Doerr, Fernando A.Kuipers,
"OpenNetMon: Network Monitoring in OpenFlow Software-Defined Networks", June 2014 - Thumbnail : Photo by Tobias Tullius on Unsplash
Comments