네트워크 시뮬레이션 공방

NBMA(Non-Broadcast Multi-Access) 네트워크에서는 OSPF가 NBMA 모드로 동작할 수 있음을 "OSPF NBMA 모드"에서 살펴보았다. OSPF가 NBMA 모드로 동작하기 위해서는 이웃 라우터들에 대한 정보가 필요하며[1], 실 장비에서는 neighbor 명령어를 통해 설정된다[2, 3].
NBMA 네트워크에서 브로드캐스팅을 통해 이웃 라우터를 발견할 수 없는 것은 모든 라우터에 해당하므로, 이웃 정보 설정은 원칙적으로 모든 라우터에서 해주어야 한다. 하지만, 어느 라우터가 DR로 선출될지 미리 알고 있다면("OSPF DR(2) - Router Priority" 참조), DR로 선출될 라우터에만 이웃 정보 설정을 해주어도 NBMA 모드로 동작하는 것이 가능하다.
다음은 이를 확인하기 위하여 "OSPF NBMA 모드"에서 사용한 시나리오를 수정하여 작성한 시험망 구조이다. R2 노드의 Neighbor List만 남겨두고, R1, R3, R4 노드의 Neighor List 정보는 모두 삭제하였으며, Priority를 조절하여 R2 노드가 DR로 선출되도록 하였다.

Client 노드에서 Server 노드로 향하는 트래픽의 송/수신량을 살펴보면 다음과 같다. Client 노드에서 Server 노드로 트래픽이 잘 전달되고 있음을 확인할 수 있다.

Neighbor List를 R2 노드에만 설정해주었다고해서, 이 트래픽이 R2 노드를 거쳐서 전달되는 것이 아니라는 것은 다음 그림처럼 R1 노드에서 ATM_SW 노드로 전달되는 트래픽과, AMT_SW 노드에서 R2, R4 노드로 전달되는 트래픽을 비교해보면 명확하게 알 수 있다.

[1] RFC 2328, "OSPF Version 2", IETF, Apr. 1998.
[2] http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13690-18.html
[3] http://egloos.zum.com/light99/v/5159722

사용자 트래픽은 어플리케이션이 만들어내는 패킷에 의해 발생한다. Riverbed(OPNET) Modeler에서는 다양한 종류의 어플리케이션들을 모의할 수 있도록 Database, Email, Ftp, Http, Print, Peer-to-peer File Sharing, Remote Login, Video Conferencing, Video Streaming, Voice, Custom 어플리케이션 프로세스 모델을 제공한다.
어플리케이션 프로세스 모델은 설정된 속성값에 따라 패킷을 만드는 작업을 수행하며, 동일한 프로세스 모델에 대해서도 속성값을 어떻게 설정해주는가에 따라 생성되는 패킷의 패턴은 크게 달라진다. 따라서, 시뮬레이션을 위해서는 해당 어플리케이션의 속성값을 시뮬레이션 대상과 유사하게 설정해줄 필요가 있다. 이를 위하여 Riverbed(OPNET) Modeler에서 사전에 설정해 둔 어플케이션 설정값 조합이 표준 어플리케이션 모델이다.
다음 그림은 Riverbed Modeler 18.0.3 버전("Riverbed Modeler 18.0.3 발표" 참조)에서 제공하는 어플리케이션 프로세스 모델과 표준 어플리케이션 모델, 그리고 모델간의 대응 관계를 보인 것이다.

표준 어플리케이션 모델중 Peer-to-peer File Sharing, Mobile User 어플리케이션은 17.5 PL3 버전("OPNET Modeler 17.5 PL3 발표" 참조)에서 추가된 것이며, Video Streaming 어플리케이션은 17.5 PL4 버전("OPNET Modeler 17.5 PL4 발표" 참조)에서 추가된 것이다.

"GRP 다음 홉 선정"에서 살펴본 것처럼, 목적지 노드 위치 정보가 쿼드런트 좌표이고 현재 노드의 이웃 노드들중 목적지 노드와 같은 쿼드런트에 속한 노드가 없는 경우에는 목적지 쿼드런트와 이웃 노드들의 거리를 비교하여 목적지 쿼드런트에 가장 가까운 이웃 노드를 다음 홉으로 사용하게 된다.
이 때, 노드와 쿼드런트와의 거리는 다음 그림과 같이 8가지 경우로 나누어져 계산된다.

Riverbed Modeler 18.8.0 버전이 지난 2월4일자로 발표되었습니다(이전 버전에 관한 내용은 "Riverbed Modeler 18.7.1 발표" 참조). 메일 공지는 오늘(2월13일) 받았습니다만, 홈페이지와 Release notes에는 2월4일자로 되어있네요.
Release notes를 통해 변경 사항을 살펴보았습니다. 모델 업데이트는 2가지입니다.

- VLAN Model Enhancement - IEEE 802.1ad Support
- TCP Model Enahcement - New MPTCP example scenario

VLAN 모델 개선 사항은 Provider Bridged Networks(PBN)에 대한 지원입니다. 이 기능은 IEEE 802.1Q-2014 표준을 기반으로 구현되었으며, 향후 Provider Backbone Bridge(IEEE 802.1ah)와 Shortest Path Bridging(IEEE 802.1aq) 등의 다양한 캐리어 이더넷 기술들이 추가로 구현될 예정이라고 합니다. VLAN 모델 개선은 정말 오랜만인데(마지막 업데이트가 언제였는지 기억조차 나지 않네요), 당분간 집중적인 개선이 이루어질 모양입니다.
TCP 모델 개선 사항은 MPTCP를 사용하는 새로운 예제 시나리오가 추가되었다는 것입니다. MPTCP 자체는 18.7.1 버전("Riverbed Modeler 18.7.1 발표" 참조)에서 구현된 기능이고, 이 기능이 적용된 예제 시나리오가 이번에 추가되었다는 것입니다. 이걸 굳이 모델 업데이트라고  발표해야하는지는 좀 의아하네요.

그리고, 기존과는 달리 향후에 퇴출(deprecate)될 기능들에 대한 예고가 있습니다. WLAN 모델의 IR PHY, FHSS PHY, DSSS PHY, PCF, nQTAs 기능과 Bridge/Switch 및 VLAN 모델의 STP, PVSTP, VLAN 기능이 없는 Bridge/switch 노드라고 합니다.

그 외에 버그 수정사항 3건도 있습니다만, 특별히 관심이 가는 내용이 아니라서 생략합니다.

Riverbed(OPNET) Modeler는 Multiple run이 필요한 시나리오의 시뮬레이션을 신속하게 수행할 수 있도록 distributed simulation 기능을 제공하며, 여기에는 멀티코어를 활용하는 기능도 포함되어 있다. 다만, 이렇게 멀티코어를 활용하는 기능은 기본적으로 비활성화되어 있으며, 활성화를 위해서는 사용자 설정이 필요하다. 이러한 불편함은 OPNET 17.5 PL3 버전("OPNET Modeler 17.5 PL3 발표" 참조)에서  멀티코어 활용을 위한 설정 기능이 개선되면서 많이 해소되었다. 다음 그림은 16.1 PL1 버전("OPNET Modeler 16.1 PL1 발표" 참조)에서 멀티코어 활용 기능을 비활성화한 상태에서 Multiple run이 필요한 시나리오를 실행시킨 화면을 보인 것이다. 각각의 실행이 순차적으로 진행되는 것을 알 수 있다.

다음 그림은 동일한 16.1 PL1 버전에서 동일한 시나리오를 멀티코어 활용 기능을 활성화하고(사용 코어수는 3개로 설정) 실행시킨 화면을 보인 것이다. 시뮬레이션 실행이 3개씩 동시에 진행되는 것을 알 수 있다.

코어가 4개인 Intel Core i5-4590 CPU가 장착된 시스템에서 위의 예제 시나리오를 멀티코어 사용 비활성화 상태로 실행하였을 때에는 3분 14초가 소요되었다. 하지만, 멀티코어 사용 활성화 상태(사용 코어수는 3개로 설정)로 실행하였을 때에는 1분 11초만이 소요되었다. 즉, 사용된 코어의 갯수에 반비례하여 시뮬레이션 소요 시간이 감소한다고 볼 수 있다.

Route Error(RERR) 메시지는 링크에서 오류가 발생한 경우에 이를 알리기 위해서 사용되며, Riverbed(OPNET) Modeler AODV 모델에서는 "AODV 메시지(1) - 패킷 포맷"에서 살펴본 것처럼 공통 AODV 패킷 포맷의 Options 필드에 RERR 메시지에 대한 구조체를 싣는 방식으로 구현된다. 다음 그림은 AODV 모델에서 사용 하는 패킷 포맷과 RERR 메시지일 경우 Options 필드에 실리는 정보를 표준[1]과 비교하여 나타낸 것이다.

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

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

NBMA 모드는 NBMA(Non-Broadcast Multi-Access) 네트워크에서 OSPF가 동작하는 방식 중 한가지[1]이며,  Riverbed(OPNET) Modeler OSPF 모델도 이를 지원한다. OSPF를 NBMA 모드로 동작시키려면, OSPF의 해당 인터페이스 Type 속성을 Non-Broadcast로 설정해주면 된다("OSPF 인터페이스 종류" 참조).
다음은 OSPF가 NBMA 모드로 동작하고 있음을 확인하기 위한 시험망 구조이다. "OSPF DR(1) - 라우터 상태"에서 사용한 시나리오를 수정한 것으로, R1, R2, R3, R4 노드간을 Non-Broadcast Multi-Access 방식인 ATM으로 연결하였다.

OSPF NBMA 모드 시뮬레이션을 위해 할당한 IP주소 내역은 다음과 같다.

이 때, R1, R2, R3, R4 노드에 구성된 OSPF 인터페이스 정보를 ODB를 통해 살펴보면 다음과 같다.

192.0.3.x 네트워크에 대하여 R4 노드가 DR로, R3 노드가 BDR(Backup DR)로 동작하고 있음을 확인할 수 있다. DR(Designated Router)은 Broadcast 모드와 NBMA 모드에서만 사용되므로[1], OSPF가 현재 Point to Point 모드나 Point to Multipoint 모드로 동작중이 아니라는 것은 이 결과로부터 알 수 있다.
또한, R4 노드(DR)에서 내보내는 Hello 메시지를 살펴보면 다음과 같이 unicast로 전달되고 있다.

Hello 메시지는 NBMA 모드와 Point to Multipoint 모드에서만 unicast로 전달되므로, OSPF가 현재 Point to Point 모드나 Broadcast 모드로 동작중이 아니라는 것은 이 결과로부터 알 수 있다.
이상의 두가지 결과로부터 이 시험망의 OSPF는 NBMA 모드로 동작하고 있음이 분명하다.

[1] RFC 2328, "OSPF Version 2", IETF, Apr. 1998.

Riverbed(OPNET) Modeler WLAN 모델에서 사용되는 BER 커브는 17.5 PL6 버전부터 코딩률(Coding Rate)를 반영한 방식으로 변경되었다("OPNET Modeler 17.5 PL6 발표" 참조). 따라서, 17.5 PL6 버전부터는 변조(Modulation)에 따른 BER 커브("WiFi MCS 레벨 (16.1 버전)" 참조)가 아니라, MCS(Modulation & Coding Scheme) 레벨에 따른 BER 커브라고 볼 수 있다.
17.5 PL6 버전에서 사용되는 데이터 전송 속도별 MCS 레벨을 살펴보면 다음과 같다.

코딩률이 추가되었기 때문에, 동일한 데이터 전송 속도를 사용하더라도 17.5 PL6 이후 버전에서는 사용되는 MCS 레벨이 17.5 PL5 이전 버전과는 약간 다르다. 또한, 17.5 PL6 버전에서 추가된 MCS 레벨의 BER 커브는 전 버전에서 사용되던 유사한 MCS 레벨의 BER 커브와 값이 꽤 다르므로, 시뮬레이션 결과 해석시 유의하여야 한다. 즉, 동일한 WiFi 설정을 가지는 시나리오를 수행하더라도 17.5 PL6 전 버전과 이후 버전에서 실행한 결과는 다를 수 있다.

"SITL에서 지원하는 프로토콜의 종류"에서 설명하였듯이 Riverbed(OPNET) Modeler SITL 모듈은 ICMP에 대한 패킷 변환을 지원하며, Riverbed(OPNET) Modeler 시나리오상에 배치한 라우터나 단말 노드에 대해서 ping 요청을 보내고 응답을 받는 것이 가능하다. (일종의 Real-Sim 형태의 시뮬레이션이다.)
다음은 이러한 ping 응답 시험을 위한 토폴로지 구성("SITL을 통해 전달된 실제 PDU를 시뮬레이터에서 처리하기" 참조)과 IP 주소 설정을 보인 것이다.

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

또한 시나리오상의 Server_1 노드(단말)로 ping 요청을 보냈을 경우의 결과는 다음과 같다. 라우터와 동일하게 ping 응답이 정상적으로 수신되는 것을 확인할 수 있다.

Riverbed(OPNET) Modeler TDMA 모델("TDMA 모델 개요" 참조)에서 사용하는 TDMA 프레임 기본 구조는 다음 그림과 같다.

TDMA 채널에서는 일정 시간 간격마다 Epoch가 반복된다. Epoch는 프레임(frame)의 집합이며, 프레임은 사용자 데이터 전송을 위한 슬롯(slot)과 제어 메시지 전송을 위한 슬롯 그리고 오버헤드로 구성된다.