네트워크 시뮬레이션 공방

802.11b 11Mbps 환경에서 237Bytes 크기의 MAC 사용자 패킷을 전송하는 경우에 거리에 따른 MAC 사용자 패킷 전달률(Throughput) 변화는 "WiFi 모델에서의 통신 가능 거리(5) - MAC Throughput(1)"에서 살펴본 바 있다.
이번에는 동일한 환경에서 IP 패킷을 전송하는 경우, 패킷 전달률이 어떻게 변화하는지 살펴보기로 하자. (얼핏 생각하면 패킷 전달률이 동일할 것처럼 생각할 수 있지만, 시뮬레이션 결과는 그렇지 않다는 것을 보여준다.)
2대의 WLAN 워크스테이션 노드를 배치하고, Physical Characteristics은 "Direct Sequence"로, Data Rate(bps)는 "11Mbps"로 설정한다. 트래픽은 Demand 타입의 Traffic Flow를 이용하여 237Bytes 크기의 패킷을 두 노드 사이에 전달하였다.

먼저, 1,024M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 시뮬레이션 결과(전달률 100%)와는 약간 차이가 있지만 유사한 결과(전달률 약 99.32%)를 보여준다.

다음으로, 1,084M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 시뮬레이션 결과(전달률 94.94%)와는 매우 큰 차이가 나는 결과(전달률 약 68.58%)를 보여준다.

다음으로, 1,116M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 시뮬레이션 결과(전달률 71.25%)와는 매우 큰 차이가 나는 결과(전달률 약 15.93%)를 보여준다.

다음으로, 1,217M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 시뮬레이션 결과(전달률 0.25%)와는 약간 차이가 있지만 유사한 결과(전달률 0.0%)를 보여준다.

즉, IP 트래픽 패킷을 사용하여도 BER이 낮을 때(거리가 가까울 때)는 MAC 사용자 패킷을 전송하는 경우와 비슷한 결과를 보여주지만, BER이 높을 때(거리가 멀 때)는 MAC 사용자 패킷을 전송하는 경우보다 훨씬 낮은 전달률을 보여준다. 왜 이런 차이가 발생하는 것일까? 그 이유는 IP 라우팅 때문이다.
IP 트래픽 패킷을 전송하기 위해서는 소스 노드의 IP 라우팅 테이블에 목적지에 대한 경로가 존재해야 한다. 만약 IP 라우팅 테이블에 경로가 존재하지 않으면, 패킷은 소스 노드의 IP 계층 하위로도 전송되지 않는다. 그런데, 라우팅 프로토콜 메시지도 IP 패킷이므로, BER이 높아지면 라우팅 프로토콜 메시지도 역시 잘 전달되지 못하고 라우팅 테이블 경로 구성에 실패하는 경우가 발생한다. 이 시점에 발생한 IP 트래픽 패킷은 모두 폐기되므로, BER이 높아지면 IP 트래픽 패킷의 전달률은 실제 MAC 계층의 전송 용량보다 크게 낮아지는 것이다.
다음은 이를 확인하기 위하여 소스 노드의 라우팅 테이블 정보를 중요 시간별로 관찰한 것이다. BER이 낮은 때(1,024M 거리)에는 라우팅 테이블상에 경로가 항상 구성되어 있음을 알 수 있다.

BER이 높을 때(1,084M 거리)에는 라우팅 테이블상에 경로 구성이 되지 않은 경우가 발생함을 알 수 있다.

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

Riverbed Modeler 18.11.1 버전이 2024년12월10일자로 발표되었습니다(이전 버전에 관한 내용은 "Riverbed Modeler 18.11.0 발표" 참조).  Release notes에는 12월16일자로 되어 있는데, 홈페이지에는 오히려 12월10일로 표시되어있습니다. 아쉽게도, 이번에도 메일 공지가 없었습니다.
Release notes를 통해 변경 사항을 살펴보았습니다. 모델 업데이트는 없으며, 다음과 같은 보안 업데이트만 적용되었습니다.

- Java Runtime Environment(JRE) 버전을 17.0.13으로 업그레이드
- Elastic Search libraries 제거

그동안 20년 넘게 OPNET(Riverbed Modeler)를 사용해왔지만, 이렇게 보안 패치만으로 버전업이 이루어지는 경우는 처음 보는 것 같습니다. 특이하네요.

Riverbed Modeler 18.11.0 버전이 2024년8월30일자로 발표되었습니다(이전 버전에 관한 내용은 "Riverbed Modeler 18.10.0 발표" 참조).  Release notes에는 8월29일자로 되어 있는데, 홈페이지에는 8월30일자로 되어있습니다. 아쉽게도, 이번에도 메일 공지가 없었습니다.
Release notes를 통해 변경 사항을 살펴보았습니다. 모델 업데이트는 1가지입니다.

- Wireless LAN Model Enhancement – IEEE 802.11ax Support Phase-I

WLAN 모델 개선 사항은 802.11ax High Efficient(또는 Wi-Fi 6 및 Wi-Fi 6E) 기술을 지원하기 사작했다는
것입니다. 금번에 지원되는 특성은 다음과 같습니다.
  * 2.4 GHz, 5 GHz, 6 GHz 밴드에서 동작
  * 56-QAM 5/6, 1024-QAM 3/4, 1024-QAM 5/6 변조를 사용하는 고속 데이터 전송률
  * 3가지 GI 옵션 (GI-LTF와의 조합 포함)
  * HE PPDU 포맷(HE SU PPDU, HE TB SU PPDU, Nominal Packet Padding, LDPC coding)
  * maximum A-MPDU size 증가
  * basic NAV and intra-BSS NAV
  * 수신된 PPDU에 대한 Intra/inter-BSS 구분
  * BSS Color
  * TXOP duration-based RTS/CTS
  * Multi-TID A-MPDUs
  * non-AP HE STA의 버퍼 상태 보고 
  * Contention free uplink access
  * Dynamic fragmentation – Level 1

그리고, WLAN 모델에서 Delayed Block ACK가 제거되었습니다.

또한, Red Hat Enterprise Linux 8 플랫폼을 지원하게 되었고, 모델러에서 사용하는 Java의 버전이 Java 17로 변경되었다고 합니다. 그 외에 버그 수정사항 4건도 있습니다만, 특별히 관심이 가는 내용이 아니라서 생략합니다.

OPNET Modeler는 17.1 버전부터 TCP Duplicate SACK[1]을 지원한다("OPNET Modeler 17.1 PL1 발표" 참조). 다음 그림은 사용자가 Duplicate SACK(D-SACK) 적용 여부를 설정할 수 있도록 OPNET TCP 모델에서 제공하는 속성을 보인 것이다.

이 속성에서 선택 가능한 값은 Disabled와 Enabled이며, Enabled를 선택하기 위해서는 SACK 속성 항목("TCP SACK(1) - 파라미터 설정" 참조)의 값이 Enabled 또는 Passive로 설정되어야만 한다. 기본값은 Enabled.

[1] RFC 2883, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", IETF, Jul. 2000.
[2] RFC 2018, "TCP Selective Acknowledgment Options", IETF, Oct. 1996.
[3] RFC 3708, "Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions, IETF, Feb. 2004.

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

어플리케이션 타이밍("어플리케이션 사용 패턴(1) - 파라미터 설정" 참조)을 조절하여 하나의 어플리케이션이 프로파일내에서 일정 시간 간격으로 반복 실행되도록 만들수 있음은 "어플리케이션 사용 패턴(3) - 어플리케이션 반복 예제"에서 살펴보았다. 트래픽을 원하는 시간 간격마다 반복해서 발생시키는 또 다른 방법은 어플리케이션이 포함되어 있는 프로파일의 타이밍을 조절하여 어플리케이션이 반복적으로 실행되도록 하는 것이다.

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

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

Duration은 100초, Inter-repetition Time은 400초로 설정하였을 때, Client로 노드로 전송되는 트래픽을 살펴보면 다음 그림과 같다.

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

Destination only flag 정보는 RREQ 메시지("AODV 메시지(2) - RREQ 구조체" 참조)에서 사용되며, RREQ에 대한 응답을 중간 노드에서 대신 처리할지의 여부를 알린다[1]. 다음 그림은 사용자가 Destination only flag사용 여부를 설정할 수 있도록 Riverbed(OPNET) Modeler에서 제공하는 속성 설정창을 보인 것이다.

설정 가능한 값은 Enabled와 Disabled이다.

- Enabled : 목적지 노드만 RREQ에 대한 응답 RREP를 생성함.
- Disabed : 목적지 노드뿐만 아니라 경로상 목적지 노드 이전에 위치한 중간 노드도 RREQ에 대한 응답 RREP를 생성할 수 있음.

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

"라우팅 테이블과 포워딩 테이블"에서 살펴본 것처럼, Riverbed(OPNET) Modeler에서 라우팅 테이블과 포위딩 테이블은 완전히 분리되어 별도로 저장된다. 하지만, "라우팅/포워딩 테이블 예제(1) - RIP"와 "라우팅/포워딩 테이블 예제(2) - OSPF"에서 살펴본 예제에서는 두 테이블에 저장되어 있는 정보의 내용은 동일하였다.
그러면, 두 테이블에는 항상 동일한 정보가 저장되는 것일까? 그렇지는 않다. 이제 또 다른 예제를 통해 라우팅 테이블과 포워딩 테이블에 서로 다른 정보가 저장될 수도 있음을 확인해보기로 하자. 다음은 "RIP 라우팅 예제"에서 사용한 시나리오를 수정하여 작성한 시험망 토폴로지이다.

Client <-> R1, R1 <-> R2, R2 <-> R4, R4 <-> Server 구간에는 RIP를 적용하였고, R1 <-> R3, R3 <-> R4 구간에는 OSPF를 적용하였다. 이 예제망에 실제로 할당된 IP주소 내역은 다음과 같다.

시뮬레이션을 수행한 후, R1 노드에서 구성된 RIP 라우팅 테이블, OSPF 라우팅 테이블, IP 포워딩 테이블을 비교하여 살펴보면 다음 그림과 같다.

R1 노드에는 RIP와 OSPF가 모두 실행되므로 RIP 라우팅 테이블과 OSPF 라우팅 테이블이 각각 만들어지며, IP 포워딩 테이블에는 RIP 라이팅 테이블 정보와 OSPF 라우팅 테이블 정보가 모두 취합되어 있는 것을 확인할 수 있다. (실제 망에서 라우팅 프로토콜을 이렇게 구성하는 경우는 거의 없을 것이라는 점에서 좋은 예제는 아니다. 하지만, Riverbed(OPNET) Modeler에서 라우팅 테이블과 포워딩 테이블의 관계를 이해하는데는 도움이 될 것이다.)

다음 그림은 Riverbed(OPNET) Modeler ICMP 모델에서 사용하는 패킷 포맷과 fields 필드에 실리는 정보를 나타낸 것이다.

ip_icmp 패킷은 ICMP 메시지를 위한 컨테이너 패킷이며, 실제 ICMP 메시지는 echo_packet 필드에 실린다. 어떤 ICMP 메시지가 실려있는지는 fields 필드에 실려있는 IpT_Icmp_Packet_Fields 구조체의 message_type 정보를 통해 구분할 수 있다. 이러한 구조는 다양한 ICMP 메시지들을 공통으로 사용하는 단일 ICMP 패킷을 통해 처리하기 위한 의도인 것으로 생각된다.
하지만, "ip_icmp 프로세스 모델"에서 살펴보았듯이 Riverbed(OPNET) Modeler 18.0.3 버전("Riverbed Modeler 18.0.3 발표" 참조)에서는 ICMP 메시지들[1, 2]중 Echo/Echo Reply 메시지만 사용되므로, 실제적으로는 이 구조가 특별한 의미를 가지지 못하고 사용자들에게 혼란을 주는 면이 있다.

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