Visual Studio 2022 버전이 나와있는 시점이지만, 아직도 어쩔 수 없이 Visual Studio 2013 버전을 사용해야하는 경우가 있기에 정리해두고자 한다. (Riverbed Modeler는 2021년에 발표된 18.9.0 버전조차도 Visual Studio 2013 이하 버전만을 지원한다.)
3) 나열된 Visaul Studio 2013 제품군중에서 Visual Studio Community 2013 with Update 5 제품을 선택하고, 다운로드 받는다.
Express Edition 과 Community Edition 차이는, Express Edition은 규모 목적에 상관없이 기업에서도 사용 가능하지만 Community Edition은 기업 사용에 일부 제한이 있다는 점이다.("https://korbillgates.tistory.com/154"참조)
TDMA 모델에서 각 노드별로 자원 할당 크기를 사전에 지정하지 않고, 동적 할당("TDMA 자원 할당" 참조)을 사용하여도 트래픽이 정상적으로 전달됨을 살펴보기로 하자. 다음 그림은 이를 확인하기 위한 TDMA 예제망 구조를 보인 것이며, "TDMA 예제(1) - 균등 고정 할당"의 예제망 구조와 동일하다.
TDMA 프로파일로는 Default를 사용하였으며, 고정 할당되는 슬롯의 수는 STA_1, STA_2, STA_3, STA_4 노드 모두 0으로 설정하였다. 시뮬레이션을 수행한 후, 각 노드에서 할당받은 프레임당 슬롯수를 살펴보면 다음 그림과 같다. 노드별 슬롯 할당 수를 지정해주지 않았지만 노드별로 슬롯 할당이 이루어지고 있으며, 특히 100초 ~ 300초 구간의 STA_3 노드처럼 특정 시간대에 전송해야할 트래픽이 많은 노드에 슬롯이 더 많이 할당된 것을 알 수 있다.
STA_1 노드에서 STA_2 노드로 향한 트래픽의 송수신량을 살펴보면 다음 그림과 같다. STA_1 노드에서 발생한 트래픽이 STA_2 노드로 모두 전달되었음을 보여준다.
STA_3 노드에서 STA_4 노드로 향한 트래픽의 송수신량을 살펴보면 다음 그림과 같다. STA_3 노드에서 발생한 트래픽(200Kbps)도 STA_4 노드로 모두 전달되었음을 보여준다.
라우팅 프로토콜 성능 분석에 있어 중요한 결과 항목 중의 한가지는 라우팅 테이블 수렴 시간(Convergence Time)이다. 이는 네트워크 토폴로지에 변경이 발생(또는, 최초 가동)되었을 때 이 정보를 라우팅 테이블에 반영 완료하는데 걸리는 시간을 의미한다. OSPF의 Global Statistics 결과 항목들을 보면 다음 그림과 같이 "Network Convergence Activity" 항목과 "Network Converence Duration (sec)" 항목을 볼 수 있다.
얼핏 보기에는 "Network Convergence Activity"와 "Network Convergence Duration" 결과값만 측정하면 OSPF 라우팅 테이블 갱신 활동이 수행된 시간과 라우팅 테이블이 완성(안정화)되는데 걸린 시간을 쉽게 알 수 있을 것처럼 생각된다. 하지만, 이 두 결과 항목은 우리가 일반적으로 생각하는 라우팅 테이블 수렴 시간(Convergence Time)과는 약간 의미가 다르므로 결과값 해석시 주의가 필요하다.
"Network Convergence Activity"와 "Network Convergence Duration" 결과값은 별도의 메커니즘을 통해 계산되는 것은 아니며, 각 노드의 OSPF "Router Convergence Activity"와 "Router Convergence Duration (sec)" 결과 항목값이 취합되어 기록된 것이다. Node Statistics의 OSPF 그룹에 속한 "Router Convergence Activity" 결과 항목에 대한 설명을 살펴보면 다음과 같다. Convergence activity가 없는 구간에서는 0, 있는 구간에서는 1이 기록된다는 것을 알 수 있다. (Convergence acvitity란 LSA 수신/생성을 의미한다.) ================================================== Records a square wave alternating between ordinates 0 and 1. It is 0 during the time interval in which no sign of convergence activity is detected; it is 1 during the time interval in which there are signs of convergence activity. ==================================================
역시 Node Statistics의 OSPF 그룹에 속한 "Router Convergence Duration (sec)" 결과 항목에 대한 설명을 살펴보면 다음과 같다. OSPF 라우팅 테이블이 수렴하는데 걸린 시간이 기록되며, 이 때의 수렴 시간(Convergence Time)이란 첫 번째 Convergence activity 발생시점으로부터 해당 convergence activity 이후 일정 간격 동안 convergence activity가 없는 특정 convergence activity 발생시점까지의 경과시간을 의미한다는 것을 알 수 있다. ================================================== Records the time it takes the OSPF routing table on this router to convergence. The convergence time is the time elapsed since a first sign of convergence activity occurs (initially, or with each new disturbance) until the a sign of convergence activity occurs that is followed by a certain interval of no convergence activity. In this case, we take a sign of convergence activity to mean a recomputation of the OSPF routing table. ==================================================
여기에서 주목해야 할 점은 "일정 간격"이라는 표현이다. 즉, 해당 convergence activity 이후 "영원히" convergence activity가 없는 마지막 convergence activity까지의 경과시간이 아니라, 해당 convergence activity 이후 "일정 간격" 동안 convergence activity가 없는 특정 convergence activity까지의 경과시간이라는 것이다. 간혹 이 사실을 간과하고 네트워크 토폴로지 변경(혹은 최초 가동)으로부터 기인한 라우팅 테이블 갱신이 완전히 끝나는 OSPF 수렴 시간을 측정하는 용도로 "Convergence Duration" 결과값을 사용하면 엉뚱한 값을 측정하게 될 수도 있다.
GRP는 목적지 노드까지 전달 가능한 것으로 확인된 경로를 사용하여 다음 홉을 결정하는 것이 아니라, 쿼드런트("GRP 쿼드런트" 및 "GRP 쿼드런트 레벨" 참조) 개념을 기반으로 가장 거리가 짧을 것으로 예상되는 경로상에 위치한 노드를 다음 홉으로 사용한다. 따라서, 데이터 패킷을 전달받은 중간 노드에서 실제로는 목적지 노드로 전달할 경로가 존재하지 않거나, 적절한 경로를 찾을 수 없는 경우도 발생한다. 이런 경우에 데이터 패킷을 폐기하지 않고 다른 경로를 찾도록 하는 기능이 Backtrack이다. GRP의 Backtrack 기능은 노드 속성편집창에서 활성화/비활성화 여부를 설정할 수 있다.
ICMP 패킷 역시 다른 IP 패킷과 동일하게 목적지 검사("IP 패킷 목적지 검사" 참조)와 TTL 처리("IP 패킷 TTL 처리" 참조) 절차를 거친다. IP 패킷 목적지를 검사한 결과 해당 노드가 목적지이고 IP 패킷의 프로토콜 타입이 ICMP이면, 해당 IP 패킷은 ICMP 패킷을 담당하는 프로세스로 전달된다. 다름 그림은 이러한 ICMP 패킷에 대한 처리 절차를 나타낸 것이다.
"라우팅 테이블과 포워딩 테이블"에서 설명한 것처럼, Riverbed(OPNET) Modeler에서 라우팅 테이블과 포워딩 테이블은 (비록 비슷한 정보가 저장된다 할지라도) 구분된다. 두 테이블의 유사점과 차이점을 "RIP 라우팅 예제"에서 사용한 예제망을 통해 확인해 보기로 하자.
이 예제망에 실제로 할당된 IP주소 내역은 다음과 같다.
시뮬레이션을 수행한 후, R1 노드에서 구성된 라우팅 테이블과 포워딩 테이블을 비교하여 살펴보면 다음 그림과 같다. ("RIP 라우팅 예제"에서는 아래의 포워딩 테이블을 라우팅 테이블 정보를 살펴보기위해서 사용하였지만, 정확하게 말하자면 포워딩 테이블이다).
정보의 항목 수에서는 조금 차이가 있지만, 저장되어 있는 정보의 내용은 동일한 것을 알 수 있다. 또한, 일반적인 예상(?)과는 달리, 포워딩 테이블이 라우팅 테이블보다 더 많은 정보 항목으로 구성되어 있음도 확인할 수 있다.
다음 그림은 수신 버크 크기 자동 조정 기능이 실제로 잘 동작 하는지를 확인하기 위하여 "TCP Window Scaling(1) - LFN에서의 동작"에서 사용한 시나리오를 수정한 시험망 토폴로지를 나타낸 것이다. STA 노드에서 Discarder_1 노드로 향하는 링크의 전송속도를 512K, DS1, OC3로 변경해가며 시뮬레이션을 수행하였으며, 이는 "TCP Receive Buffer(2) - Auto-Tuning"에서 살펴본 것처럼, 수신 버퍼 크기가 BDP(Bandwidth Delay Product) 크기에 의해 결정되기 때문이다.
시뮬레이션을 수행한 후, Server 노드에서 측정된 Remote Receive Window Size (bytes) 결과 항목의 값을 살펴보면 다음 그림과 같다.
150초 무렵에 데이터 전송이 시작된 후, 수신측(STA 노드)의 버퍼 크기가 점차 증가하는 모습을 명확히 확인할 수 있다. 또한, 수신측(STA 노드)의 BDP가 클수록 수신 버퍼 크기의 최대값도 크다는 것도 알 수 있다.
"WiFi 모델에서의 통신 가능 거리(5) - MAC Throughput(1)"에서는 802.11b 11Mbps 환경에서 237Bytes 크기의 MAC 사용자 패킷을 전송할 때, MAC 사용자 계층의 패킷 전달률 관점에서 최대 통신 가능 거리는 어디까지인지를 살펴보았다. 이번에는 동일한 크기(237Bytes)의 MAC 사용자 패킷을 802.11g 24Mbps 환경에서 전송할 때, MAC 사용자 계층의 패킷 전달률 관점에서 최대 통신 가능 거리는 어디까지인지를 살펴보기로 하자. Riverbed(OPNET) WiFi 모델에서 802.11g 24Mbps로 데이터 전송시 사용되는 MCS 레벨은 QAM16 1/2이며("WiFi MCS 레벨 (17.5 PL6 버전)" 참조), Processing Gain은 MCS 레벨에 의한 -3.01dB와 OFDM에 의한 2.28dB이다("WiFi MCS 레벨 프로세싱 게인 (17.5 PL6 버전)" 참조). Riverbed(OPNET)에서 사용하는 QAM16 1/2 MCS의 BER 커브는 다음 그림과 같다.
237Bytes의 MAC SDU 패킷을 전송할 때 송신 포트에서 내보내는 패킷의 크기는 237Bytes(MAC SDU 패킷) + 28Bytes(MAC 오버헤드) + 23.67usec * 24Mbps(PLCP 오버헤드) / 8 = 336Bytes(2,688bits)이다. (PLCP 오버헤드 계산에 대해서는 "WLAN PLCP 오버헤드 크기" 및 "WiFi에서의 throughput (5) - 802.11g 최대 throughput" 참조) MAC에서의 최대 전송 횟수는 기본값인 7이 적용된다. 이상의 정보로부터 BER별 MAC 사용자 패킷 전달률(Throughput)과 최대거리(distance)를 계산해보면 다음과 같이 예상할 수 있다.
- BER이 1.2x10^-4 일 때: MAC 사용자 패킷 전달률 99.99%, 이 때의 SNR은 9.53dB이므로 최대 거리는 약 788M. - BER이 4.1x10^-4 일 때: MAC 사용자 패킷 전달률 93.92%, 이 때의 SNR은 9.03dB이므로 최대 거리는 약 834M. - BER이 7.9x10^-4 일 때: MAC 사용자 패킷 전달률 59.26%, 이 때의 SNR은 8.73dB이므로 최대 거리는 약 864M. - BER이 3.9x10^-3 일 때: MAC 사용자 패킷 전달률 0.02%, 이 때의 SNR은 7.93dB이므로 최대 거리는 약 947M.
이제 시뮬레이션을 통해 이 예측을 확인해 보자. 2대의 WLAN 터미널 스테이션 노드를 배치하고, Physical Characteristics은 "Extended Rate PHY (802.11g)"로, Data Rate (bps)는 "24Mbps"로 설정한다. 트래픽은 237Bytes 크기의 패킷을 1초마다 발생시켜 다른 WLAN 터미널 스테이션 노드로 전송하도록 설정하였다. 788M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 예측(전달률 99.99%)과는 미세한 차이가 있는 결과(전달률 100%)이나, 오차범위 내로 볼 수 있다.
다음으로 834M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 예측(전달률 93.92%)과는 미세한 차이가 있는 결과(전달률 약 93.25%)이나, 오차범위 내로 볼 수 있다.
다음으로 864M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 예측(전달률 59.26%)과는 미세한 차이가 있는 결과(전달률 약 57.50%)이나, 오차범위 내로 볼 수 있다.
다음으로 947M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 예측(전달률 0.02%)과는 미세한 차이가 있는 결과(전달률 약 0.25%)이나, 오차범위 내로 볼 수 있다.
