열정의 힘을 믿는다...

고석주 ( 한국전자통신연구원 표준연구센터 선임연구원, sjkoh@etri.re.kr)

2000년 10월 IETF는 RFC2960을 통해 SCTP(Stream Control Transmission Protocol)를 TCP(Transmission Control Protocol), UDP(User Datagram Protocol)에 이은 제3의 수송계층 프로토콜 표준으로 제정하였다. SCTP 등장배경은 다소 필연적이다. 90년대 후반에 접어들면서 기존 TCP, UDP를 통해서는 갈수록 광대역화 및 멀티미디어화로 발전하는 인터넷 응용 요구사항을 적절히 수용할 수 없었기 때문이다. SCTP가 IETF 표준으로 제정된 지 3년이 지나는 현 시점에서 제기되는 의문은, “과연 SCTP가 TCP/UDP를 대체할 것인가? 아니면 상호 공존하며 발전할 것인가?” 및 “SCTP의 Killer 응용은 무엇인가?” 등이 있다.

SCTP vs. TCP/UDP
SCTP 표준개발은 1997년 IETF SIGTRAN(Signaling Transport) WG에서 시작되었으며, IP 망에서 VoIP(Voice over IP) 시그널링 트래픽 전송을 위한 프로토콜 개발이 주요 목적이었다. 이를 위해 시그널링 게이트웨이간에 실시간으로 수 많은 사용자의 다양한 호처리 정보를 신뢰적으로 전송하고 또한 망 장애에 대비하여 신속한 복구기능이 제공되는 SCTP 프로토콜을 개발하였다. 초기에 SCTP는 UDP 위에 탑재될 예정이었으나, IESG(Internet Engineering Steering Group)의 강력한 권고에 따라 IP 위에서 동작하는 수송계층 프로토콜로써 제정되었으며, 이로써 VoIP 시그널링 뿐만 아니라 다양한 응용에서도 SCTP를 사용할 수 있게 되었다.
SCTP는 UDP의 메시지지향(message-oriented) 특성과 TCP의 연결지향(connection-oriented) 및 신뢰전송 특성을 모두 포함하는 등 TCP와 UDP의 장점을 살리도록 설계되었다. SCTP는 TCP의 연결지향성 및 신뢰전송 기능을 제공하지만, TCP와는 달리 4-way 연결설정 및 3-way 연결종료 등의 기능을 제공한다.
특히 SCTP는 멀티스트리밍(multi-streaming) 및 멀티호밍(multi-homing) 특성을 제공한다. Multi-streaming 특성을 통해 하나의 세션에서 다양한 종류의 컨텐츠를 식별 및 전달할 수 있으며, 바이트(byte) 기반 전송방식인 TCP의 HOL(Head-of-Line) blocking 문제를 해결하고 있다. 한편, Multi-homing 특성을 통해 단말은 두 개 이상의 IP 주소를 한 세션에서 사용할 수 있으며, 이를 통해 경로 장애에 대한 복구(fail-over) 기능을 제공한다. 또한 멀티호밍 특성은 SCTP 이동단말에 대한 핸드오버 기능을 제공할 수 있다. SCTP는 IP 패킷에 표시되는 프로토콜 식별번호(Protocol ID)로써 UDP(6), TDP(17)처럼 132번을 할당 받았다.

<표1> TCP/UDP와 SCTP 비교

SCTP 표준화 및 개발 현황
SCTP 기본규격은 2000년 10월에 SIGTRAN WG에서 RFC2960으로 표준화 되었으며, 이후 RFC 3257, 3286, 3436 등의 추가 규격이 제정되었다. 현재 후속 표준개발 작업은 IETF TSV(Transport Area) WG에서 이루어지고 있다. 현재 진행 중인 WG 문서는 “SCTP Socket API”, “구현지침서”, “PR-SCTP(Partially Reliable SCTP), “ADD-IP(Dynamic Address Configuration)” 등이 있다. 최근 IETF에서는 PR-SCTP(draft-ietf-tsvwg-prsctp-02.txt) 표준화 작업이 한창 진행 중이다. PR-SCTP는 SCTP 데이터 전송 도중에 “time-critical” 스트림에 대해서는 오류복구과정을 생략하고 곧 바로 응용계층에 전달될 수 있는 기능을 정의한다. 수신자는 PR-SCTP 신호를 받았을 경우, 버퍼에 있는 해당 데이터를 곧 바로 상위 응용에 전달한다.
SCTP 표준화 작업과 함께 전 세계적으로 실제 구현작업도 활발히 진행되고 있다. 먼저 지난 2003년 12월에 출시된 리눅스 커널 2.6.0 버전부터 SCTP 프로토콜 기능이 탑재되었으며, 관련 시험도구(tool set)도 개발되었다(http://sourceforge.net/projects/lksctp). 한편 독일을 중심으로 사용자레벨(user-space) 구현코드인 “sctplib” (http://www.sctp.de/sctp.html) 개발작업이 진행 중에 있으며, SCTP 시뮬레이션을 위한 ns-2 모듈(http://pel.cis.udel.edu/#downloads)도 출시되었다.

SCTP 확장: mSCTP
그 동안 SCTP 개발작업은 주로 SCTP의 멀티스트리밍 특성을 활용하는 방향으로 진행되어 왔다. 즉, VoIP 시그널링 게이트웨이간에 혹은 AAA 서버간에 SCTP 세션을 설정하고, 이를 통해 수 많은 사용자의 호처리 신호정보를 전달하는 용도로 SCTP가 사용되고 있다.
최근에 들어서는 SCTP 멀티호밍 특성에 대한 연구개발이 한창 진행 중에 있다. 특히 세션도중에 새로운 IP 주소를 추가할 수 있는 ADD-IP(draft-ietf-tsvwg-addip-sctp-08.txt)에 대한 표준화가 진행 중에 있으며, 이에 대한 주요 활용 분야로써 “mobile SCTP(mSCTP) 핸드오버” 기술이 주목을 받고 있다. mSCTP에서는 SCTP 멀티호밍 특성과 ADD-IP 기능을 활용하여, SCTP 단말이 세션 도중에 이동함으로써 IP 주소가 변경되더라도 네트웍의 도움 없이 세션의 연속성을 제공하는 기술이다. 관련 연구개발은 Siemens 및 시스코 등을 중심으로 진행 중에 있으며, 한국에서도 활발히 관련 연구에 참여하고 있다(draft-sjkoh-sctp-mobility-03.txt, draft-sjkoh-mobile-sctp-mobileip-03.txt).

결론 및 향후 전망
SCTP 는 IETF에서 차세대 수송계층 프로토콜 표준으로 제정되었으며, 현재 관련 표준화 및 개발작업이 한창이다. 향후 SCTP는 TCP, UDP를 대체하기보다는 서로 공존하면서, 각각의 특성에 부합하는 응용 및 서비스에 활용될 것으로 전망된다. 아직은 보급 초기단계이지만, TCP/UDP처럼 향후 지속적인 기술 보완을 통해 점차 실제 인터넷 응용에 널리 적용될 것이다.
현재의 SCTP 적용은 주로 시그널링 게이트웨이간 데이터 전송에 국한되고 있으나, 향후에는 멀티미디어 신뢰전송을 요구하는 신규 응용 서비스가 killer 응용으로 떠오를 가능성이 크다. 또한 mSCTP 핸드오버 등의 이동성 기능을 활용하는 이동통신단말기의 보급도 기대할 만하다. 특히, SCTP 관련 분야는 세계적으로 아직 개발 초기단계에 해당하므로, 이동통신 단말기 제조업체 및 서비스사업자들이 눈 여겨볼만한 기술이라 하겠다.

네트워크 전송 프로토콜 SCTP

출처 : http://cafe.naver.com/licensenet/60

개요

 SCTP(Stream Control Transmission Protocol)는 PSTN망 에서 사용되는 signalling messages를 인터넷 망의 IP Network상에서 전송하기 위해 IETF SIGTRAN Working group에서2000년 10월 표준으로 제안(RFC 2960)한 전송프로토콜이다.

 SCTP는 IP Layer 위에서 동작하는 TCP와 같은 연결지향적인 프로토콜로 신뢰성 있는 데이터 전송이 가능하며,Association 설정 시 발생할 수 있는 DOS 공격 (Denial of Service Attacks)이나 Masquerading 공격에 안전하도록 설계되어졌다.
또한 SCTP에는 Multi-Streaming 기능이 있어 TCP의 Head Of Line Blocking 으로 인한 성능 저하 문제를 해결 하였다. 특히 SCTP 연결 endpoint들이 여러 개의 IP주소를 가질 수 있는 Multi-Homed일 경우 한 개 이상의 통신 경로를 설정하여 Primary Path에 Path Fail 발생하더라도 미리 설정된 다른 통신 경로로 자동적인 데이터 전송을 하게 하는 Multi-Homing 기능이 있어 데이터 전송의 신뢰성을 높일 수 있도록 개발 되었다.

 SCTP 는 Multi-Homing과 Multi-Streaming 등의 기능을 통하여 네트워크 상에서 PSTN 망의 신호를 안전하게 전달할 수 있다. 또한 SCTP가 가지는 특징들은 데이터 전송의 성능과 유연성이 높이 요구되는 Mobile IP분야, 멀티미디어나 HTTP와 같이 다중 객체를 전송해야 하는 Application 환경과 높은 신뢰성과 보안이 요구되는 인증과 군 통신 장비 등에 유용하게 사용될 수 있어 차세대 전송 프로토콜로 주목 받고 있다.

기능

SCTP 주요 기능

Four-way Handshake 통한 Association 설정

Packet에 대한 유효성 검사

데이터 전송경로 및 Idle 경로 Monitoring

Ordered and Unordered 데이터의 전송

Chunk Bundling

Multi-Streaming

Multi-Homing

TCP에 적용된 Congestion Control

Graceful close 시 Half open 지원 하지 않음

Fragmentation and Reassembly

SCTP 패킷

Common Header

 SCTP 패킷은 Common Header와 Chunk로 구분된다. Common Header에는 Association이 설정된 Endpoint들을 유일하게 식별하게 할 수 있는 32 bit의 Verification Tag field가 있고, Checksum field 있어 Adler-32 알고리즘을 이용한 SCTP 패킷의 무결성과 일관성들을 검사 할 수 있다.

SCTP Chunk Type

 Common Header 다음에 Chunk들이 위치한다. 각 Chunk들은 Chunk type으로 시작 하여 Chunk의 Type을 구분할 수 있다. 이 Chunk 들은 SCTP의 연결 설정, 해제, 에러 전송 등을 위한 Control Chunk들과 데이터 전송을 위한 Data Chunk, 응답을 위한 Sack Chunk 등이 있다.

Note : 본 문서에서는 Chunk를 설명하기 위해 연결을 요청 하고 데이터를 보내는 측을 Endpoint A, 연결 요청에 수락을 하고 데이터를 수신하는 측을 Endpoint Z라고 가정한다.

- Payload Data (DATA)

 User Data를 전송하기 위하여 사용되는 Chunk이다. Data Chunk에는 Stream Identifier와 Stream Sequence Number가 있어 데이터가 전송되는 Stream과 지정된 Stream으로 전송된 데이터 순서번호를 인식할 수 있어 SCTP는 Multi Stream 이 가능해진다.

- Initiation (INIT)

  두 개의 endpoints 사이의 SCTP Association을 하기 위해 사용된다. INIT chunk Inbound Streams, Outbound Streams의 수, Window Size, 사용 가능한 IP(IPv4, IPv6), null Preservative 등이 Variable Parameter에 포함되어 전송된다.

- Initiation Acknowledgement(INIT ACK)

 Init Chunk의 ACK를 보내기 위해 사용되는 Chunk이다. 형태는 INIT Chunk와 유사하나 State null와 Unrecognized Parameter등이 Variable Parameter에 포함되어 전송된다.

- Selective Acknowledgement(SACK)

 SACK Chunk는 수신된 DATA Chunk의 TSN에 나타난 전송 데이터의 수신된 결과와 손실된 데이터 갭을 통보하기 위해서 데이터 송신 endpoint에게 보내어진다. 또한 SACK는 Cumulative TSN ACK field 와 Advertise Receiver Window Credit(a_rwnd) Parameter가 있어 데이터 수신을 위한 버퍼 크기와 수신된 데이터의 양을 관리하여 그 결과를 상대 endpoint에게 알린다.

- Heartbeat Request(HEARTBEAT)

 Endpoint A 와 현재 연결된 다른 Endpoint B 사이의 전송 경로가 SCTP Multi-Homed 기능에 의해 생성된 여러 개의 데이터 전송 경로 (Endpoint 들이 가지고 있는 IP들에 할 당 된 경로)가 데이터 전송이 가능한지를 판별하기 위해 연결된 Endpoint A의 IP들과 경로로 맺어진 Endpoint B의 IP들에 보내어 지는 Chunk이다.(Endpoint A와 B의 반대도 성립) HEARTBEAT Chunk에는 파라미터로 현재 송신 시간과 목적지 IP를 가지게 된다.

- Heartbeat Acknowledgement(HEARTBEAT ACK)

 HEARTBEAT Chunk에 대한 응답으로서 HEARTBEAT 송신자에게 보낸다.

- Shutdown Association (SHUTDOWN)

 ABORT는 Endpoint A 와 Endpoint Z 사이의 SCTP 연결이 비정상적으로 종료할 때 연결을 close하기 위해 보내어지는 상대 endpoint에게 보내지는 Chunk이다.

- Operation Error (ERROR)

 Endpoint A나 Endpoint Z사이에 발생한 에러 상태를 상대 Endpoint에 알리기 위해 보내어지는 Chunk이다. 이 chunk는 하나 이상의 에러 원인들을 포함하고 있다.

- null Echo (null ECHO)

 null ECHO는 association의 초기화 동안에만 사용된다. 초기화 프로세스가 완성되면 Association의 initiator(연결 요청 Endpoint)에 의해 peer(연결 수락 Endpoint)로 보내진다. 이 chunk는 Association 내에서 보내지는 어느 DATA chunk보다 반드시 앞에 위치 해야 한다. 또한 같은 패킷에서 하나 이상의 DATA chunk들과 함께 bundle될 수 있다.

- null Acknowledgement (null ACK)

 null ACK는 null ECHO chunk의 수신에 대한 acknowledge에 사용된다. 이 chunk는 반드시 association내에서 전송된 어느 DATA chunk나 SACK chunk보다 앞서 와야 한다. 또한 SCTP 패킷에서 하나 이상의 DATA chunk들이나 SACK chunk와 함께 bundle될 수 있다.

SCTP 데이터 전송

 SCTP 는 IP 네트워크 기반에서 효율적인 데이터 전송을 위해 RFC 2960에 따라 Bundling, Fragment and Reassembly, Flow과 Congestion Control 메커니즘 등을 구현하고 있다. 또한 Transport Sequence Number (TSN)을 이용하여 전송된 데이터의 중복데이터와 손실데이터를 찾을 수 있는 메커니즘이 있어 데이터 전송의 신뢰성을 높일 수 있다.

Flow Control

 SCTP 는 TCP와 같은 방법으로 혼잡제어와 흐름 제어를 위해 window size를 이용한다. 즉 수신 endpoint는 Receiver Window를 데이터 송신 endpoint에게 통보하여 송신되는 데이터의 크기를 조절한다. 이때 데이터 수신 endpoint는 Receiver Window Size를 SACK Chunk를 통하여 알려준다.

Congestion Control / Slow-Start

  망 내에 존재하는 패킷의 수가 과도하게 증가되는 현상을 혼잡 (Congestion) 이라고 정의하며 혼잡 현상을 방지하거나 제거하는 기능을 혼잡제어 (Congestion Control) 라고 한다. Slow-start는 패킷을 저장하는 중간 라우터의 저장할 버퍼 공간의 부족으로 데이터 전송에 문제가 생기는 것을 말한다. SCTP는 TCP Congestion Control과 Slow-start의 메커니즘을 같이 구현 하고 있다. 또한 SCTP에서 구현되는 혼잡제어와 Slow-start 메커니즘은 Multi-Homed에 의해서 구성된 모든 경로에 대하여 Congestion Control / Slow-start 메커니즘을 적용한다.

Selective Acknowledgement

 SACK Chunk의 Cumulative TSN Ack filed를 이용하여 수신된 데이터를 알리고 모든 데이터가 성공적으로 수신하였다면 Fragment된 데이터를 Reassembly 하여 ULP(예 Application)에 전송하게 된다. 만약 데이터의 손실이 생겼다면 Gap Blocks field를 이용하여 송신 측에 데이터를 알리고 데이터 송신 측은 Fast Retransmit 메커니즘을 이용하여 데이터를 재전송하게 된다.

Ordered and Unordered Delivery

 SCTP 는 Stream 내에서 전송되는 데이터 순서 SSN(stream sequence number)를 정의한다. 이 SSL은 Data Chunk 내에 존재 하며 만약 Data Chunk의 U flag가 1에 설정되어 있으면 데이터 순서에 상관 없이 Upper layer에게 전달 한다. 반대로 Data Chunk의 U flag가 0으로 설정되면 수신된 DATA chunk를 SSL에 따라 Upper layer에게 전달해야 한다. 만일 DATA chunk들이 SSN의 순서를 벗어나서 도착했다면 수신된 DATA chunk들을 ULP로 전달하기 위해 DATA chunk들이 재 정렬될 때까지 대기 되어야만 한다.

Fragmentation and Reassembly

 SCTP 는 효율적인 데이터 전송을 위해 fragmentation과 reassembly 메커니즘을 지원 한다. 만약 보낼 사용자 메시지가 현재 MTU의 크기를 초과하면 fragment가 요구된다. 만약 SCTP가 데이터 전송 시 사용자 메시지의 fragmentation을 지원하지 않으면 SCTP는 에러를 사용자에게 전달 하고 다시 메시지를 보내지 않는다. 데이터 수신 endpoint는 Fragment 된 데이터를 Reassembly하여 ULP에 전달하게 된다.

Bundling

 SCTP 는 전송하는 SCTP 패킷 안에 여러 개의 Chunk를 포함하는 단순한 방법으로 chunk를 묶을 수 있다. 이 때 SCTP 패킷은 IP header를 포함하는 IP 데이터그램의 크기는 현재 Path MTU 보다 작거나 같아야 한다. 즉 Bundling되는 데이터 크기는 MTU크기에 의하여 Bundling되는 데이터 크기가 결정된다. 만약 수신 측의 endpoint가 멀티홈드라면 데이터를 송신하는 endpoint는 현재 모든 경로 중의 가장 작은 MTU 값을 primary path의 MTU를 값으로 설정한다.

Path MTU Discovery

 SCTP endpoint는 주어진 인터넷 경로에 존재하는 최대 전송 단위(MTU)를 측정하고, MTU를 초과하여 전송하는 패킷을 중지하고, 때때로 Path MTU(PMTU)의 변경을 시도한다. 만약 SCTP가 Multi-Homed라면 모든 경로에 대하여 Path MTU Discovery를 실행한다.

SCTP 특징

SCTP Multi-Streaming

 SCTP 전송 프로토콜은 하나의 SCTP Association에 여러 개의 Stream을 가지는 Multi-stream 기능이 있다. SCTP는 각 Stream 마다 Stream 순서번호(SSN : Stream Sequence Number)가 있어 Stream의 순서를 유지하여 해당 Stream으로 전송되는 데이터를 관리하여 신뢰성 있는 데이터의 전송이 가능하도록 하고 있다.

  하나의 Stream으로 구성되는 TCP의 경우 Stream에 전송된 데이터에 패킷의 손실이 발생한 경우 손실된 패킷이 재 전송 되기를 기다리는 동안 Application에 데이터를 전달하지 못하는 Head of line blocking 현상이 발생한다. 그러나 SCTP는 여러 개의 Stream으로 데이터를 전송할 수 있어 어느 한 Stream에서 데이터의 패킷이 손실이 발생하여 데이터 전송이 지연되더라도 다른 Stream으로 전송되던 데이터는 지연현상 없이 Application에 데이터를 전송할 수 있는 Multi-Stream기능이 있다. 따라서 SCTP는 여러 개의 Stream으로 데이터를 전송 할 수 있어 데이터 전송을 빠르게 할 수 있다는 장점을 가질 수 있다. 만약 데이터 전송 및 여러 개의 객체를 전송해야 하는 HTTP 프로토콜에서 SCTP를 전송 프로콜로 사용한다면 데이터 전송 속도를 향상 시킬 수 있을 것이다.

 또한 SCTP는 Data Chunk에 Ordered, Unordered을 선택할 수 있는 U flag가 있다. 만약 데이터의 전송 시 순서 유지가 필요 없다면 U flag를 1에 설정하여 순서 없이 데이터 전송을 할 수 있다. 이 때 U flag를 인식한 데이터의 수신 endpoint에서는 데이터의 순서를 유지할 필요가 없기 때문에 데이터의 순서를 유지하기 위하여 소모되는 시간이나 손실 된 패킷에서 발생한 데이터를 재 수신하기 위하여 기다려야 하는 시간을 줄일 수 있다. 따라서 Data Chunk의 Ordered, Unordered 기능은 Multi-stream과 병행되어 사용되기 때문에 데이터 전송 능력을 향상을 가져 올 수 있다.

SCTP Multi-Homing

 SCTP 는 SCTP Association을 맺고자 하는 endpoint들이 Multiple Ethernet의 각각에 IP가 할당된 Multi homed인 경우에 적용 될 수 있다. SCTP는 SCTP Association 성립되는 Multi-Homed endpoint들에게 하나의 Association에서 각 IP에 해당하는 데이터 전송 경로를 가질 수 있도록 한다. 즉 SCTP는 2개 이상의 사용 가능한 Ethernet 카드에 할당된 IP주소를 처음 SCTP Association Establish을 설정할 때 상호의 IP를 교환하여 각 IP에 해당하는 데이터 전송 경로를 확보하게 된다.

  연결이 성립된 후 SCTP는 데이터 전송을 위한 Primary Path로 여러 개의 경로 중 하나를 선택하여 주 데이터 전송경로로 사용하고 다른 경로들은 Idle 상태로 있게 되어진다. 이 때 SCTP는 Idle 상태에 있는 경로에 대하여 HEART BEAT CHUNK를 이용하여 Idle 경로가 사용이 가능 한지 주기적으로 모니터링을 한다. 만약 Primary Path에 Path Fail이 발생 한 경우 Idle상태에 있는 경로 중 데이터 전송이 가능 한 경로를 하나 선택하여 Primary Path로 바꾸고 데이터 전송을 계속하게 된다. 이 때 SCTP는 Association 이 끊기지 않게 이전 경로에서 새로운 경로로 변환 해주고 이전 경로에 대한 Association 정보를 새로운 경로에 대하여 자동적으로 적용하도록 한다. 이러한 SCTP의 Multi-Homed 기능은 하나의 경로만으로 데이터를 전송하는 경우보다 데이터 전송의 신뢰성을 배가 시킬 수 있는 SCTP의 특징이다.

SCTP API

ULP-to-SCTP

 ULP primitive 아래에서 설명되는 함수들은 SCTP가 내부 프로세스 통신을 지원하기 위하여 수행되어져야 하는 기본적인 함수를 이다.

Primitive	De--scription
Initialize	SCTP가 내부적인 데이터 구조를 초기화 하고 SCTP의 운용환경을 설정하기 위한 필요한 자원을 할당하는데 이용되어진다
Associate	이 primitive는 상위 계층이 특정에 peer endpoint에게 연결을 초기화 하도록 한다.
Shutdown	Graceful close을 통하여 연결을 종료한다
Abort	연결을 을 비정상적으로 종료한다
Send	SCTP을 통해서 사용자 데이타를 전송하기 위한 함수이다.
Set Primary	SCTP에게 패킷 전송을 위한 primary path로써 특정 목적지 주소를 사용할 것을 지시하는 함수이다.
Receive	SCTP에서 ULP에 의해 규정된 버퍼 안의 SCTP in queue 있는 user message를 읽는다.
Status	연결에 대한 상태정보들을 반환한다.
Change Heartbeat	SCTP endpoint가 특정 목적지 전송 주소에 heartbeat을 할지 안 할지를 지시하는 함수
Request Heartbeat	SCTP endpoint가 특정 목적지 전송 주소에 heartbeat을 수행할 것을 지시하는 함수
Get SRTT Report	SCTP에 현재의 SRTT 측정값을 보고하는 함수
Set FailureThreshold	SCTP가 규정된 목적지 주소를 위하여 "Path.Max.Retrans"의 failure detection threshold 도착 성을 최적화 한다.
Destroy SCTPinstance	소멸될 SCTP Instance를 가리킨다.

SCTP-to-ULP

 SCTP가 비 동기적인 ULP 처리 신호를 위한 인터페이스이다. 즉 SCTP연결에 이벤트가 발생하여 ULP에 처리 신호를 보낼 때 사용되는 함수들이다.

Primitive	De--scription
DATA ARRIVE notification	SCTP가 사용자 메시지를 성공적으로 수신하고 Reassembly를 위한 준비가 되었을 때 ULP에 알리는 notification이다.
SEND FAILUREnotification	메시지가 상대 Endpoint에 전달 될 수 없는 것을 SCTP ULP에 알리는 notification 이다.
NETWORK STATUSCHANGE notification	목적지 전송 주소가 비 활동이나 활동으로 표기 되었을 때 ULP에 알리는 notification 이다
COMMUNICATION UPnotification	이 notification은 SCTP가 메시지를 보내거나 받기가 준비 되었을 때나 endpoint에 대한 잃어버린 연결을 복구하기 위하여 ULP에 알리는 notification 이다
COMMUNICATION LOST notification	SCTP가 endpoint에 대한 통신을 완전히 잃었을 경우(e.g., via Heartbeat) 나 상대가 비정상 종료를 진행 중에 있을 때 ULP에 알리는 notification 이다
COMMUNICATION ERROR	SCTP가 peer로부터 ERROR chunk을 받고 이를 ULP에게 통지하기로 결정했을 때 ULP에 알리는 notification 이다
RESTART notification	상대 SCTP endpoint가 재 시작 되었다는 것을 SCTP가 감지 했을 때 ULP에 알리는 notification 이다

활용 분야

전송프로토콜 수준의 보안기능이 요구되는 시스템
    : Application의 수준의 보안 이외에SCTP 위에 TLS를 적용하여 보안 기능을 강화

인증, 권한, 과금정보를 관리하는 인증 시스템 장비
    : Multi-Homing 기능을 활용한 신뢰성 있는 데이터 전송

신뢰성이 요구되는 군 장비 및 위성 통신장비
    : SCTP 데이터 전송의 Unordered 기능 적용 됨
    : 좋지 못한 환경으로 인한 Path Fail이 발생이 쉬운 전쟁에 사용되는 군 장비나 위성통신을 위하여
      Multi-Homing 기능이 활용 됨

Mobile IP 분야
    : Multi-Homing 기능을 이용한 무선 통신 단말기에 적용

미래의 HTTP를 위한 전송 프로토콜로 활용
    : 다중 객체를 송수신해야 하는 HTTP에 전송프로토콜로 SCTP를 사용하여
      데이터 전송의 성능을 향상을 가져옴

결론

 SCTP 는 PSTN 망의 호 처리를 위해 사용되는 신호를 IP네트워크에 전송 하기 위해 사용되는 전송프로토콜이다. 그러나 SCTP는 TCP와 같은 신뢰성 있는 전송을 보장하고 UDP처럼 유연하게 데이터를 전송할 수 있을 뿐만 아니라 DOS나 SYN Flooding 공격에 안전한 전송 프로토콜이기 때문에 많은 Appliation 개발자들이 선호할 것으로 보여진다. 이러한 SCTP의 특징은 특정 기능을 요구하는 장비에 활용될 수 있기 때문에 그 가치는 더욱 높다. 특히 Multi-Stream 기능과 Multi-Homed 기능은 성능을 요구하는 Mobile 분야나 안전성 및 보안을 요구하는 군 통신 장비에 널리 사용될 수 있을 것으로 보인다. SCTP의 장점을 활용하기 위한 연구는 2000년 10월 표준 전송프로토콜로 제안된 이후 지금까지 여러 분야에서 연구가 활발히 진행 되고 있는데 Mobile 분야와 군사 및 위성장비 분야, 그리고 SCTP를 사용한 보안인증 분야 등에서 활발한 연구가 진행되고 있다. 또한 다른 한편에서는 IP기반의 네트워크 장비에 탑재하기 위한 리눅스 커널과, BSD 시스템에서의 동작하는 개발이 진행 되고 있다. 지금까지 SCTP에 대한 연구는 각 분야에서 학계, 산업계, 그리고 표준단체가 협력 관계를 유지하며 많은 연구가 진행 되어 온것이 사실이다. 그러나 아직은 IP Network 상에서 SCTP가 산업계에 적용할 수 있을 정도로 안정화되거나 검증되지 않았기 때문에 SCTP의 활용가치는 폭넓고 미래 지향적이기는 하나 보편적인 사용을 위해서는 더욱 많은 연구와 검즘이 요구되고 있는 것이 사실이다. 특히 성능과 안전성이 요구되는 네트워크 관리 분야에서도 SCTP를 활용한다면 현존하는 시스템보다 훨씬 진보된 망 관리 시스템 구성되어질 것으로 보인다.

참고자료

Reference null

RFC2960 : Stream Control Transmission protocol
RFC3257 : Stream Control Transmission Protocol Applicability Statement
RFC 2719 : Architectural Framework for Signaling Transport
draft-riegel-tuexen-mobile-sctp-00.txt
   : A Study of SCTP Services in a Mobile-IP Network
atiq-sctp-congestion-4
   : SCTP Multi-Stream capable within Mobile IP
http://www.oscer.ou.edu/Symposium2002/atiq_sctp_supercomputing1.pdf
http://rivus.sourceforge.net/RivuS.ppt
http://oss.software.ibm.com/linux/presentations/lwce2002/Chats/SCTP/SCTP- LWE.pdf

Tahoe

정해진 N개의 Duplicated ACK가 발생할 경우 Retransmit Timer와는 상관없이 바로 해당 Segment를 전송하고 Slow-Start를 시작한다.

Reno

N개의 Duplicated ACK가 발생할 경우 바로 해당 Segment를 전송하고 Congestion Window사이즈를 반으로 줄여 Fast Recovery Mode로 Congestion Avoidance를 수행한다. 그러나 패킷손실이 많은경우 Congestion Window가 줄어들고 다시 줄어들고 이러한 과정을 반복하다 TCP Timeout에 이르러 Slow-Start로 시작하는 단점을 지니고 있다.

New-Reno

Reno의 단점을 해결하기 위해 제안되었고, Fast Recovery Mode로 진입하는 것은 같으나 Full ACK가 왔을 때까지 기다린 다음 Fast Recovery Mode를 종료하는 차이를 보이고 있다. 이는 많은 패킷손실이 있다고 하더라도 Fast Recovery Mode상에서 Congestion Window사이즈를 조절하며 재전송을 수행한다. 그러나 많은 수의 패킷손실이 발생할 경우 많은 수의 RTT가 발생하는 단점을 지니고 있다.

SACK

PIPE를 통해 패킷의 전송을 계산하고, SACK옵션을 통해 재전송할 패킷만을 선택적으로 전송할 수 있는 장점을 지니고 있다. 여러 개의 패킷손실이 발생할 경우 New-Reno와 달리 하나의 RTT안에서 패킷을 재전송할 수 있는 장점을 지니고 있다.


[One packet drop]

Tahoe버전은 Packet Drop이 일어난 경우 재빨리 패킷을 재전송하고 Slow Start모드로 들어가 Congestion window를 0부터 1씩 증가시킨다. 반면 Reno, New Reno, SACK의 경우 Fast Recovery Algorithm을 사용하여 Drop이 일어난 패킷을 재전송하고 Congestion Window의 크기를 반으로 줄이고 Congestion Avoidance모드로 패킷을 전송한다. Tahoe버전을 제외한 다른버전은 좋은 성능을 보인다.

[Two Packets Drop]
Tahoe버전은 One Packet Drop과 같은 현상이 나타나고, Reno버전은 처음의 Duplicated ACK를 받았을 때 Congestion Window를 반으로 줄이고 다음의 Duplicated ACK를 받았을 때 다시 Congestion Window를 반으로 줄여 Congestion Window가 1/4로 줄어들어 느린 전송속도를 보인다. 그러나 New-Reno버전은 처음의 Duplicated ACK를 받았을 때 Fast Recovery Mode로 전환하여 Congestion Window의 크기를 반에서 늘리기 시작한다. 이때 또다른 Duplicated ACK를 받았다 하여도 상관없이 Congestion window를 늘여가기 시작한다. Sack TCP의 경우 전송한 Packet수와 Duplicated ACK의 받은 수를 비교하는 계산을 하여 PIPE를 계산해 전송량을 조절한다. Reno버전이 가장 낮은 성능을 보이고 Tahoe버전이 그 다음 New-Reno와 SACK버전은 좋은 성능을 보인다.

[Three Packets Drop]

Tahoe버전은 앞에설명한 과정을 그대로 수행하고, Reno버전은 2개의 패킷 손실을 보인 것과 같지만 세번째의 Duplicated ACK를 받을 때 uwnd바로 전송하지 못하는 상황이 벌어지고 이에 따라서 보내지 못하기 때문에 Timeout이 일어나게 된다. 이렇게 되면 Slow-Start로 Timeout이 끝나고 나서 진행하게 된다. New-Reno와 SACK의 경우 두개의 패킷을 잃어버렸을때와 동일한 과정으로 성능을 유지한다. Reno< Tahoe<New-Reno,SACK의 순서로 성능의 차이를 보인다.

[Four Packets Drop]

Tahoe버전과 Reno버전은 3개의 패킷을 잃어버렸을 때 나타나는 결과와 마찬가지의 결과를 보이고, New-Reno의 경우 Fast Recovery Mode에서의 RTT계산을 통하여 성능을 유지시키려 노력한다. SACK의 경우 PIPE계산을 통하여 성능을 유지시킨다. Reno < Tahoe < New-Reno < SACK 의 순서로 성능의 차이를 보인다.

ref. "Kevin Fall ,Sally Floyd",
"Simulation-based Comparisons of Tahoe, Rent, and SACK TCP",
작성 : 조준식 (2006.04.18)

2000년 10월 IETF는 RFC2960을 통해 SCTP(Stream Control Transmission Protocol)를 TCP(Transmission Control Protocol), UDP(User Datagram Protocol)에 이은 제3의 수송계층 프로토콜 표준으로 제정하였다. SCTP 등장배경은 다소 필연적이다. 90년대 후반에 접어들면서 기존 TCP, UDP를 통해서는 갈수록 광대역화 및 멀티미디어화로 발전하는 인터넷 응용 요구사항을 적절히 수용할 수 없었기 때문이다. SCTP가 IETF 표준으로 제정된 지 3년이 지나는 현 시점에서 제기되는 의문은, “과연 SCTP가 TCP/UDP를 대체할 것인가? 아니면 상호 공존하며 발전할 것인가?” 및 “SCTP의 Killer 응용은 무엇인가?” 등이 있다.



SCTP vs. TCP/UDP

SCTP 표준개발은 1997년 IETF SIGTRAN(Signaling Transport) WG에서 시작되었으며, IP 망에서 VoIP(Voice over IP) 시그널링 트래픽 전송을 위한 프로토콜 개발이 주요 목적이었다. 이를 위해 시그널링 게이트웨이간에 실시간으로 수 많은 사용자의 다양한 호처리 정보를 신뢰적으로 전송하고 또한 망 장애에 대비하여 신속한 복구기능이 제공되는 SCTP 프로토콜을 개발하였다. 초기에 SCTP는 UDP 위에 탑재될 예정이었으나, IESG(Internet Engineering Steering Group)의 강력한 권고에 따라 IP 위에서 동작하는 수송계층 프로토콜로써 제정되었으며, 이로써 VoIP 시그널링 뿐만 아니라 다양한 응용에서도 SCTP를 사용할 수 있게 되었다.

SCTP는 UDP의 메시지지향(message-oriented) 특성과 TCP의 연결지향(connection-oriented) 및 신뢰전송 특성을 모두 포함하는 등 TCP와 UDP의 장점을 살리도록 설계되었다. SCTP는 TCP의 연결지향성 및 신뢰전송 기능을 제공하지만, TCP와는 달리 4-way 연결설정 및 3-way 연결종료 등의 기능을 제공한다.

특히 SCTP는 멀티스트리밍(multi-streaming) 및 멀티호밍(multi-homing) 특성을 제공한다. Multi-streaming 특성을 통해 하나의 세션에서 다양한 종류의 컨텐츠를 식별 및 전달할 수 있으며, 바이트(byte) 기반 전송방식인 TCP의 HOL(Head-of-Line) blocking 문제를 해결하고 있다. 한편, Multi-homing 특성을 통해 단말은 두 개 이상의 IP 주소를 한 세션에서 사용할 수 있으며, 이를 통해 경로 장애에 대한 복구(fail-over) 기능을 제공한다. 또한 멀티호밍 특성은 SCTP 이동단말에 대한 핸드오버 기능을 제공할 수 있다. SCTP는 IP 패킷에 표시되는 프로토콜 식별번호(Protocol ID)로써 UDP(6), TDP(17)처럼 132번을 할당 받았다.



<표1> TCP/UDP와 SCTP 비교

SCTP 표준화 및 개발 현황

SCTP 기본규격은 2000년 10월에 SIGTRAN WG에서 RFC2960으로 표준화 되었으며, 이후 RFC 3257, 3286, 3436 등의 추가 규격이 제정되었다. 현재 후속 표준개발 작업은 IETF TSV(Transport Area) WG에서 이루어지고 있다. 현재 진행 중인 WG 문서는 “SCTP Socket API”, “구현지침서”, “PR-SCTP(Partially Reliable SCTP), “ADD-IP(Dynamic Address Configuration)” 등이 있다. 최근 IETF에서는 PR-SCTP(draft-ietf-tsvwg-prsctp-02.txt) 표준화 작업이 한창 진행 중이다. PR-SCTP는 SCTP 데이터 전송 도중에 “time-critical” 스트림에 대해서는 오류복구과정을 생략하고 곧 바로 응용계층에 전달될 수 있는 기능을 정의한다. 수신자는 PR-SCTP 신호를 받았을 경우, 버퍼에 있는 해당 데이터를 곧 바로 상위 응용에 전달한다.

SCTP 표준화 작업과 함께 전 세계적으로 실제 구현작업도 활발히 진행되고 있다. 먼저 지난 2003년 12월에 출시된 리눅스 커널 2.6.0 버전부터 SCTP 프로토콜 기능이 탑재되었으며, 관련 시험도구(tool set)도 개발되었다(http://sourceforge.net/projects/lksctp). 한편 독일을 중심으로 사용자레벨(user-space) 구현코드인 “sctplib” (http://www.sctp.de/sctp.html) 개발작업이 진행 중에 있으며, SCTP 시뮬레이션을 위한 ns-2 모듈(http://pel.cis.udel.edu/#downloads)도 출시되었다.



SCTP 확장: mSCTP

그 동안 SCTP 개발작업은 주로 SCTP의 멀티스트리밍 특성을 활용하는 방향으로 진행되어 왔다. 즉, VoIP 시그널링 게이트웨이간에 혹은 AAA 서버간에 SCTP 세션을 설정하고, 이를 통해 수 많은 사용자의 호처리 신호정보를 전달하는 용도로 SCTP가 사용되고 있다.

최근에 들어서는 SCTP 멀티호밍 특성에 대한 연구개발이 한창 진행 중에 있다. 특히 세션도중에 새로운 IP 주소를 추가할 수 있는 ADD-IP(draft-ietf-tsvwg-addip-sctp-08.txt)에 대한 표준화가 진행 중에 있으며, 이에 대한 주요 활용 분야로써 “mobile SCTP(mSCTP) 핸드오버” 기술이 주목을 받고 있다. mSCTP에서는 SCTP 멀티호밍 특성과 ADD-IP 기능을 활용하여, SCTP 단말이 세션 도중에 이동함으로써 IP 주소가 변경되더라도 네트웍의 도움 없이 세션의 연속성을 제공하는 기술이다. 관련 연구개발은 Siemens 및 시스코 등을 중심으로 진행 중에 있으며, 한국에서도 활발히 관련 연구에 참여하고 있다(draft-sjkoh-sctp-mobility-03.txt, draft-sjkoh-mobile-sctp-mobileip-03.txt).



결론 및 향후 전망

SCTP 는 IETF에서 차세대 수송계층 프로토콜 표준으로 제정되었으며, 현재 관련 표준화 및 개발작업이 한창이다. 향후 SCTP는 TCP, UDP를 대체하기보다는 서로 공존하면서, 각각의 특성에 부합하는 응용 및 서비스에 활용될 것으로 전망된다. 아직은 보급 초기단계이지만, TCP/UDP처럼 향후 지속적인 기술 보완을 통해 점차 실제 인터넷 응용에 널리 적용될 것이다.

현재의 SCTP 적용은 주로 시그널링 게이트웨이간 데이터 전송에 국한되고 있으나, 향후에는 멀티미디어 신뢰전송을 요구하는 신규 응용 서비스가 killer 응용으로 떠오를 가능성이 크다. 또한 mSCTP 핸드오버 등의 이동성 기능을 활용하는 이동통신단말기의 보급도 기대할 만하다. 특히, SCTP 관련 분야는 세계적으로 아직 개발 초기단계에 해당하므로, 이동통신 단말기 제조업체 및 서비스사업자들이 눈 여겨볼만한 기술이라 하겠다.

 

고석주 ( 한국전자통신연구원 표준연구센터 선임연구원, sjkoh@etri.re.kr)

The Defense Advance Research Projects Agency (DARPA) originally developed Transmission Control Protocol/Internet Protocol (TCP/IP) to interconnect various defense department computer networks. The Internet, an international Wide Area Network, uses TCP/IP to connect government and educational institutions across the world. TCP/IP is also in widespread use on commercial and private networks. The TCP/IP suite includes the following protocols

Data Link Layer
ARP/RARP	Address Resolution Protocol/Reverse Address
DCAP	Data Link Switching Client Access Protocol
Network Layer
DHCP	Dynamic Host Configuration Protocol
DVMRP	Distance Vector Multicast Routing Protocol
ICMP/ICMPv6	Internet Control Message Protocol
IGMP	Internet Group Management Protocol
IP	Internet Protocol version 4
IPv6	Internet Protocol version 6
MARS	Multicast Address Resolution Server
PIM	Protocol Independent Multicast-Sparse Mode (PIM-SM)
RIP2	Routing Information Protocol
RIPng for IPv6	Routing Information Protocol for IPv6
RSVP	Resource ReSerVation setup Protocol
VRRP	Virtual Router Redundancy Protocol
Transport Layer
ISTP
Mobile IP	Mobile IP Protocol
RUDP	Reliable UDP
TALI	Transport Adapter Layer Interface
TCP	Transmission Control Protocol
UDP	User Datagram Protocol
Van Jacobson	compressed TCP
XOT	X.25 over TCP
Session Layer
BGMP	Border Gateway Multicast Protocol
Diameter
DIS	Distributed Interactive Simulation
DNS	Domain Name Service
ISAKMP/IKE	Internet Security Association and Key Management Protocol and Internet Key Exchange Protocol
iSCSI	Small Computer Systems Interface
LDAP	Lightweight Directory Access Protocol
MZAP	Multicast-Scope Zone Announcement Protocol
NetBIOS/IP	NetBIOS/IP for TCP/IP Environment
Application Layer
COPS	Common Open Policy Service
FANP	Flow Attribute Notification Protocol
Finger	User Information Protocol
FTP	File Transfer Protocol
HTTP	Hypertext Transfer Protocol
IMAP4	Internet Message Access Protocol rev 4
IMPPpre/IMPPmes	Instant Messaging and Presence Protocols
IPDC	IP Device Control
IRC	·Internet Relay Chat Protocol
ISAKMP	Internet Message Access Protocol version 4rev1
ISP
NTP	Network Time Protocol
POP3	Post Office Protocol version 3
Radius	Remote Authentication Dial In User Service
RLOGIN	Remote Login
RTSP	Real-time Streaming Protocol
SCTP	Stream Control Transmision Protocol