네트워크 시뮬레이션 공방

UDP는 사용하는 RIP나 TCP를 사용하는 BGP와는 달리, OSPF는 TCP/UDP 계층을 거치지 않고 IP 계층을 직접 사용하여 메시지를 전달한다[1]. 이러한 차이는 다음 그림처럼 Riverbed(OPNET) Modeler에서 제공하는 노드 모델의 구조에서도 쉽게 확인할 수 있다. 즉, RIP는 UDP 계층위에 위치하지만, OSPF는 IP 계층 바로 위에 위치한다.

OSPF 메시지가 TCP/UDP를 사용하지 않고, IP 계층으로 바로 전달됨은 OSPF 메시지에 대한 Enacapsulation 구조를 통해서도 알 수 있다. 다음 그림은 "OSPF 메시지(2) - Hello 패킷 정보 확인"에서 살펴본 OSPF Hello 메시지를 담고 있는 패킷 정보를 확인한 것이다. TCP 패킷이나 UDP 패킷을 통한 Enacapsulation 과정없이, OSPF 패킷이 IP 패킷에 바로 Enacapculation 되어 있는 것을 확인할 수 있다.

OSPF 메시지를 싣고 있는 IP 패킷의 목적지 주소로는 OSPF 메시지의 종류와 단계에 따라 2가지가 사용된다. 이 IP 패킷은 OSPF Hello 메시지를 싣고 있으므로 멀티캐스트 주소인 224.0.0.5가 목적지 IP 주소로 사용되었다[1].
다음 그림은 OSPF DBD(DataBase Description) 메시지를 싣고 있는 IP 패킷을 살펴본 것인데, 수신측 인터페이스의 IP 주소인 192.0.1.2이 목적지 주소로 사용되었다.

다음 그림은 OSPF LSU(Link-State Update) 메시지를 싣고 있는 IP 패킷을 살펴본 것인데,멀티캐스트 주소인 224.0.0.5가 목적지 IP 주소로 사용되었다

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

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

목적지 노드가 동일한 경우에 Destination-Based 방식과 Packet-Based 방식의 로드 밸런싱이 어떤 차이를 보이는지에 대해서는 "다중경로 라우팅(4) - 동일 목적지 예제"에서 살펴보았다. 이번에는 목적지 노드가 다수인 경우(즉, 서비스 플로우들의 목적지가 다른 경우)에 대해서 살펴보겠다.
다음은 10개의 트래픽 플로우가 라우팅 경로가 중첩되는 다수의 목적지 노드로 향하는 경우의 예제망 구조
이다("다중경로 라우팅(1) - ECMP"의 예제망에서 확장). Client 노드에서 Server_1 ~ 10 노드로 향하는 트래픽 플로우는 "다중경로 라우팅(4) - 동일 목적지 예제"와 유사하게 100초마다 하나씩 트래픽을 발생시키도록 설정하였다(이는 트래픽 증가에 따른 로드 밸런싱 효과를 관찰하기 위해서이다).

로드 밸런싱이 Destination-Based 방식인 경우와 Packet-Based 방식인 경우에 Client 노드로부터 Server_1 ~ 10 노드로의 트래픽 전달 경로를 비교해보면 다음 그림과 같다. Destination-Based 방식인 경우 개별 트래픽 플로우는 하나의 라우팅 경로를 통해서만 전달되지만, 전체 트래픽 플로우 관점에서는 다중 경로를 통해 분산되어 전달(R1 -> R3 -> R4와 R1 -> R2 -> R4)된다. Packet-Based 방식인 경우 각 트래픽 플로우는 다중 경로를 통해 분산되어 전달(R1 -> R3 -> R4와 R1 -> R2 -> R4)된다.

R1 -> R2 링크와 R1 -> R3 링크의 트래픽유통량을 살펴보면 다음 그림과 같다.

두 방식 모두 다중 경로(R1 -> R2, R1 -> R3 링크)로 트래픽이 분산되었다. 하지만, Destination-Based 방식인 경우 다중 경로로 분산된 트래픽의 양이 불균등한 반면, Packet-Based 방식인 경우 다중 경로로 균등하게 분산되었음을 확인할 수 있다. 즉, 라우팅 경로가 중첩되는 다수 목적지에 대해서는 Packet-Based 방식보다 공평성이 떨어지기는 하지만, Destination-Based 방식도  로드 밸런싱 효과가 있다("다중경로 라우팅(3) - 로드 밸런싱" 참조).

"WiFi 모델에서의 통신 가능 거리(3)"에서 살펴본 것처럼 WiFi 노드간의 최대 거리는 300미터로 가정되지만, 이보다 먼 거리의 노드들간에도 시뮬레이션은 별 문제없이 수행된다. 그러면, 송신 파워만 충분히 높다면 WiFi 인터페이스를 사용하는 장비들간의 통신 가능 거리에 제약은 없는 것일까? 그렇지는 않은데, 그 이유는 ACK Timeout 때문이다.
IEEE 802.11에서는 DATA 프레임을 송신하면 ACK 프레임을 수신해야만 하며, 지정된 시간안에 ACK가 수신되지 않으면 송신에 실패한 것으로 간주한다. 이 때 ACK가 수신되기를 기다리는 최대 시간이 ACK Timeout 이다. 따라서, 노드간의 거리가 너무 멀어서 ACK Timeout 시간안에 ACK를 수신할 수 없을만큼 propagation delay가 큰 경우에는 통신이 이루어지지 않는다.
표준[1]에 따르면, ACK Timeout은 SIFS, Slot time, PHY-RX-START-Delay의 합으로 구성(ACKTimeout = SIFS + Slot Time + PHY-RX-START-Delay)되며, propagation delay는 Slot time 내에 포함된 것으로 간주된다. 다음은 PHY 종류별 Slot time을 정리한 것이다[1]. Slot time을 구성하는 다른 요소들을 모두 무시한다 할지라도 Slot time이 그리 크지 않으므로, 장거리 전송을 수용할 수 있는 여지는 크지 않다. (802.11에서 propagation delay는 원래 1us 이하로 가정되었다는 점을 잊지말기 바란다.) Slot time과 ACK Timeout을 변경시켜 전송 거리를 증대시킬 수는 있으나[2], 이는 802.11 표준[1] 범위를 벋어난 것이다.

Riverbed(OPNET) Modeler에서 ACK Timeout 값은 상대방이 최저 속도로 ACK 프레임을 전송(transmission)할 때를 가정하고 계산되며, 이 시간안에 응답 프레임에 대한 수신이 시작되면 timeout은 발생하지 않는다(이 부분은 표준[1]과 조금 차이가 있다). 따라서, propagation delay가 최저 속도로 ACK 프레임을 전송하는 transmission delay 미만이면 정상적으로 동작하므로, 전송 거리에 상당한 여분이 있는 편이다.

"30Km 거리에 대한 WiFi 통신 시뮬레이션 실험"에서, 11g로는 통신이 잘 되는데 11a로는 통신이 되지않는 것도 이러한 이유때문인 것으로 생각된다.

[1] IEEE Std 802.11, "Wireless LAN MAC and PHY Specifications", IEEE, 2007.
[2] http://www.air-stream.org/Change_ACK

TCP 영속(persistence) 타이머는 probe 세그먼트[1, 2]을 보내는 시간 간격을 조정하기 위하여 사용되며, Riverbed(OPNET) Modeler TCP 모델은 persistence 타이머 값을 지정할 수 있는 기능을 제공한다. 다음 그림은 사용자가 persistence 타이머 값을 설정할 수 있도록 Riverbed(OPNET) Modeler에서 제공하는 속성 설정창을 보인 것이다.

이 속성에는 실수값을 입력할 수 있으며 기본값은 1.0, 즉 1초이다.

[1] RFC 793, "TRANSMISSION CONTROL PROTOCOL", IETF, Sep. 1981.
[2] RFC 1122, "Requirements for Internet Hots -- Communication Layers", IETF, Oct. 1989.

SITL 모듈을 사용하는 시뮬레이션을 실행하다보면 다음 그림처럼 real-time ratio가 잘못 설정되었다는 오류 메시지가 보이는 경우가 있다.

오류 메시지의 내용을 자세히 살펴보면 다음과 같다. 즉,  SITL 모듈을 사용하기 위해서는 real-time ratio가 1로 설정되어야 하는데, 현재 1로 설정되어 있지 않다는 것이다.
----
<<< Warning >>>
Use of the SITL module typically requires a real-time ratio of 1.0.
The real-time ratio is currently set to 0.000.
Use the "sitl_realtime_ratio_check" preference to eliminate this warning.
----
이 오류를 해결하기 위해서는 시뮬레이션 설정창에서 Real-time execution ratio 속성을 1로 설정해주면 된다. Real-time execution ratio는 시뮬레이터 시간과 실세계 시간과의 비율이며, SITL 모듈을 사용하는 경우는 대부분 실세계 시스템과 연동이 필요하므로 시뮬레이터 시간이 실세계 시간과 동일한 속도로 진행되도록 조절할 필요가 있다. Real-time execution ratio 값 1은 시뮬레이터 시간이 실세계 시간과 동일한 속도로 흐르도록 한다는 의미이다.

GRP(Geographic Routing Protocol)는 MANET 라우팅 프로토콜 중 하나로써, 위치기반 라우팅 알고리즘을 사용한다. Riverbed(OPNET) Modeler에서 모델을 제공하는 다른 프로토콜들과는 달리, GRP는 OPNET사에서 자체적으로 개발[1]한 매우 독특한 프로토콜이다.
GRP는 표준 문서가 따로 없으며 Riverbed(OPNET) Modeler에서 제공하는 모델이 바로 표준이라고 볼 수 있다. 때문에 GRP에 대한 참고 문헌은 매우 부족한 편이다. Riverbed(OPNET) Modeler에서 제공하는 문서에는 GRP의 동작방식에 대해서는 거의 설명되어 있지 않으며, 몇 편의 논문들[2, 3, 4]에서 언급하고 있기는 하나 세부적인 사항에 대해서는 설명이 제한적이다. 따라서, GRP의 세부적인 동작에 대한 확인은 GRP 모델의 코드에 의존해야 하는 실정이다.

[1] OPNET Technologies, "Understanding MANET Model Internals and Interfaces", OPNETWORK2007, 2007.
[2] Li Zhiyuan, "Geographic Routing Protocol and Simulation", WCSE 2009, 2009.
[3] Rob Hussey, Earl Huff, Zabih Shinwari, and Vasil Hnatyshin, "A Comparative Study of Proactive and Reactive Geographical Routing Protocols for MANET", ICWN 13, 2013.
[4] Shuai Yang, Rngxi He, Sen Li, Bin Lin, Ying Wang, "An Improved Geographical Routing Protocol and its OPNET-based Simulation in VANETs", BMEI 2014, 2014.

윈도우에서 Visual Studio 2013을 컴파일러 사용하기 위한 환경 변수 설정. (Riverbed Modeler 18.0.3("Riverbed Modeler 18.0.3 발표" 참조)까지도 Visual Studio 2013 Express는 지원 컴파일러 목록에 포함되어 있지 않다. 하지만, 설치 및 동작에 큰 문제는 없는 것으로 보여진다.
Riverved(OPNET) Modeler를 위한 환경 변수 설정 방법은, Visual Studio 2010 버전 이후로는 동일하("Visual Sutdio 2010을 위한 환경 변수 설정" 참조)

1) VS2013 콘솔에서 "set INCLUDE"를 실행한다.
2) "INCLUDE=" 뒤부터 출력문을 복사한다.
3) 환경변수 입력창에서 시스템 변수에 "INCLUDE" 항목을 추가하고, 복사해둔 내용을 변수 값에 입력한다. (동일 항목이 기존에 존재하면, 값만 추가)
4) VS2013 콘솔에서 "set LIB"를 실행한다.
5) "LIB=" 뒤부터 "LIBPATH=" 전까지의 출력문을 복사한다.
6) 환경변수 입력창에서 시스템 변수에 "LIB" 항목을 추가하고, 복사해둔 내용을 변수 값에 입력한다. (동일 항목이 기존에 존재하면, 값만 추가)
7) VS2013 콘솔에서 "set Path"를 실행한다.
8) "Path=" 뒤부터 "C:\Windows\system32;"까지의 출력문을 복사한다.
9) 환경변수 입력창의 시스템 변수에서 "Path" 항목을 찾고, 본사해둔 내용을 변수 값에 추가한다.

다음 그림은 Riverbed(OPNET) Modeler에서 AODV 프로토콜이 동작하는 WLAN 노드 모델의 구조를 보인 것이다. 그런데, 해당 라우팅 프로토콜에 대한 프로세서 모듈이 바로 식별되는 RIP나 OSPF와는 달리, AODV는 프로세서 모듈이 직접 보이지 않는다.

그럼 AODV 프로세스는 어디에 위치하는 것일까? 일반적으로는 UDP를 사용하는 AODV의 특성[1]을 고려하면 UDP 계층위의 manet_rte_mgr 프로세서 모듈에 위치할 것 같지만, 실제로는 다음 그림처럼 ip 프로세서 모듈 내부에 차일드 프로세스 형태로 존재한다.

이러한 프로토콜 계층 구성은 사용자들에게 혼란을 주는 AODV 모델의 문제점이다. 사실 Riverbed(OPNET) Modeler에서는 계층 개념을 정확히 준수하지 않고도 충분히 표준에 맞는 프로토콜을 구현할 수 있다. 하지만, 대부분의 프로토콜은 계층 구조를 준수하여 구현되어 있으며, 계층 구조에 맞지 않은 위치에 구현되어 있는 경우는 AODV 모델외에는 아직 보지 못했다.

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

OSPF Hello 메시지("OSPF 메시지(1) - Hello 패킷 포맷" 참조)에 실제로 어떤 정보가 실려서 전달되는지, "OSPF 라우팅 예제"에서 사용한 예제를 활용하여 시뮬레이션을 통해 확인해보기로 하자. 다음은 "OSPF 라우팅 예제"에서 사용한 시험망 구조와, 시뮬레이션 수행시 실제로 할당된 IP주소 내역을 보인 것이다.

이 때, R1 노드에서 R2 노드로 전달되는 Hello 메시지 정보를 ODB를 통해 살펴보면 다음과 같다.

각 필드에 실린 정보의 의미는 다음과 같다.

- type : OSPF 패킷의 종류. 1은 Hello Packet임을 의미.
- version : OSPF 버전. 2는 OSPFv2를 의미.
- Hello Interval : Hello 메시지 전송 간격. 단위는 초(sec).
- Router Dead Interval : 상대 라우터의 비활성화 여부 판단 시간. 단위는 초(sec).
- priority : DR 선출시에 사용되는 라우터 우선 순위. 1은 기본값.
- options : OSPF 옵션. 2는 ExternalRoutingCapability 비트가 설정되었음을 의미.
- Router ID : Hello 메시지를 보내는 라우터의 ID. 192.0.2.1은 이 예제망에서 R1 노드의 Router ID이다.
- Area ID : Hello 메시지가 속한 Area의 ID. 이 예제망에서는 Area가 설정되지 않았으므로, 0.0.0.0으로 지정된다.
- Network Mask : Hello 메시지를 보내는 인터페이스에 사용되는 Metwork Mask.
- DR : DR의 IP 주소. Point-to-point 네트워크에서는 DR이 사용되지 않으므로, 0.0.0.0으로 지정된다.
- Backup DR : BDR의 IP 주소. Point-to-point 네트워크에서는 BDR이 사용되지 않으므로, 0.0.0.0으로 지정된다.

"EIGRP 메트릭"에서 설명하였듯이, EIGRP에서 Metric 계산시 Delay는 인터페이스 전송 속도에 의해 지정[2]된다. 다음은 Riverbed(OPNET) Modeler EIGRP 모델에서 사용하는 Delay 값 변환 표이다.

[1] http://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/16406-eigrp-toc.html#eigrpmetrics
[2] http://www.ietf.org/staging/draft-savage-eigrp-00.txt