네트워크 시뮬레이션 공방

WiFi 인터페이스를 사용하는 노드들간의 기본적인 통신 가능거리에 대해서는 "WiFi 모델에서의 통신 가능 거리"에서, 확산이득과 Reception threshold의 영향에 대해서는 "WiFi 모델에서의 통신 가능 거리(2)"에서, delay의 영향에 대해서서는 "WiFi 모델에서의 통신 가능 거리(3)"에서 살펴본 바 있다.
이러한 기존의 분석에서는 BER 기준으로 10^-4을 사용하였다. 그러면, BER이 10^-4만 만족하면 항상 통신이 잘 이루어지는 것일까? 그렇지는 않다. BER 10^-4은 분석을 위해 필자가 임의로 정한 기준이었을 뿐이며 실제로는 각 시험 환경에 따라 달라질 수 있다.
이번에는 MAC 사용자 계층을 기준으로 99.9%의 패킷 전달률을 유지할 수 있는 최대 거리는 어디까지인지를 살펴보기로 하자. 802.11b 11Mbps 환경에서 237Bytes 크기의 MAC 사용자 패킷을 100Kbps로 전송하는 경우를 가정하였으며, 명기한 항목외에는 Riverbed(OPNET) WLAN 노드 모델의 기본 설정을 그대로 사용였다. 또한, 지형모델(TMM)을 적용하지 않았으며, 아무런 interference 신호도 존재하지 않을 경우로 한정하였다.
Riverbed(OPNET) WiFi 모델에서 802.11b 11Mbps로 데이터 전송시 사용되는 모듈레이션 방식은 CCK11이며("WiFi MCS 레벨 (16.1 버전)" 및 "WiFi MCS 레벨 (17.5 PL6 버전)" 참조),Processing Gain은 0 이다("WiFi 변조 방식별 프로세싱 게인 (16.1 버전)" 및 "WiFi MCS 레벨 프로세싱 게인 (17.5 PL6 버전)" 참조). Riverbed(OPNET)에서 사용하는 CCK11 변조방식의 BER 커브는 다음 그림과 같다.

237Bytes의 MAC SDU 패킷을 전송할 때 송신 포트에서 내보내는 패킷의 크기는 237Bytes(MAC SDU 패킷) + 28Bytes(MAC 오버헤드) + 192usec * 11Mbps(PLCP 오버헤드) / 8 = 529Bytes(4,232bits)이다. (PLCP 오버헤드 계산에 대해서는 "WLAN PLCP 오버헤드 크기" 참조) MAC에서의 최대 전송 횟수는 기본값인 7이 적용된다.
이상의 정보로부터 BER별 MAC 사용자 패킷 전달률(Throughput)과 최대거리(distance)를 계산해보면 다음과 같이 예상할 수 있다.

  - BER이 8.1x10^-5 일 때: MAC 사용자 패킷 전달률 99.98%, 이 때의 SNR은 7.25dB이므로 최대 거리는 약 1,024M.
  - BER이 2.5x10^-4 일 때: MAC 사용자 패킷 전달률 94.94%, 이 때의 SNR은 6.75dB이므로 최대 거리는 약 1,084M.
  - BER이 4.4x10^-4 일 때: MAC 사용자 패킷 전달률 69.31%, 이 때의 SNR은 6.5dB이므로 최대 거리는 약 1,116M.
  - BER이 2.1x10^-3 일 때: MAC 사용자 패킷 전달률 0.10%, 이 때의 SNR은 5.75dB이므로 최대 거리는 약 1,217M.

이제 시뮬레이션을 통해 이 예측을 확인해 보자. 2대의 WLAN 터미널 스테이션 노드를 배치하고, Physical Characteristics은 "Direct Sequence"로, Data Rate (bps)는 "11Mbps"로 설정한다. 트래픽은 237Bytes 크기의 패킷을 1초마다 발생시켜 다른 WLAN 터미널 스테이션 노드로 전송하도록 설정하였다.
1,024M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 예측(전달률 99.98%)과는 미세한 차이가 있는 결과(전달률 100%)이나, 오차범위 내로 볼 수 있다.

다음으로 1,084M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 예측(전달률 94.94%)과는 미세한 차이가 있는 결과(전달률 약 95.50%)이나, 오차범위 내로 볼 수 있다.

다음으로 1,116M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 예측(전달률 69.31%)과는 미세한 차이가 있는 결과(전달률 약 71.25%)이나, 오차범위 내로 볼 수 있다.

다음으로 1,217M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 예측(전달률 0.10%)과는 미세한 차이가 있는 결과(전달률 약 0.25%)이나, 오차범위 내로 볼 수 있다.

Riverbed(OPNET) Modeler TCP 모델에서는 사용자 편의를 위하여 TCP 버전 및 OS별로 속성값들이 조정된 TCP 프로파일("OS별 TCP 프로파일 (16.1 버전)" 참조)을 제공한다. 새로운 OS가 등장함에 따라 OS별 기본 프로파일의 추가가 이루어져왔으며("OPNET Modeler 17.1 PL1 발표" 참조), 17.5 버전("OPNET Modeler 17.5 PL6 발표" 참조)에서 제공되는 TCP 프로파일은 Windows 7, Andriod, FreeBSD 8.2, HP-UX 10.x/11.x, iPad, iPhone, Linux 2.6, Mac OS X, NT (3.5/4.0), Solaris 2.6, Solaris 2.7, Solaris 2.8, Solaris 2.9, Windows 98, Windows 2000, Windows Server 2003, Windows Server 2008, Windows Vista, Windows XP, Tahoe, Reno, New Reno, SACK, Full-Featured, Default 이다.
16.1 버전후에 새롭게 추가된 프로파일 중 자주 사용되는 프로파일의 세부 속성항목들의 값을 살펴보면 다음 표와 같다.

ospf_interface_v2 프로세스 모델에서 DR 선출이 필요없는 경우와 DR 선출이 필요한 경우에 대한 스테이트 천이 과정은 "OSPF 인터페이스 프로세스(2) - 천이 순서"에서 살펴보았다. 이번에는 시뮬레이션 수행시에 실제로 이 분석 결과대로 천이가 일어나는지 ODB(OPNET Debugger)의 Show Animation 기능("무선망에서의 패킷 전송 애니메이션 보기" 참조)을 통해 확인해보도록 하자.
다음 그림은 DR 선출이 필요없는 경우의 스테이트 천이 애니메이션을 보기 위해 "OSPF 라우팅 예제"에서 사용한 시나리오를 활용한 예제망 구조를 나타낸 것이다.

R1 노드에서 R2 노드와 연결된 인터페이스를 담당하는 ospf_interface_v2 프로세스의 스테이트 천이 애니메이션을 살펴보면 다음 영상과 같다. Down -> Point-to-Point 스테이트 순서로 천이하는 것을 확인할 수 있다.

동일한 링크를 사용하는 R2 노드에서 R1 노드와 연결된 인터페이스의 스테이트 천이 애니메이션을 살펴보면 다음 영상과 같다. R1 노드에서와 마찬가리로 Down -> Point-to-Point 스테이트 순서로 천이하는 것을 확인할 수 있다.

다음 그림은 DR 선출이 필요한 경우의 스테이트 천이 애니메이션을 보기 위해 "OSPF DR(1) - 라우터 상태"에서 사용한 시나리오를 활용한 예제망 구조를 나타낸 것이다.

R1 노드에서 Hub 노드와 연결된 인터페이스를 담당하는 ospf_interface_v2 프로세스의 스테이트 천이 애니메이션을 살펴보면 다음 영상과 같다. Down -> Wating -> Calc DR -> DR Other 스테이트 순서로 천이하는 것을 확인할 수 있다.

R2 노드에서 Hub 노드와 연결된 인터페이스의 스테이트 천이 애니메이션을 살펴보면 다음 영상과 같다. Down -> Wating -> Calc DR -> DR Other 스테이트 순서로 천이하는 것을 확인할 수 있다.

R3 노드에서 Hub 노드와 연결된 인터페이스의 스테이트 천이 애니메이션을 살펴보면 다음 영상과 같다. Down -> Waiting -> Clac DR -> DR Other -> Calc DR -> Backup 스테이트 순서로 천이하는 것을 확인할 수 있다.

R4 노드에서 Hub 노드와 연결된 인터페이스의 스테이트 천이 애니메이션을 살펴보면 다음 영상과 같다. Down -> Waiting -> Calc DR -> DR 스테이트 순서로 천이하는 것을 확인할 수 있다.

이러한 천이 과정은 모두 "OSPF 인터페이스 프로세스(2) - 천이 순서"에서 살펴본 내용과 일치하는 것이다.

tracert 명령어를 Riverbed(OPNET) Modeler SITL 모듈과 연동시켜 사용할 경우 정상적으로 동작하지 않음은 "SITL tracert 예제(1)"에서 살펴보았다. 이를 명확히 하기 위해서 좀 더 복잡한 망 구조에서 다시 확인해보도록 하겠다.
다음은 "SITL Ping 예제(2)"의 시험망에서 Access_2 노드를 상대로 tracert 명령어를 사용했을 때의 결과를 보인 것이다.

Access_2 노드는 SITL 게이트웨이로부터 4홉 거리에 있으며, ping 요청에 대해서 정상적으로 응답하였다. 하지만, 중간에 위치한 Access1, R2, R1 노드에서는 응답을 하지않아 중간 경로 확인은 불가능함을 알 수 있다.

32비트 OS 시스템에서는 Riverbed(OPNET) Modeler 18.0.3 버전("Riverbed Modeler 18.0.3 발표" 참조)까지만 사용할 수 있으며, 18.5.0 버전("Riverbed Modeler 18.5.0 발표" 참조)부터는 사용할 수 없다.
32비트 윈도우즈 시스템에서 18.5.0 이후의 버전을 설치하려고 하면, 다음 그림처럼 "Java VM 로드 중 Windows 오류 216 발생" 에러 메시지를 발생시키고 설치가 중지된다.

에러 메시지만 보고는 32비트 OS에 의한 제약점인지 파악하기가 쉽지 않다. 더군다나, 이런 중요한 사항이 release note에 제대로 기술되어 있지 않은 것은 사용자들에게 큰 혼란을 줄수 있다고 보여진다.

"GRP 쿼드런트 예제"에서 사용한 예제망에서 데이터 패킷이 전달되는 과정을 통해 GRP의 동작 결과를 좀 더 확인해보기로 하자. 시뮬레이션을 수행한 후, STA_1 노드에서 STA_8 노드로의 패킷 전달 경로를 살펴보면 다음 그림과 같다.

데이터 패킷은 STA_1 -> STA_2 -> STA_5 -> STA_8 경로로 전달되었음을 보여주고 있다. 이 경로가 사용된 이유를 좀더 세부적으로 살펴보면 다음과 같다.

- STA_1 -> STA_2 : STA_1 노드의 이웃 노드인 STA_2, STA_3, STA_4 노드중 (STA_8 노드가 속한) Ab3 쿼드런트와 가장 인접한 노드가 STA_2 노드이므로, STA_2 노드가 다음 홉으로 사용되었다("GRP 다음 홉 선정" 및 "GRP 쿼드런트와의 거리 계산" 참조).
- STA_2 -> STA_5 : STA_2 노드의 이웃 노드인 STA_1, STA_4, STA_5 노드중 (STA_8 노드가 속한) Ab3 쿼드런트에 속한 노드가 STA_5 노드이므로, STA_5 노드가 다음 홉으로 사용되었다("GRP 다음 홉 선정" 참조).
- STA_5 -> STA_8 : STA_5 노드의 이웃 노드인 STA_2, STA_6, STA_7, STA_8 노드중 STA_8 노드가 동일한 Ab3 쿼드런트에 속해있으며 목적지이므로, STA_8 노드가 다음 홉으로 사용되었다.

TDMA 네트워크에는 각 멤버 노드들에 대한 자원 할당을 제어하는 네트워크 제어기(Network Controller)가 필요하다. Riverbed(OPNET) Modeler TDMA 모델에서는 별도의 제어기 노드 모델을 사용하지 않으며, 모든 TDMA 노드는 네트워크 제어기로 사용될 수 있다.
어느 노드가 네트워크 제어기로 동작할지의 여부는 사용자 설정에 따른다. 다음 그림은 사용자가 TDMA 네트워크 제어기 동작 여부를 설정할 수 있도록 Riverbed(OPNET) Modeler에서 제공하는 속성 설정창을 보인 것이다. 하나의 TDMA 네트워크에는 한개의 네트워크 제어기만 동작하여야 하며, 복수 개의 네트워크 제어기가 동작하도록 설정해서는 안된다.

네트워크 제어기는 멤버 노드들에 대한 자원 할당을 제어하는 것외에 중계 역활도 수행한다. 네트워크 제어기 노드는 목적지가 자신이 아닌 데이터 패킷이 수신되면 다른 멤버 노드들이 받아볼 수 있도록 이를 다시 TDMA 네트워크로 재전송한다.

Riverbed(OPNET) Modeler에서 OSPF 인터페이스 관리를 담당하는 ospf_interface_v2 프로세스 모델의 구조는 "OSPF 인터페이스 프로세스(1) - State Diagram"에서 살펴보았다. 이번에는 OSPF 인터페이스 상태 변화에 따른 ospf_interface_v2 프로세스 모델 state diagram에서의 천이 과정을 살펴보기로 하자.
시뮬레이션이 시작된후 OSPF 라우팅 테이블이 완성되기까지(즉, 인터페이스가 처음 활성화 된후 장애가 발생하지 않은 경우)의 상태 천이 과정을 추적해보면 다음 그림과 같다.

큰 범주에서는 DR 선출이 필요없는 경우와 DR 선출이 필요한 경우의 2가지 구분되며, 이는 인터페이스 종류("OSPF 인터페이스 종류" 참조)에 따라 결정된다.

1) DR 선출이 필요없는 경우("OSPF 라우팅 예제" 참조) : Point-to-point 인터페이스일 때만 해당하며, Down -> Point-to-Point 스테이트의 순서로 천이한다. DR 선출이 필요없으므로 상태천이 과정이 매우 단순한다.

2) DR 선출이 필요한 경우("OSPF DR(1) - 라우터 상태" 참조) : Broadcast, NBMA 등의 인터페이스일 때에 해당하며, 해당 노드가 DR 또는 BDR 노드로 선출되는가에 따라 천이 과정이 달라진다.
2-1) DR 노드로 선출되는 경우: Down -> Waiting -> Calc DR -> DR 스테이트의 순서로 천이한다.
2-2) BDR 노드로 선출되는 경우: Down -> Waiting -> Clac DR -> DR Other -> Calc DR -> Backup 스테이트의 순서로 천이한다.
2-3) DR/BDR 노드로 선출되지 않는 경우 : Down -> Wating -> Calc DR -> DR Other 스테이트의 순서로 천이힌다.

EIGRP에서 제공하는 UCMP에서는 Traffic Share 속성을 추가로 사용하여 로드 밸런싱(부하 분산)을 더 세밀하게 조정할 수 있음을 "다중경로 라우팅(9) - UCMP에서의 로드 밸런싱"에서 살펴보았다. 이번에는 Traffic Share 방법으로 Balanced 방식을 선택했을 때와 Minium 방식을 선택했을 때 동작이 어떻게 차이나는지 예제를 통해 확인해보도록 하자.
다음 그림은 Traffic Share 방법간의 차이를 비교하기 위하여, "다중경로 라우팅(7) - UCMP"에서 사용한 시나리오를 수정하여 작성한 시험망의 구조를 나타낸 것이다. R1 노드와 R4 노드 사이에 R5 노드를 배치하고 R1 <-> R2, R2 <-> R4 링크와 동일한 대역폭을 가지는 링크로 연결하였다.

Traffic Share 방법이 Minimum 방식일 경우와 Balanced 방식일 경우의 라우팅 경로를 비교해보면 다음 그림과 같다. Minimum 방식일 때에는 최소 metric 값을 가지는 2개의 경로만 사용되었지만, Balanced 방식일 때에는 최소 metric 비용을 가지는 경로를 포함하여 3개의 경로가 사용되었음을 확인할 수 있다.

트래픽이 실제로 분산된 양을 확인하기 위하여 R1 -> R2, R1 -> R5, -> R1 -> R3 링크의 트래픽 유통량을 살펴보면 다음 그림과 같다.

Minimum 방식일 때에는 대역폭이 큰(즉, 최소 metric 값을 가지는) R1 -> R2 링크와 R1 -> R5 링크로만 트래픽이 분산되었지만, Balanced 방식일 때에는 대역폭이 작은(즉, 비용이 큰) R1 -> R3 링크로도 일부 트래픽이 분산되었음을 확인할 수 있다.

RREQ_RETRIES는 RREQ 메시지의 최대 재전송 횟수를 지정하기 위하여 사용되며, Riverbed(OPNET) Modeler AODV 모델은 RREQ_RETRIES 값을 지정할 수 있는 기능을 제공한다. 다음 그림은 사용자가 RREQ_RETRIES 값을 설정할 수 있도록 Riverbed(OPNET) Modeler에서 제공하는 속성 설정창을 보인 것이다.

0 이상의 정수값을 입력할 수 있으며, 기본값은 5 이다.