네트워크 시뮬레이션 공방

"TCP Receive Buffer"에서 살펴본 것처럼 17.1 PL2 버전 이상에서는 Receive Buffer (bytes) 속성의 값, 즉 수신 버퍼 크기를 Auto-Tuning으로 설정하는 것도 가능하다("OPNET Modeler 17.1 PL2 발표" 참조).

수신 버퍼 크기에 Auto-Tuning이 적용되면, Window Scaling("TCP Window Scaling(1) - LFN에서의 동작" 참조) 기능과 타임스탬프 기능("TCP 타임스탬프(1) - 파라미터 설정" 참조)은 Enabled 상태로 자동 변경된다.

수신 버퍼 크기는 최소 크기로부터 BDP(Bandwidth Delay Product) 크기에 도달할 때까지 일정 단위로 증가된다. 단, 링크의 대역폭 별(1Mbps이하, 100Mbps이하, 100Mbps 초과)로 지정된 최대 크기보다 커질 수는 없다. 수신 버퍼 자동 계산 모드에서 버퍼 크기 증가는 RTT 시간동안 수신한 트래픽 총량이 기준을 초과하였을 때만 이루어진다.

Riverbed(OPNET) Modeler IP 모델에서 TTL(Time-to-Live) 값 처리는 해당 패킷이 그 노드에서 사용되지 않고, 다른 노드로 포워딩된다는 것을 확인한 이후에 이루어진다. 다음 그림은 그 상관 관계를 개념적으로 표현한 것이다.

수신된 패킷은 먼저 해당 노드가 목적지인지 검사가 이루어진다("IP 패킷 목적지 검사" 참조). 만약 해당 노드가 목적지라면 패킷은 상위 계층으로 전달된다. 해당 노드가 목적지가 아니라면, TTL 값을 1만큼 감소시킨다. 감소된 TTL 값이 0이라면, 해당 패킷은 폐기된다. 감소된 TTL 값이 0이 아니라면 패킷은 이웃 노드와 연결된 인터페이스를 통해 포워딩된다.

Feasibility Condition은 DUAL 알고리즘의 일부로써, 루프를 방지하기 위한 것이다. 그런데, 사용자가 주의를 기울이지 않으면 이 기능으로 인한 결과는 혼란스러운 면이 있으므로, 결과 해석시 주의가 필요하다.

"다중경로 라우팅(8) - UCMP 라우팅 테이블"에서 EIGRP는 동일한 비용을 가지는 경로가 없을 때에도 다음 그림처럼 다중경로로 라우팅 테이블을 구성해줄 수 있음을 확인한 바 있다.

그런데, "다중경로 라우팅(8) - UCMP 라우팅 테이블"의 예제망에서 R1 <-> R3 링크의 대역폭과 R3 <-> R4 링크의 대역폭을 서로 바꾸고 시뮬레이션을 수행하면, 다음 그림처럼 라우팅 테이블에 다중경로가 구성되지 않는 것을 볼 수 있다.

얼핏 생각하면, R1 노드에서 Server 노드로 향하는 경로의 전체 Metric 값에는 변화가 없으므로(R1 <-> R3 링크와 R3 <-> R4 링크의 대역폭을 서로 바꾸기만 하였으므로) 이전의 예제와 동일한 라우팅 테이블이 구성되어야 할 것처럼 생각된다. 하지만, 시뮬레이션 결과는 예상(?)과는 다르며, 이러한 차이가 발생한 원인은 Feasibility Condition 때문이다.
즉, EIGRP에서는 전체 경로의 Metric이 동일하더라도 Next-Hop 라우터에서 목적지까지의 경로 Metric 값이 어떻게 변화하는가에 따라 다중경로가 라우팅 테이블에 사용될 수도 있고 안될 수도 있다.

OSPF 망에서 DR("OSPF DR(1) - 라우터 상태" 참조) 변경이 발생할 경우, 이웃 노드들은 Hello 패킷("OSPF 메시지(2) - Hello 패킷 정보 확인" 참조)을 통해 이를 알수 있다. DR 변경후 Hello 메시지 수신은 다음 2가지 경우가 존재한다.

1) 새로운 DR로 선출된 노드로부터의 Hello 패킷 수신: 이전에는 DR 노드가 아니었던 이웃이 자신을 DR로 선언함.2) 이전 DR 노드로부터의 Hello 패킷 수신: 이전에는 DR 노드였던 이웃이 자신이 DR이 아님을 선언함.

이러한 경우, NeighborChange 이벤트가 발생하고 이웃 노드들과의 관계("OSPF DR(3) - 이웃 상태" 참조) 변경 여부에 대한 점검이 숫행된다. 또한, NeighborChange 이벤트는 BDR 노드 변경시에도 동일하게 발생한다.

GRP에서 사용되는 쿼드런트의 기본 개념에 대해서는 "GRP 쿼드런트"에서 살펴본 바 있다. 이 쿼드런트는 또한 계층개념을 가지는데, 상위 계층 쿼드런트는 하위 계층 쿼드런트 4개로 구성된다. 따라서, 상위 계층 쿼드런트 한 변의 길이는 하위 계층 쿼드런트의 2배이다. 다음 그림은 이러한 쿼드런트의 계층 관계를 나타낸 것이다.

소스 노드(S)는 1번 노드의 위치를 Aa2 쿼드런트로 간주한다. 2번 노드의 위치는 한단계 상위인 Ab 쿼드런트로 간주하며, 3번 노드의 위치는 두단계 상위인 B 쿼드런트로 간주한다. 동일한 원리로 4번 노드의 위치는 D 쿼트런트로, 5번 노드와 6번 노드의 위치는 C 쿼드런트로 간주한다. 즉, 소스 노드에서 멀리 떨어진 노드일수록 더 상위 계층의 쿼드런트를 적용하며, 이 과정은 대상 노드의 쿼드런트가 결정될때까지 반복된다.
쿼드런트는 좌표계를 기준으로 결정되므로 시나리오상의 노드 배치를 보고 어느 노드가 어느 쿼드런트에 속할 것인지를 직관적으로 파악하기는 쉽지 않다("GRP 쿼드런트 예제" 참조). 더구나, 소스 노드에서 멀어질수록 더 큰 크기의 상위 계층 쿼드런트가 적용되므로, 어떤 노드들이 같은 쿼드런트에 속할 것인지를 직관적으로 파악하기는 더 어려워진다. 그 예로, 위 그림에서 4번 노드와 5번 노드는 서로 다른 쿼드런트로 간주되는 반면, 상대적으로 더 큰 거리를 가지는 5번 노드와 6번 노드는 같은 쿼드런트로 간주된다.

TDMA 모델에서 트래픽 전송이 어떻게 이루어지는지 예제망을 통해 살펴보기로 하자. 다음 그림은 4개의 노드로 이루어진 간단한 TDMA 예제망 구조를 보인 것이다.

TDMA 프로파일로는 Default를 사용하였으며, 이 때 사용할 수 있는 44개의 데이터 슬롯은 4개의 노드에 균등하게 11개씩 고정 할당("TDMA 자원할당 방식" 참조)하였다. Default TDMA 프로파일일 경우, 프레임("TDMA 프레임 구조" 참조) 길이는 100ms이고 슬롯당 데이터 전송량은 200Bytes이므로 11개의 슬롯을 할당받은 노드의 최대 전송량은 176Kbps(= 200 Bytes * 8 bits/byte * 11 slots/frame * 1 / 0.1 frames/sec)이다.
데이터 트래픽 발생을 위해서는 demand 트래픽 플로우가 STA_1 노드에서 STA_2 노드로, STA_3 노드에서 STA_4 노드로 향하도록 각각 배치하였다. STA_1 노드에서 STA_2 노드로 향하는 demand 트래픽의 양은 150Kbps로, STA_3 노드에서 STA_4 노드로 향하는 트래픽의 양은 200Kbps로 설정하였다. 노드의 최대 전송량이 176Kbps이므로 STA_1 노드에서 STA_2 노드로 향하는 트래픽은 모두 전달될 것이고, STA_3 노드에서 STA_4 노드로 향하는 트래픽은 모두 전달되지 못할 것이다.
시뮬레이션을 수행한 후, 각 노드에서 할당받은 프레임당 슬롯수를 살펴보면 다음 그림과 같다. 설정해준 것처럼 모든 노드가 매 프레임마다 11개의 슬롯을 할당받은 것을 알 수 있다.

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

STA_3 노드에서 STA_4 노드로 향한 트래픽의 송수신량을 살펴보면 다음 그림과 같다. STA_3 노드에서 발생한 트래픽(200Kbps)이 모두 전달되지 못하고, 일부(176Kbps)만 STA_4 노드로 전달되었음을 보여준다.

어플리케이션 모델을 사용하여 트래픽 발생 시작 시간을 조정하는 방법은 "어플리케이션 사용 패턴(2) - Start Time 예제"에서 살펴보았다. 그러면, 트래픽을 원하는 시간 간격마다 반복해서 발생시키려면 어떻게 해야할까?
어플리케이션 트래픽을 반복 발생시키는 방법에는 어플리케이션 타이밍을 사용하는 방법과 프로파일 타이밍을 사용하는 방법이 있다. 여기에서는 어플리케이션 타이밍을 사용하는 방법을 살펴보기로 하자. 예제망 토폴로지는 "어플리케이션 사용 패턴(2) - Start Time 예제"에서 사용한 것을 그대로 사용였다.

"어플리케이션 사용 패턴(1) - 파라미터 설정"에서 살펴보았듯이, 어플리케이션의 실행시간은 Duration에 의해 지정되며, 실행간의 간격은 Inter-repetition Time에 의해 지정된다. 따라서, 이 두 값을 조정하면 하나의 어플리케이션이 프로파일내에서 일정 시간 간격으로 반복 실행되도록 만들수 있다.
어플리케이션 타이밍의 Duration은 200초, Inter-repetition Time은 300초로 설정하였을 때, Client로 노드로 전송되는 트래픽을 살펴보면 다음 그림과 같다.

200초 길이의 트래픽 발생 구간이 300초 간격을 두고 계속 반복되는 것을 확인할 수 있다.
Duration은 100초, Inter-repetition Time은 400초로 설정하였을 때, Client로 노드로 전송되는 트래픽을 살펴보면 다음 그림과 같다.

100초 길이의 트래픽 발생 구간이 400초 간격을 두고 계속 반복되는 것을 확인할 수 있다.

Riverbed(OPNET) Modeler IP 모델에서 수신된 패킷을 상위 계층으로 전달하는 경우는 기본적으로 패킷의 목적지가 해당 노드일 때, 브로드캐스트 패킷일 때, 해당 노드가 속한 멀티캐스트 그룹의 패킷일 때이다.
다음 그림은 그 판단 절차를 논리적으로 표현한 것이다.

라우팅 프로토콜 모델들은 동작 시작 시점을 지정하는 "Start Time" 속성을 가지고 있으며, OSPF Mdoel 역시 해당 속성을 가지고 있다. 라우팅 프로토콜 모델들이 "Start Time" 속성을 제공하는 이유는 동일한 네트워크 토폴로지에서도 시작 시간에 따라 동작이 달라지거나, 라우팅 테이블 결과가 달라질 수 있기 때문이다.

사용자가 설정해준 "Start Time" 값은 ospf_v2 프로세스 모델로부터 ospf_process 프로세스 모델로 전달된다("OSPF 프로세스 모델 구조" 참조). ospf_process 프로세스 모델은 해당 시간이 지난 후에 Init 스테이트로부터 Idle 스테이트로 천이하므로，OSPF 프로토콜의 실질적인 동작은 "Start Time" 이후에 일어나게 되는 것이다.

AODV에서 사용하는 메시지로는 Route Request(RREQ), Route Reply(RREP), Route Error(RERR), Route Reply Acknowledgment(RREP-ACK), Hello가 있는데, Riverbed(OPNET) Modeler AODV 모델에 구현된 각 메시지 구조는 표준과 잘 일치함은 "AODV 메시지(2) - RREQ 구조체", "AODV 메시지(3) - RREP 구조체", "AODV 메시지(4) - RERR 구조체", "AODV 메시지(5) - RREP-ACK 구조체", "AODV 메시지(6) - Hello"에서 살펴보았다. 이번에는 이 AODV 메시지들의 크기와 하위 프로토콜 계층에서 실제로 사용되는 패킷 크기를 살펴보도록 하자.
RREQ 메시지는 24Bytes, RREP 메시지는 20Bytes, RREP-ACK 메시지는 2Bytes 크기로 정의되어 있으며(IPv4일 경우) 고정적이다. RERR 메시지 크기는 에러가 발생한 목적지 수에 따라 달라지는데, 기본 크기 4Bytes에 에러가 발생한 목적지 수에 따라 8Bytes씩 증가한다. 따라서 RERR 메시지의 최소 크기는 12Bytes이다.
AODV 메시지는 UDP를 사용하므로("AODV 메시지(1) - 패킷 포맷" 참조), 하위 계층으로 전달될 때 UDP 헤더 8Bytes, IP 헤더 20Bytes, MAC 오버헤드 28Bytes가 추가된다. 따라서 MAC 계층에서 사용되는 패킷 크기는 RREQ 80Bytes, RREP 76Bytes, RERR(최소) 68Bytes, RREP-ACK 58Bytes이다.

AODV 메시지가 WiFi 802.1b 11Mbps 인터페이스를 통해 전송되는 경우 Riverbed(OPNET) Modeler 파이프라인 스테이지에서 사용되는 패킷 크기는 RREQ 344Bytes(2,752bits), RREP 340Bytes(2,720bits), RERR(최소) 332Bytes(2,656bits), RREP-ACK 322Bytes(2,576bits)가 된다. (PLCP 오버헤드 계산에 대해서는 "WLAN PLCP 오버헤드 크기" 참조)