네트워크 시뮬레이션 공방

"OPNET 기초다지기" 3.5절의 TCP 예제를 수행할 때, 14.0 이상의 버전에서는 Packet discarder 노드 때문에 다음과 같은 에러가 발생하고 시뮬레이션이 정상적으로 수행되지 않는 문제가 발생한다.

Simulation terminated by process (ethernet_mac_v2) at module (top.Logical Network.Server.mac), T (0), EV (64)
An error has been detected by the Ethernet Model Suite.
Check the simulation log for details. If the simulation log was not
enabled, rerun the simulation after enabling this feature in the
Project/Simulation Editor.

이는 14.0 버전에서 수정된 Ethernet MAC 모듈의 코드가 Packet Discarder의 동작과 관련이 있기 때문에 발생하는 현상이다. 다음과 같은 방법을 통해 문제를 피해갈 수 있다. (이 방법은 12.1 버전에 적용해주어도 된다. 12.1 버전에 적용해주면, 기존에 발생하던 경고 메시지가 발생하지 않는다)
1) oms_packet_discarder 프로세서 모델을 프로세스 편집창에서 열고, Interface-->Model Attributes 메뉴를 실행한다.
2) Attribute 항목에 "MAC Parameters"를 추가하고, Type을 compound로 설정한다.
3) 하단의 Edit Properties 버튼을 클릭해서 MAC Parameters에 대한 속성 편집창을 열고, Attribute 항목에 "Operational Mode"를 추가하고 Type을 integer로 설정한다. Default value는 1로 설정한다.
4) Compile-->Compile code 메뉴를 실행하여 oms_packet_discarder 프로세서 모델을 새로 컴파일하고, 시뮬레이션을 다시 실행한다.

위의 방법을 사용하면 최신 버전(16.1)에서도 Packet Discarder 노드를 Ethernet과 연결해서 사용할 수 있다.

그런데, 때로는 Packet discarder를 동작시켰음에도 불구하고 재전송이 일어나지 않는 경우가 있다. (14.5, 15.0, 16.0 버전에서 seed 값으로 128을 사용하였을 때 이러한 현상이 발생하는 것이 확인됨) 이는 폐기된 패킷이 데이터 패킷이 아니라 ACK 패킷이기 때문에 발생하는 현상이다. ACK 패킷은 한두개 손실되더라도 이후에 뒤따라오는 ACK 패킷에 의해서 극복이 가능하기때문에, 재전송이 발생하지 않는다.
이럴 경우에는 Packet Discard Configuration에서 손실되는 패킷의 수(Discard Count)를 2~3으로 증가시켜 시뮬레이션해보면 데이터 패킷에도 손실이 발생하여 재전송이 일어나는 것을 볼 수 있다.

이러한 혼란이 발생하는 근본적인 이유는 우리가 단방향 링크를 사용하지 않고 양방향 링크(Ethernet 100 BaseT)를 사용하여서, 특정 방향으로 향하는 패킷만을 정확히 지정하여 폐기할 수 없기 때문이다. 이더넷 같은 양방향 링크를 사용하지 않고 단방향 링크를 사용하면 이러한 문제를 피해갈 수 있겠지만, 노드 모델 교체나 포트 설정등의 작업이 추가적으로 필요하다. 여기에서는 앞에서 만들었던 예제 시나리오를 최대한 재활용하는 것이 목적이므로, 양방향 노드를 그대로 두고 사용하기로 한다.

CD 바인더를 정리하다가 나온 OPNET CD들을 한곳에 모아서 한컷 찍어보았습니다.

예전에는 이렇게 버전별로 디자인이 다른 CD에 담아서 배포했었는데, 어느 무렵부터인가 그냥 똑같은 디자인의 CD에 버전만 스티커로 표시해서 배포하더군요. 아마 두자리수 버전으로 넘어가던 시점부터였을 겁니다. 뭐, CD가 중요한건 아닙니다만, 오랜만에 예전 CD들을 보니, 그나마 좀 디자인이 나아 보이네요.
OPNET을 처음 접했던 때가 1997년, 그러니까 학부 4학년 여름 무렵이었던 걸로 기억합니다. 위 사진에도 보이는 3.0.B 버전이었습니다(그 이후로는 B가 붙는 버전을 본 기억이 없네요). 하지만, 이때에는 그냥 OPNET을 접했을 뿐이고, 본격적으로 사용하기 시작한 것은 대학원에 진학한 1998년, 3.5.A 버전부터였습니다.
이 당시에는 OPNET을 사용할 때, SUN Solaris 서버에 설치해두고 PC에서 서버로 X매니저나 CDE를 통해서 접속하는 방법을 주로 사용했었습니다. PC의 성능 문제도 있거니와 Windows계열은 NT만을 지원했던 터라, Windows 95나 98을 주로 사용했던 개인 PC에 직접 설치해서 사용하기에는 좀 힘들었기 때문입니다.
박사과정을 마칠때까지 6.0 버전을 사용했었고, 연구실 자산관리를 대부분 제가 담당했던 터라 남은 CD를 제가 보관하고 있었네요. (사실 CD는 서류 처리를 위한 것이지, 실제로는 별 의미가 없죠.) 그 이후에는 회사에서 사용했기 때문에 개인적으로 보관하고 있는 CD가 없습니다.

Custom Application을 사용할 때, Task 설정 단계에서의 REQ/RESP와 결과확인창의 Requesting/Responding의 관계가 혼란스러울 때가 있다. 이들 간의 관계를 명확하게 파악하지 못하면, 정상적으로 수행된 시뮬레이션에 문제가 있다고 판단하거나 정상적으로 수행되지 못한 시뮬레이션에 문제가 없는 것으로 판단 할 수가 있기때문에 주의가 필요하다.
다음 그림과 같이 Client와 Server 노드로 이루어진 네트워크를 예로 들어 살펴보자.

Task Config를 이용하여 Custom Application을 설정하는데, 먼저 Source 노드에서 Destination 노드로 1,000Bytes 크기의 패킷을 1sec마다 전송하도록 하고, 이 패킷들에 대한 응답으로 500Bytes 크기의 패킷을 Destination 노드에서 Source 노드로 전송하도록 다음 그림과 같이 설정한다. (이를 1번 Custom Traffic으로 부르자) 만들어진 Custom Traffic Profile을 Client 노드에 적용해주고, Dest으로 Server 노드를 지정해 준다.

결과 수집항목 설정창에서 "Requesting Custom Application" 항목과 "Responding Custom Application" 항목을 모두 선택하고 시뮬레이션을 수행한 후 살펴보면, 다음 그림과 같이 Client 노드에는 "Requesting Custom Application" 항목 결과만이, 그리고 Server 노드에는 "Responding Custom Application" 항목 결과만이 수집되어 있는 것을 볼 수 있다.

Client 노드의 "Requesting Custom Application" 아래에 속한 "Traffic Sent(bytes/sec)" 항목과 "Traffic Received(bytes/sec)" 항목의 결과를 살펴보면 다음 그림과 같다. 즉, Task Config에서 Source로 지정되어 있는 노드에서는 "REQ/RESP Pattern"에 해당하는 트래픽이 모두 "Requesting Custom Application" 결과로 보여지는 것이다.

다음으로 Source 노드에서 Destination 노드로 1,000Bytes 크기의 패킷을 한번 전송하도록 하고(일종의 서비스 요청이라고 볼 수 있다), 이 패킷에 대한 응답으로 1,000Bytes 크기의 패킷을 1초마다 Destination 노드에서 Source 노드로 전송하도록 다음 그림과 같이 설정한다. (이를 2번 Custom Traffic으로 부르자)
만들어진 Custom Traffic Profile을 Client 노드에 적용해주고, Dest으로 Server 노드를 지정해 준다.

이제 다시 시뮬레이션을 수행한 후 살펴보면, 다음 그림과 같이 Client 노드와 Server 노드에 모두 "Requesting Custom Application" 항목 결과와 "Responding Custom Application" 항목 결과가 수집되어 있는 것을 볼 수 있다.

Client 노드의 "Requesting Custom Application" 아래에 속한 "Traffic Sent(bytes/sec)" 항목과 "Responding Custom Application" 아래에 속한 "Traffic Received(bytes/sec)" 항목의 결과를 살펴보면 다음 그림과 같다. 즉, Task COnfig에서 Source로 지정되어 있는 노드에서는 설정된 트래픽이 "Requesting Custom Application" 결과로 보여지며, Destination으로 지정되어 있는 노드에서는 설정된 트래픽이 "Responding Custom Application으로 보여진다.

결론적으로 요약하자면,
1) 해당 트래픽이 Task Config에서 REQ(Source->Dest Traffic)에 해당하는지 RESP(Dest->Source Traffic)에 해당하는지의 여부와 상관없이 Source로 지정되어 있는 노드에서는 설정된 트래픽이 모두 "Requesting Custom Application" 결과로 보여지며, Destination으로 지정되어 있는 노드에서는 "Respoding Custom Application"결과로 보여진다.
2) "Requesting Custom Application" 또는 "Responding Custom Application" 아래에서 "Traffic Sent(bytes/sec)"로 표현될지 "Traffic Received(bytes/sec)"로 표현될지의 여부는 REQ에 해당하는 설정인지 RESP에 해당하는 설정인지에 따라 결정된다.

32비트 버전 OPNET의 경우 2GBytes 이상의 메모리를 사용할 수 없기 때문에 대규모 망을 시뮬레이션할 때 문제가 발생할 수도 있다. 물론 이는 OPNET의 문제가 아니라 하나의 어플리케이션은 최대 2GBytes까지의 메모리만 (가상 메모리를 포함하더라도) 사용할 수 있도록 허용하는 32비트 윈도우의 문제이다.
따라서, 2GBytes 이상의 메모리가 요구되는 대규모망을 시뮬레이션할 때에는 64비트 OS상에서 64비트 버전의 OPNET을 사용해야 한다.
64비트 윈도우에서 Visual Studio 2008을 컴파일러로 사용하기 위한 환경 변수 설정은 다음과 같다.

Framework35Version=v3.5

FrameworkDir=C:\WINDOWS\Microsoft.NET\Framework64

FrameworkVersion=v2.0.50727

INCLUDE=
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\ATLMFC\INCLUDE;
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\INCLUDE;
C:\Program Files\Microsoft SDKs\Windows\v6.0A\include;

LIB=
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB\amd64;
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\LIB\amd64;
C:\Program Files\Microsoft SDKs\Windows\v6.0A\lib\x64;

LIBPATH=
C:\WINDOWS\Microsoft.NET\Framework64\v3.5;
C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727;
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB\amd64;
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\LIB\amd64;

Path=
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64;
C:\WINDOWS\Microsoft.NET\Framework64\v3.5;
C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727;
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\VCPackages;
C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE;
C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools;
C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\x64;
C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin

VCINSTALLDIR=
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC

VS90COMNTOOLS=
C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools\

VSINSTALLDIR=
C:\Program Files (x86)\Microsoft Visual Studio 9.0

WindowsSdkDir=
C:\Program Files\Microsoft SDKs\Windows\v6.0A\

그런데, 64비트 컴파일러를 설치하기 위해서는 다음 그림과 같이 Visual Studio 2008 설치 과정에서 x64 옵션을 선택해주어야만 한다. 그렇지 않으면, 64비트 윈도우 환경이라 할지라도 64비트 컴파일러가 설치되지 않아서 64비트로 컴파일이 이루어지지 않는 문제가 발생한다. (이 문제의 원인을 찾아내느라 고생하신 엠에이의 박성우씨에게 감사드립니다)

두 번째 OPNET 한글 교재를 드디어 정식으로 출판하였습니다. 제목은 "OPNET 중급입문"이고, 기본적인 OPNET 사용법을 알고 있는 분들을 위한 예제 실습 위주의 책입니다.
ISBN은 978-89-7283-903-3 이고, 오늘부터 교보문고에서 검색이 되네요.
http://www.kyobobook.co.kr/product/detailViewKor.laf?ejkGb=KOR&mallGb=KOR&barcode=9788972839033&orderClick=LAG

첫 번째 OPNET 한글 교재인 "OPNET 기초다지기"가 2008년 1월에 나왔으니 거의 3년이 지났네요. 처음 계획은 2009년 상반기에 두 번째 교재를 내놓을 생각이었습니다만, 바쁜 직장생활과 공동작업 조율의 어려움, 그리고 편집 방향의 수정등으로 인하여 계획에서 1년이나 훌쩍 뒤쳐진 지금에서야 출판하게 되었습니다.

두 번째 교재 작업을 시작할때의 기획 의도는 중급자를 위한 OPNET 활용서를 만드는 것이었습니다. 그런데, 초보자도 쉽게 따라할 수 있는 실습예제 중심의 교재가 필요하는 의견이 여러차례 있어서 책 내용을 수정하다보니, 시간도 많이 걸렸거니와 중급자를 위한 활용서라기보다는 중급자가 되기위한 연습문제서가 되어 버렸습니다. 따라서, 어떤 측면에서는 지난번 "OPNET 기초다지기"보다도 학습하기에 더 쉬운 부분도 많으며, 교재의 제목이 "OPNET 중급입문"이라는 다소 어정쩡한 이름으로 결정된 것도 이 때문입니다. 그렇지만, 처음의 기획의도가 변경된 것에 대해서는 후회하지 않으며, 사용자들이 실제로 필요로 하는 부분을 반영하여 출판할 수 있었다는 것은 무척 다행스러운 일이라고 생각합니다.

OPNET 고급사용자를 위한 세번째 교재는 "OPNET 기초다지기"의 개정작업때문에 잠시 미루어질 것 같습니다. "OPNET 기초다지기"가 출판된지 거의 3년이 지나서 GUI나 사용법이 달라진 부분들이 있는데다가, 보완이 필요한 부분들이 여러 곳 발견되었기 때문입니다.

이 책이 국내의 OPNET 사용자들에게 많은 도움이 되기를 바랍니다.

                                                                                                               - 신상헌

지난 10월16일에 발표된 OPNET사의 공지에 의하면 앞으로는 Windows 2000을 지원하지 않을 예정이라고 한다. 따라서, 현재의 16.0 버전이 Windows 2000에서 사용할 수 있는 마지막 OPNET 버전이 될 것으로 보인다. (Modeler 및 IT Guru 모두 해당)
혹시라도 아직까지 Windows 2000을 사용하고 있던 사용자라면, 이제 OS를 업그레이드 할 시기가 된 것 같다.

32비트 윈도우에서 Visual Studio 2008을 컴파일러로 사용하기 위한 환경 변수 설정. (OPNET 14.5 PL0 버전부터
Visual Studio 2008을 지원한다)

DevEnvDir=C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE

Framework35Version=v3.5

FrameworkDir=C:\WINDOWS\Microsoft.NET\Framework

FrameworkVersion=v2.0.50727

INCLUDE=
C:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\INCLUDE;
C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE;
C:\Program Files\Microsoft SDKs\Windows\v6.0A\include;

LIB=
C:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;
C:\Program Files\Microsoft Visual Studio 9.0\VC\LIB;
C:\Program Files\Microsoft SDKs\Windows\v6.0A\lib;

LIBPATH=
C:\WINDOWS\Microsoft.NET\Framework\v3.5;
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;
C:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;
C:\Program Files\Microsoft Visual Studio 9.0\VC\LIB;

PATH=
C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE;
C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN;
C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools;
C:\WINDOWS\Microsoft.NET\Framework\v3.5;
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;
C:\Program Files\Microsoft Visual Studio 9.0\VC\VCPackages;
C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin;

VCINSTALLDIR=
C:\Program Files\Microsoft Visual Studio 9.0\VC

VS90COMNTOOLS=
C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\

VSINSTALLDIR=
C:\Program Files\Microsoft Visual Studio 9.0

WindowsSdkDir=
C:\Program Files\Microsoft SDKs\Windows\v6.0A\

하나의 시나리오에서 네트워크 파라미터의 변경이 전혀없이 생성된 결과 그래프들인데도 불구하고, 실행할 때마다 그 값이 달라지는 경우가 종종 있다. (물론 시뮬레이션 seed값이 다른 경우라면 이는 당연할 것이며, 여기에서는 동일한 seed 값이 사용된 경우를 얘기한다) 이 경우, OPNET에 익숙하지 않은 사용자들은 당황하거나, 심지어는 OPNET 시뮬레이션 결과를 불신하는 상황이 벌어지기도 한다.
하지만, 이는 OPNET에서 결과값을 기록하는 방식을 정확히 이해하지 못하는 데서 발생하는 오해(?)로서, 시뮬레이션이 잘못된 것이 전혀 아니다. 즉, 시뮬레이션의 실제 결과값은 동일하지만, 이 결과값들을 가공하여 사용자에게 보여주는 과정에서 마치 다른 결과값들인 것처럼 보여지는 경우가 있는 것이다. 어떤 관점에서 보면, 결과값을 사용자에게 보여주는 방법에 있어서 너무 다양한 수단을 제공하기 때문에 발생하는 문제라고 할 수 있다.
그 예로서, 아래의 두 결과 그래프를 비교해보도록 하자. 첫번째 그래프는 VoIP_example 시나리오  (조만간 출판될 "OPNET 중급입문" 교재에 소개되어 있다)에서 Calling_1 노드의 Voice Application -->Traffic Received (bytes/sec) 항목을 그린 것이며(10분동안 수행된다), 두번째 그래프는 동일한 시나리오를 5분동안만 수행하고 동일한 항목의 결과를 그린 것이다.

두 개의 결과값이 다르게 보이는 것을 확인할 수 있을 것이다. 동일한 시뮬레이션인데도 불구하고 왜 결과값이 달라보이는 것일까? 그 이유는 역설적이지만 두 시뮬레이션에서 동일한 "Values per statistic" 속성값이 사용되었기 때문이다. Values per statistic 속성은 하나의 결과항목(statistic)을 위해서 몇 개의 값(value point)을 기록할 것인가를 지정하는 것으로, 시뮬레이션 수행시 Configuration/Run DES 창에서 설정할 수 있으며 기본값은 100이다.

두 시뮬레이션에서 동일하게 100개의 값만을 최종적으로 기록하므로, 10분(600sec)동안 시뮬레이션을 한 경우에는 600sec/100 = 6sec 간격으로 데이터를 기록하고 5분(300sec)동안 시뮬레이션을 한 경우에는 300sec/100 = 3sec 간격으로 데이터를 기록하게 된다. 기록되는 데이터는 시간에 대한 평균값이므로, 설령 동일한 시각의 기록이라 할지라도 기록 간격이 다르면 서로 다른 값으로 보여지게 된다.
다음의 결과는 이러한 매커니즘을 확인하기 위한 것이다. 첫번째 그래프는 Values per statistic 값을 100으로 두고 5분동안 수행한 것이며, 두번째 그래프는 Values per statistic 값을 200으로 변경하고 10분동안 수행한 것이다. 따라서, 두 시뮬레이션에서 데이터를 기록하는 간격은 동일하게 3sec이다. 5분까지의 결과만을 살펴보았을 때, 두 시뮬레이션의 결과가 완벽하게 일치하는 것을 확인할 수 있다.

이렇게 시뮬레이션 수행시간에 따라 결과 그래프가 달라지는 현상을 피하고 싶다면, 해당 결과항목(statistic probe)의 capture mode를 수정하여 데이터 기록 주기를 일정하게 고정시켜주면 된다. 단, 이 상태에서 긴 수행시간에 대해서 시뮬레이션을 수행할 경우, 기록되는 데이터 양의 증가로 인해 결과 프래프를 표현하는데 불편함이 발생할 수 있으니 주의하기 바란다.
다음의 결과 그래프는 동일한 시뮬레이션 결과에 대해서 데이터 기록 간격을 서로 달리하여 결과를 수집하여 그 차이를 비교해본 것이다. 즉, 세 시뮬레이션에서 실제로 발생한 raw data는 모두 같지만, 결과 데이터를 기록하는 간격이 6sec(600sec/100), 3sec(600sec/200), 1sec(매 1초마다 기록하도록 고정)로 다를 뿐이다.

단말의 수가 많은 세그먼트에서 실제 네트워크 구성시, 이더넷 허브를 데이지 체인(daisy chain) 형태로 연결하여 사용하는 경우가 있다. 즉, 허브에 허브를 연결하여 연결 가능한 포트수를 늘리는 것으로, 허브의 포트수가 부족한 경우에 많은 포트수를 가지는 새로운 장비를 구입할 필요없이 기존의 허브를 활용하여 문제를 해결할 수 있으므로, 상당히 유용한 방법이며 종종 사용된다.
이러한 구성이 OPNET에서도 가능할까? 아쉽게도 이렇게 허브를 연속적으로 연결하는 구성은 OPNET에서 지원되지 않는다. 즉, OPNET의 이더넷 허브 모델은 자신이 다른 허브와 직접 연결되지 않는다고 가정하고 만들어졌기 때문에, 허브에 허브를 연결하고 시뮬레이션을 수행하면 다음과 같은 에러 메시지를 보여주고 시뮬레이션이 중단된다.

이러한 에러메시지가 출력되는 직접적인 이유는 이덧넷 허브 노드 모델에 사용되는 etherent_hub_v2 프로세스 모델의 init 스테이트에서 연결된 주변 노드들을 검사하고 만약 허브와 연결되어 있으면 시뮬레이션을 중단시키기 때문이다.
init 스테이트의 Exit 블럭을 살펴보면 168라인에 다음과 같은 코드가 있다. 이웃 노드에 등록된 프로세스들을 살펴보고 "protocol" 속성값으로 "eth_hub"를 가진 프로세스가 있으면, 에러 메시지를 출력하고 시뮬레이션을 종료(ethernet_hub_concat_log_wirte() 함수)시키는 것이다.

물론, 단순히 이 부분의 코드를 삭제한다고 해서 데이지 체인으로 연결된 허브가 성공적으로 시뮬레이션 되지는 않는다. 이 부분에서 시뮬레이션을 종료시키는 이유는 데이지 체인 형태의 연결에 의한 문제인 경우, 이후의 코드에서 다른 원인에 의해서 발생하는 에러메시지와 구분되지 않아서 혼란을 주는 것을 예방하기 위해서이기 때문이다.
이러한 문제를 해결하는 방안은 충분한 포트수를 가지는 이더넷 허브 모델을 사용(256 포트를 가지는 모델을 기본으로 제공한다)하거나, 허브와 허브 사이에 브릿지나 스위치를 연결해주는 것이다.
시뮬레이션 관점에서 본다면, 한개의 허브에 수백개의 단말을 개별적으로 연결해야하는 경우는 극히 드물다. 왜냐하면 많은 수의 단말에 의한 전체적인 영향을 살펴보기 위해서라면, 한개의 LANs 노드 모델로 충분히 모델링이 가능하며 훨씬 간편하기 때문이다.

OPNET에서 사용하는 언어는 정확히 표현하자면 그냥 C가 아니라 "Proto-C"이다. Proto-C라는 별도의 명칭을 사용하는 이유는 OPNET에서는 일반적인 C/C++ 언어의 기능외에도, KP(Kernel Procedure)라고 불리우는 추가적인 함수들을 사용할 수 있으며, 프로토콜을 모델링할 때 그래픽 유저 인터페이스를 통해 STD(State Transition Diagram)를 표현하기 때문이다.
즉, Proto-C라고 해서 기존의 C/C++ 언어와 다른 문법을 사용하는 것은 아니며(이는 OPNET이 자체적인 컴파일러를 가지고 있지 않으며, Visual C++이나 gcc등의 범용 컴파일러를 불러와서 사용하는 것을 생각해보면 당연한 것이다), 통신망 모델링에서 공통적으로 사용되는 여러가지 편리한 함수 라이브러리들을 추가적으로 제공하고, GUI상에 그려진 스테이트 다이어그램을 자동으로 C 코드로 변환해주는 기능을 제공하는 것이다.