네트워크 시뮬레이션 공방

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

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

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

OSPF는 OSPF 메시지가 TCP/UDP를 사용하지 않고, IP 계층으로 바로 전달됨은 "OSPF 메시지(3) - Encapsulation"에서 살펴본 바 있다. 이 때, Point-to-Point 네트워크에서 OSPF 패킷을 싣고 있는 IP 패킷의 목적지 주소로 2가지가(멀티캐스트 주소중 224.0.0.5와 유니캐스트 주소)가 사용되었는데, Broadcast 네트워크(BMA 모드)에서는 3가지(멀티캐스트 주소중 224.0.0.5, 224.0.0.6과 유니캐스트 주소)가 사용된다.
다음은 "OSPF DR(4) - Hello 패킷"의 예제를 사용하여 OSPF 메시지를 담고 있는 패킷 정보를 확인한 것이다. 먼저 DR(R4 노드)에서 전송하는 Hello 패킷을 살펴보면 다음 그림과 같다.

다음은 DR other(R1 노드)에서 전송하는 Hello 패킷을 살펴본 것이다.

DR/DR other 노드 모두 OSPF Hello 메시지를 싣고 있는 IP 패킷의 목적지 주소로는 224.0.0.5가 사용된다[1].
다음 그림은 DR other(R1 노드)에서 전송하는 OSPF DBD(DataBase Description) 메시지를 싣고 있는 IP 패킷을 살펴본 것인데, 수신측 인터페이스의 IP 주소인 192.0.1.4가 목적지 주소로 사용되었다.

다음 그림은 DR other(R1 노드)에서 전송하는 OSPF LSU(Link-State Update) 메시지를 싣고 있는 IP 패킷을 살펴본 것인데, Point-to-point 네트워크("OSPF 메시지(3) - Encapsulation" 참조)와는 달리 멀티캐스트 주소
224.0.0.6이 목적지 IP 주소로 사용되었다.

포트 번호로는 [1]에 정의된 대로 항상 89가 사용된다.

[1] RFC 2328, "OSPF Version 2", IETF, April 1998.

SITL 모듈을 사용하는 시뮬레이션을 MS Windows 환경에서 실행할 때에는 관리자(Administrator) 권한이 필요하다. 관리자 권한이 아닌 상태에서 SITL 모듈을 사용하는 시뮬레이션을 실행하면 다음 그림처럼 에러 메시지는 없지만 시뮬레이션이 정상적으로 진행되지 않고 종료되어 버린다.

시뮬레이션된 시간도 0초이고 처리된 이벤트 수도 0개이므로 실제로는 시뮬레이션이 전혀 진행되지 않은 것이다. 또한, 시뮬레이션이 종료되어 버렸으므로, 시뮬레이션과 외부 장비를 연동시키는 것도 불가능하다. 따라서, SITL 모듈을 사용하는 시뮬레이션 시에는 관리자 권한에 대한 주의가 필요하다.

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) - 이웃 상태" 참조)에도 교환된다.