네트워크 시뮬레이션 공방

GRP에서 backtrack 기능("GRP Backtrack" 참조)이 어떻게 동작하는지 예제를 통해 살펴보도록 하자. 다음은 backtrack 동작을 살펴보기 위한 예제망 구조이다. 쿼드런트("GRP 쿼드런트" 참조) 크기는 2Km로 설정하였으며, 트래픽은 STA_1 노드에서 STA_16 노드로 향하도록 하였다.

시뮬레이션을 수행한 후 데이터 패킷이 전달된 경로를 확인("GRP 라우팅 경로 확인하기" 참조)해보면 다음 그림과 같이 STA_1 -> STA_2 -> STA_5 -> STA_7 -> STA_13 -> STA_16 경로가 사용되었다.

그런데, ODB를 사용하여 데이터 패킷이 각 노드를 거쳐 전달되는 과정을 자세하게 추적해보면, 실제로는 다음 그림과 같이 STA_1 -> STA_4 -> STA_1 -> STA_2 -> STA_4 -> STA_2 -> STA_5 -> STA_7 -> STA_13 -> STA_16 경로를 거쳤음을 보여준다.

여기에서 STA_4 노드에서 STA_1 노드로, STA_4 노드에서 STA_2 노드로 되돌려진 과정이 바로 backtrack이다. 그러면, 왜 이렇게 backtrack이 발생한 것일까? 그 이유는 목적지 쿼드런트와의 거리계산 방식("GRP 쿼드런트와의 거리 계산" 참조)때문이다. 다음 그림은 이를 확인하기 위하여 STA_1 노드에 구성된 목적지 테이블을 분석한 결과를 토폴로지상에 표시한 것이다.

이제 이 쿼드런트 정보를 사용하여 각 단계별로 다음 홉이 선정된 이유를 살펴기로 하자.

(1) STA_1 -> STA_4 : 목적지 노드인 STA_16은 쿼드런트 B에 속해있으며, STA_1 노드의 이웃 노드인 STA_2, STA_3, STA_4 노드중 쿼드런트 B와의 거리가 가장 가까운 노드는 STA_4 노드이므로("GRP 쿼드런트와의 거리
계산" 참조), 데이터 패킷은 STA_4 노드로 전달된다.

(2) STA_4 -> STA_1 : STA_4 노드에서는 자신보다 쿼드런트 B에 더 가까운 이웃 노드를 찾을 수 없으므로, 이전 노드인 STA_1 노드로 패킷을 되돌림(backtrack)한다("GRP Backtrack" 참조).

(3) STA_1 -> STA_2 : STA_1 노드에서는 backtrack된 경로를 제외하고 쿼드런트 B에 가장 가까운 노드인 STA_2 노드로 데이터 패킷을 전달한다.

(4) STA_2 -> STA_4 : STA_2 노드의 이웃 노드인 STA_1, STA_4, STA_5 노드중 쿼드런트 B와의 거리가 가장 가까운 노드는 STA_4 노드이므로, 데이터 패킷을 STA_4 노드로 전달한다.

(5) STA_4 -> STA_2 : STA_4 노드에서는 자신보다 쿼드런트 B에 더 가까운 이웃 노드를 찾을 수 없으므로, 이전 노드인 STA_2 노드로 패킷을 되돌림(backtrack)한다.

(6) STA_2 -> STA_5 : STA_2 노드의 이웃 노드인 STA_1, STA_4, STA_5 노드중 쿼드런트 B와의 거리가 자신보다 가까운 STA_5 노드로 데이터 패킷을 전달한다.

(7) STA_5 -> STA_7 : STA_5 노드의 이웃 노드인 STA_2, STA_6, STA_7, STA_8 노드중 쿼드런트 B와의 거리가 가장 가까운 노드인 STA_7 노드로 데이터 패킷을 전달한다.

(8) STA_7 -> STA_13 : STA_7 노드의 이웃 노드인 STA_5, STA_8, STA_13 노드중 STA_13 노드가 목적지 쿼드런트에 위치하므로, STA_13 노드로 데이터 패킷을 전송한다.

(9) STA_13 -> STA 16 : STA_13 노드의 이웃 노드중에 목적지 노드인 STA_16 노드가 있으므로, STA_16 노드로 데이터 패킷을 전송한다.

Riverbed Modeler의 Urban Propagation Model에 대한 제공 중단이 지난 10월15일자로 아래와 같이 공지되었습니다.

Urban Propagation Model은 Riverbed Modeler 18.0 버전("Riverbed Modeler 18.0 발표" 참조)에서 발표되었던 Urban Propagation Module을 가리키는 것으로 보입니다.
기존에는 Release note에나 포함되었을 법한 내용인데, 이렇게 별도의 공지 메일을 통해 알려주네요. (Modeler 신규 버전 발표는 메일 공지를 잘 안해주면서, 이런 사소한(?) 변경은 또 이렇게 메일 공지를 해주니 당황스럽네요.)

RIP를 사용할 때의 라우팅 테이블과 포워딩 테이블의 비교는 "라우팅/포워딩 테이블 예제(1) - RIP"에서 살펴본 바 있다. 이번에는 OSPF를 사용할 때의 라우팅 테이블과 포워딩 테이블을 비교해 보기로 하자.
예제망은 "OSPF 라우팅 예제"에서 사용한 것을 사용하였다.

이 예제망에 실제로 할당된 IP주소 내역은 다음과 같다.

시뮬레이션을 수행한 후, R1 노드에서 구성된 라우팅 테이블과 포워딩 테이블을 비교하여 살펴보면 다음 그림과 같다. ("OSPF 라우팅 예제"에서는 아래의 포워딩 테이블을 라우팅 테이블 정보를 살펴보기위해서 사용하였지만, 정확하게 말하자면 포워딩 테이블이다).

정보의 항목에서는 조금 차이가 있지만, 저장되어 있는 정보의 내용은 동일한 것을 알 수 있다. 다만, Metric 항목은 RIP의 경우("라우팅/포워딩 테이블 예제(1) - RIP" 참조)와는 달리 라우팅 테이블과 포워딩 테이블에 저장된 값이 조금 차이가 있다. 그리고, OSPF 라우팅 테이블의 일부 정보 항목은 IP 라우팅 테이블에 저장되지 않는 것도 RIP와의 차이점이다.

TDMA 네트워크에서 데이터 전송을 위해서는 슬롯을 할당받아야만 하며 다음 그림은 그 절차를 보인 것이다. (논리적인 이해를 돕기위해 전파지연 시간은 무시하였다.)

동적 할당을 받아야하는 멤버 노드는 전송할 데이터가 있을 경우 제어 슬롯(control slot)을 이용하여 네트워크 제어기("TDMA 네트워크 제어기" 참조) 노드로 자원(슬롯) 할당 요청 메시지를 보낸다. 네트워크 제어기는 다음 프레임의 시작 시점에 고정 할당과 동적 할당("TDMA 자원할당 방식" 참조)에 대한 슬롯 할당을 수행하고, 슬롯 할당 정보를 멤버 노드들에게 알려준다. 멤버 노드는 자신이 할당받은 데이터 슬롯(data slot)을 사용하여 데이터를 전송한다.

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이다. 사전 정의된 값을 선택하는 것도 가능하며, 사전 정의된 값을 가지는 항목들은 다음과 같다.

- Auto-Calculate
- WLAN 11b
- WLAN 11g/11a
- WLAN 11n
- WiMAX
- LTE
- UMTS
- 10Base-T
- 100Base-T
- 1000Base-T

최소 가용 대역폭은 TCP 수신 버퍼 크기가 Auto-Tuning("TCP Receive Buffer(2) - Auto-Tuning" 참조)으로 지정된 경우에, BDP(Bandwidth Delay Product)를 계산하기 위해서 사용된다.

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가 정상적으로 동작하지 못하는 것이다.

[1] https://en.wikipedia.org/wiki/Traceroute
[2] https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol
[3] https://technet.microsoft.com/en-us/library/cc940128.aspx

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(일정 시간 간격 동안 라우팅 테이블 갱신이 없는 것) 도달 여부를 판단하는 "일정 시간" 기준값 때문이다.