Feasibility Condition은 DUAL 알고리즘의 일부로써, 루프를 방지하기 위한 것이다. 그런데, 사용자가 주의를 기울이지 않으면 이 기능으로 인한 결과는 혼란스러운 면이 있으므로, 결과 해석시 주의가 필요하다.
"다중경로 라우팅(8) - UCMP 라우팅 테이블"에서 EIGRP는 동일한 비용을 가지는 경로가 없을 때에도 다음 그림처럼 다중경로로 라우팅 테이블을 구성해줄 수 있음을 확인한 바 있다.
그런데, "다중경로 라우팅(8) - UCMP 라우팅 테이블"의 예제망에서 R1 <-> R3 링크의 대역폭과 R3 <-> R4 링크의 대역폭을 서로 바꾸고 시뮬레이션을 수행하면, 다음 그림처럼 라우팅 테이블에 다중경로가 구성되지 않는 것을 볼 수 있다.
얼핏 생각하면, R1 노드에서 Server 노드로 향하는 경로의 전체 Metric 값에는 변화가 없으므로(R1 <-> R3 링크와 R3 <-> R4 링크의 대역폭을 서로 바꾸기만 하였으므로) 이전의 예제와 동일한 라우팅 테이블이 구성되어야 할 것처럼 생각된다. 하지만, 시뮬레이션 결과는 예상(?)과는 다르며, 이러한 차이가 발생한 원인은 Feasibility Condition 때문이다. 즉, EIGRP에서는 전체 경로의 Metric이 동일하더라도 Next-Hop 라우터에서 목적지까지의 경로 Metric 값이 어떻게 변화하는가에 따라 다중경로가 라우팅 테이블에 사용될 수도 있고 안될 수도 있다.
GRP에서 사용되는 쿼드런트의 기본 개념에 대해서는 "GRP 쿼드런트"에서 살펴본 바 있다. 이 쿼드런트는 또한 계층개념을 가지는데, 상위 계층 쿼드런트는 하위 계층 쿼드런트 4개로 구성된다. 따라서, 상위 계층 쿼드런트 한 변의 길이는 하위 계층 쿼드런트의 2배이다. 다음 그림은 이러한 쿼드런트의 계층 관계를 나타낸 것이다.
소스 노드(S)는 1번 노드의 위치를 Aa2 쿼드런트로 간주한다. 2번 노드의 위치는 한단계 상위인 Ab 쿼드런트로 간주하며, 3번 노드의 위치는 두단계 상위인 B 쿼드런트로 간주한다. 동일한 원리로 4번 노드의 위치는 D 쿼트런트로, 5번 노드와 6번 노드의 위치는 C 쿼드런트로 간주한다. 즉, 소스 노드에서 멀리 떨어진 노드일수록 더 상위 계층의 쿼드런트를 적용하며, 이 과정은 대상 노드의 쿼드런트가 결정될때까지 반복된다. 쿼드런트는 좌표계를 기준으로 결정되므로 시나리오상의 노드 배치를 보고 어느 노드가 어느 쿼드런트에 속할 것인지를 직관적으로 파악하기는 쉽지 않다("GRP 쿼드런트 예제" 참조). 더구나, 소스 노드에서 멀어질수록 더 큰 크기의 상위 계층 쿼드런트가 적용되므로, 어떤 노드들이 같은 쿼드런트에 속할 것인지를 직관적으로 파악하기는 더 어려워진다. 그 예로, 위 그림에서 4번 노드와 5번 노드는 서로 다른 쿼드런트로 간주되는 반면, 상대적으로 더 큰 거리를 가지는 5번 노드와 6번 노드는 같은 쿼드런트로 간주된다.
TDMA 모델에서 트래픽 전송이 어떻게 이루어지는지 예제망을 통해 살펴보기로 하자. 다음 그림은 4개의 노드로 이루어진 간단한 TDMA 예제망 구조를 보인 것이다.
TDMA 프로파일로는 Default를 사용하였으며, 이 때 사용할 수 있는 44개의 데이터 슬롯은 4개의 노드에 균등하게 11개씩 고정 할당("TDMA 자원할당 방식" 참조)하였다. Default TDMA 프로파일일 경우, 프레임("TDMA 프레임 구조" 참조) 길이는 100ms이고 슬롯당 데이터 전송량은 200Bytes이므로 11개의 슬롯을 할당받은 노드의 최대 전송량은 176Kbps(= 200 Bytes * 8 bits/byte * 11 slots/frame * 1 / 0.1 frames/sec)이다. 데이터 트래픽 발생을 위해서는 demand 트래픽 플로우가 STA_1 노드에서 STA_2 노드로, STA_3 노드에서 STA_4 노드로 향하도록 각각 배치하였다. STA_1 노드에서 STA_2 노드로 향하는 demand 트래픽의 양은 150Kbps로, STA_3 노드에서 STA_4 노드로 향하는 트래픽의 양은 200Kbps로 설정하였다. 노드의 최대 전송량이 176Kbps이므로 STA_1 노드에서 STA_2 노드로 향하는 트래픽은 모두 전달될 것이고, STA_3 노드에서 STA_4 노드로 향하는 트래픽은 모두 전달되지 못할 것이다. 시뮬레이션을 수행한 후, 각 노드에서 할당받은 프레임당 슬롯수를 살펴보면 다음 그림과 같다. 설정해준 것처럼 모든 노드가 매 프레임마다 11개의 슬롯을 할당받은 것을 알 수 있다.
STA_1 노드에서 STA_2 노드로 향한 트래픽의 송수신량을 살펴보면 다음 그림과 같다. STA_1 노드에서 발생한 트래픽이 STA_2 노드로 모두 전달되었음을 보여준다.
STA_3 노드에서 STA_4 노드로 향한 트래픽의 송수신량을 살펴보면 다음 그림과 같다. STA_3 노드에서 발생한 트래픽(200Kbps)이 모두 전달되지 못하고, 일부(176Kbps)만 STA_4 노드로 전달되었음을 보여준다.
어플리케이션 모델을 사용하여 트래픽 발생 시작 시간을 조정하는 방법은 "어플리케이션 사용 패턴(2) - Start Time 예제"에서 살펴보았다. 그러면, 트래픽을 원하는 시간 간격마다 반복해서 발생시키려면 어떻게 해야할까? 어플리케이션 트래픽을 반복 발생시키는 방법에는 어플리케이션 타이밍을 사용하는 방법과 프로파일 타이밍을 사용하는 방법이 있다. 여기에서는 어플리케이션 타이밍을 사용하는 방법을 살펴보기로 하자. 예제망 토폴로지는 "어플리케이션 사용 패턴(2) - Start Time 예제"에서 사용한 것을 그대로 사용였다.
"어플리케이션 사용 패턴(1) - 파라미터 설정"에서 살펴보았듯이, 어플리케이션의 실행시간은 Duration에 의해 지정되며, 실행간의 간격은 Inter-repetition Time에 의해 지정된다. 따라서, 이 두 값을 조정하면 하나의 어플리케이션이 프로파일내에서 일정 시간 간격으로 반복 실행되도록 만들수 있다. 어플리케이션 타이밍의 Duration은 200초, Inter-repetition Time은 300초로 설정하였을 때, Client로 노드로 전송되는 트래픽을 살펴보면 다음 그림과 같다.
200초 길이의 트래픽 발생 구간이 300초 간격을 두고 계속 반복되는 것을 확인할 수 있다. Duration은 100초, Inter-repetition Time은 400초로 설정하였을 때, Client로 노드로 전송되는 트래픽을 살펴보면 다음 그림과 같다.
100초 길이의 트래픽 발생 구간이 400초 간격을 두고 계속 반복되는 것을 확인할 수 있다.
Riverbed(OPNET) Modeler IP 모델에서 수신된 패킷을 상위 계층으로 전달하는 경우는 기본적으로 패킷의 목적지가 해당 노드일 때, 브로드캐스트 패킷일 때, 해당 노드가 속한 멀티캐스트 그룹의 패킷일 때이다. 다음 그림은 그 판단 절차를 논리적으로 표현한 것이다.
라우팅 프로토콜 모델들은 동작 시작 시점을 지정하는 "Start Time" 속성을 가지고 있으며, OSPF Mdoel 역시 해당 속성을 가지고 있다. 라우팅 프로토콜 모델들이 "Start Time" 속성을 제공하는 이유는 동일한 네트워크 토폴로지에서도 시작 시간에 따라 동작이 달라지거나, 라우팅 테이블 결과가 달라질 수 있기 때문이다.
사용자가 설정해준 "Start Time" 값은 ospf_v2 프로세스 모델로부터 ospf_process 프로세스 모델로 전달된다("OSPF 프로세스 모델 구조" 참조). ospf_process 프로세스 모델은 해당 시간이 지난 후에 Init 스테이트로부터 Idle 스테이트로 천이하므로，OSPF 프로토콜의 실질적인 동작은 "Start Time" 이후에 일어나게 되는 것이다.
AODV에서 사용하는 메시지로는 Route Request(RREQ), Route Reply(RREP), Route Error(RERR), Route Reply Acknowledgment(RREP-ACK), Hello가 있는데, Riverbed(OPNET) Modeler AODV 모델에 구현된 각 메시지 구조는 표준과 잘 일치함은 "AODV 메시지(2) - RREQ 구조체", "AODV 메시지(3) - RREP 구조체", "AODV 메시지(4) - RERR 구조체", "AODV 메시지(5) - RREP-ACK 구조체", "AODV 메시지(6) - Hello"에서 살펴보았다. 이번에는 이 AODV 메시지들의 크기와 하위 프로토콜 계층에서 실제로 사용되는 패킷 크기를 살펴보도록 하자. RREQ 메시지는 24Bytes, RREP 메시지는 20Bytes, RREP-ACK 메시지는 2Bytes 크기로 정의되어 있으며(IPv4일 경우) 고정적이다. RERR 메시지 크기는 에러가 발생한 목적지 수에 따라 달라지는데, 기본 크기 4Bytes에 에러가 발생한 목적지 수에 따라 8Bytes씩 증가한다. 따라서 RERR 메시지의 최소 크기는 12Bytes이다. AODV 메시지는 UDP를 사용하므로("AODV 메시지(1) - 패킷 포맷" 참조), 하위 계층으로 전달될 때 UDP 헤더 8Bytes, IP 헤더 20Bytes, MAC 오버헤드 28Bytes가 추가된다. 따라서 MAC 계층에서 사용되는 패킷 크기는 RREQ 80Bytes, RREP 76Bytes, RERR(최소) 68Bytes, RREP-ACK 58Bytes이다.
AODV 메시지가 WiFi 802.1b 11Mbps 인터페이스를 통해 전송되는 경우 Riverbed(OPNET) Modeler 파이프라인 스테이지에서 사용되는 패킷 크기는 RREQ 344Bytes(2,752bits), RREP 340Bytes(2,720bits), RERR(최소) 332Bytes(2,656bits), RREP-ACK 322Bytes(2,576bits)가 된다. (PLCP 오버헤드 계산에 대해서는 "WLAN PLCP 오버헤드 크기" 참조)
WiFi 인터페이스를 사용하는 노드들간의 기본적인 통신 가능거리에 대해서는 "WiFi 모델에서의 통신 가능 거리"에서, 확산이득과 Reception threshold의 영향에 대해서는 "WiFi 모델에서의 통신 가능 거리(2)"에서, delay의 영향에 대해서서는 "WiFi 모델에서의 통신 가능 거리(3)"에서 살펴본 바 있다. 이러한 기존의 분석에서는 BER 기준으로 10^-4을 사용하였다. 그러면, BER이 10^-4만 만족하면 항상 통신이 잘 이루어지는 것일까? 그렇지는 않다. BER 10^-4은 분석을 위해 필자가 임의로 정한 기준이었을 뿐이며 실제로는 각 시험 환경에 따라 달라질 수 있다. 이번에는 MAC 사용자 계층을 기준으로 99.9%의 패킷 전달률을 유지할 수 있는 최대 거리는 어디까지인지를 살펴보기로 하자. 802.11b 11Mbps 환경에서 237Bytes 크기의 MAC 사용자 패킷을 100Kbps로 전송하는 경우를 가정하였으며, 명기한 항목외에는 Riverbed(OPNET) WLAN 노드 모델의 기본 설정을 그대로 사용였다. 또한, 지형모델(TMM)을 적용하지 않았으며, 아무런 interference 신호도 존재하지 않을 경우로 한정하였다. Riverbed(OPNET) WiFi 모델에서 802.11b 11Mbps로 데이터 전송시 사용되는 모듈레이션 방식은 CCK11이며("WiFi MCS 레벨 (16.1 버전)" 및 "WiFi MCS 레벨 (17.5 PL6 버전)" 참조),Processing Gain은 0 이다("WiFi 변조 방식별 프로세싱 게인 (16.1 버전)" 및 "WiFi MCS 레벨 프로세싱 게인 (17.5 PL6 버전)" 참조). Riverbed(OPNET)에서 사용하는 CCK11 변조방식의 BER 커브는 다음 그림과 같다.
237Bytes의 MAC SDU 패킷을 전송할 때 송신 포트에서 내보내는 패킷의 크기는 237Bytes(MAC SDU 패킷) + 28Bytes(MAC 오버헤드) + 192usec * 11Mbps(PLCP 오버헤드) / 8 = 529Bytes(4,232bits)이다. (PLCP 오버헤드 계산에 대해서는 "WLAN PLCP 오버헤드 크기" 참조) MAC에서의 최대 전송 횟수는 기본값인 7이 적용된다. 이상의 정보로부터 BER별 MAC 사용자 패킷 전달률(Throughput)과 최대거리(distance)를 계산해보면 다음과 같이 예상할 수 있다.
- BER이 8.1x10^-5 일 때: MAC 사용자 패킷 전달률 99.98%, 이 때의 SNR은 7.25dB이므로 최대 거리는 약 1,024M. - BER이 2.5x10^-4 일 때: MAC 사용자 패킷 전달률 94.94%, 이 때의 SNR은 6.75dB이므로 최대 거리는 약 1,084M. - BER이 4.4x10^-4 일 때: MAC 사용자 패킷 전달률 69.31%, 이 때의 SNR은 6.5dB이므로 최대 거리는 약 1,116M. - BER이 2.1x10^-3 일 때: MAC 사용자 패킷 전달률 0.10%, 이 때의 SNR은 5.75dB이므로 최대 거리는 약 1,217M.
이제 시뮬레이션을 통해 이 예측을 확인해 보자. 2대의 WLAN 터미널 스테이션 노드를 배치하고, Physical Characteristics은 "Direct Sequence"로, Data Rate (bps)는 "11Mbps"로 설정한다. 트래픽은 237Bytes 크기의 패킷을 1초마다 발생시켜 다른 WLAN 터미널 스테이션 노드로 전송하도록 설정하였다. 1,024M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 예측(전달률 99.98%)과는 미세한 차이가 있는 결과(전달률 100%)이나, 오차범위 내로 볼 수 있다.
다음으로 1,084M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 예측(전달률 94.94%)과는 미세한 차이가 있는 결과(전달률 약 95.50%)이나, 오차범위 내로 볼 수 있다.
다음으로 1,116M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 예측(전달률 69.31%)과는 미세한 차이가 있는 결과(전달률 약 71.25%)이나, 오차범위 내로 볼 수 있다.
다음으로 1,217M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 예측(전달률 0.10%)과는 미세한 차이가 있는 결과(전달률 약 0.25%)이나, 오차범위 내로 볼 수 있다.
Riverbed(OPNET) Modeler TCP 모델에서는 사용자 편의를 위하여 TCP 버전 및 OS별로 속성값들이 조정된 TCP 프로파일("OS별 TCP 프로파일 (16.1 버전)" 참조)을 제공한다. 새로운 OS가 등장함에 따라 OS별 기본 프로파일의 추가가 이루어져왔으며("OPNET Modeler 17.1 PL1 발표" 참조), 17.5 버전("OPNET Modeler 17.5 PL6 발표" 참조)에서 제공되는 TCP 프로파일은 Windows 7, Andriod, FreeBSD 8.2, HP-UX 10.x/11.x, iPad, iPhone, Linux 2.6, Mac OS X, NT (3.5/4.0), Solaris 2.6, Solaris 2.7, Solaris 2.8, Solaris 2.9, Windows 98, Windows 2000, Windows Server 2003, Windows Server 2008, Windows Vista, Windows XP, Tahoe, Reno, New Reno, SACK, Full-Featured, Default 이다. 16.1 버전후에 새롭게 추가된 프로파일 중 자주 사용되는 프로파일의 세부 속성항목들의 값을 살펴보면 다음 표와 같다.
