네트워크 시뮬레이션 공방

Riverbed(OPNET) Modeler에서 트래픽을 발생시키는 방법으로는 어플리케이션 모델("어플리케이션 모델" 참조)을 사용하는 방법과 디맨드 모델("Background Traffic의 영향(4) - Demand Model" 참조)을 사용한는 방법이 있다. 어플리케이션 모델에서는 어플리케이션 종류별(예: HTTP,FTP, Email, Voice 등)로 특성에 맞는 세세한 설정을 해줄 수 있기때문에 관찰대상이 되는 트래픽을 만들때 주로 사용된다.
그런데, 네트워크에 부가되는 트래픽은 어플리케이션의 특성에 의해서도 변하지만,어플리케이션들이 단말에서 어떤 패턴으로 사용되는가에 따라서도 크게 영향을 받는다. 이러한 어플케이션 사용 패턴은 Riverbed(OPNET) Modeler에서 어플리케이션 타이밍에 대한 정의와 프로파일 타이밍에 대한 정의를 통해 모델링된다. 어플리케이션 타이밍은 어플리케이션 자체에 대한 사용 패턴 설정이며, 프로파일 타이밍은 이러한 어플리케이션들의 모음에 대한 사용 패턴 설정이다. 다음 그림은 어플리케이션과 프로파일의 관계를 보인 것이다.

어플리케이션 사용 패턴은 Profile Config 노드 모델에서 설정해줄 수 있다. 다음 그림은 Profile Config 노드 모델의 어플리케이션 사용 패턴 설정 속성을 보인 것이다.

먼저 프로파일 타이밍에 대한 설정 항목을 살펴보면 다음과 같다.

- Profile Name: 프로파일 타이밍 이름.
- Applications: 어플리케이션 타이밍에 대한 설정.
- Operation Mode: 프로파일에 포함된 어플리케이션들의 시작 순서에 대한 설정. 선택 가능한 값은 Serial (Random), Serial (Ordered), Simultaneous.
- Start Time (seconds): 프로파일의 시작 시간.분포함수 형태로 입력한다.
- Duration (seconds): 프로파일의 최대 실행 기간. End of Simulation, End of Last Application 중에서 선택하거나 분포함수 형태로 입력할 수 있다.
- Repeatability: 프로파일의 반속 실행 횟수와 방법. Once at Start Time, Unlimited 중에서 선택하거나 Repeatability 테이블("Repeatability 테이블" 세부 항목에 대해서는 뒤에서 다시 설명한다)에 대한 직접 입력이 가능하다.

다음으로 어플리케이션 타이밍에 대한 설정 항목은 다음과 같다.

- Name: 어플리케이션 이름.
- Start Time Offset (seconds): 어플리케이션의 시작 시간. No Offset, Never 중에서 선택하거나 분포함수 형태로 입력할 수 있다.
- Duration (seconds): 어플리케이션의 최대 실행 기간. End of Profile, End of Last Task 중에서 선택하거나 분포함수 형태로 입력할 수 있다.
- Repeatability: 어플리케이션의 반복 실행 횟수와 방법. Once at Start Time, Unlimited 중에서 선택하거나 Repeatability 테이블("Repeatability 테이블" 세부 항목에 대해서는 뒤에서 다시 설명한다)에 대한 직접 입력이 가능하다.

다음 그림은 Repeatability 테이블의 설정 속성을 보인 것이다.

Repeatability 테이블의 세부 설정 항목은 다음과 같다.

- Inter-repetition Time (seconds): 프로파일이나 어플리케이션이 반복될때의 사이 간격. 분포함수 형태로 입력.
- Number of Repetitions: 반복 횟수. None, Unlimited 중에서 선택하거나 분포함수 형태로 입력.
- Repetition Patterns: 반복되는 프로파일이나 어플리케이션에서 다음번 세션의 시작 시간 기준을 정의. 선택 가능한 값은 Serial, Concurrent.

Riverbed(OPNET) Modeler 17.5 PL3 ~ 18.5.0 버전에서는 노드 속성(Attribute) 편집창이 기본적으로 Advanced 모드로 열리는 문제가 있다. Advanced 모드에서는 다음 그림처럼 자주 사용되지 않는 속성 항목들(예: model, x position, y position, threshold, icon name, creation source, creation timestamp, creation data, label color, altitude modeling, condition, financial cost, hostname, minimized icon, role)도 모두 보여지게 되므로, 많은 경우에 오히려 사용하기 불편하다.

물론, "Advanced" 체크박스를 해제하면 일반 모드로 전환할 수 있으므로, 기능상에는 문제가 없다. 하지만, 노드의 속성 편집창을 열때마다 Advanced 체크박스를 해제하는 것은 매우 번거로운 일이며, Advanced 모드가 기본으로 적용되지 않도록 제어할 방법이 없다는 점에서 매우 불편한 문제였다.
이 문제는 18.5.1 버전("Riverbed Modeler 18.5.1 발표" 참조)에서 해결되었다. 프로그램 속성 설정의 기본값만 변경해주면 될 것 같은데, 해결되기까지 상당히 오랜 시간이 걸렸다(2013년 10월에 문제 제기, 2016년 5월 버전에 반영).

BER 커브를 조회할 때 입력값으로 사용하는 SNR은 수신 SNR이 아니라 수신 SNR에 프로세싱 게인(Gain)이 더해진 실효(Effective) SNR이다. OPNET 16.1 버전("OPNET Modeler 16.1 PL1 발표" 참조)에서 사용하는 변조 방식별("WiFi MCS 레벨 (16.1 버전)" 참조) 프로세싱 게인을 살펴보면 다음 표와 같다.

"WiFi 모델에서의 통신 가능 거리(2)"에서 1Mbps의 Data rate인 경우에 대해 프로세싱 게인 값으로 10.414를 적용한 것도 이 때문이었다.

UCMP가 사용되면 다중 경로를 통해 트래픽이 분산됨은 "다중경로 라우팅(7) - UCMP"에서 트래픽 유통량을 통해 살펴보았다. 여기에서는 이러한 경우에 라우팅 테이블이 어떻게 구성되는지를 확인해 보도록 하자. 사용된 예제의 네트워크 토폴로지와 실제로 할당된 IP주소 내역은 다음과 같다.

UCMP가 사용되지 않은 경우에, R1 노드에 구성된 라우팅 테이블을 살펴보면 다음 그림과 같다("라우팅 경로 확인하기" 참조). Server 노드가 속한 서브네트워크로 향하는 경로가 하나 뿐인 것을 알 수 있다.

UCMP가 사용되는 경우에, R1 노드에 구성된 라우팅 테이블을 살펴보면 다음 그림과 같다. Server 노드가 속한 서브네트워크로 향하는 경로가 두 개이며, 두 경로의 비용이 서로 다른 것을 알 수 있다.

TDMA 자원(슬롯) 할당 방식은 고정 할당(static allocation) 방식과 동적 할당(dynamic allocation) 방식으로 구분될 수 있으며, Riverbed(OPNET) Modeler TDMA 모델은 이 두가지 방식을 모두 지원한다.

- 고정 할당: 각 노드의 트래픽 전송량과는 관계없이 사전에 지정된 크기의 슬롯을 매 프레임마다 계속 할당.
- 동적 할당: 각 노드는 트래픽 전송에 필요한 크기만큼의 슬롯을 제어 노드로 요청하고, 제어 노드는 매 프레임마다 가변적으로 슬롯 할당.

또는, 이 두가지 방식을 혼합하여 사용하는 것도 가능하다. 즉, 매 프레임마다 지정된 크기의 슬롯을 계속 할당하되, 해당 노드에서 더 많은 슬롯을 요청하면 추가적인 슬롯을 할당해주는 것이다.

OSPF Broadcast 모드는 Broadcast(BMA) 네트워크에서 사용되는 방식이고, OSPF NBMA 모드는 NBMA 네트워크에서는 사용되는 방식이다. 두 방식은 모두 DR을 사용("OSPF DR(1) - 라우터 상태" 참조)한다는 점에서는 동일하다. 그러면, Broadcast 모드와 NBMA 모드의 차이점은 무엇일까? 그것은 두 방식에서 사용하는 목적지 IP 주소이다.
Broadcast 모드에서는 유니캐스트 주소뿐만 아니라 멀티캐스트 주소가 함께 사용되지만("OSPF DR(5) - 메시지 Encapsulation" 참조), NBMA 모드에서는 유니캐스트 주소만 사용되며 멀티캐스트 주소는 사용되지 않는다("OSPF NBMA 모드" 참조). 다음의 표는 이를 비교한 것이다.

바꾸어 말하자면, Broadcast 모드로 동작하기 위해서는 MAC 계층에서 멀티캐스팅을 지원해야만 한다.

Riverbed(OPNET) Modeler 시나리오상에 배치한 라우터나 단말 노드로 ping 요청을 보내고 응답을 받는 것이 가능함은 "SITL Ping 예제(1)"에서 살펴보았다. 이번에는 좀 더 복잡한 망 구조에서도 이러한 시험이 가능함을 확인해보도록 하겠다.
다음은 좀 더 복잡한 망 구조에서 ping 응답 시험을 위한 포토로지 구성과 IP 주소 설정을 보인 것이다.

SITL GW를 통해 연동된 실장비에서 시나리오상의 Access_2 노드(라우터)로 ping 요청을 보냈을 경우의 결과는 다음과 같다. 라우터 여러 대를 거쳐서도 ping 응답이 정상적으로 수신되는 것을 확인할 수 있다.

Route Reply Acknowledgment(RREP-ACK) 메시지는 RREP 메시지에 대한 수신확인을 위해 사용되며, Riverbed(OPNET) Modeler AODV 모델에서는 "AODV 메시지(1) - 패킷 포맷"에서 살펴본 것처럼 공통 AODV 패킷 포맷의 Options 필드에 RERR-ACK 메시지에 대한 구조체를 싣는 방식으로 구현된다. 다만, RREP-ACK 메시지에는 단지 Type 정보만이 필요하므로, RREQ, RREP, RERR 메시지와는 달리 별도의 구조체를 추가로 사용하지 않고 AODV 패킷 옵션에 대한 공통 구조체만을 사용한다. 다음 그림은 AODV 모델에서 사용 하는 패킷 포맷과 RREP-ACK 메시지일 경우 Options 필드에 실리는 정보를 표준[1]과 비교하여 나타낸 것이다.

AODV 모델에 구현된 RREP-ACK 메시지 구조체와 표준이 잘 일치함을 확인할 수 있다.

[1] RFC 3561, "Ad hoc On-Demand Distance Vector (AODV) Routing", IETF, July 2003.

CUBIC 알고리즘의 기본적인 동작은 "TCP CUBIC(2) - 예제"에서 살펴보았으며, CUBIC을 사용하지 않은 경우와 비교하였을 때 성능(전송률)이 개선되기는 하였지만, 그 차이는 미약한 수준이었다. 그러면, CUBIC 사용에 따른 성능 개선은 이 정도가 한계인 것일까? 그렇지는 않다.
CUBIC 사용에 따른 성능 차이를 좀더 명확히 관찰하기 위하여, STA 노드의 수신 버퍼 크기를 160Kbytes로 늘리고 Server 노드와 STA 노드 사이의 RTT도 300ms로 증가시킨다. 다음 그림은 변경된 시나리오에 대한 CWND 결과 값을 비교한 것이다.

200초 무렵에 재전송 발생후 CWND 값이 New Reno를 사용한 경우와 CUBIC을 사용한 경우에 있어 매우 큰 차이를 보이며, New Reno를 사용한 경우에 CWND 값이 160Kbytes(수신 버퍼 크기)보다 낮은 구간이  상당 시간 유지되는 것을 알 수 있다.
다음 그림은 Server 노드에서 Discarder_2 노드로 전달되는 트래픽 양을 비교한 것이다. 재전송이 발생 하였을 때(200초 무렵)에도 New Reon에서는 전송률이 저하되는 구간이 길지만(약 40초), CUBIC을 사용한 경우에는 전송률이 저하되는 구간이 짧고(약 10초) 저하되는 크기도 훨씬 적다. 또한 파일 전송 완료까지의 시간도 상당히(약 7초) 더 짧다.

Adaptive 모드일 때 지터 버퍼의 최초 크기 계산 과정은 일반적인 지터 버퍼 크기 계산 과정과 동일하다. 즉, Nominal Value는 사용되지 않으며, packetization delay와 지터 버퍼의 Minimum/Maximum Value를 이용하여 최상의 MOS 값을 얻을 수 있는 지터 버퍼 크기가 선택된다.