라우팅 프로토콜 성능 분석에 있어 중요한 결과 항목 중의 한가지는 라우팅 테이블 수렴 시간(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" 결과값을 사용하면 엉뚱한 값을 측정하게 될 수도 있다. 

Posted by 신상헌
,

GRP는 목적지 노드까지 전달 가능한 것으로 확인된 경로를 사용하여 다음 홉을 결정하는 것이 아니라, 쿼드런트("GRP 쿼드런트" 및 "GRP 쿼드런트 레벨" 참조) 개념을 기반으로 가장 거리가 짧을 것으로 예상되는 경로상에 위치한 노드를 다음 홉으로 사용한다. 따라서, 데이터 패킷을 전달받은 중간 노드에서 실제로는 목적지 노드로 전달할 경로가 존재하지 않거나, 적절한 경로를 찾을 수 없는 경우도 발생한다. 이런 경우에 데이터 패킷을 폐기하지 않고 다른 경로를 찾도록 하는 기능이 Backtrack이다.
GRP의 Backtrack 기능은 노드 속성편집창에서 활성화/비활성화 여부를 설정할 수 있다.

 

 

'Riverbed Modeler(OPNET) > GRP Model' 카테고리의 다른 글

GRP Backtrack 예제  (0) 2022.10.27
GRP 쿼드런트 레벨 예제  (0) 2021.03.21
GRP 쿼드런트 레벨  (0) 2020.07.20
GRP 라우팅 예제(1)  (0) 2020.03.11
GRP 라우팅 경로 확인하기  (0) 2019.10.01
Posted by 신상헌
,

ICMP 패킷 역시 다른 IP 패킷과 동일하게 목적지 검사("IP 패킷 목적지 검사" 참조)와 TTL 처리("IP 패킷 TTL 처리" 참조) 절차를 거친다. IP 패킷 목적지를 검사한 결과 해당 노드가 목적지이고 IP 패킷의 프로토콜 타입이 ICMP이면, 해당 IP 패킷은 ICMP 패킷을 담당하는 프로세스로 전달된다.
다름 그림은 이러한 ICMP 패킷에 대한 처리 절차를 나타낸 것이다.

 

 

'Riverbed Modeler(OPNET) > IP Model' 카테고리의 다른 글

ICMP 메시지(1) - 패킷 포맷  (0) 2022.11.12
ip_icmp 프로세스 모델  (0) 2022.03.21
IP 포워딩 테이블 구조  (0) 2021.11.07
다중링크 라우팅  (0) 2021.01.07
IP 패킷 TTL 처리  (0) 2020.10.11
Posted by 신상헌
,

"라우팅/포워딩 테이블 예제(1) - RIP"에서 살펴본 포워딩 테이블 정보는 Riverbed(OPNET) Modeler 내부에서 다음 그림과 같은 구조로 저장된다.

 

'Riverbed Modeler(OPNET) > IP Model' 카테고리의 다른 글

ip_icmp 프로세스 모델  (0) 2022.03.21
ICMP 패킷 처리 절차  (0) 2021.12.12
다중링크 라우팅  (0) 2021.01.07
IP 패킷 TTL 처리  (0) 2020.10.11
IP 패킷 목적지 검사  (0) 2020.06.07
Posted by 신상헌
,

"라우팅 테이블과 포워딩 테이블"에서 설명한 것처럼, Riverbed(OPNET) Modeler에서 라우팅 테이블과 포워딩 테이블은 (비록 비슷한 정보가 저장된다 할지라도) 구분된다. 두 테이블의 유사점과 차이점을 "RIP 라우팅 예제"에서 사용한 예제망을 통해 확인해 보기로 하자.

 


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

 


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

 


정보의 항목 수에서는 조금 차이가 있지만, 저장되어 있는 정보의 내용은 동일한 것을 알 수 있다. 또한, 일반적인 예상(?)과는 달리, 포워딩 테이블이 라우팅 테이블보다 더 많은 정보 항목으로 구성되어 있음도 확인할 수 있다.

Posted by 신상헌
,

다음 그림은 수신 버크 크기 자동 조정 기능이 실제로 잘 동작 하는지를 확인하기 위하여 "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가 클수록 수신 버퍼 크기의 최대값도 크다는 것도 알 수 있다.

Posted by 신상헌
,

"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%)이나, 오차범위 내로 볼 수 있다.

 

 

Posted by 신상헌
,

RREQ_RATELIMIT는 해당 노드에서의 초당 RREQ 메시지 생성 횟수를 제한하기 위하여 사용되며, Riverbed(OPNET) Modeler AODV 모델도 다음 그림처럼 RREQ_RATELIMIT 값을 지정하기 위한 속성 항목을 제공한다.

 


하지만, Riverbed(OPNET) Modeler AODV 모델에서 이 속성값은 실제로 시뮬레이션시에 사용되지 않으며, 결과에 아무런 영향을 미치지 않는다. 기본값은 10.

'Riverbed Modeler(OPNET) > AODV Model' 카테고리의 다른 글

AODV Destination Only Flag  (0) 2023.04.03
AODV Gratuitous Route Reply Flag  (0) 2022.02.06
AODV 메시지(7) - 패킷 크기  (0) 2020.05.24
AODV Route Request Retries  (0) 2020.01.14
AODV 메시지(6) - Hello  (0) 2019.11.02
Posted by 신상헌
,

OSPF Model에서 실제로 Hello 메시지가 전송되는 간격은 Hello Inteval 값과 정확히 일치하지 않는다("Hello Interval" 참조). 다음은 이를 확인하기 위하여 "Hello Interval" 예제에서 실제로 Hello 메시지가 송신된 간격을 표로 정리한 것이다.

 


간격이 계속 변화하며, 그 값이 10초(Hello Interval 속성 값)보다는 약간 큰 것을 알 수 있다. 이렇게 Hello 메시지 간격이 지정된 Hello Interval 값보다 큰 이유는 Riverbed(OPNET) Modeler OSPF Model에는 Hello Jitter 시간이 추가로 반영되어 있기 때문이다.
Hello Jitter 값을 17.5 PL6 버전("OPNET Modeler 17.5 PL6 발표" 참조)까지는 사용자가 변경할 수 없으며, 18.0 버전("Riverbed Modeler 18.0 발표" 참조)부터는 GUI를 통해 변경할 수 있다. 다음 그림은 Riverbed(OPNET) Modeler 18.7.0 버전("Riverbed Modeler 18.7.0 발표" 참조)에서 제공하는 Hello Jitter 설정창을 보인 것이다. 입력값은 Hello Interval에 대한 비율을 의미한다.

 

 

Posted by 신상헌
,

고정 할당 방식에서도 노드별로 슬롯 수를 다르게 할당할 수 있다. 즉, 전송량이 많은 노드에는 슬롯을 많이 할당해주고, 전송량이 작은 노드에는 적게 할당해줄 수 있다. "TDMA 예제(1) - 균등 고정 할당"의 예제에서 STA_3 노드에는 필요한 양보다 작은 수의 슬롯이 할당되었기 때문에, STA_3 노드에서 STA_4 노드로 향하는 트래픽이 제대로 전달되지 못했다. STA_3 노드에 더 많은 슬롯을 할당해주어 이 문제를 해결할 수 있음을 확인해보기로 하자. 다음 그림은 이를 확인하기 위한 TDMA 예제망 구조를 보인 것이며, "TDMA 예제(1) - 균등 고정 할당"의 예제망 구조와 동일하다.

 


TDMA 프로파일로는 Default를 사용하였으며, 이 때 사용할 수 있는 44개의 데이터 슬롯을 STA_1 노드에 11개, STA_2 노드에 8개, STA_3 노드에 14개, STA_4 노드에 11로 나누어 할당하였다. Default TDMA 프로파일일 경우, 프레임("TDMA 프레임 구조" 참조) 길이는 100ms이고 슬롯당 데이터 전송량은 200Bytes이므로 14개의 슬롯을 할당받은 STA_3 노드의 최대 전송량은 224Kbps(= 200 Bytes * 8 bits/byte * 14 slots/frame * 1 / 0.1 frames/sec)이다. STA_3 노드에서 STA_4 노드로 향하는 트래픽의 양은 200Kbps이므로, 이번에는 STA_4 노드로 모두 전달될 것이다.
시뮬레이션을 수행한 후, 각 노드에서 할당받은 프레임당 슬롯수를 살펴보면 다음 그림과 같다. 설정해준 것처럼 STA_1 노드와 STA_4 노드가 11개, STA_2 노드가 8개, STA_3 노드가 14개의 슬롯을 매 프레임 할당받은 것을 알 수 있다.

 


STA_1 노드에서 STA_2 노드로 향한 트래픽의 송수신량을 살펴보면 다음 그림과 같다. STA_1 노드에서 발생한 트래픽이 STA_2 노드로 모두 전달되었음을 보여준다.

 


STA_3 노드에서 STA_4 노드로 향한 트래픽의 송수신량을 살펴보면 다음 그림과 같다. STA_3 노드에서 발생한 트래픽(200Kbps)도 STA_4 노드로 모두 전달되었음을 보여준다.

 

 

'Riverbed Modeler(OPNET) > TDMA Model' 카테고리의 다른 글

TDMA 자원 요청/할당 절차  (5) 2022.08.01
TDMA 예제(3) - 동적 할당  (0) 2022.01.08
TDMA 예제(1) - 균등 고정 할당  (0) 2020.07.04
TDMA 네트워크 제어기  (0) 2020.03.03
TDMA 자원할당 방식  (0) 2019.07.20
Posted by 신상헌
,