네트워크 시뮬레이션 공방

Riverbed Modeler 18.7.1 버전이 지난 6월25일자로 발표되었습니다(이전 버전에 관한 내용은 "Riverbed Modeler 18.7.0 발표" 참조). 홈페이지에는 6월22일자로 올라와 있고，Release notes에는 6월25일자로 되어 있고，메일 공지는 오늘(7월18일) 날자로 중구난방이라 어느게 정확한 날짜인지 모르겠네요. 그나마 이번에는 메일 공지를 해줬다는 점에서 위안을 삼아야할 것 같습니다.
Relase notes를 통해 변경 사항을 살펴보았습니다. 모델 업데이트는 1가지입니다.

- TCP Model Enhancement - Multipath TCP Support

TCP 모델 개선 사항은 RFC-6824에 기반한 Multipath TCP(MPTCP)에 대한 지원입니다. 이를 위해 MPTCP 연결을 담당하는 mptcp_conn 프로세스 모델이 추가되었습니다. MPTCP를 사용하도록 설정되어 있는지의 여부에 따라 tcp 모듈의 root 프로세스인 tcp_manager_v3 프로세스에서 이 mptcp_conn 프로세스를 호출하거나, 아니면 기존의 tcp_conn_v3 프로세스, 또는 tcp_conn_tao_v3 프로세스를 호출하는 방식을 취하고 있습니다.

이외에 버그 수정사항 3건도 포함되었습니다. SITL 모듈이 Windows 플랫폼의 optimized 커널에서 수행되지 않던 문제와, Linux 플랫폼의 parallel 커널에서 수행되지 않던 문제가 수정되었다고 합니다. 그리고, LTE 모델의 path-loss 모델 중 "Indoor Office" 모델에서 미터를 킬로미터로 잘못 계산하던 오류가 수정되었다고 합니다.

이더넷 (더미) 허브는 연결된 포트로 들어오는 트래픽을 다른 포트들로 모두 복사/전달하는 기능을 수행하는 장비이다. 따라서, 실제 목적지가 아닌 포트들로도 트래픽이 같이 전달되므로, 측정되는 유통 트래픽 량이 실제로 전달되어야하는 트래픽 양보다 크다. Riverbed(OPNET) Modeler에서 제공하는 이더넷 허브 노드 모델 역시 이와 같은 특성을 그대로 보여주므로, 허브 노드가 포함된 시험망의 트래픽을 설정하고 결과를 해석할 때에는 조금 더 세심한 주의가 필요하다.
다음은 "허브 노드를 지나는 디맨드 트래픽의 경로"에서 사용한 예제망을 재활용한 것이다.

Client 노드에서 Server 노드로 향하는 플로우와 Client 노드에서 Server_2 노드로 향하는 플로우의 Traffic Mix 속성을 All Explicit로 변경하고 Client

노드로부터 R1, Hub, Server 노드로 전달되는 트래픽량을 비교해보면 다음 그림과 같다. Client 노드에서 R1 노드, Hub 노드에서 Server 노드, 허브 노드에서 Server_2 노드로 전달되는 트래픽 양이 모두 동일한데, 이는 Client 노드에서 발생하여 Server 노드와 Server_2 노드로 향하던 트래픽이 Hub 노드에서 분기되지 않고 양 링크로 모두 전달되었기 때문이다. 

트래픽 발생을 위해 Application Model을 사용하여도 허브 노드가 연결된 모드 링크로 트래픽을 복사/전송하는 특성은 동일하게 나타난다. 다음 그림은 허브 노드를 지나는 Application Model 트래픽 효과를 관찰하기 위하여 구성한 예제망이다. 디맨드 플로우를 삭제하고, 동등한 수준의 Application Model 트래픽(Custom)을 추가해주었다.

시뮬레이션을 수행한 후 Client 노드로부터 R1, Hub, Server 노드로 전달되는 트래픽량을 비교해보면 다음 그림과 같다. Application Model 트래픽을 사용하여도, Hub 노드에서 트래픽이 분기되지 않고 양 링크로 모두 전달되므로 Client 노드에서 R1 노드, Hub 노드에서 Server 노드, 허브 노드에서 Server_2 노드로 전달되는 트래픽 양이 모두 동일한 것을 확인할 수 있다.

Riverbed(OPNET) Modeler는 17.5 PL3버전부터 TCP CUBIC[1, 2, 3]을 지원한다("OPNET Modeler 17.5 PL3 발표" 참조). CUBIC 적용 여부는 다음 그림처럼 TCP 속성 설정창에서 Flavor 속성을 CUBIC으로 선택하여 조정할 수 있다.

17.5 버전에서의 기본값은 New Reno이므로 CUBIC을 적용하지 않는다. Flavor 속성값을 CUBIC으로 직접 변경하거나, TCP Parameter로 Linux 2.6 프로파일을 선택하면 CUBIC 알고리즘이 적용된다. 실제로, Linux 2.6.19 커널에서는 기본 TCP Congestion algorithm으로 CUBIC이 사용된다[4].

[1] http://research.csc.ncsu.edu/netsrv/?q=content/bic-and-cubic
[2] http://tools.ietf.org/html/draft-rhee-tcpm-cubic-02
[3] Sangtae Ha, Injong Rhee and Lisong Xu, "CUBIC: A New TCP-Friendly High-Speed TCP Variant",
ACM SIGOPS Operating System Review, Volue 42, Issue 5, July 2008, Page(s):64-74, 2008.
[4] http://kernelnewbies.org/Linux_2_6_19

시뮬레이션을 진행하다보면, 가끔 전송오류가 없는 이상적인 환경이 필요할 때가 있다. 물론, Network Scale을 Logical로 선택하면 물리적인 조건에 전혀 영향을 받지않는 환경을 만들수 있지만, 이 경우에는 좌표 정보도 사용할 수 없는 문제가 있다. 따라서, 좌표 정보는 사용하면서도 물리계층에서의 전송오류가 없는 환경이 필요할 때에는 PHY단을 약간 수정해주어야 한다.
WLAN 모델에서는 파이프라인 스테이지중 error 단계를 조금 수정해주면 전송오류(즉, 비트 에러)가 발생하지 않도록 만들 수 있다.

GRP에서의 쿼드런트 개념은 "GRP 쿼드런트"에서 살펴보았다. 여기에서는 예제를 통해 이를 확인해보기로 하자. 다음은 쿼드런트 개념을 살펴보기 위한 시험망의 구조를 보인 것이다. 라우팅 프로토콜로 GRP를 적용하였고, 쿼드런트 크기는 2Km로 설정하였다.

쿼드런트는 좌표계를 기준으로 결정되므로, 시나리오상의 노드 배치를 보고 쿼드런트의 경계를 직접 파악하기는 매우 어렵다. 각 노드에 구성된 목적지 테이블 정보로부터 이 예제망에서 사용된 쿼드런트를 파악해보면 다음 그림과 같다. STA_1, STA_2, STA_3, STA_4 노드가 한 쿼드런트에 속하고, 이웃한 쿼드런트에는 STA_5, STA_6, STA_7, STA_8 노드가 속한다.

STA_1 노드에 구성된 목적지 테이블을 살펴보면 다음과 같다. 동일한 쿼드런트에 속한 STA_2, STA_3, STA_4 노드에 대해서는 대상 노드의 좌표값을 사용하므로 각각 다른 값이 저장되어 있다. 반면, 동일한 쿼드런트에 속하지 않은 STA_5, STA_6, STA_7, STA_8 노드에 대해서는 대상 노드가 속한 쿼드런트의 좌표값을 사용하므로, 4개 노드 모두 동일한 값이 저장되어 있다.

반대로 SATA_1 노드와 다른 쿼드런트에 속한 STA_8 노드에 구성된 목적지 테이블을 살펴보면 다음과 같다. 동일한 쿼드런트에 속한 STA_5, STA_6, STA_7 노드에 대해서는 각각 다른 값이 저장되어 있으며, 동일한 쿼드런트에 속하지 않은 STA_1, STA_2, STA_3, STA_4 노드에 대해서는 모두 동일한 값이 저장되어 있음을 확인할 수 있다.

AODV에서 Route Request(RREQ) 메시지는 이웃을 찾아내고 위해서 사용되며, Riverbed(OPNET) Modeler AODV 모델에서는 "AODV 메시지(1) - 패킷 포맷"에서 살펴본 것처럼 공통 AODV 패킷 포맷의 Options 필드에 RREQ 메시지에 대한 구조체를 싣는 방식으로 구현된다. 다음 그림은 AODV 모델에서 사용 하는 패킷 포맷과 RREQ 메시지일 경우 Options 필드에 실리는 정보를 표준[1]과 비교하여 나타낸 것이다.

AODV 모델에 구현된 RREQ 메시지 구조체와 표준이 잘 일치함을 확인할 수 있다.

[1] RFC 3561, "Ad hoc On-Demand Distance Vector (AODV) Routing", IETF, July 2003.

OSPF에서 사용되는 Hello 메시지의 내용과 형식에 대해서는 "OSPF 메시지(2) - Hello 패킷 정보 확인"과 "OSPF 메시지(3) - Encapsulation"에서 살펴보았다. 이번에는, DR이 사용되는 경우(Broadcast 네트워크나 NBMA 네트워크)에 Hello 메시지의 내용에 어떠한 차이가 있는지 살펴보겠다.
"OSPF DR(1) - 라우터 상태"에서 사용한 시험망을 재사용할 것이며, 다음은 "OSPF DR(1) - 라우터 상태"에서 사용한 시험망 구조와, 시뮬레이션 수행시 실제로 할당된 IP주소 내역을 보인 것이다.

이 때, R2 노드(DR other)에서 R4 노드(DR)로 전달되는 Hello 메시지는 다음과 같이 관찰된다.

R4 노드(DR)에서 R2 노드(DR other)로 전달되는 Hello 메시지는 다음과 같이 관찰된다.

그리고, R2 노드(DR other)에서 R1 노드(DR other)로 전달되는 Hello 메시지도 다음과 같이 관찰된다.

R1 노드(DR other)에서 R2 노드(DR other)로 전달되는 Hello 메시지도 다음과 같이 관찰된다.

즉, Hello 메시지는 Adjacenct 노드간뿐만아니라 Neighbor 노드간("OSPF DR(3) - 이웃 상태" 참조)에도 교환된다.

Riverbed(OPNET) Modeler WLAN 모델에서 사용되는 MCS(Modulation & Conding Scheme)는 데이터 전송 속도에 따라서 달라진다. 즉, 사용자가 설정해준 데이터 전송 속도에 의해 MCS 레벨이 선택되며, 시뮬레이션 도중에 동적으로 변화하지는 않는다.
16.1 버전에서 사용되는 데이터 전송 속도별 MCS 레벨을 살펴보면 다음과 같다(17.5 PL5 버전까지는 동일하다). 변조(Modulation) 방식만 구분되며, 코딩률(Coding Rate)은 구분되지 않기 떄문에 MCS로 표현하기에는 조금 부족한 면이 있다.

데이터 전송 속도가 11Mbps일 때 변조방식은 CCK11임을 표에서 확인할 수 있다. "WiFi 모델에서의 통신 가능 거리"에서 분석할 당시까지의 OPNET 버전에서는 WiFi 모델의 "Data Rate (bps)"의 기본값이 11Mbps였으며, CCK11 변조방식에 대한 BER 커브를 분석에 사용한 것은 이 때문이었다.

Riverbed(OPNET) Modeler의 라이센스는 floating 형태로 설치하더라도 동일한 서브넷 상에 속한 단말에서만 사용할 수 있다.
단일 연구실이나 부서에서 사용할 경우에는 이러한 특성이 별 문제가 되지 않지만, 서브넷 주소가 다른 여러 부서에서 공동으로 사용하거나 여러 사업장을 가진 회사에서 사용할 경우에는 문제가 된다. 이러한 경우VPN 사용이 좋은 대책이 될 수 있다. VPN을 사용하면 서로 다른 서브넷에 속한 Riverbed(OPNET) Modeler 사용자들을 라이센스 서버와 동일 서브넷으로 만들어 줄 수 있기 때문이다.

Riverbed Modeler 18.7.0 버전이 지난 1월22일자로 발표되었습니다(이번 버전에 관한 내용은 "Riverbed Modeler18.6.1 발표" 참조). 공지가 없어서 배포된 줄도 몰랐네요. Riverbed사의 다른 제품군에 대한 업데이트 안내는 Modeler 사용자에게도 꼬박꼬박해주더니 정작 Modeler에 대한 업데이트 안내는 안해주네요. 상당히 당황스럽습니다.
Release notes를 통해 변경 사항을 살펴보았습니다. 모델 업데이트는 2가지입니다.

- Wireless LAN Model Enhancement
- Software-Defined Networking (SDN) Model Enhancement

WLAN 모델 개선 사항은 802.11ac Very High Throughput(VHT)에 대한 지원입니다. 세부적으로는 80MHz 대역폭 전송, 정적/동적 대역폭 선택 방법, 최대 8개의 spatial 스트림, 256-QAM 모듈레이션, VHT MPDU/PPDU 포맷, A-MSDU와 A-MPDU에 대한 보다 큰 최대 크기 적용, 11n과 11a 기술에 대한 하위호완성 등입니다.
SDN 모델 개선 사항은 Barrier Request/Response 메시지와 Role Request/Response 메시지 추가입니다.

이외에 버그 및 마이너한 개선사항 4건도 포함되었습니다만, 현재 관심이 가는 내용이 아니라서 생략합니다.