네트워크 시뮬레이션 공방

AODV에서는 이웃을 찾아내고 이웃과의 관계를 유지하기 위해서 Route Request(RREQ), Route Reply(RREP), Route Error(RERR), Route Reply Acknowledgment(RREP-ACK), Hello 메시지를 사용한다. 다음 그림은 Riverbed(OPNET) Modeler AODV 모델에서 사용하는 패킷 포맷과 Options 필드에 실리는 정보를 나타낸 것이다.

그림에서 알수 있듯이, 각 메시지 별로 다른 패킷을 사용하지 않고 하나의 공통 AODV 패킷 포맷을 사용한다. 대신 각 메시시별로 Options 필드에 실리는 구조체의 내용을 달리하여 서로 다른 메시지 정보를 수용한다.
AODV 패킷 포맷임에도 UDP 헤더 필드가 포함되어 있는 것은 "AODV 프로토콜 계층 구조"에서 설명하였듯이 AODV 메시지가 UDP를 사용함[1]에도 불구하고, AODV 프로세스 모델이 UDP 모듈 상위가 아닌 IP 모듈에 직접 구현되어 있기 때문이다.

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

다음 그림은 Riverbed(OPNET) Modeler에서 AODV 프로토콜이 동작하는 WLAN 노드 모델의 구조를 보인 것이다. 그런데, 해당 라우팅 프로토콜에 대한 프로세서 모듈이 바로 식별되는 RIP나 OSPF와는 달리, AODV는 프로세서 모듈이 직접 보이지 않는다.

그럼 AODV 프로세스는 어디에 위치하는 것일까? 일반적으로는 UDP를 사용하는 AODV의 특성[1]을 고려하면 UDP 계층위의 manet_rte_mgr 프로세서 모듈에 위치할 것 같지만, 실제로는 다음 그림처럼 ip 프로세서 모듈 내부에 차일드 프로세스 형태로 존재한다.

이러한 프로토콜 계층 구성은 사용자들에게 혼란을 주는 AODV 모델의 문제점이다. 사실 Riverbed(OPNET) Modeler에서는 계층 개념을 정확히 준수하지 않고도 충분히 표준에 맞는 프로토콜을 구현할 수 있다. 하지만, 대부분의 프로토콜은 계층 구조를 준수하여 구현되어 있으며, 계층 구조에 맞지 않은 위치에 구현되어 있는 경우는 AODV 모델외에는 아직 보지 못했다.

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

"RIP 라우팅 예제"나 "OSPF 라우팅 예제"에서 사용한 예제망과 유사한 토폴로지의 네트워크를 사용하여 AODV의 동작을 확인해보기로 하자. 예제망의 네트워크 토폴로지와 실제로 할당된 IP주소 내역은 다음과 같다.

STA_3 노드의 최초 위치는 STA_2, STA_5 노드와 모두 통신이 가능한 거리이며, STA_4 노드의 최초 위치는 STA_2 노드와만 통신이 가능하고 STA_5 노드와는 통신할 수 없는 거리이다. 시간이 지남에 따라 STA_3 노드와 STA_4 노드는 이동하여 STA_3 노드는 STA_2 노드와는 통신할 수 없는 거리에, STA_4 노드는 STA_2, STA_5 노드와 모두 통신이 가능한 거리에 도달한다. 
시뮬레이션을 수행한 후, STA_2 노드에서 초기에 구성된 라우팅 테이블을 살펴보면 다음 그림과 같다.

STA_1, STA_3, STA_6 노드에 대한 라우팅 정보가 생성되었으며, STA_6 노드로의 전달을 위한 다음 홉은 STA_3 노드로 지정되어 있음을 확인할 수 있다. 또한, STA_1, STA_3 노드에 대한 홉 카운트는 1, STA_6 노드에 대한 홉 카운트는 3임을 알 수 있다. ("AODV 홉 카운트"에서 설명하였듯이, AODV는 홉 카운트를 라우팅 기준으로  사용한다.)
STA_1 노드로부터 STA_6 노드로의 디맨드 트래픽 전달 경로는 다음과 같이 STA_3 노드를 거쳐가는 경로로 확인되며, 이는 라우팅 테이블 정보와 일치한다.

STA_3 노드와 STA_4 노드의 이동에 따라 변경된 STA_2 라우팅 테이블을 살펴보면 다음 그림과 같다.

STA_3 노드에 대한 라우팅 정보가 없어지고 STA_4 노드에 대한 라우팅 정보가 생성되었으며, STA_6 노드로의 전달을 위한 다음 홉은 STA_4 노드로 변경되었음음 확인할 수 있다.
STA_1 노드로부터 STA_6 노드로의 디맨드 트래픽 전달 경로는 다음과 같이 STA_4 노드를 거쳐가는 경로로 확인되며, 이 역시 라우팅 테이블 정보와 일치한다.

AODV에서 라우팅 테이블을 구성할 때에는 홉 카운트(Hop count)를 기준으로 사용한다[1]. 즉, RIP나 OSPF의 cost("RIP에서의 네트워크 비용" 및 "OSPF에서의 링크 비용" 참조)에 해당하는 요소가 AODV에서는 홉인 것이다.
RIP에서도 cost를 1로 설정하면 홉 카운트와 동일한 의미가 된다(대부분 이렇게 사용한다)는 점에서는 RIP와 유사한 측면이 있다. 하지만, RIP에서와는 달리 AODV에서 사용하는 홉 값은 사용자가 변경할 수 없는 값이므로, 완전히 동일하지는 않다.  
Riverbed(OPNET) Modeler AODV 모델에서도 홉 정보는 내부적으로만 관리되며, 사용자가 변경할 수 없게 되었다.

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