테스트배드의 경우 아래와 같은 구조를 가진다.
모든 테스트는 이 data plane 에서 동작하며, 모든 리소스를 중앙 controller에서 관리하기 쉽도록 다음과 같은 정보를 Java Script Object Notation (JSON) 으로 저장해둔다.

이렇게 구성된 정보는 controller에 위치하게 되며 controller에는 다음과 같은 소프트웨어가 내장된다.
또한, 테스트에 참여하는 각각의 노드들은 아래와 같은 구조의 소프트웨어가 내장된다.
위의 모듈들에 대한 자세한 설명은 4절에서 깊게 다룰 예정이다.

Test Case Definition 

다수가 참여하는 실험환경에서 testcase를 명확히 정의 하는것은 매우 중요하다. 예를들어서 20개의 노드가 Fully Connected 되어있다고 가정하면 연결을 위해서 20! 개의 링크가 필요한데, 만약 이 중 몇개의 노드의 연결상태가 좋지 않아서 10mbps의 대역폭과 40~50%의 loss율을 보인다고 가정 한다면 위와 같은 실험환경을 그대로 재현 하는것은 매우 복잡한 문제가 된다.
따라서 물리적으로 구성된 환경을 바탕으로 이러한 내용을 특정한 Software적, 특히 Java Script Object Notation (JSON) 표기법을 이용해, 각 노드간의 연결 (link)와, 연결 상태 (link status)를 기술하고자 한다.
각각의 테스트 케이스는 link 정보 (topology)를 가지게 되며, 이러한 testcase를 시스템에 입력하면 case no가 자동으로 발급되어 나오게 된다.
link정보는 JSON array 방식으로 매우 간단하게 구성된다.

Simplex connection

{     "node1": ["node2"],     "node2": [] }

Duplex connection

{     "node1": ["node2"],    "node2": ["node1"] }

Connection with apply link options

{     "node1": [{"node2": {"loss": 0.1, "bandwidth": 0.5, "delay": 100}}],     "node2": ["node1"] }
링크 옵션의 경우 loss와 bandwidth, delay에 대한 정보를 받으며, 각각 probability (0-1), mbps, ms 단위를 가진다. 만약 80.5kbps를 가정한다면 0.0805가 이에 해당한다.  또한 이러한 옵션은 alias로 지정하여 사용할 수 있는데 이는 option 필드에 사전에 지정한 이후 아래와 같이 사용할 수 있다.
{     "options": {         "option1": {"loss": 0.1, "bandwidth": 0.5, "delay": 100}     },     "links": {         "node1": [{"node2": "option1"}],         "node2": ["node1"]     } }   
이는 정확히 이전의 예제와 같은 코드를 의미한다.
만약 실제로는 여러 노드를 거쳐서 도달해야 하는 상황이지만 tunnel을 지정하여 사용하고 싶은경우, testcase apply 과정에서 automatically 하게 터널을 구성하지만, 만약 그렇지 않고, 꼭 특정 노드를 거쳐서 가도록 하고싶다면 아래와 같이 지정할 수 있다.
{   "links": {       "node1": [{"node2": {"path": ["node2"]}}],       "node3": [{"node1": {"path": ["node2"]}}]   } }
이때 path는 왼쪽에서 오른쪽 순서로 현재 노드부터 목적지 노드까지 프레임이 운반되며, 인접한 중간 노드끼리는 서로 neighbor여야 하며, path가 반복되거나, 자기자신 또는 목적지를 포함할 수 없다.

Test Cases Projection on to Test-bed

테스트케이스가 테스트베드에 투영되기 위해셔는 아래와 같은 일련의 과정을 거친다.
  1. 테스트베드 모델이 정의된다.
  2. 컨트롤러는 테스트베드 모델을 읽어 실제 topology를 파악한다.
  3. 이때, 누락된 노드가 존재하는경우 에러가 발생된다.
  4. 파악된 topology를 바탕으로 테스트케이스 모델을 불러들인다.
  5. 테스트케이스의 link 정보를 수집하여 아래와 같이 나눈다.
1. neighbor인 노드끼리는 이래의 패킷 포워딩 룰을 source와 dest 노드 모두에 아래와 같이 정의한다.
if addr_src=${source} and addr_dst=$(dest) then ACCEPT
2. 만약 그렇지 않은경우 graph 탐색기법 또는 사용자가 제공한 link 연결 순서를 따라서 아래의 포워딩 룰을 제공한다.
if addr_src=${source} and addr_dst=$(dest) then FORWARD_NEXT
이때 egress 과정에서 l2 frame이 forwarding 될때 source addr과 dest addr이 수정되지 않도록 관리되어야 한다. 특히 l3 이상의 network 장치 (switch, router, wireless ap 등)에는 자신의 mac address를 기반으로 잘못된 packet을 filtering하여 전달되지 않도록 하거나, 자신의 주소로 override 하는 경우가 존재하므로 ad-hoc을 이용한 연결 또는 hub 를 바탕으로 한 유선연결이 test-bed 구성에 권장 되어 진다.
이러한 flow는 동시에 여러 testcase가 돌아갈 수 있도록 가상 인터페이스에 할당이 되어지는데, 아래와 같은 과정을 거쳐 가상 인터페이스를 할당한다.
  1. ovs의 가상인터페이스를 새로 할당한다.
  2. 할당된 가상인터페이스의 번호 "ex : br0.100" 을 기억해두고 할당한다.
  3. 할당된 인터페이스에 할당된 번호에 맞는 mac address를 할당한다. (ex : 0:0:0:0:100:0 ~ 0:0:0:0:100~20)
  4. 해당 mac address에 맞춰 open flow rule 을 가상 인터페이스에 적용시킨다.

Evaluation

본 연구에서 사용된 테스트 베드는 20개의 raspberry pi 3, 1개의 l2 hub를 이용하였고, 각각 hub와 wireless interface를 이용하여 fully connected 되어있으며, hub와의 연결은 유선연결로 "eth0"에 매핑되어있고, wireless interface는 "wlan0"에 매핑되어있다.
hub를 이용하여 연결된 유선환경에서 모든 노드는 192.168.0.2 ~ 192.168.0.22 까지의 ip를 부여받으며, 이는 control plane으로써 외부망과 완전히 독립되었음을 가정하고, 실제 배포를 위한 controller는 192.168.0.1의 ip를 부여하여 hub와 직접 연결되어진다.
 

Conclusion