다수가 참여하는 실험환경에서 testcase를 명확히 정의 하는것은 매우 중요하다. 예를들자면 20개의 노드가 Fully Connected 되어있고,이 중 몇개의 노드는 연결상태가 좋지 않아 10mbps의 대역폭과 40~50%의 loss율을 보인다고 가정하였을때, 일반적인 물리환경에서는 같은 경우를 명확하게 재현하기에 매우 어렵다. 따라서 이러한 내용을 특정한 language로 명문화 하여야 하며 본 연구에서는 널리 쓰이는 Structural Language중 하나인 Java Script Object Notation을 사용하였다.
우선 전체 실험환경에 대해서 기술한 model database json이 존재하며, 이는 "Testbed" 라고 지칭한다. 하나의 testcase는 하나의 파일안에 정의되며, 이는 "Testcase"라고 지칭한다. 이때 하나의 Testbed에는 다수의 Testcase가 동시에 구현될 수 있으며, Testcase가 Testbed에 올라가는 일련의 과정을 "Projection" 된다고 표현한다.

Test Cases Projection on to Test-bed

테스트케이스가 테스트베드에 투영되기 위해셔는 아래와 같은 일련의 과정을 거친다.
  1. 테스트베드 모델이 정의된다.
  2. 컨트롤러는 테스트베드 모델을 읽어 실제 topology를 파악한다.
  3. 이때, 누락된 노드가 존재하는경우 에러가 발생된다.
  4. 파악된 topology를 바탕으로 테스트케이스 모델을 불러들인다.
  5. 테스트케이스의 link 정보를 수집하여 아래와 같이 나눈다.
1. neighbor인 노드끼리는 이래의 패킷 포워딩 룰을 source와 dest 노드 모두에 아래와 같이 정의한다.
if mac_addr_src=${source} and mac_addr_dst=$(dest) then ACCEPT
2. 만약 그렇지 않은경우 graph 탐색기법 또는 사용자가 제공한 link 연결 순서를 따라서 아래의 포워딩 룰을 제공한다.
if mac_addr_src=${source} and mac_addr_dst=$(dest) then FORWARD_NEXT
이때 egress 과정에서 l2 frame이 forwarding 될때 source addr과 dest addr이 수정되지 않도록 관리되어야 한다.

Defining Topology and Test Cases

Testbed Modeling

Testbed model 안에는 다음과 같은 정보가 포함된다.
name alias 필드는 해당 노드를 testcase에서 손쉽게 지칭하기 위한 별칭으로 전체 테스트 베드에서 unique하여야 한다. 또한, ssh user name과 credential은 valid해야 하며, 지정된 노드의 ip주소를 이용하여 연결하게 된다.

Testcase Modeling

각각의 테스트 케이스는 link 정보 (topology)를 가지게 되며, 이러한 testcase를 시스템에 입력하면 case no가 자동으로 발급되어 나오게 된다.
link정보는 JSON array 방식으로 매우 간단하게 구성된다.

Simplex connection

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

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 하게 터널을 구성하지만, 만약 그렇지 않고, 꼭 특정 노드를 거쳐서 가도록 하고싶다면 아래와 같이 지정할 수 있다.
{     "node1": [{"node3": {"loss": 0.1, "bandwidth": 0.5, "delay": 100, "path": ["node2"]}}],     "node3": [{"node1": {"path": ["node2"]}}] } 
이때 path는 왼쪽에서 오른쪽 순서로 현재 노드부터 목적지 노드까지 프레임이 운반되며, 인접한 중간 노드끼리는 서로 neighbor여야 하며, path가 반복되거나, 자기자신 또는 목적지를 포함할 수 없다.

Validation

이렇게 구성된 모든 파일은 controller에 위치하며, controller 데몬을 구동하면 testbed 파일을 입력받아 
 

Test-bed Environments

본 연구에서 사용된 테스트 베드는 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