네트워크 시뮬레이션 공방

Riverbed Modeler(OPNET) TCP 모델은 다음 그림처럼 사용자가 ECN(Explicit Congestion Notification)[1] 적용 여부를 설정할 수 있는 ECN Capability 속성을 제공한다.

이 속성에서 선택 가능한 값은 Enabled, Disabled, Passive이다. Passive로 설정되면 상대방(client)에서 ECN 사용을 먼저 요청하는 경우에만 ECN을 사용한다. 즉, Passive는 Server 노드에서만 의미가 있으며, Client 노드가 Passive로 설정되면 Disbled로 설정된 것과 동일하다. 기본값은 "Disabled"이다.

[1] RFC 3168, "The Addition of Explicit Congestion Notification (ECN) to IP", IETF, Sep. 2001.

TCP SACK의 동작을 시험하기 위해서 "TCP 재전송(8) - Duplicate ACK"에서 사용한 시나리오를 수정하여 Discarder_2 노드에서 폐기되는 패킷수를 2로 변경하고, STA 노드와 Server 노드의 "Selective ACK (SACK)" 속성값을 다음 그림과 같이 Enabled로 변경한다.

시뮬레이션을 수행한 후, Server 노드에서 측정된 "Selectively ACKed Data (bytes)" 결과 항목을 살펴보면 다음 그림처럼 200초 무렵에 패킷 손실이 발생하였을 때 SACK에 의한 응답이 사용되었음을 확인할 수 있다.

"Selective ACK (SACK)" 속성값이 Disabled로 설정된 경우에는 SACK에 의한 응답이 사용되지 않으므로, 이 "Selectively ACKed Data (bytes)" 결고 항목에 아무런 값도 기록되지 않는다.

"라우터 배치 순서와 라우팅 경로 선정"에서 사용한 예제망을 활용하여 RIP의 동작을 확인해보기로 하자.
첫번째 예제의 네트워크 토폴로지는 "라우터 배치 순서와 라우팅 경로 선정"에서 사용한 예제망 구조와 동일하다.

이 예제망에 실제로 할당된 IP주소 내역은 다음과 같다.

시뮬레이션을 수행한 후, R1 노드에서 구성된 라우팅 테이블을 살펴보면 다음 그림과 같다. ("라우팅 경로 확인하기" 참조).

R2 - R4, R3 - R4, R4 - Server 네트워크에 대한 라우팅 정보가 RIP에 의해 생성되었으며, R2 - R4, R3 - R4 네트워크에 대한 Metric은 1, R4 - Server 네트워크에 대한 Metric은 2임을 확인할 수 있다. 이는 "RIP에서의 네트워크 비용"에서 설명하였듯이, RIP는 홉 카운트를 기본 Metric으로 사용하기 때문이다.
Client 노드로부터 Server 노드로의 트래픽 전달 경로는 다음과 같이 2홉(R1 -> R2 -> R4 경로)으로 확인되며, 이는 라우팅 테이블과 일치한다. (이후의 1홉 예제의 결과와 비교할 것이므로 R1 -> R2 -> R4 경로, 또는 R1 -> R3 -> R4 경로 어느 쪽이던 별 상관은 없다)

이제 R1 노드와 R4 노드사이에 1홉 링크를 추가하여 RIP의 특성을 보다 자세히 살펴보자. 다음 그림은 첫번째 예제를 변형한 두번째 예제의 구조이다. R1 노드와 R4 노드 사이에 다른 링크(DS3)보다 작은 대역폭의 링크(DS1)를 추가하였다.

두번째 예제망에 실제로 할당된 IP주소 내역은 다음과 같다.

시뮬레이션을 수행한 후, 두 번재 시나리오에서 R1 노드에 구성된 라우팅 테이블을 살펴보면 다음 그림과 같다.

R1 노드와 R4 노드를 연결하는 링크가 추가됨에 따라 R4 - Server 네트워크에 대한 경로가 Metric 1인 경로로 변경되었음을 확인 할 수 있다.
이제 Client 노드로부터 Server 노드로의 트래픽 전달 경로를 살펴보면 라우팅 테이블의 구성과 같이 1홉 경로(R1 -> R4)인 것을 알 수 있다.

즉, 기본적으로 RIP는 링크의 대역폭에 상관없이 홉수를 기반으로 라우팅 경로를 선정한다. 만약, 링크들의 대역폭이 크게 차이나는 경우라면, 이러한 특성은 큰 문제를 불러일으킬 수도 있다.

Riverbed Modeler(OPNET) SITL에서 시뮬레이션 패킷과 실세계 패킷 간의 패킷 변환을 지원하는 프로토콜 종류에 대해서는 "SITL에서 지원하는 프로토콜의 종류"에서 살펴보았다. 그러면, 여기에 해당하지 않는 프로토콜 패킷은 어떻게 처리되는지 좀더 살펴보기로 하자.
현재 대부분의 네트워크 장비는 IP 프로토콜을 사용하므로, 네트워크 계층 프로토콜을 SITL을 통해 연동시키는 것에서는 문제가 거의 발생하지 않는다. 문제는 NetBIOS나 RTP처럼 종단 단말간에 전달되는 상위계층 프로토콜에서 발생한다("SITL 사용시 NetBIOS 트래픽 처리" 참조). 이렇게 패킷 변환이 지원되지 않는 프로토콜의 패킷이 SITL 게이트웨이에 도착하였을 때의 처리 결과를 시뮬레이션 시나리오 및 파라미터 설정상태에 따라 구분하여 정리해보면 다음과 같다.

1) Riverbed Modeler(OPNET)을 통과(Passthrough)하는 패킷을 때 : 해당 페이로도를 unformatted 패킷에 담아 전달한다. 최종적으로 Riverbed Modeler(OPNET) 외부에서 해석될 것이므로 문제가 되지 않는다.

2) Riverbed Modeler(OPNET) 시나리오 상의 노드를 목적지로 하는 패킷일 때 : SITL 게이트웨이의 "Drop Real Packet If Translation Fails" 속성 설정값에 따른다. "Drop Real Packet If Translation Fails" 속성이 Enabled이면(기본값이 Enabled이다), 전달하지 않고 폐기한다. 해당 속성이 Disabled이면, 페이로드를 unformatted 패킷에 담아 전달한다.

3) Riverbed Modeler(OPNET) 시나리오 상의 노드를 목적지로 하는 브로드캐스트 패킷일 때 : SITL 게이트웨이의 "Drop Real Packet If Translation Fails" 속성 설정값과는 상관없이 페이로드를 unformatted 패킷에 담아 전달한다. "SITL 사용시 NetBIOS 트래픽 처리" 예에서 문제가 발생한 이유도 NetBIOS 패킷들이 브로드캐스트 주소를 사용하기 때문이다.

여기에서 한 가지 유의해야할 사항은 "2) Riverbed Modeler(OPNET) 시나리오 상의 노드를 목적지로 하는 패킷일 때"의 경우와 "3) Riverbed Modeler(OPNET) 시나리오 상의 노드를 목적지로 하는 브로드캐스트 패킷일 때"의 경우에 있어 unformatted 패킷으로 변환되는 페이로드 레벨이 다를 수 있다는 점이다. 즉, unformatted 패킷으로 변환하는 페이로드 레벨은 2)의 경우 SITL 게이트웨이 노드의 "Maximum Packet Translation Level" 속성값에 의해 결정된다. 하지만, 3)의 경우에는 "Maximum Packet Translation Level for Passthrough" 속성값에 의해 결정된다(단, SITL GW와 맵핑된 NIC에서 발생시킨 패킷은 항상 "Maximum Packet Translation Level for Passthrough" 속성값이 2일 때와 동일하게 처리된다. 즉, UDP 헤더부터 unformatted 패킷에 담겨서 처리된다).

global_perm_data[][] 행렬은 모든 Zone type과 FFT 사이즈에 대한 서브캐리어와 서브채널간 매핑 정보와 주파수 중첩에 대한 정보(overlap matrix)를 저장하기 위한 공간이다.
global_perm_data 행렬의 각 멤버는 CochannelT_zone_perm_data 구조체이며, 이 구조체의 subchannel_map_pointer_array 멤버에 permutation base 별 서브캐리어와 서브채널간 매핑 정보가 저장된다. subchannel_map_pointer_array 행렬의 멤버는 CochannelT_subchannel_map_pointer_array 구조체이며, 이 구조체의 subcarr_to_sub_chan_map 멤버에 해당 permutation base를 사용했을 때 각 서브캐리어가 어느 서브채널에 의해서 사용되는지의 정보가 기록된다. 서브캐리어와 서브채널간 맵핑은 표준[1]에서 정의한 규칙에 따라 각 zone type(DLFUSC, DLPUSC, ULPUSC) 별로 따로 계산된다.
CochannelT_zone_perm_data 구조체의 cum_overlap_pointer_matrix 멤버는 동일한 zone type을 사용하는 섹터들간의 주파수 중첩 정보를 위한 것이며, "WiMAX 모델(120) - Subcarrier overlap matrix"에서 설명한 subcarrier overlap matrix가 cumulative matrix 형태로 저장된다. 이러한 중첩 발생이 가능한 경우의 수는 permutation base의 갯수의 제곱이다.
CochannelT_zone_perm_data 구조체의 cum_overlap_non_data_array 멤버는 서로 다른 zone type을 사용하는 섹터들간의 주파수 중첩 정보를 위한 것이다.

[1] IEEE 802.16-2009, "Air Interface for Broadband Wireless Access Systems", 2009.

Riverbed Modeler(OPNET) TCP 모델은 다음 그림처럼 사용자가 Selective Acknowlegment(SACK) 적용 여부를 설정할 수 있는 속성을 제공한다.

이 속성에서 선택 가능한 값은 Enabled, Disabled, Passive이다. Passive로 설정되면 상대방(client)에서 SACK 사용을 먼저 요청하는 경우에만 SACK을 사용한다. 즉, Passive는 Server 노드에서만 의미가 있으며, Client 노드가 Passive로 설정되면 Disabled로 설정된 것과 동일하다. 기본값은 17.1 버전까지는 "Disabled", 17.5 버전에서는 "Enabled"이다.

Riverbed Modeler(OPNET) TCP 모델은 다음 그림처럼 사용자가 Slow Start에서 사용될 Congestion Window의 초기값을 설정할 수 있는 기능을 제공한다.

이 속성값은 MSS("TCP MSS" 참조)의 배수를 의미하며, 선택 가능한 값은 1, 2, 4, As defined in RFC-2414 이다. "As defined in RFC-2414"가 선택되면 RFC 2414[1]에 정의되어 있는 다음 수식에 따라 Congestion Window의 초기값을 계산한다.

initial window = min (4*MSS, max (2*MSS, 4380 bytes))  (1)

RFC 2414[1]는 RFC 3390[2]으로 대체되었지만, initial window 계산 공식에는 변화가 없다.

[1] RFC 2414, "Increasing TCP's Initial Window", IETF, Sep. 1998.
[2] RFC 3390, "Increasing TCP's Initial Window", IETF, Oct. 2002.

RIP에서 라우팅 테이블을 구성할 때 사용되는 Metric은 네트워크(또는 홉)의 비용(cost)이다[1, 2]. CISCO사의 제품에서는 홉 카운트를 cost로 사용하며[3], Riverbed Modeler(OPNET)의 RIP 모델 역시 이와 동일한 방식을 사용한다.
다음 그림은 Riverbed Modeler(OPNET)에서 제공하는 인터페이스별 RIP Cost 설정창을 보인 것이다. 1 ~ 16 범위의 정수값을 입력할 수 있다.

[1] RFC 1058, "Routing Information Protocol", IETF, June. 1988.
[2] http://docwiki.cisco.com/wiki/Routing_Information_Protocol
[3] http://www.cisco.com/c/en/us/td/docs/ios/12_2/ip/configuration/guide/fipr_c/1cfrip.html#wp1000992

다음 그림은 동일한 토폴로지상에 배치된 두 단말사이의 라우팅 경로를 비교하여 나타낸 것이다. 그런데, 사용된 모델 및 파라미터가 모두 동일한데도 불구하고, 두 시나리오에서 선정된 라우팅 경로가 서로 다른 것을 알 수 있다.

왜 이런 차이가 발생한 것일까? 그 이유는 두 시나리오에서 토폴로지를 그릴 때, 라우터의 배치 순서가 달랐기 때문이다. 시나리오1에서는 R2를 R3보다 먼저 배치하였고, 시나리오2에서는 R3를 R2보다 먼저 배치하였다. 먼저 배치되었다고 해서 라우팅 경로가 항상 해당 라우터 쪽으로 설정되는 것은 아니다. 다만, 라우팅 프로토콜이 동일한 시간에 동작한다면 먼저 생성(instancing)된 라우터의 라우팅 프로토콜 메시지가 먼저 발생하고(동일한 시간에 발생한 event들도 발생 순서에 따라 처리되는 것은 discrete event simulation의 특성이다), 이웃 라우터에도 먼저 도착하여 처리되므로 동일한 비용을 가지는 경로 들중에서는 우선적으로 선택되는 것이다.

TCP의 Delayed ACK Mechanism이 Segment/Clock Based 방식이고 데이터가 계속 수신되고 있는 상태라면 ACK 메시지는 대부분 Segment 기반으로 (즉, Maximum ACK Segments에 도달하여) 발생되지만, Clock 기반으로 (즉, Maximum ACK Delay에 도달하여) 발생되는 경우도 있다.
실제로 "TCP Delayed ACK(2) - 예제"에서의 결과에서도 200.4초에 송신된 ACK는 Clock 기반으로 발생된 (즉, Maximum ACK Delay에 도달하여 수신 세그먼트 1개에 대한 응답만으로 구성된) 것이다. 단순하게 생각하면 Maximum ACK Delay 시간(200ms)보다 훨씬 짧은 간격(약 100ms)으로 데이터가 계속 수신되고 있으므로, 모든 ACK는 Maximum ACK Segments에 의해 발생되어야 할 것 같은데 왜 이런 현상이 발생한 것일까?
그 이유는 Delayed ACK을 위한 타임아웃 설정은 데이터 패킷 수신 시점을 기준으로 이루어지는 것이 아니라, Maximum ACK Delay 시간 단위(tick)로 이루어지기 때문이다. 따라서, 데이터 패킷을 계속 수신중이라 할지라도 마지막 ACK 송신후 수신된 데이터 패킷의 수가 Maximum ACK Segments에 도달하지 않은 상태(즉, ACK를 보내지 않은 데이터 패킷이 있는 상태)에서 Maximum ACK Delay에 의한 타임아웃 시각에 도달하는 경우가 발생할 수도 있는 것이다.