RUDP : Reliable User Datagram Protocol (Reliable UDP)
IETF상에서 아직(2007-04 현재) 정식으로 등록되지 못한 MEMO등급의 문서이다.
http://www.ietf.org/proceedings/99mar/I-D/draft-ietf-sigtran-reliable-udp-00.txt
DRAFT로 등록되어 있으며 초기 문서인 00 버전이 ietf사이트에 등록되어있다.
현재까지 지속적으로 업데이트 되고 있으므로, 이를 구현하였을 경우 벤더가 다르면
서로 호환되지 못할 수도 있으므로, 만약 RUDP를 구현하여 어떤 장비나 기나 endpoint와
통신할 경우는 이 점에 대하여 인지하고 대처하여야 한다.
본 문서는 RFC908(v1), RFC1151(v2) RDP(Reliable Datagram Protocol)에서 보강된 프로토콜이다.
아래의 내용은 드레프트를 대충, 그냥.. 간단하게 생략 번역한 것이다.
이해가 모자란 부분은 원문을 참조하기 바란다.
본 드레프트 문서는 다음과 같은 목차를 가지고 있다.
1. 소개
1.1 시스템 오버뷰
1.2 백그라운드
1.3 데이터 구조
1.4 특징
2. 추 후의 잠재성
3. 참고
4. 저자 주소
1. 소개
본 드래프트 문서는 데이터를 전송하는 간단한 시퀀스 베이스 프로콜(즉, UDP)을 이용하는 어플리케이션에 신뢰성을 부여하는 것에 대하여 논한다. RUDP는 RFC908 및 RFC1151 - Reliable Data Protocol을 기초로 작성되었다. 또한 RUDP는 UDP/IP레이어 위에 설계되었다.
1.1 시스템 오버뷰
목차에는 있던데, 원문에는 없다.. -_-;;;
1.2 백그라운드
IP 네트워크상에서 텔레포니 시그널을 전송하기 위해서는 신뢰성있는 전송 프로토콜이 필요하다. 이 신뢰성있는 전송 프로토콜은 다양한 어플리케이션의 아키텍처를 지원할 수 있어야 한다. 현존하는 전송 프로토콜을 면밀히 조사해본 결과 텔레커뮤니케이션 시그날링을 위한 새로운 신뢰성있는 메카니즘이 필요하게 되었다. 이 새로운 프로토콜은 다음과 같은 기준을 반드시 포함해야 한다.
* 전송계층은 최대크기의 데이터 의 신뢰성 있는 전송을 지원해야만 한다.
* 전송계층은 순차전송을 보장해야 한다.
* 전송계층은 메시지 베이스여야 한다.
* 전송계층은 플로우 컨트롤 메카니즘을 지원해야한다.
* 전송계층은 적은 오버헤드에, 최고의 퍼포먼스를 내야한다.
* 개별적인 가상 연결을 핸들링 할 수 있어야 한다.
* 킵 얼라이브 메카니즘을 지원해야 한다.
* 에러 디텍션을 지원해야 한다.
* 암호화된 전송을 지원해야 한다.
RUDP는 이러한 것들을 지원하기 위하여 디자인 되었다.
1.3 데이터 구조
1.3.1 데이터 전송을 위한 최소 헤더 six octet
UDP처럼 전송되는 RUDP는 앞단에 여섯개의 옥텟헤더로 시작해야한다. 첫번째는 시리즈로 구성된 싱글비트 플래그 7개와 리절브 비트 한개, 다음 3개는 한 바이트로 구성된 넘들.. 헤더길이, 시퀀스번호, 엑크넘버이다. 이 뒤에는 2옥텟(바이트)으로 이루어진 첵크섬이 따라 붙는다.
0 1 2 3 4 5 6 7 8 15
+-+-+-+-+-+-+-+-+---------------+
|S|A|E|R|N|C|T| | Header |
|Y|C|A|S|U|H|C|0| Length |
|N|K|K|T|L|K|S| | |
+-+-+-+-+-+-+-+-+---------------+
| Sequence # + Ack Number |
+---------------+---------------+
| Checksum |
+---------------+---------------+
Figure 1, RUDP Header
Control bits
컨트롤 비트는 이 패킷이 머하는 넘인지를 구분시켜준다. SYN 비트는 동기화를 위한 세그먼트의 존재를 알린다. ACK는 헤더가 유효한지를 알려주고, EAK는 ACK의 확장 비트이고, RST는 세션을 리셋시키는 넘이다. NUL은 null 세그먼트라는데???, TCS는 상내를 알려준다. CHK는 0과 1로 되는데 0일 경우는 첵크섬이 헤더만 계산한 것이고, CHK가 1이면 헤더와 데이터영역을 모두 계산한 것이다. 요런 저런 컨트롤에 필요한 세그먼트를 몇가지 모아 놓은 것이데... 이런걸 flow control을 위한 control bit라고 하고.. 이런게 있으면 플로우 컨트롤을 지원한다 라고 말할 수 있다.
Header length
사용자 데이터를 포함하지 않은 헤더만의 크기를 나타낸다. 덩어리 패킷을 받았을 때, 시작부터
이 길이만큼을 제거하면 사용자 데이터의 시작이다. EACK, NUL, RST 비트가 셑 되어있으면 사용자 데이터 영역이 따라올 수 없다. 유저 데이터가 포함될 때는 항상 ACK 플래그가 셑 되어있다.
Sequence number
모든 패킷은 시퀀스 넘버를 가져야한다. 커넥션이 처음으로 열릴 때 초기화 시킨 랜덤넘버를 채운다. 이 번호는 커넥션이 열릴 때 SYN 플래그를 탑재한 패킷에 넣는다. 데이터를 전송할 때 마다
시퀀스 넘버를 증가 시킨다.
Acknowledgment Number
엑크넘버는 전송단위를 구분하는 구분자로 받는 측에서 마지막 받은 시퀀스 넘버를 이용한다.
Checksum
첵크섬은 모든 RUDP헤더에 계산되어 포함된다. CHK 비트의 값에 따라 전체 혹은 헤더만 계산하여 넣는다. 여기서 사용되는건 UDP나 TCP에서 사용하는 16-bit one's complement of the one's complement sum 방식을 사용한다.
to be continue...
IETF상에서 아직(2007-04 현재) 정식으로 등록되지 못한 MEMO등급의 문서이다.
http://www.ietf.org/proceedings/99mar/I-D/draft-ietf-sigtran-reliable-udp-00.txt
DRAFT로 등록되어 있으며 초기 문서인 00 버전이 ietf사이트에 등록되어있다.
현재까지 지속적으로 업데이트 되고 있으므로, 이를 구현하였을 경우 벤더가 다르면
서로 호환되지 못할 수도 있으므로, 만약 RUDP를 구현하여 어떤 장비나 기나 endpoint와
통신할 경우는 이 점에 대하여 인지하고 대처하여야 한다.
본 문서는 RFC908(v1), RFC1151(v2) RDP(Reliable Datagram Protocol)에서 보강된 프로토콜이다.
아래의 내용은 드레프트를 대충, 그냥.. 간단하게 생략 번역한 것이다.
이해가 모자란 부분은 원문을 참조하기 바란다.
본 드레프트 문서는 다음과 같은 목차를 가지고 있다.
1. 소개
1.1 시스템 오버뷰
1.2 백그라운드
1.3 데이터 구조
1.4 특징
2. 추 후의 잠재성
3. 참고
4. 저자 주소
1. 소개
본 드래프트 문서는 데이터를 전송하는 간단한 시퀀스 베이스 프로콜(즉, UDP)을 이용하는 어플리케이션에 신뢰성을 부여하는 것에 대하여 논한다. RUDP는 RFC908 및 RFC1151 - Reliable Data Protocol을 기초로 작성되었다. 또한 RUDP는 UDP/IP레이어 위에 설계되었다.
1.1 시스템 오버뷰
목차에는 있던데, 원문에는 없다.. -_-;;;
1.2 백그라운드
IP 네트워크상에서 텔레포니 시그널을 전송하기 위해서는 신뢰성있는 전송 프로토콜이 필요하다. 이 신뢰성있는 전송 프로토콜은 다양한 어플리케이션의 아키텍처를 지원할 수 있어야 한다. 현존하는 전송 프로토콜을 면밀히 조사해본 결과 텔레커뮤니케이션 시그날링을 위한 새로운 신뢰성있는 메카니즘이 필요하게 되었다. 이 새로운 프로토콜은 다음과 같은 기준을 반드시 포함해야 한다.
* 전송계층은 최대크기의 데이터 의 신뢰성 있는 전송을 지원해야만 한다.
* 전송계층은 순차전송을 보장해야 한다.
* 전송계층은 메시지 베이스여야 한다.
* 전송계층은 플로우 컨트롤 메카니즘을 지원해야한다.
* 전송계층은 적은 오버헤드에, 최고의 퍼포먼스를 내야한다.
* 개별적인 가상 연결을 핸들링 할 수 있어야 한다.
* 킵 얼라이브 메카니즘을 지원해야 한다.
* 에러 디텍션을 지원해야 한다.
* 암호화된 전송을 지원해야 한다.
RUDP는 이러한 것들을 지원하기 위하여 디자인 되었다.
1.3 데이터 구조
1.3.1 데이터 전송을 위한 최소 헤더 six octet
UDP처럼 전송되는 RUDP는 앞단에 여섯개의 옥텟헤더로 시작해야한다. 첫번째는 시리즈로 구성된 싱글비트 플래그 7개와 리절브 비트 한개, 다음 3개는 한 바이트로 구성된 넘들.. 헤더길이, 시퀀스번호, 엑크넘버이다. 이 뒤에는 2옥텟(바이트)으로 이루어진 첵크섬이 따라 붙는다.
0 1 2 3 4 5 6 7 8 15
+-+-+-+-+-+-+-+-+---------------+
|S|A|E|R|N|C|T| | Header |
|Y|C|A|S|U|H|C|0| Length |
|N|K|K|T|L|K|S| | |
+-+-+-+-+-+-+-+-+---------------+
| Sequence # + Ack Number |
+---------------+---------------+
| Checksum |
+---------------+---------------+
Figure 1, RUDP Header
Control bits
컨트롤 비트는 이 패킷이 머하는 넘인지를 구분시켜준다. SYN 비트는 동기화를 위한 세그먼트의 존재를 알린다. ACK는 헤더가 유효한지를 알려주고, EAK는 ACK의 확장 비트이고, RST는 세션을 리셋시키는 넘이다. NUL은 null 세그먼트라는데???, TCS는 상내를 알려준다. CHK는 0과 1로 되는데 0일 경우는 첵크섬이 헤더만 계산한 것이고, CHK가 1이면 헤더와 데이터영역을 모두 계산한 것이다. 요런 저런 컨트롤에 필요한 세그먼트를 몇가지 모아 놓은 것이데... 이런걸 flow control을 위한 control bit라고 하고.. 이런게 있으면 플로우 컨트롤을 지원한다 라고 말할 수 있다.
Header length
사용자 데이터를 포함하지 않은 헤더만의 크기를 나타낸다. 덩어리 패킷을 받았을 때, 시작부터
이 길이만큼을 제거하면 사용자 데이터의 시작이다. EACK, NUL, RST 비트가 셑 되어있으면 사용자 데이터 영역이 따라올 수 없다. 유저 데이터가 포함될 때는 항상 ACK 플래그가 셑 되어있다.
Sequence number
모든 패킷은 시퀀스 넘버를 가져야한다. 커넥션이 처음으로 열릴 때 초기화 시킨 랜덤넘버를 채운다. 이 번호는 커넥션이 열릴 때 SYN 플래그를 탑재한 패킷에 넣는다. 데이터를 전송할 때 마다
시퀀스 넘버를 증가 시킨다.
Acknowledgment Number
엑크넘버는 전송단위를 구분하는 구분자로 받는 측에서 마지막 받은 시퀀스 넘버를 이용한다.
Checksum
첵크섬은 모든 RUDP헤더에 계산되어 포함된다. CHK 비트의 값에 따라 전체 혹은 헤더만 계산하여 넣는다. 여기서 사용되는건 UDP나 TCP에서 사용하는 16-bit one's complement of the one's complement sum 방식을 사용한다.
to be continue...