네트워크 시뮬레이션 공방

OFDLMA UL에서는 burst를 위한 패킷 전송시 특수한 상황이 발생하여 전송 시작시간과 전송시간을 근사값으로 변환하여 사용하는 경우가 있다. 전송 시작시간과 전송시간은 채널 간섭 계산에서 매우 중요한 요소이므로, 이러한 경우에 계산된 동일 채널 간섭은 실제와는 약간의 오차가 있음에 주의하여야 한다.
첫 번째로는 다음 그림과 같이 하나의 burst가 시간적으로 보아 분리되는 경우이다.

이 경우 두 개의 조각(segment)중에서 큰 쪽을 선택하여 패킷 전송 시작시간(start_seconds)과 전송시간(transmission_delay)를 모두 재조정한다.
두 번째로는 다음 그림과 같이 하나의 burst가 시간적으로 연속되어 있기는 하지만, 첫 번째의 서브 채널에서의 시작 시간이 다른 서브채널에서의 시작시간보다 늦은 경우이다.

이 경우 패킷 전송 시작 시간(start_seconds)은 UL 서브프레임의 시작시점(즉, 가장 빠른 서브채널에서의 시작시점)으로 지정하고, 전송 시간(transmission_delay)은 (제어 오버헤드에 사용되는 부분을 제외한) UL 서브프레임의 전체 길이로 설정한다.

Riverbed(OPNET) Modeler TCP 모델은 패킷 손실에 의한 재전송 수행시 Slow Start 기준값(ssthreshold)을 계산하는 방법을 선택할 수 있도록 "Segment Send Threshold" 속성을 제공한다.

이 속성에서 선택 가능한 값은 Byte Boundary와 MSS Boundary이다. 패킷 손실에 의한 재전송 수행시 ssthreshold 크기는 현재 네트워크를 통해 전송중인 데이터 크기(FlightSize)의 절반으로 줄어든다("OPNET 기초다지기" 참조). 이 때, Segment Send Threshold 속성이 Byte Boundary로 설정되어 있으면 ssthresh 크기는 단순히 전송중인 데이터 크기의 절반으로 줄어들고, MSS Boundary로 설정되어 있으면 가장 근접한 MSS("TCP MSS" 참조) 배수값에 맞춘다. 기본값은 MSS Boundary이다.

다음은 ECN 기능 적용시의 효과를 확인하기 위하여 "TCP 재전송(8) - Duplicate ACK"에서 사용한 시나리오를 수정한 시험망 토폴로지를 나타낸 것이다. 네트워크에서 혼잡상황 발생시 IP 패킷에 표시(마킹)를 해주기 위하여 Discarder_2 노드를 라우터 노드 모델로 대체하였다. 또, 이 라우터에 혼잡 상황을 발생시키기 위하여 디맨드 모델("Background Traffic의 영향(4) - Demand Model" 참조)을 이용하여 100초동안 2.5Mbps의 트래픽이 Server 노드에서 STA 노드로 전달되도록 하였다.

혼잡상황 발생시 라우터 버퍼에서의 패킷 손실을 구현하는 것이 목적이므로 디맨드 모델의 Taffic Mix는 "All Explicit"로 설정("Background Taffic의 영향(5) - Traffic Mix" 참조)하였다. 요즘 사용되는 대부분의 TCP 구현물들은 Fast Recovery를 사용하고 있으므로, Server 노드의 Fast Recovery 속성도 New Reno로 설정하였다.
ECN 기능을 사용하였을 경우와의 비교를 위하여, 먼저 ECN 기능을 사용하지 않았을 경우의 송신측(Server 노드) CWND 결과값과 Retransmission Count 결과값을 살펴보면 다음 그림과 같다. 라우터(R1 노드)에서 혼잡상황이 발생한 212초부터 재전송이 발생하고 CWND 값이 매우 작은 크기(주로 2,920 바이트)로 감소하는 겂을 볼 수 있다.

이제 ECN 기능을 사용하였을 경우의 송신측(Server 노드) CWND 결과값을 살펴보면 다음 그림과 같다. 혼잡 상황이 발생한 212초부터 CWND 값이 감소하기는 하였으나, 재전송은 발생하지 않았다(재전송이 발생하지 않으므로 Retransmission Count 결과 항목에 대한 그래프는 그려지지 않는다). 또 CWND 값도 ECN 기능을 사용하지 않아 재전송이 발생한 경우와 비교하면 매우 큰 수준(8,115 ~ 8,994바이트)이다.

"OPNET 중급입문"에서 설명하였듯이, Riverbed(OPNET) Modeler에서는 음성 코덱을 간편하게 모델링하여 시뮬레이션에서 사용하는 기능을 제공할 뿐만 아니라, 널리 사용되는 음성 코덱들을 이미 모델링하여 제공하므로 쉽게 사용할 수 있다.
G.711도 이렇게 기본적으로 모델링되어 있는 코덱중의 하나이므로, 손쉽게 사용할 수 있다. 그러면, G.711A는 어떻게 모델링할 수 있을까? G.711은 A-law와 u-Law의 두가진 압축 알고리즘을 사용하며[1], G.711 A-Law를 G.711A로, G.711 u-Law를 G.711U로 표기하기도 한다. 따라서, G.711과 G.711A/G.711U는 별개의 코덱이 아니며, G.711은 G.711A와 G.711U를 포괄하는 표현이다.
Riverbed(OPNET) Modeler 모델링 관점에서 G.711A와 G.711U는 아무런 차이가 없다. 즉, Riverbed(OPNET) Modeler에서의 음성코덱 모델링 요소인 Frame Size, Lookahead Size, DSP Processing Ratio, Coding Rate, Equipment Impairement Factor, Packet Loss Robustness Factor에 있어서 G.711A와 G.711U는 동일한 값을 가진다. Riverbed(OPNET) Modeler에서 기본적으로 제공하는 음성 코덱 모델에서 G.711A/G.711U대신 G.711이라는 이름을 사용한 것도 이러한 이유 때문인 것으로 생각된다.
그러므로, G.711A에 대한 모델링이 필요한 경우에도 Riverbed(OPNET) Modeler에서 기본적으로 제공되는 G.711 음성 코덱 정보를 사용하면 된다.

[1] ITU-T G.711, "Pulse code modulation (PCM) of voice frequencies," 1998.
[2] http://en.wikipedia.org/wiki/G.711

OSPF에서 라우팅 테이블 구성할 때 사용되는 Metric은 링크(정확하게는 인터페이스)의 비용(cost)이다[1]. CISCO사의 제품에서는 해당 링크의 대역폭 정보를 사용하여 cost를 계산하며[2, 3], Riverbed Modeler(OPNET)의 OSPF 모델 역시 이와 동일한 방법으로 cost를 계산한다.
다음 그림은 Riverbed Modeler(OPNET)에서 제공하는 인터페이스별 OSPF Cost 설정창을 보인 것이다. 1 ~ 65,535 범위의 정수값을 입력하거나 또는 Auto Calculate로 지정할 수 있다. Auto Calculate로 지정되면 해당 인터페이스에 연결된 링크 대역폭에 대한 Reference Bandwidth의 비율로 자동 계산된다.

다음 그림은 OSPF Cost가 Auto Calculate로 지정된 경우 링크 Cost 계산에 사용되는 Reference Bandwidth (bps) 설정창을 보인 것이다. 0 보다 큰 실수값을 입력하거나 10, 100, 1000 Mbps 중에서 선택할 수 있다.

[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/7039-1.html#t6
[3] http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/9237-9.html#q3

"WiMAX 모델(122) - 서브캐리어와 서브채널간 맵핑"에서 설명한 것처럼 CochannelT_zone_perm_data 구조체에는 cum_overlap_pointer_matrix 멤버와 cum_overlap_non_datra_array 멤버가 있어서, 섹터들간의 주파수 중첩 정보도 저장한다.
동일한 zone type을 상요하는 경우 중첩 발생이 가능한 경우의 수는 사용 중인 permutation base의 갯수의 제곱이며, 각각의 경우에 대한 서브채널별 서브캐리어 중첩정보가 "WiMAX 모델(120) - Subcarrier overlap matrix"에서 설명한 것처럼 계산되어 1차원 행렬 형태로 저장되어 있다.

이 때 주의할 점은 이후의 burst 단위의 중첩 서브캐리어 계산을 편하게 하기 위해서 cumulative overlap matrix 형태로 변환되어 저장된다는 점이다. 다음 그림은 "WiMAX 모델(120) - Subcarrier overlap matrix"에서 예로 들었던 정보를 이용하여 섹터-1의 subchannel 7 ~ 11과 섹터-2의 subchannel 5 ~ 7 사이의 cumulative overlap matrix로의 변환을 설명한 것이다. 왼쪽은 원래의 overlap matrix를 표현한 것이며, 오른쪽은 cumulative overlap matrix를 표현한 것이다. overlap matrix를 cumulative overlap matrix로 변환하는 공식은 (i, j) = (i, j) + (i, j-1) + (i-1, j) - (i-1, j-1)이다. 즉, 섹터-1의 subchannnel 7과 섹터-2의 subchannel 5에 대해서 계산한다면, 1 + 31 + 30 - 26 = 36이 된다.

이제 섹터-1에서 subchannel 7 ~ 11을 사용하는 Burst가 섹터-2의 subchannel 5 ~ 7을 사용하는 burst와 중첩된 경우에 대하여 중첩되는 서브캐리어의 총 수를 구해보면 다음 그림과 같다. 왼쪽은 원래의 overlap matrix를 사용한 경우이며, 오른쪽은 cumulative overlap matrix를 사용한 경우이다. 원래의 overlap matrix를 사용하면 14번의 덧셈이 필요하지만, cumulative overlap matrix를 사용하면 뺄셈 2번과 덧셈 1번만이 필요하므로 수행 속도가 빨라진다.

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 패킷에 담겨서 처리된다).