Mobile IP(Internet Protocol)의 연구개발 동향

멀티미디어 서비스의 욕구가 증대됨에 따라 ATM을 근간으로 하는 고속망이 WAN(Wide Area Network)에서 뿐만 아니라 학교 망이나 연구소 망과 같은 LAN(Local Area Network)에서도 급속도로 확대되고 있다. 그러나 이러한 망의 변화에도 불구하고 서비스는 인터넷 서비스가 여전히 가장 널리 이용되고 있다. 따라서 ATM과 같은 초고속 통신망에서도 IP(Internet Protocol)를 수용할 수 있는 방안이 IETF(Internet Engineering Task Force)와 ATM Forum을 중심으로 제안되고 표준화가 이루어지고 있다^{[1, 2]}. 또한 이동통신의 폭발적인 발전에 따라 향후의 망은 유선과 무선이 연동내지는 통합된 형태로 운용될 것이다. 이러한 유무선 통합망에서 IP 서비스를 제공하기 위해서는 이동성을 제공할 수 있어야 하겠다. 인터넷 망에서 이동성을 제공하기 위한 연구로는 IETF의 Mobile IP^[3]가 있으며 ATM 망에서 이동성을 제공하기 위한 연구로는 ATM Forum^[4]과 ETSI BRAN (Broadband Radio Access Network)^[5]으로 이원화 되어 진행되고 있는 무선 ATM이 있다. ATM을 기반으로 한 유무선 통합망에서의 인터넷 서비스를 제공하기 위한 방안에 대한 연구는 거의 없는 실정이다. 따라서 유무선 통합망에서의 이동 인터넷 서비스에 대한 연구가 선행되어야 할 것이다.

WATM WG(Wireless ATM Working Group)에서는 기존의 유선 구간에만 적용되었던 ATM 기술을 무선 구간까지 확장한 개념인 무선 ATM을 '98년 말까지 표준화의 완료를 목표로 연구가 진행되고 있는 반면^[4] IETF에서는 이동 노드에 라우팅 프로토콜을 통합함으로써 이동 무선 네트워크에 대한 효율적인 운영을 제공하며 이동성을 무선 영역으로 확대하는 것을 목표로 표준화가 진행되고 있다^{[6, 7]}.

본 논문에서는 기존의 IP를 확장 시켜 인터넷 상에서 이동 컴퓨터에게 유일한 주소의 제공과 어느 위치에서라도 이동 컴퓨터의 데이터를 효과적으로 전달하고 받을 수 있도록 하기 위해 IETF에서 제안된 Mobile IP에 대한 기술적 분석과 외국의 구현 사례들을 분석하였다.

현재 인터넷 대부분의 환경에서 사용되는 IP version 4는 IP 주소를 이용하여 어떤 노드 (node: host or router)의 접속 점을 유일하게 식별할 수 있다고 가정한다. 그러므로, 어떤 한 노드가 자신에게 전달되는 데이터그램을 받기 위해서는 그 노드의 IP 주소를 포함하는 네트워크 내에 위치해야만 한다. 만약 그 위치가 바뀐다면 데이터그램은 전송되어질 수 없다.

어떤 노드가 통신을 유지한 채로 그 접속 점을 바꿀 수 있게 하기 위해서는 두 가지 메커니즘 중 하나가 채택되어야 한다.

○ 접속 점이 바뀔 때 마다 노드는 자신의 IP 주소를 바꾸어야 한다.

○ 이동한 호스트의 주소가 인터넷 전체에 전달되어야 한다.

그러나 위와 같은 두 가지 방법 모두가 문제를 가진다. 첫째는, 노드의 위치가 변하였을 때 노드가 전송계층과 그 상위계층의 연결을 유지하는 것을 어렵게 만든다. 두번째는, 향후 이동 노드의 수가 증가한다고 가정하였을 때 수용하기 어려운 방안이라 할 수 있다. 따라서, 인터넷에서 노드의 이동성을 지원하기 위해서는 좀 더 확장적인 기술이 요구되며, 이런 이동성을 지원하기 위해 현재 IETF에서 추진되고 있는 표준화 방안이 Mobile IP이다.

(그림 1)에서 홈 에이전트(HA: Home Agent)와 외부 에이전트(FA: Foreign Agent)는 이동 노드(mobile node)에 데이터그램을 전달해 주기 위한 노드이다^[8]. 이동 노드가 correspondent node와 통신 중에 홈 네트워크에서 외부 네트워크로 이동하였을 경우, 이를 지원하기 위한 절차를 필요로 하게 된다. Mobile IP의 구성요소는 아래와 같이 3가지 정도로 구분할 수 있다^[3].

홈 에이전트나 외부 에이전트를 의미하는 이동성 에이전트(mobility agent)는 기존의 인터넷에서 인터넷 호스트가 라우터를 발견하고자 할 때 사용한 방법(ICMP(Internet Control Message Protocol) router discovery^[9])과 유사한 방법인 에이전트 광고 메시지를 통해 자신의 존재를 알린다. 선택적으로 이동 노드가 에이전트 획득 메시지를 이용하여 에이전트 광고 메시지를 얻을 수 있다. 이동 노드가 이러한 에이전트 광고 메시지를 받고 자신이 홈 네트워크에 있는지를 판단한다.

에이전트 발견 절차에 의해 이동 노드가 외부 네트워크에 있다고 판단되었을 때 이동 노드와 홈 에이전트는 등록 요청과 등록 응답 메시지를 교환함으로써 이동 노드의 COA(Care-of Address)를 홈 에이전트에 등록한다. COA에는 외부 에이전트를 이동 노드의 COA로 사용하는 외부 에이전트 COA와, DHCP(Dynamic Host Configuration Protocol^[10])에 의해 임시 IP 주소를 이동 노드에 할당하는 Co-located COA 등의 두 가지 방법이 사용될 수 있다. 이들 등록 메시지들은 UDP(User Datagram Protocol) 포트 434번을 사용하며, 이동 노드의 COA와 lifetime등을 포함하고 있다.

홈 에이전트와 이동 노드 사이에 등록이 성공적으로 수행되게 되면, 외부에서 이동 노드의 홈 주소로 보내지는 데이터그램은 홈 에이전트에 의해 이동 노드의 COA로 터널링 된다. 터널링은 여러 가지 encapsulation 알고리즘 중에 하나를 사용할 수 있으며, 기본적으로 터널링 알고리즘은 IP-within-IP encapsulation^[11]을 지원해야 한다. 만약, COA가 외부 에이전트로 지정되어 있는 경우에는 외부 에이전트가 decapsulation을 하게 되며, Co-located COA를 사용하는 경우 이동 호스트 자신이 decapsulation하게 된다. 이동 노드에서 외부의 노드로 보내지는 데이터그램은 홈 에이전트를 거쳐갈 필요 없이 표준 IP 라우팅 방법을 사용하여 목적지까지 전달된다.

위에서 언급하였듯이, 만약 이동 호스트가 자신의 홈 네트워크 내에 존재하지 않는 경우에 이동 호스트로 보내져야 할 데이터그램은 일단 홈 에이전트로 전달되어 다시 이동 노드로 터널링된다. 반면에, 이동 호스트가 인터넷의 다른 노드에게 데이터그램을 전달하고자 할 때에는 표준 IP 라우팅 방법에 의해 바로 전달이 가능하다(그림 2). 이러한 비대칭 라우팅을 triangle 라우팅이라 한다. 이 triangle 라우팅 문제는 상당한 네트워크의 비효율성을 초래한다. 특히, 연관 노드(correspondent node)가 이동 호스트와 가까운 위치에 존재할 경우에는 더욱 비효율성이 가중된다.

경로 최적화 방법^{[12, 13]}은 상대 노드가 바인딩의 캐쉬(cache)를 관리하게 하여, 이동 노드의 홈 에이전트로 보내야 할 데이터그램을 자신이 직접 터널링하여 이동 노드의 현재 위치로 보내도록 한다(그림 3). 또한 이 방법은 이동 노드가 이동했을 때 이미 이전의 외부 에이전트로 터널링되어 보내진 데이터그램과, 낡은 캐시 바인딩에 의해 보내진 데이터그램을 현재 위치한 곳으로 포워딩(forwarding)하는 방법을 제공한다.

현재 IETF를 중심으로 Mobile IP의 표준화가 수행되고 있으나, 각 대학과 벤더들이 구현하여 발표한 사례들을 중심으로 살펴보겠다.

Binghamton대학에서의 구현^[14]은 리눅스(Linux) 상에서 수행되었으며, IETF에서 제안한 규격의 완성을 위해 리눅스의 기존의 인터페이스를 활용하여 사용자 레벨 코드만으로 구성하였다. 이 구현에서는 유선과 무선 환경을 모두 고려하였으며 무선 환경에서의 이동 감지 방법으로 Lazy cell switching방법^[12]을 사용하였다.

Lazy cell switching방식은 이동 노드가 에이전트 광고의 lifetime필드를 참조하여 이 값으로 타이머를 설정한 후 이 타이머가 종료될 때까지 이 에이전트 광고를 다시 수신하지 못하면 외부 네트워크로 다시 이동한 것으로 간주하는 방법이다. 이동 노드는 보통 3개 정도의 다른 에이전트 광고를 저장하며 이에 대한 각 타이머를 동작시키게 되는데 처음 등록한 에이전트 광고의 타이머가 종료하여 이동으로 간주되면 나머지 타이머가 종료되지 않은 에이전트에 등록 요구를 행한다. 만약 타이머가 종료되지 않은 에이전트가 없을 시는 에이전트 요청(agent solicitation)에 의해 등록 설정 절차를 재시작하게 된다.

사용자 레벨 코드는 에이전트인 back-ground daemon과 MH(Mobile Host)의 이동 노드 프로그램의 두 부분으로 나뉘어 지며, 에이전트와 MH 간의 등록 절차, 그리고 MH의 이동 시 라우팅 테이블의 변경 등의 기능을 수행한다. 등록절차 패킷의 교환은 UDP socket을 사용하여 수행하고, 라우팅 테이블의 변경은 ioctl( ) 시스템 호출을 사용하여 수행하게 된다.

홈 에이전트가 이동 노드의 목적지인 패킷을 수신하는 방법은 다음과 같다. 홈 에이전트는 게이트웨이 또는 일반 호스트일 수 있다. 홈 에이전트가 게이트웨이인 경우 외부 네트워크에서 들어오는 이동 노드가 목적지인 패킷은 수신할 수 있으나, 서브넷 내의 이동 노드에 대한 물리 주소를 ARP(Address Resolution Protocol) 캐쉬 테이블에 가진 노드들과 이동 노드간의 통신은 잠시 중단이 일어나므로 이런 노드들의 ARP 캐쉬 테이블을 갱신하기 위해 홈 에이전트와 이동 노드간의 등록 절차가 완료된 후 gratuitous ARP를 사용하여 이동 노드에 대한 물리 주소를 갱신한다.

홈 에이전트가 일반 호스트인 경우도 위에서 언급한 수정되지 않은 ARP 캐쉬 테이블 문제가 있으므로 gratuitous ARP를 사용하며, 또한 게이트웨이와 같이 이동 노드가 목적지인 패킷을 직접 수신할 수 없으므로 Proxy ARP를 사용하여 이동 노드에 대한 ARP request에 대신 응답하여 수신하는 방법을 취한다.

이 Mobile IP의 구현에서 기술적으로 약간 다른 부분은 encapsulation방법과 라우팅 테이블의 변경에도 TCP의 연결을 유지하기 위한 인터페이스의 설정 방법이다.

리눅스에서는 encapsulation을 위해 터널 인터페이스가 제공된다. 터널 인터페이스는 소프트웨어 인터페이스로 라우팅을 수행하는 노드가 전달받은 데이터그램에 새 IP 헤더를 붙여 라우팅 테이블에 적혀진 목적지 경로로 패킷을 전송하는 인터페이스이다. 이 구현에서는 홈 에이전트가 이동 노드의 패킷을 수신할 때 라우팅 테이블의 설정에 따라 자동으로 터널의 목적지 (외부 에이전트)로 encapsulation 패킷을 전송한다.

패킷의 decapsulation을 수행하는 노드는 외부 에이전트 또는 이동 노드일 수 있다. Decapsulation역시 리눅스에서 'self-decapsulation mode'가 지원이 되므로 FA또는 MH는 이 모드로 동작하게 된다. 다만 이동 노드가 DHCP 등을 이용하여 하나 이상의 IP 주소를 획득할 경우 하나의 네트워크 인터페이스에 IP 주소를 두 개를 가질 수 없으므로 다른 방법이 모색되어야 한다(BSD 또는 현재의 리눅스 version에서는 IP aliasing을 지원하여 하나의 인터페이스가 여러 개의 IP 주소를 가질 수 있으나, 구현 당시 여러 개의 IP 주소를 설정하는 방법은 더미 인터페이스에 지원됨).

기존의 통신은 홈 네트워크에서의 IP 주소를 계속 사용하여야 TCP의 연결이 끊기는 문제를 방지할 수 있으며 패킷의 수신은 목적지 주소가 외부 네트워크 주소인 패킷을 수신해야 하므로 두 개의 IP 주소가 모두 설정되어야 한다. 이를 해결하기 위해 리눅스의 더미 인터페이스를 사용하여 다수의 IP 주소를 하나의 네트워크 디바이스에 설정하는 방법을 취하였으며, 홈 네트워크에서의 IP 주소는 원래 설정되어 있던 이더넷 인터페이스에 고정적으로 설정한 뒤 새로 할당 받은 IP 주소는 더미 인터페이스에 할당한다.

◎ 홈 네트워크에서의 동작 절차

홈 네트워크에서 홈 에이전트의 동작 절차는 다음과 같은 라우팅 테이블 <표 1>로 표현하는 것이 가장 쉽게 나타낼 수 있다. 아래의 라우팅 테이블의 변경은 에이전트의 ioctl( ) 시스템 호출에 의해 이뤄진 것으로 세부적인 코드는 생략하고 동작 절차를 간단히 기술하겠다.

홈 에이전트는 등록요구 절차가 끝나면 그 이동 노드의 패킷을 수신하여 encapsulation을 통해 외부 에이전트 또는 이동 노드에게 전달하여야 한다. 이것은 간단히 터널 인터페이스 하나를 추가함으로써 수행될 수 있다. (그림 4)에서 목적지가 128.226.3.30인 패킷은 MH가 목적지인 패킷이므로 이것은 터널을 통해 128.226.3.28의 주소를 가진 자신의 이더넷 인터페이스를 통해 전송하게 된다. 터널 설정 시 자동으로 목적지가 설정되므로 수신한 MH의 패킷은 상위 계층까지 전달되지 않고, 네트워크 계층에서 새 IP 헤더가 붙여져서 전송된다.

◎ 외부 에이전트에 의한 동작 절차

<표 2>는 외부 네트워크에서 외부 에이전트가 decapsulation을 행할 경우 각 라우팅 테이블을 나타낸 것이다. 외부 에이전트는 self decapsulation mode로 수행되므로 encapsulation 되었던 패킷은 일단 decapsulate되어지고, <표 2>의 라우팅 테이블의 첫째줄에 따라 이 패킷은 네트워크 내부에 연결된 이더넷 인터페이스에 의해 전송되게 된다. MH의 라우팅 테이블은 기본 게이트웨이가 FA로 바뀌었음을 알 수 있다.

◎ 이동 노드에 의한 동작 절차

<표 3>은 이동 노드가 decapsulation을 행할 경우 각 라우팅 테이블을 나타낸 것이다. FA가 만약 라우터로써의 역할만 할 경우 FA의 라우팅 테이블은 <표 3>과 같이 기본적인 두 항목만을 가진다고 하자. 아래의 라우팅 테이블은 전송시 참조하는 테이블이다. 따라서, MH에서 전송시는 게이트웨이 라우터에게 패킷을 전송하고, 수신시는 Proxy ARP에 의해 encapsulation되어진 임시 주소의 패킷을 수신하게 된다. 이를 self decapsulation하여 홈 네트워크 주소를 가진 응용 프로그램은 동작하게 된다.

CMU대학에서의 구현^[5]은 BSD (NetBSD 1.1 또는 FreeBSD 2.2) 커널 (kernel) 환경하에서 수행되었으며, 리눅스에서의 구현과 달리 여러 인터페이스들이 커널 레벨에서 제공되지 않으므로 커널 코드와 사용자 레벨 코드의 두 가지 부분이 나뉘어져 있다. 그 세부적인 기능을 나뉘어 보면 아래와 같다.

◎ 커널 코드: Encapsulation, decapsulation, forwarding 등의 기능은 커널 코드로 구현.

이 구현에서도 유선과 무선 환경을 모두 고려하였으며 무선 환경에서의 이동 감지 방법으로 Lazy cell switching 방법을 사용하였다.

BSD커널에서의 구현은 라우팅 테이블을 변경시키는 방법에서 약간 특이한 부분이 있다. BSD socket에서는 라우팅 테이블을 변경시키기 위한 방법이 제공되는데, 이것이 routing socket이다. 기존의 socket 함수와 같은 형식을 사용하여 수행되며, root의 권한으로만 수행 가능하다.

외부 에이전트를 사용한 방법과 외부 에이전트가 없는 네트워크에서 지원하는 두 가지 방법 모두 고려되었으며, 멀티플 인터페이스의 지원에 중점을 두고 있다. 또한 다수 개의 디바이스를 지원하기 위한 방안에 좀 더 역점을 두고 있으며, 현재까지의 진행은 다음과 같다.

◎ DHCP 사용(Co-located COA)

미리 co-located 주소에 관한 인터페이스를 설정하여 다수 개의 디바이스에 관한 네트워크 설정이 미리 이뤄지면 동작한다.

◎ 외부 에이전트 사용(COA 사용)

외부 에이전트를 통하여 등록하면, 존재하는 네트워크 연결은 계속되나, 새로운 COA를 할당 받은 인터페이스는 제대로 동작하지 않는다. 이 구현에서는 언급한 내용들을 제외하고는 리눅스 구현과 유사하다고 할 수 있다.

Singapore대학의 구현은 IETF의 규격에 기반하여 리눅스를 기본 환경으로 구현하였으며^[16], 다른 구현들과 유사하다. 이동 노드는 Windows 95환경에서도 구현을 하였는데 이식성 밖에 지원을 하지 못하는 한계성을 가진다.

Windows 3.1, 95, CE등의 IP 스택은 정적 라우팅 밖에 지원을 하지 못하므로 리눅스에서의 구현과 같이 라우팅 테이블을 변경시키는 방법을 수행할 수 없다. 따라서, 부팅 과정 시 수행되어야 하며, 재부팅 과정에 라우팅 테이블을 자동으로 재 설정하는 프로토콜 구성요소를 Windows 95의 프로토콜 스택에 추가하여 이식성만을 지원한다.

다음과 같은 두 가지의 제안에 중점을 두고 구현하였다.

◎ 상호 운영성 테스트를 위한 터널 설정 프로토콜의 제안.

◎ Localizing registration을 위한 클라이언트-서버 모델 도입.

현재 각 구현들에서의 에이전트와 이동 노드들은 상호운영성에 관한 테스트를 거쳐야 하는데, 실제로 멀리 떨어진 원거리의 에이전트들간에 이동 노드의 이동을 테스트하기 위해서는 시뮬레이션이 유일한 방법이라 할 수 있다. 이를 위해 터널 설정 프로토콜을 제안하였는데 이 프로토콜의 절차는 아래와 같다.

① 터널 설정 프로토콜

이 프로토콜의 목적은 실제로는 홈 에이전트와 먼 거리에 떨어진 이동 노드가 홈 네트워크에 있는 것처럼 인식하도록 해주며, 또한 먼 거리에 떨어진 외부 네트워크로 이동하였을 때에도 역시 직접 이동한 것처럼 인식하도록 해준다. 터널을 설정하기 위해 클라이언트와 서버 모델을 도입하였고, 클라이언트와 서버는 터널을 설정하여 주는 역할을 한다.

서버의 역할은 이동 노드의 역할을 대신한다. (그림 5)에서 이동 노드가 홈 네트워크에서 외부 네트워크로 이동하였을 때 서버는 이 이동을 에이전트에게 인식되도록 한다. 실제적으로 (그림 5)와 같이 이동 노드는 두 네트워크에 터널을 동시에 설정해 놓은 상태이며, 따라서 두 에이전트의 광고를 동시에 수신하게 된다. 이동 노드는 이동을 수행하기 위해 에이전트 광고를 선택하여 임의로 이동한 것처럼 행동한다. 이 때 proxy update메시지를 보냄으로써 이동을 에이전트에게 알리게 된다. 그러므로, registration request는 proxy update이후에 이뤄져야 한다.

Mobile IP 프로그램에 추가하여야 되는 부분은 proxy update에 대한 부분이다. 이동 노드와 에이전트는 Proxy Update 패킷을 수신하고 나서야 registration request를 수행하도록 고쳐져 있고, 그 외의 클라이언트, 서버의 터널 설정부분은 Mobile IP와는 별개로 수행된다.

에이전트는 물리적 한계성 때문에 하나의 서브넷에 하나씩 상주해야 홈 네트워크의 모든 노드를 서비스할 수 있다. 이런 구조로 인하여 이동 노드가 하나의 외부 네트워크로 자주 이동할 때 잦은 등록 요구에 대한 오버헤드를 줄이기 위해 외부 네트워크내에서 하나의 외부 에이전트가 이 요구를 홈 네트워크에 전송하지 않고 패킷의 전송을 담당하는 것이 localizing registration이라 할 수 있다.

이 구현에서는 이런 모든 기능을 가진 외부 에이전트가 모든 서브넷에 하나씩 존재하는 것 보다는 registration과 binding 기능과 패킷 전송 기능을 분리하여 (그림 6)과 같이 registration과 binding 기능은 외부 에이전트에서만 수행하고, 패킷의 전송과 이동 감지는 클라이언트와 서버가 담당하도록 한다.

Stanford 대학의 구현^[17] 특징은 IP의 route lookup 함수를 수정하여 기존의 라우팅 테이블과 Mobile Policy Table의 참조에 의한 경로 설정의 유연성을 첫째로 들 수 있고, 두번째는 VIF(Virtual InterFace)에 의한 encapsulation 기능, 서로 다른 네트워크와 통신 디바이스의 스위칭에서 연결을 유지하기 위한 기능 등을 들 수 있다.

Route lookup 함수에서는 근원지 IP를 검사하여 이것이 이동 서비스가 필요한 것인지 또는 Mobile IP의 요구 없이 임시 주소로 사용 가능한 것인지 검사하는 역할을 수행하며 만약 이동 서비스가 필요한 것이라면 다음과 같은 절차를 거치게 된다.

기존의 리눅스의 구현들에서는 라우팅 테이블의 변경만을 수행하였으나, 이 구현에서는 라우팅 테이블 외에 Mobile Policy Table이란 특정 테이블을 생성하여 참조하게 된다. 이 테이블이 갖는 정보는 목적지 주소에 따른 경로 설정에 관한 정보를 가지고 있는데 이 경로설정에 관한 정보는 방화벽, 또는 경계-라우터 등에 관한 고려사항으로 좀 더 빠른 triangular routing을 수행할 것인지 아니면 encapsulation시켜 홈 에이전트에 전송 패킷을 전달하는 안전한 전송을 수행할 것인지 등을 판단하는데 쓰인다.

아래 (그림 7)과 같은 환경에서 예를 들어 보자. 현재 TCP계층에서 전송한 패킷은 route lookup 함수를 거치게 된다. 이것이 근원지 주소가 임시 주소로 설정된 Mobile-aware 또는 이동 서비스가 필요 없는 패킷이라면 이것은 라우팅 테이블만을 참조하여 strip 인터페이스 등으로 전송되어 질 수 있다. 만약 근원지 주소가 홈 주소로 설정된 연결 상태에 있던 통신이라면 이것은 Mobile Policy Table을 참조하여 encapsulation되어서 전송되던가 아니면 직접 이더넷 인터페이스로 전송할 수 있다. 이때 encapsulation은 VIF에서 수행된다.

또한 VIF는 다음과 같은 상황의 지원을 위해서도 이용될 수 있다. 만약 외부 네트워크로 이동하였을 때 기존의 이더넷이 사용 불가능 해지고, strip가 사용 가능하여졌을 경우 TCP 연결의 끊김을 방지하기 위해 VIF가 redirection하는 역할을 수행할 수도 있다.

Mobile IP 연구 및 구현에서는 현재 인터넷 프로토콜과의 적응성이 가장 크게 대두된 가운데 표준화가 진행되고 있다. 현재는 IP version 4에 기초하여 기본적 고려 사항들만 표준화가 이뤄진 상태이며, 각 연구 기관들에 의하여 특수한 구현들이 시험되고 있다.

현재 주로 논의되고 있는 부분은 경로 최적화, 투명성 제공, 잦은 등록 요구에 따른 최적화 기법, TCP의 연결 유지 방안, 그리고 방화벽 등의 보안 시스템과의 연동 등이다.

경로 최적화는 초기에도 논의가 계속되었던 부분으로 에이전트에 의한 패킷 전달에 수반되는 비 효율적인 경로를 줄이는 것이 목표이나, 현재 IP version 4에서는 적절한 대응책이 보이지 않으며, 향 후 차세대 IP에서나 기대해 볼만한 것으로 보인다. 투명성 제공이란 Mobile IP프로토콜의 구성요소를 최소화하여 기존의 프로토콜에 최대한 변화를 주지 않으면서 Mobile IP로 옮기기 위한 방안이다. 이것은 차세대 IP를 고려하였을 경우 이동 노드에 탑재될 것으로 가장 유력해 보인다. 등록 요구의 최적화는 각 서브넷 간의 이동 시 등록 요구의 횟수를 줄이는 것으로 대체로 localizing registration에 관한 일반적 방법이 쓰일 것이며, 방화벽과의 연동은 장기적인 대책으로 방화벽과 이동 노드간의 협상 프로토콜이 자리 잡을 것으로 예상된다. 이외에 실제적인 구현에서의 문제인 TCP 연결의 유지 방안 등은 여러 구현들에서 문제가 되었으나, 다중 인터페이스의 구현에 의한 여러 가지 해결 방안이 나오고 있으며, 이외에 TCP에서의 이동성 지원에 관한 효율적 고려 사항 등 다른 계층에서의 지원 방안들도 적극 검토되고 있는 중이다.

<참 고 문 헌>

1. E. C. Rosen, A. Viswanathan, and R. Callon, “Multiprotocol label switching architecture,” draft-ietf-mpls-arch-02.txt, July 1998.
2. W. Y. Lee, Y. J. Kim, and Y. S. Mun, “IP mobility support over WATM,” ATM Forum afm98-0296, Apr. 1998.
3. C. E. Perkins, editor, "IP mobility support version 2," draft-ietf-mobileip-v2-00.txt, Nov. 1997.
4. ATM Forum Technical Committee, Baseline Text for MPOA, BTD-MPOA-1_1.01, Oct. 1998.
5. ETSI BRAN, Broadband Radio Access Networks (BRAN); HIgh PErformance Radio Local Area Network (HIPERLAN) Type 2; requirements and architectures for wireless broadband access and interconnection, DTR/BRAN-010002 v0.1.3, Sept. 1998.
6. C. E. Perkins, "Mobile Ad Hoc networking terminology," draft-ietf-manet-term-00.txt, Oct. 1997.
7. S. Corson and J. Macker, “Mobile Ad Hoc networking (MANET): Routing protocol performance issues and evaluation consideration,” draft-ietf-manet-issues-01.txt, Mar. 1998.
8. C. E. Perkins and P. Bhagwat, "Highly dynamic destination-sequenced distance-vector routing (DSDV) for mobile computers," ACM SIGCOMM, vol. 24, pp. 234-244, Oct. 1994.
9. S. E. Deering, “ICMP router discovery messages,” RFC 1256, Sept. 1991.
10. R. Droms, “Dynamic host configuration protocol,” RFC 2131, Mar. 1997.
11. C. E. Perkins, "IP encapsulation within IP," RFC 2003, May 1996.
12. C. E. Perkins, Mobile IP, Design Principles and Practices, Addison Wesley, 1997.
13. C. E. Perkins, "Route optimization in Mobile IP," draft-ietf-mobileip-optim-07.txt, Nov. 1997.
14. A. Dixit and V. Gupta, "Mobile IP for Linux," Dept. of Computer Science University of New York Binghamton, May 1996.
15. D. A. Maltz and D. B. Johnson, "The CMU Monarch project IETF Mobile IPv4 implementation user's guide," Dept. of Computer Science University of Carnegie Mellon, June 1997.
16. F. C. Chung, "TCP performance in Mobile IP," Dept. of Electrical Engineering University of Singapore, June 1997.
17. X. Zahno, "Stanford MosquitoNet project Mobile IPv4 distribution user's manual," Dept. of Computer Science University of Stanford, May 1998.
18. E. Gafni and D. Bertsekas, "Distributed algorithms for generating loop-free routes in networks with frequently changing topology," IEEE Trans. Commun., vol. 29, pp. 11-18, Jan. 1981.
19. C. Huitem, Routing in the Internet, Prentice Hall, 1995.
20. J. Moy, "OSPF Version 2," RFC 2178, July 1997.