네트워크 시뮬레이션 공방

AODV에서 라우팅 테이블을 구성할 때에는 홉 카운트(Hop count)를 기준으로 사용한다[1]. 즉, RIP나 OSPF의 cost("RIP에서의 네트워크 비용" 및 "OSPF에서의 링크 비용" 참조)에 해당하는 요소가 AODV에서는 홉인 것이다.
RIP에서도 cost를 1로 설정하면 홉 카운트와 동일한 의미가 된다(대부분 이렇게 사용한다)는 점에서는 RIP와 유사한 측면이 있다. 하지만, RIP에서와는 달리 AODV에서 사용하는 홉 값은 사용자가 변경할 수 없는 값이므로, 완전히 동일하지는 않다.  
Riverbed(OPNET) Modeler AODV 모델에서도 홉 정보는 내부적으로만 관리되며, 사용자가 변경할 수 없게 되었다.

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

EIGRP에서 라우팅 테이블을 구성할 때 사용되는 Metric은 bandwidth, load, delay, reliability 정보로부터 계산된다[1, 2]. CISCO사의 제품에서는 각 metric 항목별 비중을 계수를 통해 조정할 수 있으며, Riverbed(OPNET) Modeler의 EIGRP 모델 역시 이와 동일한 기능을 제공한다.
다음 그림은 Riverbed(OPNET) Modeler에서 제공하는 EIGRP 메트릭 계수(coefficient) 설정창을 보인 것이다.

이 계수들은 다음의 수식[1, 2]에서 Metric을 계산하는데 사용된다.

이 때 bandwidth는 대역폭값 그대로가 아니라 10^7/(인터페이스 전송 속도)로 조정된 값이다. Delay는 인터페이스 전송 속도에 의해 지정[2]된다.

[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

OSPF에서는 이웃(Neighbor) 노드의 상태를 Down, Attempt, Init, 2-Way, ExStart, Exchange, Loading, Full로 구분하며, 이웃 노드의 상태가 ExStart 이상일 때를 Adjacency 관계라고 한다[1]. Riverbed Modeler(OPNET) OSPF Model에서도 이웃 노드와 이러한 관계가 맺어져 있음을 시뮬레이션을 통해 확인해보기로 하자. 다음은 "OSPF 라우팅 예제"에서 사용한 시험망 구조와, 시뮬레이션 수행시 실제로 할당된 IP주소 내역을 보인 것이다.

이 때, R2 노드와 연결된 R1 노드 인터페이스에서 구성된 이웃 정보를 ODB를 통해 살펴보면 다음과 같다.

R2 노드와 (Full 상태이므로) Adjacency 관계로 맺어져 있음을 확인할 수 있다. 이 정보는 [2]에서 제시한 양식을 따른 것이다.

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

STP(Spanning Tree Protocol)은 스위치간의 루프를 방지하기 위한 프로토콜이며, Riverbed(OPNET) Modeler에도 구현되어 있다. 다음 그림은 STP 동작을 확인하기 위한 시험망 구조를 나타낸 것이다, 이더넷 스위치인 SW1 ~ SW4 노드를 격자형으로 연결하였다(즉, 루프가 발생한다). R1 ~ R4 노드는 라우터인데, IP 망 구조를 명확하게 하기 위해 연결한 것이며 스위치간의 STP 동작과는 관련이 없다.

다음 그림은 시뮬레이션 수행 후 스위치간에 구성된 Spanning Tree를 나타낸 것이다. SW1 노드가 Root로 선정되었으며, SW3 노드와 SW4 노드간의 링크가 차단(붉은색으로 표시)되어 루프를 방지하는 것을 확인할 수 있다.

이제 Client1 노드에서 Server1 노드로 향하는 트래픽과 Client2 노드에서 Server2 노드로 향하는 트래픽의 전달 경로를 살펴보면 다음 그림과 같다. SW3 노드와 SW4 노드간의 링크가 논리적으로 차단되어 있으므로, Client2 노드에서 Server2 노드로 향하는 트래픽이 이 링크를 사용하지 못하고 Client2-->R3-->SW3-->SW1-->SW2-->SW4-->R4-->Server2 경로를 통하여 전달되고 있음을 알 수 있다.

시스템 성능에 비하여 과도한 트래픽이 사용된 것이 아님에도 불구하고, 시스템 NIC에 수신된 패킷이 Riverbed(OPNET) SITL 게이트웨이로 넘겨지는 과정에서 일부가 누락되는 경우가 있다. VLC 프로그램을 사용하여 비디오 스트리밍 트래픽을 발생시키는 경우에 이러한 현상이 확인되었으며, 그 원인은 패킷 간격때문인 것으로 생각된다.

1) 다음 그림은 Gigabit 이더넷 인터페이스를 통해 Iperf로 30Mbps 트래픽을 발생시켰을 때 수신된 패킷 간격을 측정한 것이다. 패킷 간격이 수백us인 것을 확인할 수 있으며, Riverbed(OPNET) SITL GW에서 패킷 누락없이 처리된다.

2) 다음 그림은 VLC를 사용하여 평균이 수Mbps인 트래픽을 발생시켰을 때 수신된 패킷 간격을 측정한 것이다. 패킷들이 집중된 구간에서는 때때로 수us 간격으로 패킷이 수신되는 것을 확인할 수 있으며, Riverbed(OPNET) SITL GW
에서 패킷 누락이 발생한다.

"RIP 라우팅 예제"에서 사용한 예제망의 라우팅 프로토콜을 OSPF로 변경하여 OSPF의 동작을 확인해보기로 하자. 첫번째 예제의 네트워크 토폴로지와 실제로 할당된 IP주소 내역은 다음과 같다.

시뮬레이션을 수행한 후, R1 노드에서 구성된 라우팅 테이블을 살펴보면 다음 그림과 같다. ("라우팅 경로 확인하기" 참조).

R2 - R4, R3 - R4, R4 - Server 네트워크에 대한 라우팅 정보가 OSPF에 의해 생성되었으며, R2 - R4, R3 - R4 네트워크에 대한 Metric은 4, R4 - Server 네트워크에 대한 Metric은 5임을 확인할 수 있다. (R4 - Server 네트워크에 대해서 2개의 경로 정보가 구성된 것은 ECMP 때문이다. ECMP의 영향에 대해서는 이후의 글에서 살펴볼 것이다.) "OSPF에서의 링크 비용"에서 설명하였듯이 OSPF는 대역폭 정보로부터 계산된 인터페이스의 비용을 기본 Metric으로 사용하며, 기본값 사용시 DS3(44.746Mbps) 링크의 비용은 2, Fast Ethernet(100Mbps) 링크의 비용은 1로 계산된다. 따라서, R1 -> R2 -> (R4) 경로와 R1 -> R3 -> (R4) 경로의 Metric은 2 + 2 = 4가 되며, R1-> R2-> R4 -> (Server) 경로의 Metric은 2 + 2 + 1= 5가 된다.

Client 노드로부터 Server 노드로의 트래픽 전달 경로는 다음과 같이 2홉 경로(R1 -> R3 -> R4 경로)으로 확인되며, 이는 라우팅 테이블과 일치한다. (이후의 1홉 예제의 결과와 비교할 것이므로 R1 -> R3 -> R4 경로, 또는 R1 -> R2 -> R4 경로 어느 쪽이던 별 상관은 없다)

이제 R1 노드와 R4 노드사이에 1홉 링크를 추가하여 OSPF의 특성을 보다 자세히 살펴보자. 다음 그림은 첫번째 예제를 변형한 두번째 예제의 구조이다. R1 노드와 R4 노드 사이에 다른 링크(DS3)보다 작은 대역폭의 링크(DS1)를 추가하였다.

시뮬레이션을 수행한 후, 두 번재 시나리오에서 R1 노드에 구성된 라우팅 테이블을 살펴보면 다음 그림과 같다.

R1 노드와 R4 노드를 연결하는 링크가 추가되었음에도 불구하고 R4 - Server 네트워크에 대한 경로는 변경이 없으며, Metric도 동일하게 5임을 확인 할 수 있다.
이제 Client 노드로부터 Server 노드로의 트래픽 전달 경로를 살펴보면 라우팅 테이블의 구성과 같이 2홉 경로(R1 -> R3 -> R4)인 것을 알 수 있다.

즉, 기본적으로 OSPF는 링크의 대역폭 정보로부터 계산된 인터페이스의 비용을 기반으로 라우팅 경로를 선정한다. 만약, 링크(인터페이스) 비용이 더 작은 경로가 존재하는 경우라면, 홉 수에 상관없이 해당 경로를 라우팅 경로로 선정한다.

512bytes 크기의 데이터가 30ms 간격으로 발생하며 TCP Ack를 응답받는데 걸리는 시간이 충분히 큰 경우, TCP Nagle 알고리즘을 사용하지 않은 경우와 사용한 경우의 동작을 예측해보면 다음과 같다.

이제 시뮬레이션을 통해 이 예측이 맞음을 확인해보도록 하자. 다음 그림은 TCP Nagle 알고리즘의 동작을 시험하기 위해서 "TCP Window Scaling(1) - LFN에서의 동작"에서 사용한 시나리오를 수정한 시험망 토폴로지를 나타낸 것이다. Server 노드와 STA 노드 사이의 RTT는 100ms가 되도록 설정한다.

Nagle 알고리즘을 사용하지 않은 경우와 사용한 경우의 비교를 위하여, Server 노드와 STA 노드의 "Nagle Algorithm" 속성값을 다음 그림과 같이 Disabled로 설정한 시나리오와 Enabled로 설정한 시나리오를 작성한다.

시뮬레이션을 수행한 후, Nagle 알고리즘이 실제로 수행되었음은 다음 그림처럼 TCP 송신측(이 시나리오에서는 Server 노드)에서 측정된 "Send Delay (Nagle's) (sec)" 결과항목값을 관찰하여 확인할 수 있다. ("Nagle Algorithm" 속성값을 Disabled로 설정한 시나리오에서는 값이 기록되지 않는다)

"Send Delay (Nagle's) (sec)" 결과항목값은 Nagle 알고리즘의 수행여부를 확인하는데는 유용하지만, Nagle 알고리즘의 효과를 확인하기에는 충분하지 않다.
Nagle 알고리즘으로 인한 효과를 확인하기 위해서, Server 노드에서 전송한 IP 패킷의 수를 비교해보면 Nagle 알고리즘을 사용한 경우에 네트워크로 내보낸 패킷의 수가 다음 그림처럼 크게(이 시나리오에서는 약 1/3 수준으로) 감소하였음을 확인할 수 있다.

패킷의 수는 이처럼 크게 감소하지만 전송된 데이터의 양에는 차이가 없다. 다음 그림은 전송된 데이터 양이 동일함을 확인하기 위하여, STA 노드의 TCP 단에서 수신한 트래픽 양을 비교한 것이다.

동일한 양의 데이터를 훨씬 작은 수의 패킷으로 전달 할 수 있다면, Nagle 알고리즘을 사용하는 것이 항상 유리한 것일까? 그렇지는 않다. Nagle 알고리즘은 네트워크로 내보내는 패킷의 수를 줄이기 위해 작은 크기의 패킷 전송을 제한하므로, 지연(Delay) 측면에서는 불리하다. 다음 그림은 이를 확인하기 위해서 STA 노드에서 측정한 TCP 데이터의 지연을 나타낸 것이다. Nagle 알고리즘을 사용한 경우가 사용하지 않은 경우보다 큰(이 시나리오에서는 2배 이상) 지연을 가지는 것을 확인할 수 있다.

어제(2015년 12월 1일) Riverbed Modeler 18.5.0 버전이 발표되었습니다(이전 버전에 관한 내용은 "Riverbed Modeler 18.0.3 발표" 참조). Release note에는 11월 5일로 표기되어 있습니다만, 실제로 배포된 것은 12월 1일이 맞습니다.
Release note에 따르면, LTE 모델에 대한 기능 개선과 버그 수정(총 6건)이 변경된 사항입니다.

LTE 모델 개선 사항은 다음과 같습니다.
- Semi-Persistent Scheduling

Semi-Persistent Scheduling(SPS)는 음성과 같이 작은 크기의 패킷이 일정한 간격으로 발생하는 경우에 유용한 Scheduling 방법으로, SPS 기능의 추가와 함께 해당 기능의 설정을 위해 LTE Config 노드와 eNodeB 노드에 관련 파라미터들이 추가되었다고 합니다.

이외에도, 제품 구조상의 변화(Flow Analysis 등 몇 개의 기능이 제외되고 ODK가 표준 기능으로 포함됨)와 ZigBee 모델 기능 개선에 대한 설명도 있습니다만, 제품 구조의 이러한 변화는 18.0 버전에서 적용된 사항("Riverbed Modeler 18.0 발표" 참조)이고 ZigBee 모델 기능 개선은 18.0.3 버전에서 적용된 사항("Riverbed Modeler 18.0.3 발표" 참조)이므로, 18.5 버전에서 새롭게 변경된 사항들은 아닙니다.(Riverbed Modeler로 변경된 이후로는 Release note가 좀 보기 혼란스럽게 작성된다는 느낌이 드네요).

Riverbed(OPNET) Modeler WiMAX 모델에서 Multi-path fading이 계산되는 구조는 다음 그림과 같다.

SNR이 계산되면 Modulation/Coding 기법과 multi-path 종류에 따라 fading이 포함됨 Effective SNR로 변환하는 EESM(Exponential Effective SNR Mapping) 과정을 통해 multi-path fading을 반영한다. EESM의 계산 공식은 다음과 같다.

r_eff는 effective SNR이며, r_i는 i_th 서브캐리어의 순시 SNR이다. N은 서브캐리어의 수이며, beta는 MCS에 따라 변하는 계수값이다.
Riverbed(OPNET) Modeler에서는 시뮬레이션 수행시 이 공식을 직접 적용하는 대신 사전에 이 공식에 따라 계산해둔 테이블(EESM Coefficient array)을 이용하는 방식을 사용한다. EESM Coefficient 행렬 선택에는 현재의 페이딩 스테이트가 필요하다. 페이딩 스테이트는 FSMC(Finite State Markove Chain)에 의해서 결정되며, 시테이트의 수는 16개이다. 이러한 스테이트 변환은 1ms마다 일어나며, 스테이트간의 천이는 Multi-path channel 모델에 따라서 선택된 TPM(Transition Probability Matrix)에 의해서 결정된다. TPM도 사전에 계산해둔 행렬값을 사용한다.

OPNET Modeler 17.5("OPNET Modeler 17.5 PL6 발표" 참조)은 공식적으로는 MS Visual Studio 2010 버전까지만을 지원한다.
하지만, 실제로는 OPNET Modeler 17.5에서 MS Visual Studio 2013을 사용하여도 컴파일시 에러는 발생하지 않는다. (그렇더라도, MSVS 2013이 OPNET Modeler 17.5에서도 항상 문제없이 동작한다고 필자가 보장할 수는 없다.)