Riverbed(OPNET) Modeler TCP 모델은 17.1 PL2 버전부터 TCP 연결에 사용되는 링크의 가용 대역폭을 사용자가 지정할 수 있는 Minimum Available Bandwidth 속성을 다음 그림처럼 제공한다("OPNET Modeler 17.1 PL2 발표" 참조).
이 속성에는 0 이상의 실수값을 입력할 수 있으며, 단위는 bps이다. 사전 정의된 값을 선택하는 것도 가능하며, 사전 정의된 값을 가지는 항목들은 다음과 같다.
Riverbed(OPNET) Modeler SITL 모듈 사용시 시나리오상에 배치한 라우터나 단말 노드가 tracert[1]에는 정상적으로 응답하지 않는 문제(?)가 있음은 "SITL tracert 예제(1)"에서 확인하였다. 그 원인은 tracert에서는 ping 요청(ICMP Echo Request)에 대한 응답으로 ICMP Echo Reply 메시지외에 ICMP Time Exceeded 메시지[2]도 사용되는데[3], Riverbed(OPNET) Modeler에는 이에 대한 처리 기능이 구현되어 있지 않기 때문("ip_icmp 프로세스 모델" 참조)이다. 즉, tracert가 정상적으로 동작하기 위해서는 중간 노드에서 TTL 값이 만료된 ICMP 패킷에 대해 Time Exceeded 메시지로 응답해 주어야만 한다. 하지만, Riverbed(OPNET) Modeler에서는 TTL 값이 만료된 IP 패킷은 모두 폐기 처리하므로("IP 패킷 TTL 처리"와 "ICMP 패킷 처리 절차" 참조), tracert가 정상적으로 동작하지 못하는 것이다.
Riverbed Modeler 18.10.0 버전이 지난 4월29일자로 발표되었습니다(이전 버전에 관한 내용은 "Riverbed Modeler 18.9.0 발표" 참조). Release notes에는 4월21일자로 되어 있고 홈페이지에는 4월29일자로 되어있는데, 4월28일에 홈페이지를 확인했을 때는 없었으므로 4월29일이 맞는 것 같습니다. 아쉽게도, 이번에도 메일 공지가 없었습니다. Release notes를 통해 변경 사항을 살펴보았습니다.
18.10.0 버전에서는 드디어 지원 컴파일러가 변경되었다는 점이 가장 중요해보입니다. Riverbed(OPNET) Modeler는 2021년에 발표된 18.9.0 버전에서조차 MS Visual Studio 2013 이하 버전만을 지원하고, MS Visual Studio 2015는 지원하지 않았습니다("Riverbed(OPNET) Modeler 18.x 버전에서의 컴파일러 선택 유의사항" 및 "Visual Studio Community 2013 설치" 참조). 이때문에 Riverbed(OPNET) Modeler 사용에 많은 불편함이 있었고, 최근에는 Visual Studio Community 2013 버전 사용을 위한 인증이 되지 않는(인터넷 익스플로러 지원 종료 이슈 때문인 것으로 짐작되는) 현상도 발생하여 Riverbed(OPNET) Modeler 사용 환경 구축에 어려움이 많았습니다. 다행히 이번 18.10.0 부터는 이러한 불편함이 드디어 해소되었습니다. 지원되는 Windows 컴파일러는 MS Visual Studio 2015, 2017, 2019, 2022 버전이며, Community 버전도 가능합니다.
모델 업데이트는 2가지입니다.
- WLAN Model Enhancements - Configurable Reserved Buffer Size Capacity for Access Category Transmission Queues - OSPF Model Enhancements - A new utility for configuring OSPFv3 area information
Wireless LAN 모델 개선 사항은 AC별 전송 큐 크기에 대한 예약 기법이 적용된다는 것이며, "Buffer Size Sharing Scheme" 파라미터와 "Buffer Size Share (%)" 파라미터가 추가되었다고 합니다. 그리고, 기존에 예고되었던 것처럼("Riverbed Modeler 18.8.0 발표" 참조) 구식이 되어버 IR PHY, FHSS PHY 기능이 제거되었습니다. OSPF 모델 개선 사항은 OSPFv3 영역 정보 설정을 위한 새로운 도구가 Project Editor의 Protocols 메뉴에 추가되었다는 것입니다.
그 외에 버그 수정사항 5건도 있습니다만, 특별히 관심이 가는 내용이 아니라서 생략합니다.
"WiFi 모델에서의 통신 가능 거리(7) - MAC Throughput(3)"에서는 802.11g 24Mbps 환경에서 237Bytes 크기의 MAC 사용자 패킷을 전송할 때, MAC 사용자 계층의 패킷 전달률 관점에서 최대 통신 가능 거리는 어디까지인지를 살펴보았다. 이번에는 동일한 환경(802.11g 24Mbps)에서 1,500Bytes 크기의 MAC 사용자 패킷을 전송할 때, MAC 사용자 계층의 패킷 전달률 관점에서 최대 통신 가능 거리는 어디까지인지를 살펴보기로 하자. 동일한 환경이므로 MCS 레벨(QAM16 1/2)과 프로세싱 게인(MCS gain: -3.01dB, OFDM gain: 2.28dB)은 기존의 분석과 동일하다. 1,500Bytes의 MAC SDU 패킷을 전송할 때 송신 포트에서 내보내는 패킷의 크기는 1,500Bytes(MAC SDU 패킷) + 28Bytes(MAC 오버헤드) + 22.67usec * 24Mbps(PLCP 오버헤드) / 8 = 1,596Bytes(12,768bits)이다. (PLCP 오버헤드 계산에 대해서는 "WLAN PLCP 오버헤드 크기" 및 "WiFi에서의 throughput (5) - 802.11g 최대 throughput" 참조) MAC에서의 최대 전송 횟수는 기본값인 7이 적용된다.
이상의 정보로부터 BER별 MAC 사용자 패킷 전달률(Throughput)과 최대거리(distance)를 계산해보면 다음과 같이 예상할 수 있다. - BER이 8.1x10^-6 일 때: MAC 사용자 패킷 전달률 100%, 이 때의 SNR은 10.63dB이므로 최대 거리는 약 694M. - BER이 1.0x10^-4 일 때: MAC 사용자 패킷 전달률 89.89%, 이 때의 SNR은 9.63dB이므로 최대 거리는 약 779M. - BER이 1.6x10^-4 일 때: MAC 사용자 패킷 전달률 60.93%, 이 때의 SNR은 9.43dB이므로 최대 거리는 약 797M. - BER이 7.9x10^-4 일 때: MAC 사용자 패킷 전달률 0.03%, 이 때의 SNR은 8.73dB이므로 최대 거리는 약 864M.
이제 시뮬레이션을 통해 이 예측을 확인해 보자. 2대의 WLAN 터미널 스테이션 노드를 배치하고, Physical Characteristics은 "Extended Rate PHY (802.11g)"로, Data Rate (bps)는 "24Mbps"로 설정한다. 트래픽은 1,500Bytes 크기의 패킷을 1초마다 발생시켜 다른 WLAN 터미널 스테이션 노드로 전송하도록 설정하였다.
694M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 송수신량이 동일(전달률 100%)하며, 이는 앞의 예측과 일치한다.
다음으로 779M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 예측(전달률 89.89%)과는 미세한 차이가 있는 결과(전달률 약 89.50%)이나, 오차범위 내로 볼 수 있다.
다음으로 797M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 예측(전달률 60.93%)과는 미세한 차이가 있는 결과(전달률 약 58.50%)이나, 오차범위 내로 볼 수 있다.
다음으로 864M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 예측(전달률 0.03%)과는 미세한 차이가 있는 결과(전달률 약 0.25%)이나, 오차범위 내로 볼 수 있다.
Riverbed(OPNET) Modeler OSPF 모델에서 제공하는 "Convergence Activity"와 "Convergence Duration"의 의미에 대해서는 "OSPF 수렴 시간 (1) - Convergence Duration"에서 살펴보았다. 이번에는 예제를 통해 실제 시뮬레이션에서 어떤 결과값이 측정되는지 살펴보기로 하자. 다음은 "OSPF 라우팅 예제"의 예제망에서 측정된 "Convergence Activity"와 "Convergence Duration" 결과값을 보인 것이다.
Convergence가 1번 기록되었는데, convergence activity는 6초대에 시작되어 51초대에 끝났으며 convergence duration은 약 45초로 기록된 것을 알 수 있다. 네트워크가 가동된 후 convergence가 1번만 기록되었으므로 네트워크 개통에서 기인한 OSPF 라우팅 테이블 갱신 완료에 걸린 시간(Convergence time)은 45초로 볼 수 있다.
다음은 "OSPF DR(1) - 라우터 상태"의 예제망에서 측정된 "Convergence Activity"와 "Convergence Duration" 결과값을 보인 것이다.
Convergence가 2번 기록되었는데, 첫번째 convergence acvitiy는 6초대에 시작되어 23초대에 끝났고 convergence duration은 약 17초로 기록되었다. 두번쨰 convergence acvitity는 46초대에 시작되어 64초대에 끝났으며, convergence duration은 약 18초로 기록되었다. 네트워크 개통 이후 추가적인 토폴로지 변경은 없으므로 네트워크 개통에서 기인한 OSPF 라우팅 테이블 갱신 완료에 걸린 시간(Convergence time)은 약 58초(6초 ~ 64초)로 보아야 한다. 23초 ~ 46초 구간은 OSPF 라우팅 테이블 갱신이 완료된 것은 아니지만, "일정 간격" 동안 convergence activity가 없는 상태이다.
OSPF Convergence time으로 각각 45초, 58초가 소요된 이유를 구체적으로 설명하는 것은 대단히 복잡한 작업이며, 라우터들간에 송수신된 메시지와 인터페이스 상태 변화등을 상세히 추적해야만 한다. (OSPF 라우터들간에 송수신된 메시지 순서와 메시지간 상관 관계에 대해서는 이후의 글에서 분석해 볼 예정이다.)
네트워크 토폴로지 변경 횟수가 동일하지만 예제망마다 convergence 기록 횟수가 다른 것은 네트워크 토폴로지의 차이와 convergence(일정 시간 간격 동안 라우팅 테이블 갱신이 없는 것) 도달 여부를 판단하는 "일정 시간" 기준값 때문이다.
Riverbed(OPNET) Modeler에서 ICMP 메시지에 대한 실질적인 처리는 ip_icmp 프로세스 모델에서 담당한다. 다음은 ip_icmp 프로세스 모델의 FSM을 보인 것이다.
request_gen 스테이트에서는 Echo Request 메시지(Ping 요청에 사용)를 생성시키는 기능을 담당한다. request_rcvd 스테이트에서는 해당 노드가 목적지인 Echo Request 메시지에 대한 응답으로 Echo Reply 메시지를 생성하는 기능을 수행한다. reply_received 스테이트에서는 수신된 Echo Reply 메시지 정보를 처리하는 기능을 수행한다. 즉, Riverbed(OPNET) Modeler 18.0.3 버전("Riverbed Modeler 18.0.3 발표" 참조)에서는 ICMP 메시지들[1, 2] 중 Echo Request와 Echo Reply 메시지만 처리된다.
복수 어플리케이션이 필요하므로 기존의 FTP 어플리케이션외에 500KBytes 크기의 파일을 100초마다 전송하는 FTP 어플리케이션을 하나 더 추가하고, Offset은 200초로, Duration은 100초로 설정하였다. (당연히 FTP외에 다른 어플리케이션을 추가하여도 된다. 여기에서는 결과 해석의 편의성때문에 FTP를 다시 추가한 것이다)
먼저 어플리케이션들이 차례로 실행되도록 해보자. 어플리케이션 타이밍의 Repeatiablity를 Once at Start Time으로 설정하고, 프로파일 타이밍의 Operation Mode를 Serial (Ordered)로 설정하였을 때, GW_1 노드로부터 Client 노드로 전송되는 트래픽은 다음 그림과 같다.
200초 길이의 첫번째 어플리케이션이 먼저 실행되어 종료된 후,두번째 어플리케이션이 Offset 시간 200초후에 실행되어 100초간 실행되고 종료되는 것을 확인할 수 있다. 즉, 여러 개의 어플리케이션을 차례대로 원하는 시간 간격으로 실행시킬수 있는 것이다. 다음으로 어플리케이션들이 동시에 실행되도록 해보자. 동일한 어플리케이션 설정을 가지고, 프로파일 타이밍의 Operation Mode를 Simultaneous로 설정하였을 때, GW_1 노드로부터 Client 노드로 전송되는 트래픽은 다음 그림과 같다.
첫번째 어플리케이션은 150초(Start Time 100초 + Offset 50초)에 시작되어 200초간 실행되고, 두번째 어플리케이션은 300초(Start Time 100초 + Offset 200초)에 시작되어 100초간 실행되었음이 확인된다. 300초에서는 두 어플리케이션에서 동시에 트래픽이 발생하여 다른 때보다 더 많은 트래픽이 기록되었음도 알 수 있다.
Gratuitous RREP(Route Reply) flag 정보는 RREQ 메시지("AODV 메시지(2) - RREQ 구조체" 참조)에서 사용되며, RREQ에 대한 응답을 중간 노드에서 대신 처리할 때 RREP를 목적지 노드로도 전송할지의 여부를 알린다[1]. 다음 그림은 사용자가 Gratuitous Route Reply 사용 여부를 설정할 수 있도록 Riverbed(OPNET) Modeler에서 제공하는 속성 설정창을 보인 것이다.
설정 가능한 값은 Enabled와 Disabled이다.
- Enabled : 경로상 목적지 노드 이전에 위치한 중간 노드가 RREQ에 대한 응답 RREP를 생성하는 경우, 소스 노드 뿐만 아니라 목적지 노드로도 RREP를 전송한다. - Disabed : 경로상 목적지 노드 이전에 위치한 중간 노드가 RREQ에 대한 응답 RREP를 생성하는 경우, 소스 노드로만 RREP를 전송한다.
[1] RFC 3561, "Ad hoc On-Demand Distance Vector (AODV) Routing", IETF, July 2003.
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" 결과값을 사용하면 엉뚱한 값을 측정하게 될 수도 있다.
