산업 사회의 급속한 발전은 실시간 제어 시스템을 요구하고 있다. 실시간 제어 시스템을 최적화하기 위하여 로컬에서 동작하는 다양한 제어 장치들은 임베디드 시스템을 기본으로 사용하고 있다.

분산 환경에서 로컬 장비들을 모니터링 하는 노드(이하 노드)와 이를 통합 관제하는 중앙 서버(이하 서버)와의 실시간 처리는 네트워크 환경으로 구성되어 있다. 이러한 환경에서 서버와 노드의 실시간성과 데이터 무결성을 제공하는 것은 무엇보다 중요하다.

임 영 규 / lim.younggyu@gmail.com
금오공대 IT융복합 공학과 박사과정
前 대한상공회의소 충북인력개발원 정보통신과 교수
현, 다람기술 소프트웨어 설계팀




1. 서론

본 강좌에서는 서버와 노드의 데이터 전송에 있어 데이터 종류에 따른 이중화 경로를 사용하여 시스템 성능을 향상 시킬 수 있는 기법을 제안한다. TCP/UDP 가 네트워크 환경에서 데이터 전송을 위한 기본 프로토콜로 사용되어 왔으나 이들 프로토콜은 전송과 확인, 비 신뢰성 전송 등 시스템 성능에 영향을 미치는 문제들을 가지고 있다.

이러한 문제들을 해결하기 위하여 SCTP프로토콜을 적용한 BDCR 기법을 알아본다. BDCR 는 TCP와 UDP 응용의 단점을 보완하며 데이터와 데이터 전송 경로를 이중화를 통한 병렬처리가 가능한 시스템이다.

실시간을 요구하는 데이터는 UDP 특성을 이용하여 노드로부터 실시간 데이터를 전송 받는다. 실시간 데이터의 지연을 최소화하기 위하여 10개의 UDP 특성을 가진 채널을 생성하였다. 제어 신호는 TCP 특성을 이용하여 노드로 제어를 위한 데이터를 전송한다.

본 강좌는 1장 소개에 이어 2장에서는 제안하는 연구에서 사용하는 SCTP 개요에 대하여 논한다. 그리고 3장에서는 제안하는 BDCR 기법에 대하여 소개하며 4장에서는 SCTP의 성능을 평가 결과 및 제안하는 기법의 속도 향상에 대한 속도 향상 기댓값을 계산한다. 마지막 5장에서는 결론과 향후 연구방향에 대하여 알아본다.




2. SCTP 소개

2.1 SCTP 개요
SCTP은 SIGTRAN WG에서는 IP망에서의 VoIP 전송을 위해 적합한 새로운 전송 프로토콜 표준개발을 주요 목표로 하였다. 이것은 전송계층에서의 전송경로 장애를 대비한 대체 경로를 확보할 수 있는 기능을 제공하며, 하나의 세견을 통해 여러 호처리 메시지가 전송되는 다중 스트리밍 기능도 제공한다.

SCTP를 단순히 신호 전달 기능이 아닌, TCP 이후의 차세대 수송계층 프로토콜로 개발하기 위한 확장 작업은 현재 진행 중이다. SCTP는 TCP와 UDP의 제약사항을 해결할 수 있는 기능도 포함하고 있다.

▲ 그림 1.인터넷 프로토콜 스택
▲ 그림 2. TCP와 SCTP의 연결 및 연결해제 동작 비교


TCP의 제약사항
- TCP는 신뢰성 있는 데이터 전달과 엄격한 전달 순서를 지킨다. 그러나 몇몇 어플리케이션에서는 순서대로 처리되지 않아도 되는 경우도 있다. 또한 어느정도 수준의 순서만 맞아도 되는 어플리케이션이 있다. 그래서 TCP의 경우 head-of-line 블로킹 같은 불필요한 지연을 가지고 있는 셈이 된다.
- TCP의 stream-oriented 성질은 다소 불편하게 된다. 어플리케이션은 그 메시지에 레코드의 끝을 알리는 마킹을 추가 하여야 한다. 그리고, 메시지가 완성되어 제때 전송하도록 하기 위해서는 push기능을 사용하여 바로 전송하도록 해야만 한다.
- TCP소켓의 범위의 제약사항은 멀티홈 호스트를 사용할 때 고가용성 데이터 전달을 제공하는 데 부적합하다.
- TCP는 SYN 공격과 같은 DOS 공격에 상대적으로 취약하다.


UDP의 제약사항
- UDP는 비 연결지향성이기 때문에 데이터 전송에 대한 신뢰성을 보장하지 못한다. 그래서 응용프로그램은 패킷이 목적지에 도달했는지 확인할 수 없다.
- UDP는 경로를 검출하는 내장 혼잡 제어 메커니즘을 포함하지 않는다. 그 결과 더 많은 데이터가 이미 혼잡에 주입 될 수 있어 네트워크상의 데이터 손실이 발생할 수 있다.
- 응용프로그램에서 USP를 이용하여 신뢰성 있는 데이터 전송을 위한 엄격한 규칙이 구현되는 경우, 이에 대한 추가적인 오버 헤드와 복잡성이 발생한다.

그러나 SCTP는 TCP와 UDP가 지원하는 모든 기능을 제공하며 TCP 특정 한계를 극복하고 UDP의 유익한 기능을 제공한다. 이것을 정리하면 표 1과 같다.


▲ alt="0018(표 1.SCTP, TCP, UDP 비교)"

2.2 SCTP 구조
SCTP는 신뢰성있는 전송을 가능하게 하는 연결 지향 전송 프로토콜이며 TCP와 UDP와 같은 네트워크 계층에 존재한다.

그림 1은 인터넷 프로토콜 스택에서 SCTP가 위치하는 계층을 나타내었다.

송수신 연결 설정에 있어서도 TCP의 3-way Handshaking과 달리 4-way Handshaking을 이용하며, 해제 시 TCP와 달리 2번의 연결종료 확인 과정을 거친다.

그림 2는 TCP와 SCTP의 연결을 비교하여 나타내었다. SCTP는 그림 3과 같은 메시지 포맷을 이용하여 데이터를 전송하며 각 메시지는 하나 또는 그 이상의 패킷을 포함한다.
하나의 패킷은 공통 head와 하나 또는 그 이상의 Chunk를 포함하고 있다. SCTP의 공통 header 가지고 있는 정보들은 다음과 같다.


- 동일한 주소에서 다른 SCTP 연결의 다중화를 가능하게 하는 소스 및 목적지 포트 번호.
- SCTP 연결에서 out-of-date 또는 전송 실패한 메시지의 삽입에 대한 경비 32 비트 확인 태그.
- 에러 검출을 위한 32 비트 체크섬, CRC또는 Adler-32을 포함한다.


▲ 그림 3.단일 홈 노드 연결

▲ 그림 4.NI를 가진 멀티 홈 연결방식

▲ 그림 5.다중 스트리밍 연결방식


2.3 SCTP 메시지 및 노드 연결과 해제
SCTP은 단일 홈과 멀티 홈 방식 모두를 지원한다. 그림 4와 그림 5는 각각 단일 홈과 멀티 홈 방식에 대하여 나타내었다. 먼저 단일 홈 연결 방식은 각각의 노드는 오직 하나의 네트워크 인터페이스(NI)를 통해 연결되는 경우이다. 만약 네트워크 또는 경로 상에 문제가 발생하면 종단의 노드는 네트워크에서 완전히 분리되어 더 이상 데이터 전송이 불가능하다.

이를 보완하기 위하여 SCTP는 멀티 홈 연결을 지원한다.

멀티 홈 연결의 경우 하나의 노드는 그림 5와 같이 여러 개의 NI를 가지고 있는 경우이다. SCTP는 메인 주소로 하나의 주소를 선택하고 정상적인 데이터 전송을 위해 이것을 모든 메시지의 대상 주소로 사용한다. 다른 NI들은 모두 다른 IP 주소를 가지며 이들 IP들은 메시지의 재전송 및 원격 종단의 포인트에 도달하는 확률을 개선하기 위해 대체 IP 주소로 사용된다.

이것을 다중 스트리밍 연결방식이라 하며 그림 7과 같다.


▲ 그림 6.SCTP 개발환경 설정과 리눅스 커널지원 확인


2.4 SCTP 개발 환경
윈도우즈 환경에서 SCTP 응용 프로그램을 개발하기 위해서는 SCTP 커널 모듈과 C 언어 라이브러리를 설치하여야 하며, 소켓통신을 위한 방화벽을 해제하여야 한다.

그림 6은 우분투 12.04 Linux 환경에서 SCTP를 구현하기 위한 과정을 보여준다.

▲ 그림 7.커널, 라이브러리 설치와 방화벽 설정

▲ 그림 8.분산제어 시스템에서 BDCR 프로세싱 개념도



Linux Kernel 3.2 기반에서는 SCTP를 지원하기 때문에 SCTP 응용 프로그램 개발을 위한 지원 프로그램과 라이브러리를 설치하여야 한다. 그리고 해당 커널이 SCTP를 지원하는지 확인하는 절차를 나타내었다.

그림 7은 윈도우즈 XP 환경에서 SCTP를 구성하기 위한 과정을 보여주며, 그림 8은 클라이언트 및 서버 응용 프로그램이 실행됨을 보여준다.

이를 위하여 윈도우즈 XP 환경에서 Microsoft visual tudio 2005를 설치하고 여기에 SCTP 드라이버를 설치하였다.




3. BDCR

3.1 BDCR 데이터
RDCR은 실시간 시스템의 신뢰성 향상과 신속한 데이터 전송을 위하여 SCTP를 기본으로 하는 제어 시스템이다.

2장에서 살펴본 SCTP의 노드 연결 방식에서 멀티 홈 연결 방식을 채용하여 네트워크를 구성 하였다. 그리고 전송되는 데이터를 De-Facto와 De-Jure 두 종류로 구분하였다.


De-Jure  데이터
- 센서 노드들로부터 입력받은 데이터를 네트워크로 신속하게 전달하기 위하여 SCTP의 UDP 특징을 이용하는 데이터로써, 지연을 허락하지 않는 데이터.

De-Facto 데이터
- 센서 노드들에 대하여 제어 신호를 위해 SCTP의 TCP 연결지향 특성을 이용하는 데이터.



3.2 BDCR 데이터 경로
그림 8은 제안하는 BDCR 기법의 개념도를 나타내었다.

BDCR 기법은 실시간 시스템의 신뢰성 향상과 신속한 응답시간을 위하여 2개의 De-Facto 데이터 채널과 10개의 De-Jure 실시간 데이터 전송 채널로 구성되는 것을 가정하였다.

채널 증가에 따른 시스템 증가를 기대할 수 있지만 채널 생성과 파괴 및 작업 불균형에 따른 추가 시간 지연이 발생할 수 있는 단점이 있다. 제안하는 BDCR 기법은 모두 12개의  프로세스로 구성하였다. 멀티 홈 방식을 위하여 서버와 노드는 각각 2개의 NI를 장착하였다.

▲ alt="0010(그림 9.SCTP를 이용한 제어 데이터 전송)"

▲ alt="0011(그림 10.SCTP를 이용한 실시간 데이터 전송)"



그림 9는 멀티 홈 방식을 이용하기 위한 SCTP Application Interface (APIs) 플로우를 나타내었다. 서버와 클라이언트에서는 2개의 NI를 사용하기 위해 bindx와 connectx API를 호출한다. 이것은 sctp의 TCP 특성을 이용하여 구현한다.

그림 9에서 서버는 노드로부터 받은 데이터를 분석하여 제어가 필요한 경우 제어 데이터를 노드로 보내게 된다.

하나의 NIC에 대하여 2개의 IP를 설정하였기 때문에 bindx와 connect API 함수를 호출하였다. 이를 통하여 첫 번째 할당한 IP에 대하여 문제가 발생하면 두 번째 할당한 IP로 제어 데이터를 보낼 수 있게 된다.

서버에서는 서버에 저장되어 있는 실시간 데이터를 기반으로 제어 범위에 대한 변경이 필요하면 send_snsr함수를 이용하여 센스노드로 제어 데이터를 재전송한다. 따라서 로컬의 각 임베디드 시스템들의 제어 설정 값은 재 적용된다.

그림 10은 각 노드에서 센서로부터 받은 실시간 데이터를 서버로 전송하기 위한 API 함수 호출에 대하여 나타내었다. 이는 SCTP의 UDP 특성을 이용하는 방법이며 모든 노드는 그림 10의 플로우에 따른다. 서버에서 sctp_recvmsg함수를 통해 받은 실시간 데이터는 저장 장치에 스트림 번호를 기준으로 저장되며, 이 데이터들은 향후 제어 데이터 변경을 위해 사용된다.

데이터 전송 속도 향상을 위한 기대값은 멀티 홈 방식으로 구성된 네트워크를 적용하였기 때문에 암달의 법칙을 적용한다는 것을 가정하였다.

식 1은 본 연구에서 사용하는 데이터 전송 성능에 대한 기대값을 구하는 공식을 나타내었다.

▲ alt="0019()"


 

4. 성능 평가

SCTP와 TCP의 성능 분석을 초당 1G 비트속도와 수신 큐의 크기 10000개 그리고 측정 단위 시간은 10초부터 3600초로 하고 이더넷 기반에서 수행한 결과를 그림으로 나타내었다. 그림 11, 12는 각각 10, 600초 간격으로 데이터를 전송하고 이들의 대역폭을 측정한 결과를 보여준다. 결과에서 SCTP가  TCP 대비 5% 낮은 대역폭으로 데이터 전송하는 결과를 제공하였다.

▲ alt="0012(그림 11.SCTP와 TCP 10 ms 단위 대역폭)"

▲ alt="0013(그림 12.SCTP와 TCP 600 ms 단위 대역폭)"

▲ alt="0014(그림 13.SCTP와 TCP 10 ms 단위 데이터 전송)"

▲ alt="0015(그림 14.SCTP와 TCP 600 ms 단위 데이터 전송)"

▲ alt="0016(그림 15.SCTP와 TCP 전체 대역폭)"

▲ alt="0017(그림 16.SCTP와 TCP 전체 데이터 전송)"


그림 13, 14에서는 10, 60초 간격으로 데이터를 전송하였을 때 단위 시간당 데이터 처리량을 보여준다. 결과를 보면 SCTP가 상대적으로 더 많은 데이터를 전송하는 것을 알 수 있다.

그림 15, 16은 전체 실험을 정리한 것으로 SCTP가 TCP에 비하여 더 안정적이며 단위 시간당 100M 비트 속도에 비하여 Round Trip Time (RTT)도 120 ms로 빠른 것을 보여 준다. SCTP와 TCP의 성능 평가를 통해서 보면 SCTP가 TCP 보다 성능이 우수함을 보여 준다.  식) 1에서 기대효율(f) 50 %로 설정 하고 프로세스(P) 개수는 12개를 적용하고 식) 1에 대입하면 데이터 전송 성능 기대값은 1.84이다.

그러나 직렬화 하여 처리하는 경우 실 제 기대값은 식) 1의 역수와 같아서 2 배가 된다. 따라서 직렬처리 하는 것은 채널 개수에 의존하지 않기 때문에 제안하는 BDCR 기법을 적용하면 데이터 전송 성능은 1.84배 향상됨을 기대할 수 있다.




5. 결론 및 향후 과제

이번 강좌에서는 실시간 제어 시스템의 성능을 향상시키기 위해 데이터 종류와 데이터 전송 채널 이중화가 적용된  BDRC 기법을 알아봤다.

BDCR 기법은 노드에서 전송되는 실시간 데이터를 서버에서 수신할 수 있는 다 채널로 설계하고 SCTP가 제공하는 UDP 특성을 이용하였다. 이것은 로컬 임베디드 시스템들의 개수가 많아지고 이로 인한 노드 및 네트워크 규모가 증가하는 경우에 대한 유연성을 제공한다.

그리고 노드에 제어 데이터를 전송하기 위해 SCTP의 TCP 특성을 이용하였다. 이중 경로를 생성하기 위하여 SCTP가 제공하는 멀티 홈 방식을 적용하였다. 이를 통하여 실시간 제어 시스템의 성능을 50 % 향상 시키려고 할 때 데이터 전송 성능이 약 2배가 증가되는 것을 확인할 수 있었다.

 

참고 문헌

1. Tuexen, Michael, Robin Seggelmann, and Eric Rescorla. “Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP).” (2011).
Budzisz, Łukasz, et al. “A taxonomy and survey of SCTP research.” ACM Computing Surveys (CSUR) 44.4 (2012): 18.
2. Tuexen, Michael, and Randall Stewart. “Stream Control Transmission Protocol (SCTP) Chunk Flags Registration.” (2011).
Cui, Lin, Seok Joo Koh, and Woo Jin Lee. “Fast selective ACK scheme for throughput enhancement of multi-homed SCTP hosts.” Communications Letters, IEEE 14.6 (2010): 587-589.
3. Dreibholz, Thomas, and Jobin Pulinthanath. “Applicability of reliable server pooling for SCTP-based endpoint mobility.” (2012).
4. Camarillo, Gonzalo, and Salvatore Loreto. “Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP).” (2013).
5. Yamada, Shota, et al. “A study of TCP over SCTP parallel networking and parallel route selection approach for Mass data transfer applications.” Optical Network Design and Modeling (ONDM), 2010 14th Conference on. IEEE, 2010.
6. Yilmaz, Ertugrul, et al. “Throughput analysis of non-renegable selective acknowledgments (NR-SACKs) for SCTP.” Computer Communications 33.16 (2010): 1982-1991.
7. Loreto, S., and G. Camarillo. “Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP).” draft-ietfmmusic-sctp-sdp-01 (work in progress) (2012).    
8. Allman, M., et al. “Early retransmit for TCP and stream control transmission protocol (SCTP).” Internet RFCs, ISSN 2070-1721, RFC 5827 (2010).
9. Adhari, Hakim, Thomas Dreibholz, and Martin Becke. “SCTP Socket API Extensions for Concurrent Multipath Transfer.” (2012).
10. Stewart, R., P. Lei, and M. Tuexen. “Stream Control Transmission Protocol (SCTP) Stream Reconfiguration.” draft-ietf-tsvwg-sctp-strrst-04, Internet-Draft work in progress (2010).
11. Johnson, Andrew, et al. “IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream.” (2012).
12. Salim, J. Hadi, and K. Ogawa. “SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol.” RFC5811, March (2010).
13. SCTP Performance, http://datatag.web.cern.ch/datatag/WP3/sctp/tests.htm, 2013.
14. Ha, Jong-Shik, Sang-Tae Kim, and Seok J. Koh. “Performance comparison of SCTP and TCP over Linux platform.” Advances in Intelligent Computing. Springer Berlin Heidelberg, pp. 396-404, 2005.
15. Ravier, Thomas, Rob Brennan, and Thomas Curran. “Experimental studies of SCTP multi-homing.” First Joint IEI/IEE Symposium on Telecommunications Systems Research. 2001.     

 


이 기사를 공유합니다
저작권자 © 테크월드뉴스 무단전재 및 재배포 금지