Riverbed(OPNET) Modeler OSPF 모델에서 라우팅 테이블의 수렴(convergence) 여부는 특정 convergence activity 이후 "일정 간격" 동안 convergence activity가 없는지(즉, 일정 시간 간격 동안 라우팅 테이블 갱신이 없는지)의 여부를 통해 판단한다("OSPF 수렴 시간 (1) - Convergence Duration" 참조). 이 "일정 간격"은 기본적으로 시뮬레이션 실행시의 "Routing Activity Idle Timer (seconds)" 속성값에 의해 정해진다.
다만, OSPF에서는 라우팅 테이블 갱신 작업이 SPF Hold Time에 의해 연기될 수 있으므로 SPF Hold Time 범위내의 시간 값도 같이 고려된다.
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 노드로 모두 전달되었음을 보여준다.
