네트워크 가상화 환경에서 끊김 없는 핸드오버를 위한 일반 AP 활용

2-1 SDN (Software-Defined Networking)

SDN은 원래 PSTN (Public Switched Telephone Network)에서 프로비저닝 (네트워크 자원의 할당 및 배치)과 관리를 간소화시키기 위해 제어 평면과 데이터 평면을 분리하자는 취지에서 출발했고, 2004년경 IETF (Internet Engineering Task Force, 인터넷 표준화기구)에 의해 이 개념을 인터넷 네트워크 표준 도입을 시도했으나 위험 부담과 벤더들의 상이한 이해관계로 실패했고[1], 이 후 스탠포드 대학 등 학계를 중심으로 연구가 시작되었고 현재는 유수의 네트워크 기업들이 지원하는 공개 프로젝트 형태로 진행되고 있다.

2-2 OpenFlow

OpenFlow는 SDN 표준 개방 플랫폼 중의 하나로 스탠포드 대학의 Ethane 프로젝트[2]에 의해 2008년 1차 완성되었다. OpenFlow는 각 플로우 구성요소를 연관지어 실행하는 플로우 테이블 (flow table), OpenFlow 콘트롤러로부터의 명령 패킷을 보내고 받는 보안 채널 (secure channel), 그리고 OpenFlow 콘트롤러와 OpenFlow 가상 스위치 간의 통신을 지원하는 OpenFlow 프로토콜로로 구성된다. OpenFlow 가상 스위치는 OpenFlow 프로토콜을 이해하는 스위치이며, OpenFlow 콘트롤러와의 연결을 형성ㆍ유지하고, OpenFlow 콘트롤러의 제어를 받는다. Open Flow 가상 스위치는 다수의 네트워크 인터페이스로 구성되며, 보안 채널은 OpenFlow 콘트롤러와의 통신을 위한 TCP 기반의 보안 채널을 형성한다. 플로우 테이블은 VLAN (Virtual LAN), 이더넷, IP, TCP, 포트 등에 대한 관련 정보를 가지고 있으며, 이러한 정보들에 의해 플로우 동작이 결정되고, OpenFlow 프로토콜을 통해 정보들이 OpenFlow 콘트롤러로 전달된다[2]. OpenFlow의 전체적인 구성도를 그림 1에 보였다.

Fig. 1.

Overall Block Diagram of the OpenFlow

이더넷 환경을 염두에 두고 시작된 OpenFlow를 무선랜에 적용하려는 시도는 주로 무선 노드 간 라우팅 정책 수립에 SDN을 적용하는 연구들이다. 논문 [3]-[5]는 주요 거점에 무선 중계 노드를 두어 멀티 홉 무선 통신으로 넓은 영역을 커버하는 무선 백본 즉, 무선 메시 네트워크 구현에 SDN을 활용하였다. 이와 성격이 다른 기업이나 학교, 병원 등 AP를 중심으로 밀집된 무선 통신 인프라에서의 SDN 적용 방안에 대한 연구는 최근에 시작되고 있다. 논문 [6]은 기존의 AP에는 중앙 콘트롤러와의 제어 통신 기능이 존재하지 않으므로 그림 2와 같이 인증, 어카운팅, 정책 설정, 채널 설정, 단말기 이동성 지원 등을 위해 중앙의 OpenFlow 콘트롤러와 통신할 수 있는 가벼운 가상 AP인 LVAP (Light Virtual Access Point) 구현 개념을 Odin으로 명명하여 제안하였다. 여기서 Odin은 SDN을 이용해 물리적 AP들을 가상화시켜 주변의 무선 단말기에게는 오직 하나의 AP만을 보여주자는 것으로 이를 위해 특별히 목적에 부합하는 물리적 AP를 제조하여 사용하였다.

Fig. 2.

Concept of the LVAP (Odin)

2-3 무선랜 핸드오버

CAPWAP (Control And Provisioning of Wireless Access Points)[7]은 그림 3과 같이 무선랜 AP 그룹을 중앙 콘트롤러에서 관리할 수 있는 표준 네트워크 프로토콜로서 네트워크 가상화에 중점을 두는 본격적인 SDN과는 약간 거리가 있다[8]. 전통적인 WLAN 환경은 AS (Authentication Server), AP (Access Point), MS (Mobile Station) 등 크게 3 개의 컴포넌트로 구성되고, AP는 물리계층과 MAC 계층으로 구성된다. WTP (Wireless Termination Points)는 기존 Fat AP (자체 기능이 풍부한 AP)의 MAC 계층 기능 중 일부분과 물리계층의 기능을 Thin AP (기본 기능만 갖춘 AP)로 구현한 일종의 무선 안테나로 IEEE 802.11 물리 계층 기능을 담당하는 장치인데, CAPWAP의 AC (Access Controller)는 기존 Fat AP의 MAC 계층 기능을 중앙에서 통합 관리하기 위해 엔터프라이즈 무선랜 환경에서 도입한 물리적 구성 요소이다. 즉, CAPWAP는 엔터프라이즈 무선랜을 구성하고 있는 모든 AP의 MAC 기능을 중앙의 AC를 통해 직접 관리하도록 하는데, 이 때 AC는 IEEE 802.11의 인증 및 접근제어 부분을 담당한다. CAPWAP 무선랜 환경에서 AC를 통하여 티켓을 생성하고 분배하여 핸드오버를 지원하기 위해 WTP와 AC사이에 사용되는 CAPWAP 프로토콜은 단지 티켓을 전송하는 역할만 담당하며, 호스트 (MS: Mobile Station)가 최초 인증과정을 거친 후 새로운 WTP로 핸드오버할 때 802.1x EAP-TLS (Extensible Authentication Protocol - Transport Layer Security, 인증 프레임워크 중 하나) 인증 과정 없이 곧바로 접속하여 서비스를 계속 이용할 수 있도록 함으로써 고속 핸드오버를 지원한다. CAPWAP에서 핸드오버 과정은 그림 4와 같다. 이 그림의 Ⓑ는, WTP1로부터 무선 네트워크 서비스를 제공받던 호스트가 새로운 WTP로 로밍하기 위해 Probe Request/Response 과정을 통해 이용 가능한 WTP2를 발견한 후 WTP2와 사용할 세션키를 새롭게 도출하는 과정인데, 이때 CAPWAP는 802.1x EAP-TLS 인증과정 없이 AC가 PMK (Pairwise Master Key)를 도출하여 AC와 호스트사이의 4-Way Handshake 과정을 바로 진행한다. 즉, 호스트는 접속하고 있던 WTP1과의 접속을 Disassociation 과정을 통해 해지한 후 최초 인증 시 도출했던 PMK0를 재사용하여 WTP2와의 Association 과정을 통해 4-Way Handshake 과정을 바로 실행하고 이를 통해 새로운 세션 키 PTK1을 도출한다. 시스코는 CAPWAP에 기반한 무선랜 핸드오버 가능 제품을 출시하고 있는데 독자적인 고유 AP를 개발하여 사용한다[9].

Fig. 3.

Overall Block Diagram of the CAPWAP

Fig. 4.

Authentication and Session Key Extraction Process of the CAPWAP

3-1 끊김 없는 무선랜 핸드오버 프로토콜 표준

안전하고 끊김 없는 802.11 무선랜 핸드오버를 위해서는 산업 표준의 인프라 연동 모델인 ESS (Extended Service Set) 환경 하에서 신속한 BSS (Basic Service Set) 전이를 지원하는 IEEE 802.11r과, 무선 자원 관리 기능을 제공하는 IEEE 802.11k, AP를 제어하고 프로비저닝을 담당하는 중앙 콘트롤러, 기본 WLAN 기능을 담당하는 BSS, 그리고 이동 클라이언트 (무선 단말기)를 관리하는 AAA 서버 (Radius server) 등 크게 다섯 개의 요소가 필요한데[10], 이들은 기본적으로 CAPWAP의 802.11 바인딩 (binding) 버전이다.

• • IEEE 802.11r : 하나의 무선 통신 링크에 해당되는 BSS를 다른 AP로 전이하기 위한 안전 키 교환 프로토콜로서, 키 교환과 무선 자원 (AP) 할당을 병렬로 진행함으로써 로밍 시간을 단축한다[11].
• • IEEE 802.11k : 클라이언트 (무선 단말기)에 설치되어 AP를 중심으로 한 주변의 무선랜 자원 관리 체계 및 서비스 표준으로 클라이언트들이 가장 적합한 AP를 선택할 수 있는 정보를 제공한다[12].
• • 중앙 콘트롤러 : 전체 네트워크를 대상으로 BSS에 대한 정책 설정으로 가상 네트워크를 유지ㆍ관리한다.
• • BSS : 하나의 AP와 해당 AP에 연결된 무선 단말기의 총칭으로 무선랜 통신 서비스의 기본 단위이다.
• • AAA 서버 : 인증 (Authentication), 권한 부여 (Authorization), 계정 관리 (Accounting) 등 세 가지 기능을 제공하는 서버로서 요청ㆍ응답 형태로 동작한다.

다섯 가지 요소들에 의해 끊김 없는 핸드오버가 이루어지는 과정은 아래와 같다 (그림 5).

• ① 무선 단말이 AP1와의 거리가 멀어지면, 주변 AP들에게 응답 요청 메시지를 보낸다.
• ② 주변 AP들은 단말에게 가까이 있음을 알리는 응답 메시지를 무선 단말에게 보낸다.
• ③ 무선 단말은 주변 AP들로부터의 메시지를 받아 신호 세기 등을 고려하여 가장 적합한 AP에게 접속을 요청하여 링크를 맺는다. 이 때, AP는 인증 절차를 따른다.
• ④ 마지막으로 무선 단말은 AP1과의 링크를 해제한다.

Fig. 5.

Handover Process of 802.11k

3-2 OpenFlow 가상 스위치

□ 하드웨어 플랫폼

OpenFlow 가상 스위치는 논문 [13]의 LVSAP (Light Virtual Switch for AP) 개념을 표 1의 RB450G 보드에 적용하여 구현한다. RB450G 보드는 그림 6과 같이 시스템 연결 포트 (eth0)와 스위치 연결 포트 (eth0.1 ~ eth0.5)를 분리하여 제공한다.

Table 1.

Speification of RB450G Board

Fig. 6.

Internal Block Diagram of RB450G Board

□ OpenWrt 및 OVS의 보드 설치 및 부팅

TFTP (Trivial File Transfer Protocol)를 이용하여 OpenWrt 및 OVS 패키지를 RB450G 보드에 설치하고 부팅시킨 다음 그림 7과 같이 OVS 커맨드로 확인한다.

Fig. 7.

Booting Process of OpenFlow vSwitch

□ OpenWrt 네트워크 설정

그림 6의 내부 인터페이스에 따라 OpenWrt 내 네트워크 인터페이스를 그림8과 같이 설정한다. 이 설정의 주요 내용은 아래와 같다.

• • 물리 네트워크 인터페이스 “eth0”에 가상 네트워크 인터페이스 “lan”을 생성하고 고정 IP 주소 “192.168.1.10”을 부여한다.
• • 물리 네트워크 인터페이스 “eth0”에 가상 네트워크 인터페이스 “wan”을 생성하고, IP 주소는 DHCP로 받는다.
• • 여러 개의 VLAN을 지원하는 스위치 “switch0”를 생성한다.
• • 스위치 “switch0”에 0~4의 다섯 개 VLAN을 생성하여 AP와의 연결을 지원한다.

Fig. 8.

Network Configuration of OpenWrt

□ OVS 브릿지 설정

가상 스위치 보드 (RB450G)의 AP 연결 이더넷 인터페이스 eth0.1과 연결할 OVS 내 브릿지를 아래 스크립트와 같이 생성하고 대응시킨 후, 가상 스위치와 OpenFlow 컨트롤러의 통신을 개시하고 , 그림 9와 같이 확인한다.

> ovs-vsctl add-br ovsbr0↲ > ovs-vsctl add-port ovsbr0 eth0.1↲ > ovs-vsctl set-controller ovsbr0 tcp:192.168.1.5↲

Fig. 9.

Confirmation of Bridge Configuration in OVS

3-3 AAA Server

AAA 서버는 끊김 없는 핸드오버를 위한 핵심 컴포넌트로서, Ububtu 18.04 운영체제 하에 표 2의 소프트웨어를 이식·구현한다. 그림 10은 이들 소프트웨어의 연동 체계도인데, 이중 인증을 위한 핵심 소프트웨어는 Free RADIUS [14]이다. 그림 11에 FreeRADIUS의 설치 및 인증 시험 과정을 보였다.

Table 2.

Software Items for AAA Server

Fig. 10.

Block Diagram of AAA Server

Fig. 11.

Installation and Test Process of AAA Server

3-4 OpenFlow 콘트롤러

OpenFlow 콘트롤러로는 ONOS (Open Network Operating System) 1.13.1 버전 [15]을 PC 리눅스 플랫폼 (Ubuntu 18.04)에 아래 스크립트와 같이 이식하여 구현한다. 그림 12에 ONOS 실행 모습을 보였다. 여기서 git clone은 해당 URL에 존재하는 패키지 환경을 로컬 시스템에 연결ㆍ구축한다.

Fig. 12.

Excution of ONOS (OpenFlow Controller)

3-5 핸드오버 어플리케이션

호스트 이동을 감지하여 플로우 테이블을 변경하는 “handover” 어플리케이션을 ONOS의 “Host Mobility” 어플리케이션을 이식하여 아래 스크립트와 같이 빌드하여 등록한다. 그림 13에 onos 서버에 번들된 “handover” 어플리케이션을 보였다.

Fig. 13.

Confirmation of Handover Application Bundling in ONOS Server

좀 더 구체적인 ONOS 어플리케이션 개발 과정은 아래와 같다.

• • 어플리케이션 템플릿 생성
• - 어플리케이션 개발 디렉터리 (ONOS 소스 영역 밖)에서 “onos-create-app↲” 실행
• - groupId는 org.myapp, artiacrtId는 org.myapp.newapp, version은 1.0.0, onos-version은 1.13.1로 각각 입력하여 설정
• - pom.xml 파일과 src/main/java/org/myapp/newapp/AppCom ponent.java 소스파일이 생성됨
• • $ONOS_HOME/apps 디렉터리에서 유사한 어플리케이션을 탐색하여 모든 소스파일을 newapp의 소스 디렉터리로 복사
• • newapp의 pom.xml 파일 수정
• - onos.app.name은 org.myapp.newapp, onos.app.version은 1.0.0 으로, 기타 onos.app,title 등을 수정
• - 탐색된 유사 app의 pom.xml과 newapp의 pom.xml 파일의 dependencies 파트를 비교하여 newapp의 pom.xml에 존재하지 않는 항목들을 복사. 복사 항목 중 version이 미지정된 것은 MAVEN Repositary (http://mavenrepositary.com)에서 검색하여 설정
• - Maven의 test 단계에서 실패하는 경우가 있으므로 src/test 디렉터리는 삭제
• • newapp의 pom.xml 파일이 존재하는 디렉터리에서 “mvn clean install↲” 실행하여 어플리케이션 빌드

4-1 실험 환경 및 시나리오

무선랜 핸드오버를 실험하기 위해 그림 14와 같이 공유기를 통한 192.168.1.*의 내부 네트워크를 구성하고, 가상 스위치에 접근하는 무선 단말들은 DHCP로부터 192.168.3.*의 주소를 할당받아 무선 네트워크에 참여하도록 한다. 이 실험의 구체적인 상황 설정 및 전개는 아래와 같다.

• • 두 개의 AP (ipTIME)을 다른 무선 네트워크가 미약한 건물 옥상에 25m 거리를 두고 배치한다.
• • 802.11k가 탑재된 무선 단말기(Intel Wirelss Adapter)를 AP_0에 접근하여 무선 링크를 형성하고 3분 이상 길이의 유튜브 동영상에 접근한다.
• • 무선 단말기를 AP_1 쪽으로 이동시켜 핸드오버를 유도한다.
• • 무선 단말기의 동영상이 끊김없이 플레이되는지를 확인하다.
• • 위 과정에 대한 주요 패킷을 Wireshark으로 캡쳐한다.

Fig. 14.

Experiment Environment for Handover Test

4-2 실험 결과

AP_0를 통해서 동영상을 시청하다가 (그림 15 참조), 무선 단말기를 이동시켜 핸드오버 임계치에 다다르면 주변 AP를 스캐닝하고 (그림 16 참조), AP_1과 새롭게 링크 연결을 시도하여 핸드오버를 완료한 후 (그림 17 참조), 계속해서 동영상 스트리밍을 이어가는 모습 (그림 18 참조)으로부터 끊김 없는 핸드오버 기능이 작동하고 있음을 확인할 수 있다.

Fig. 15.

Video Streaming Packet before Handover

Fig. 16.

AP Scanning Packet for Handover

Fig. 17.

Authentication and Key Exchange Packet for Association

Fig. 18.

First Video Streaming Packet after Handover

4-3 성능 분석 및 평가

그림 15~18에 나타난 핸드오버 시간표를 요약하면 그림 19와 같고, 전체 지연시간은 832ms 이다. 이는 동영상과 같은 실시간 스트리밍 서비스를 위해 권고되는 핸드오버 최대 지연시간인 150ms [16]-[17]를 상당히 벗어날 뿐만 아니라, 이보다 더 나은 QoS를 위해 여러 개의 WLAN 카드를 활용하여 지연 시간을 34.7ms 까지 단축한 사례[18]에 비춰보았을 때, 개선의 필요성이 강하게 제기되고 있다. 타당성이 높게 예상되는 개선 방향은 아래와 같다 (그림 20 참조).

• • 무선 단말 주도 스캐닝 (active scanning)을 AP 주도 방식 (passive scanning)으로 전환하여 스캐닝 시간을 단축
• • AP 재접속 시간과 플로우 테이블 업데이트 시간을 중복시켜 직렬처리 대신 병행처리 도입
• • OpenFlow의 플로우 테이블 업데이트를 사후처리 (reactive update) 대신 사전처리 (proactive update) 도입

Fig. 19.

Time Line for Handover Progress

Fig. 20.

Desirable Time Line for Handover Progress