네트워크 시뮬레이션 공방

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 메시지만 처리된다.

[1] RFC 792, "Internet Control Message Protocol", IETF, 1981. 
[2] https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol

프로파일 내에서 하나의 어플리케이션을 사용하는 방법은 "어플리케이션 사용 패턴(3) - 어플리케이션 반복 예제"와 "어플리케이션 사용 패턴(4) - 반복 패턴 예제"에서 살펴보았다. 이제 프로파일 내에서 여러 개의 어플리케이션을 사용하는 방법을 살펴보기로 하자.
예제망 토폴로지는 "어플리케이션 사용 패턴(2) - Start Time 예제"에서 사용한 것을 그대로 사용였다.

복수 어플리케이션이 필요하므로 기존의 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" 결과값을 사용하면 엉뚱한 값을 측정하게 될 수도 있다. 

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

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

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

"라우팅 테이블과 포워딩 테이블"에서 설명한 것처럼, 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가 클수록 수신 버퍼 크기의 최대값도 크다는 것도 알 수 있다.