Testbed Definition
이렇게 구성된 물리적 테스트배드 정보는 중앙 controller에서 관리하기 쉽고, 재사용이 가능하도록 Java Script Object Notation (JSON) 으로 저장해둔다.
아래는 하나의 노드의 정의 예시이다.
"node1": {
"ip": "192.168.1.1",
"ssh": {
"user": "root",
"key": "~/node1.pem"
},
"interface": {
"wlan0": {"ssid": "mesh1", "channel": 6}
}
}
이렇게 구성된 정보는 controller에 위치하게 되며, 위의 정보를 바탕으로 다음의 과정을 통해 실험 환경을 물리적으로 구성한다.
- 해당 ip와 ssh정보로 노드에 접근 가능한지 살펴본다.
- 접근이 가능하다면 해당 interface에 mesh link를 구성한다.
- 해당 interface들을 Open vSwitch에 할당해준다.
- Open vSwitch를 외부에서 제어할 수 있도록 control port를 open한다.
이렇게 구성된 실험용 interface는 "br0"라는 이름으로 구성되어진다.
Test Case Definition
정의된 테스트배드는 여러가지 다른 환경으로 정의되어 사용할 수 있는데, 이러한 정의된 환경을 본 연구에서는 "testcase"라고 칭한다.
이러한 테스트 환경을 정의한 testcase model은 "test bed model"을 바탕으로 각 노드간의 연결정보 (link)와, 연결옵션 (option)를 JSON으로 기술하게 된다. 연결관계는 크게 Simplex 연결과 Duplex 연결로 나뉠 수 있는데, 이는 각각 아래와 같이 정의된다.
Simplex connection
{
"node1": ["node2"],
"node2": []
}
Duplex connection
{
"node1": ["node2"],
"node2": ["node1"]
}
링크 옵션의 경우 loss와 bandwidth, delay에 대한 정보를 가지고 있으며, 각각 probability (0-1), mbps, ms 단위를 가진다. 이러한 옵션은 alias로 지정하거나 직접 입력하여 아래와 같이 사용할 수 있다.
Connection with apply link options
{
"node1": [{"node2": {"loss": 0.1, "bandwidth": 0.5, "delay": 100}}],
"node2": ["node1"]
}
Link options with alias
{
"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
테스트케이스가 테스트베드에 투영되기 위해셔는 아래와 같은 일련의 과정을 거친다.
- 테스트베드 모델이 정의된다.
- 컨트롤러는 테스트베드 모델을 읽어 실제 topology를 파악한다.
- 이때, 누락된 노드가 존재하는경우 에러가 발생된다.
- 파악된 topology를 바탕으로 테스트케이스 모델을 불러들인다.
- 테스트케이스의 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가 돌아갈 수 있도록 가상 인터페이스에 할당이 되어지는데, 아래와 같은 과정을 거쳐 가상 인터페이스를 할당한다.
- ovs의 가상인터페이스를 새로 할당한다.
- 할당된 가상인터페이스의 번호 "ex : br0.100" 을 기억해두고 할당한다.
- 할당된 인터페이스에 할당된 번호에 맞는 mac address를 할당한다. (ex : 0:0:0:0:100:0 ~ 0:0:0:0:100~20)
- 해당 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