'Network/Netowrk_network'에 해당되는 글 7건

  1. 2009.01.18 ENUM
  2. 2009.01.18 실시간 통신 시스템 위한 VoIP 표준 프로토콜 H.323과 ..
  3. 2009.01.18 IPv4 Header
  4. 2009.01.18 VoIP 관련 표준 문서
  5. 2009.01.18 IP헤더
  6. 2009.01.18 IP Header 와 IP 서비스의 특징
  7. 2009.01.18 IP (Internet Protocol)

ENUM

|
출처 카페 > softswitch | rndsys
원문 http://cafe.naver.com/softswitch/59
 
전화와 인터넷

 

인터넷 이전에 지난 한 세기를 지배한 통신의 기본은 전화였습니다. 사람들은 웹브라우저에서 세상을 보고, 이메일과 메신저로 24시간 잠들지 않는 세상을 경험하고 있지만, 전화 또한 여전히 중요한 통신수단중 하나 입니다.

 

전화망(PSTN: Public Switched Telephone Network)은 오랜세월동안 전세계에 충분히 구축 되었고, 다양한 시행착오를 거쳐 현재 안정적으로 운영되고 있습니다.  전화는 일반 대중에게는 가장 친숙하고 매우 신뢰성이 높은 통신매체라고 할 수 있습니다.

 

인터넷의 경우는 어떨까요? 전세계적으로 대중에 알려지기 시작하며 급속도로 망이 구축된것이 90년대 후반이므로 아직 20년도 안된 역사를 가지고 있습니다. 초창기에 비하면 지금은 인터넷망의 안정성도 매우 높아졌지만, 태생자체가 인터넷은 안정성보다 생존성에 그리고 폐쇄성보다는 개방성에 촛점이 맞춰 있기 때문에 기존 전화망과 직접접인 비교는 어려울 것 같습니다.

 

인터넷전화(VoIP:Voice over IP)는 기존 전화망의 신뢰성보다는 인터넷망의 개방성에 더 촛점을 맞춘 전화서비스라고 볼 수 있습니다. 예전에는 통화품질 면에서는 전화망이 월등히 좋았으나, 기술의 발전은 이 격차마저 줄여가고 있습니다. 

 

인터넷전화는 폐쇄된 PSTN 대신 공개된 인터넷망을 이용할 뿐입니다. 전화가입자는 인터넷만 되는곳이면 어디서나 전화를 이용할 수 있어 사실상 지역구분(시내,시외,국제)도 사라지는 개념이고 사업자는 고가의 장비가 없어도 전화서비스가 가능해 요금도 저렴한 장점이 있습니다. 

 

결국 90년대 후반 국내에도 무료 인터넷전화(VoIP) '다이얼패드'가 최초로 등장해 많은 파란을 일으켰습니다. PC에서 헤드셋을 갖추고 통화를 해야하므로, 일반전화보다는 불편하고 통화품질도 다소 열악했지만, 사실상 무료통화를 제공함으로서 사람들의 관심을 집중시킬 수 있었습니다.

 

다만 서비스사 내부사정으로 서비스가 오래가진 못했지만, 이 일을 계기로 이용자와 통신사업자 모두는 기존 전화망 위주의 통신서비스 구도가, 인터넷망 중심으로 재편될 것이라는 것을 인지할 수 있었습니다.

 

하지만 수년의 시간이 흘렀지만 지금도 크게 달라진것은 없어보입니다.  그 사이 관련 기술의 발전은 계속되 왔지만 제도적으론 기존 전화사업자의 수익 악화에 따른 대응책 마련이 쉽지 않기 때문입니다.

 

이놈?~ 이넘(ENUM)!!

 

이와같이 90년대 후반 우리나라뿐 아니라 세계적으로도 전화가 인터넷의 영역으로 넘어오기 시작하면서, 사람들은 인터넷주소와 전화번호와의 연결 가능성에 대해 생각해 보기 시작했습니다.

 

그러던중 2001년경, 인터넷기술표준을 제정하는 IETF(Internet Engineering Task Force)ENUM WG(Working Group)생기고, 전화번호 표준을 담당하는 ITU와도 협력해 본격적으로 ENUM 기술표준을 제정하기 시작합니다. 

 

개념은 간단합니다. 누군가의 전화번호 하나만 알면 다양한 응용프로그램을 통해 그 사람의 홈페이지에 접속하고, 인터넷전화도 걸고, 이메일 및 팩스도 보낼수 있게 하자는 것입니다.  예를 들어 ENUM번호가 있다면 명함을 만들때, 사무실 전화번호, 개인 핸드폰 번호, 메일주소, 홈페이지주소 등 온갖 정보를 다 넣지 않아도 ENUM번호 하나만 적어주면 됩니다. 명함을 받은 사람은 PC나 ENUM이 지원되는 휴대용기기 등에서 ENUM번호를 이용해 필요한 서비스를 선택할 수 있습니다.





단순히 생각하면 통신사업자가 개별적으로 제공하는 원넘버 서비스와 다를게 없이 보이지만, ENUM은 인터넷 기반기술인 DNS(Domain Name System)를 이용하고, 전세계 전화번호 표준인 ITU의 'E.164 권고안'을 따름으로서 최종적으론 전화망과 인터넷망의 융합(Convergence)을 가능케하는 전세계 공통표준 이라는 점에서 다릅니다. 즉, ENUM의 본질은 전화망과 인터넷망 사이에서 의사소통을 위한 "동시통역사"의 역할이라고 볼 수 있습니다. (예: 전화번호를 --> 인터넷식별자로 바꿔줌)

 

ENUM과 DNS(Domain Name System)

 

기술적으로 ENUM을 이해하기 위해서는 먼저 DNS를 이해해야 합니다. DNS서버는 도메인네임(예:www.naver.com)을 그에 대응하는 IP주소로(예:222.122.84.250) 변환시켜 주는 역할을 하는 인터넷 사용에 있어 매우 중요한 서버로, 이와 같은 정보는 어느 한 서버에 있는것이 아니라, 아래 그림과 같이 '루트(근원)' 부터 시작하여 국가별, 회사별로 체계에 따라 여러 관련 서버에 분산되어 있습니다. 따라서 특정 정보를 찾기 위해서는 상위의 루트부터 시작하여 점점 하위단계로 내려가면서 여러번의 검색을 수행해야 최종정보에 접근할 수 있습니다.

<그림 출처: 한국인터넷진흥원, 도메인네임시스템은 계층적인 tree구조를 가진다.>

 

*DNS관련 참고자료

 - Powered by DNS : http://www.kr.freebsd.org/doc/PoweredByDNS/  

 - 위키피디아 자료(영문) : http://en.wikipedia.org/wiki/Domain_name_system

 - 한국인터넷진흥원 : http://domain.nic.or.kr/infomation/class.jsp

 

ENUM에서는 DNS서버에 도메인과 IP주소 대신 전화번호와 그에 대응하는 홈페이지주소, 메일주소, 팩스번호등을 인터넷식별자(URI: Uniform Resource Identifier) 형태로 저장하여 사용합니다. 

 

그리고, 전세계 통용이 가능하게 하기위해, ENUM전용 도메인을 생성하여 사용하고 있습니다. 아래 그림과 같이 "e164.arpa" 라는 도메인을 루트도메인 아래 생성하여, 전세계의 모든 전화번호를 이 도메인 아래서 표현이 가능하게 했습니다.



ENUM의 또 다른 활용

 

지금까지 설명한 ENUM은 '이용자 ENUM'이라고 하여 초기 시작부터 최근까지의 개념이었고, 최근에는 '사업자 ENUM'이라는 개념으로 발전해 제2의 도약기를 맞이하고 있습니다.

 

사실, ENUM의 기본 개념이었던 '이용자 ENUM'은 표준이 제정되고 상당한 시일이 경과했으나, 개인 프라이버시 문제 등으로 전세계적으로 답보상태에 있습니다. 2006년 10월 현재 전세계적으로 다음의 6개 국가만이 '이용자 ENUM' 상용서비스를 운영하고 있으며, 대부분 등록건수는 미미한것으로 알려져 있습니다.

 

오스트리아(+43)

폴란드(+48)

루마니아(+40)

독일(+49)

네델란드(+31)

핀란드(+358)

 

'사업자ENUM(Infrastructure ENUM)'은 인터넷전화 사업자가 인터넷전화 호 소통을 목적으로 ENUM을 활용하는 방안입니다. 아래의 개념도는 한국인터넷진흥원의 http://www.enum.or.kr 사이트에서 발췌한 것으로 ENUM이 지금까지 설명한 내용과는 전혀 다른목적으로 사용되고 있다는 것을 알수 있습니다.

 
전화와 인터넷

 

인터넷 이전에 지난 한 세기를 지배한 통신의 기본은 전화였습니다. 사람들은 웹브라우저에서 세상을 보고, 이메일과 메신저로 24시간 잠들지 않는 세상을 경험하고 있지만, 전화 또한 여전히 중요한 통신수단중 하나 입니다.

 

전화망(PSTN: Public Switched Telephone Network)은 오랜세월동안 전세계에 충분히 구축 되었고, 다양한 시행착오를 거쳐 현재 안정적으로 운영되고 있습니다.  전화는 일반 대중에게는 가장 친숙하고 매우 신뢰성이 높은 통신매체라고 할 수 있습니다.

 

인터넷의 경우는 어떨까요? 전세계적으로 대중에 알려지기 시작하며 급속도로 망이 구축된것이 90년대 후반이므로 아직 20년도 안된 역사를 가지고 있습니다. 초창기에 비하면 지금은 인터넷망의 안정성도 매우 높아졌지만, 태생자체가 인터넷은 안정성보다 생존성에 그리고 폐쇄성보다는 개방성에 촛점이 맞춰 있기 때문에 기존 전화망과 직접접인 비교는 어려울 것 같습니다.

 

인터넷전화(VoIP:Voice over IP)는 기존 전화망의 신뢰성보다는 인터넷망의 개방성에 더 촛점을 맞춘 전화서비스라고 볼 수 있습니다. 예전에는 통화품질 면에서는 전화망이 월등히 좋았으나, 기술의 발전은 이 격차마저 줄여가고 있습니다. 

 

인터넷전화는 폐쇄된 PSTN 대신 공개된 인터넷망을 이용할 뿐입니다. 전화가입자는 인터넷만 되는곳이면 어디서나 전화를 이용할 수 있어 사실상 지역구분(시내,시외,국제)도 사라지는 개념이고 사업자는 고가의 장비가 없어도 전화서비스가 가능해 요금도 저렴한 장점이 있습니다. 

 

결국 90년대 후반 국내에도 무료 인터넷전화(VoIP) '다이얼패드'가 최초로 등장해 많은 파란을 일으켰습니다. PC에서 헤드셋을 갖추고 통화를 해야하므로, 일반전화보다는 불편하고 통화품질도 다소 열악했지만, 사실상 무료통화를 제공함으로서 사람들의 관심을 집중시킬 수 있었습니다.

 

다만 서비스사 내부사정으로 서비스가 오래가진 못했지만, 이 일을 계기로 이용자와 통신사업자 모두는 기존 전화망 위주의 통신서비스 구도가, 인터넷망 중심으로 재편될 것이라는 것을 인지할 수 있었습니다.

 

하지만 수년의 시간이 흘렀지만 지금도 크게 달라진것은 없어보입니다.  그 사이 관련 기술의 발전은 계속되 왔지만 제도적으론 기존 전화사업자의 수익 악화에 따른 대응책 마련이 쉽지 않기 때문입니다.

 

이놈?~ 이넘(ENUM)!!

 

이와같이 90년대 후반 우리나라뿐 아니라 세계적으로도 전화가 인터넷의 영역으로 넘어오기 시작하면서, 사람들은 인터넷주소와 전화번호와의 연결 가능성에 대해 생각해 보기 시작했습니다.

 

그러던중 2001년경, 인터넷기술표준을 제정하는 IETF(Internet Engineering Task Force)ENUM WG(Working Group)생기고, 전화번호 표준을 담당하는 ITU와도 협력해 본격적으로 ENUM 기술표준을 제정하기 시작합니다. 

 

개념은 간단합니다. 누군가의 전화번호 하나만 알면 다양한 응용프로그램을 통해 그 사람의 홈페이지에 접속하고, 인터넷전화도 걸고, 이메일 및 팩스도 보낼수 있게 하자는 것입니다.  예를 들어 ENUM번호가 있다면 명함을 만들때, 사무실 전화번호, 개인 핸드폰 번호, 메일주소, 홈페이지주소 등 온갖 정보를 다 넣지 않아도 ENUM번호 하나만 적어주면 됩니다. 명함을 받은 사람은 PC나 ENUM이 지원되는 휴대용기기 등에서 ENUM번호를 이용해 필요한 서비스를 선택할 수 있습니다.

 

<명함예: 여러 연락처를 ENUM번호 하나로 표현>

 

 

단순히 생각하면 통신사업자가 개별적으로 제공하는 원넘버 서비스와 다를게 없이 보이지만, ENUM은 인터넷 기반기술인 DNS(Domain Name System)를 이용하고, 전세계 전화번호 표준인 ITU의 'E.164 권고안'을 따름으로서 최종적으론 전화망과 인터넷망의 융합(Convergence)을 가능케하는 전세계 공통표준 이라는 점에서 다릅니다. 즉, ENUM의 본질은 전화망과 인터넷망 사이에서 의사소통을 위한 "동시통역사"의 역할이라고 볼 수 있습니다. (예: 전화번호를 --> 인터넷식별자로 바꿔줌)

 

ENUM과 DNS(Domain Name System)

 

기술적으로 ENUM을 이해하기 위해서는 먼저 DNS를 이해해야 합니다. DNS서버는 도메인네임(예:www.naver.com)을 그에 대응하는 IP주소로(예:222.122.84.250) 변환시켜 주는 역할을 하는 인터넷 사용에 있어 매우 중요한 서버로, 이와 같은 정보는 어느 한 서버에 있는것이 아니라, 아래 그림과 같이 '루트(근원)' 부터 시작하여 국가별, 회사별로 체계에 따라 여러 관련 서버에 분산되어 있습니다. 따라서 특정 정보를 찾기 위해서는 상위의 루트부터 시작하여 점점 하위단계로 내려가면서 여러번의 검색을 수행해야 최종정보에 접근할 수 있습니다.

 

<그림 출처: 한국인터넷진흥원, 도메인네임시스템은 계층적인 tree구조를 가진다.>

 

*DNS관련 참고자료

 - Powered by DNS : http://www.kr.freebsd.org/doc/PoweredByDNS/  

 - 위키피디아 자료(영문) : http://en.wikipedia.org/wiki/Domain_name_system

 - 한국인터넷진흥원 : http://domain.nic.or.kr/infomation/class.jsp

 

ENUM에서는 DNS서버에 도메인과 IP주소 대신 전화번호와 그에 대응하는 홈페이지주소, 메일주소, 팩스번호등을 인터넷식별자(URI: Uniform Resource Identifier) 형태로 저장하여 사용합니다. 

 

그리고, 전세계 통용이 가능하게 하기위해, ENUM전용 도메인을 생성하여 사용하고 있습니다. 아래 그림과 같이 "e164.arpa" 라는 도메인을 루트도메인 아래 생성하여, 전세계의 모든 전화번호를 이 도메인 아래서 표현이 가능하게 했습니다.

 

 

ENUM의 또 다른 활용

 

지금까지 설명한 ENUM은 '이용자 ENUM'이라고 하여 초기 시작부터 최근까지의 개념이었고, 최근에는 '사업자 ENUM'이라는 개념으로 발전해 제2의 도약기를 맞이하고 있습니다.

 

사실, ENUM의 기본 개념이었던 '이용자 ENUM'은 표준이 제정되고 상당한 시일이 경과했으나, 개인 프라이버시 문제 등으로 전세계적으로 답보상태에 있습니다. 2006년 10월 현재 전세계적으로 다음의 6개 국가만이 '이용자 ENUM' 상용서비스를 운영하고 있으며, 대부분 등록건수는 미미한것으로 알려져 있습니다.

 

오스트리아(+43)

폴란드(+48)

루마니아(+40)

독일(+49)

네델란드(+31)

핀란드(+358)

 

'사업자ENUM(Infrastructure ENUM)'은 인터넷전화 사업자가 인터넷전화 호 소통을 목적으로 ENUM을 활용하는 방안입니다. 아래의 개념도는 한국인터넷진흥원의 http://www.enum.or.kr 사이트에서 발췌한 것으로 ENUM이 지금까지 설명한 내용과는 전혀 다른목적으로 사용되고 있다는 것을 알수 있습니다.

[출처] [본문스크랩] ENUM|작성자 문수

'Network > Netowrk_network' 카테고리의 다른 글

실시간 통신 시스템 위한 VoIP 표준 프로토콜 H.323과 ..  (0) 2009.01.18
IPv4 Header  (0) 2009.01.18
VoIP 관련 표준 문서  (0) 2009.01.18
IP헤더  (0) 2009.01.18
IP Header 와 IP 서비스의 특징  (0) 2009.01.18
And

실시간 통신 시스템 위한 VoIP 표준 프로토콜 H.323과 ..

|

출처 죽도록 사랑하고 싶은 오직 한사람만을 위한 삶을.. | 레베로프
원문 http://blog.naver.com/heavenksm/80021535525
실시간 통신 시스템 위한 VoIP 표준 프로토콜 H.323과 SIP
새로운 부가서비스 제공 유리 SIP’ … 상호 운용 솔루션 출시 눈앞



이종석
케이티인포텍 신사업기획단 상무
jslee@kti.co.k
지난 호에서는 이전의 음성통신망인 PSTN에 대해 살펴봤다. PSTN은 음성통신 서비스에 특화된 네트워크기 때문에 프로토콜 구조가 간단하며, 효율적으로 구성돼 있다. 그러나 인터넷을 위시한 패킷 네트워크는 파일전송 및 기타 실시간 통신을 목적으로 한 네트워크가 아니기 때문에 VoIP 등의 실시간 통신 시스템에는 여러 가지 특별한 프로토콜 및 기술들이 필요하다. 이번 호에서는 VoIP 시스템의 주요 프로토콜인 H.323과 SIP를 중심으로 VoIP 기술을 상세히 알아본다. <편집자>


현재 VoIP 시스템에서 가장 표준화된 프로토콜은 IETF(Internet Engineering Task Force)에서 발표한 SIP(Session Initiation Protocol)와 ITU-T(International Telecommunication Union-Telecommunication standardization sector)에서 제정한 H.323이다. 대부분의 VoIP 장비 판매업체 및 시스템 관련 산업은 두 가지 프로토콜을 모두 지원한다.
그러나 지난 2005년 7월 IETF에서 SIP와 H.323 프로토콜의 상호연동에 필요한 기술문서인 RFC(Request For Comments) 4123 SIP-H.323 Req.를 제정함에 따라, RFC 4123 초안에 근거해 상호연동이 가능한 제품이 근 시일내에 등장할 전망이다.

1. H.323
1) 개요
H.323은 인터넷을 포함한 패킷 네트워크에서 실시간 음성, 영상 및 데이터 통신을 위한 프로토콜이다. 최초 버전은 지난 1996년 ITU-T에 의해 승인됐으며, 현재 최종 발표된 H.323 버전은 5다. 가장 먼저 발표된 VoIP 지원 프로토콜로서 현재 가장 많이 사용되고 있는 H.323은 기존 네트워크의 하부구조를 변경하지 않고 멀티미디어 서비스를 사용할 수 있을 뿐 아니라 랜과 GSTN, N-ISDN, B-ISDN 등 다른 망과의 상호운용성에 대한 표준을 제공한다.

2) 구성 요소
H.323 시스템의 구성요소로는 단말(Terminal), 게이트웨이(Gateway), 게이트키퍼(Gatekeeper), MCU(Multipoint Control Unit)가 있다.
단말은 H.323 네트워크 내에서 이뤄지는 통신의 종단점이다. PC 및 H.323 단말기 등과 더불어 게이트웨이 MCU도 단말에 속한다. 게이트웨이는 H.323 프로토콜을 운용하는 네트워크와 H.323을 운용하지 않은 네트워크의 상호 정보교환 및 연동을 담당한다. 따라서 동일한 H.323 네트워크 내에서 H.323 단말들끼리의 통신에는 게이트웨이가 필요하지 않다.
게이트 키퍼는 단말, 게이트웨이, MCU 중 등록된 종단점에 대한 콜 컨트롤(call control)과 관련된 서비스를 제공하는 일종의 교환기다. H.323 네트워크 내에서는 선택적 구성요소로서 게이트키퍼가 있을 경우 모든 단말은 콜 제어와 관련해 게이트키퍼를 사용해야 하지만, 없을 경우에는 단말끼리의 통신으로 대체된다.
MCU는 3개 이상의 단말에 대한 다수통신을 가능하게 하는 기능을 수행한다. 다수 통신에 참여하는 모든 단말은 MCU와 연결을 설정해야 한다.

3) 프로토콜 구조
H.323을 구성하는 프로토콜로는 오디오 코덱, 비디오 코덱, H.225 RAS(Registration, Admission, Status) 프로토콜, H.225 콜 시그널링 프로토콜, H.245 콜 제어 프로토콜, RTP(Real-Time Transport Protocol), RTCP(Real-Time Transport Control Protocol) 등으로 구성된다.
4) 통신 과정
H.323을 이용한 1:1 통신은 크게 3가지의 방식으로 나뉜다. 첫 번째는 다이렉트 라우티드콜 시그널링(Direct Routed Call Signaling) 방식이다. 이 방식은 Q.931 및 H.245 메시지들을 게이트키퍼를 경유하지 않고 통신 당사자들만 직접 주고받는다. 두 번째는 게이트키퍼 라우티드 콜 시그널링(Gatekeeper Routed Call Signaling) 방식으로 Q.931, H.245 메시지들이 게이트키퍼를 경유해 주고받는다.
마지막으로는 게이트키퍼 라우티드 콜 시그널링 위드 다이렉트 H.245(Gatekeeper Routed Call Signaling with Direct H.245)는 게이트 키퍼는 콜 시그널링에 관여하고 H.245 메시지들만 통신 당사자들끼리 직접 주고받는 방식으로 가장 널리 사용된다.



1. 단말 1이 등록을 위해 RAS ARQ(Admission ReQuest)를 RAS 채널을 통해 게이트키퍼에 전송한다.
2. 게이트키퍼는 ACF(Admission ConFirmed)를 전송해 단말 1을 등록하며, 단말 1에 다이렉트 콜 시그널링이 가능하다는 것을 인증한다.
3. 단말 1은 H.225 콜 시그널링 셋업(call signaling Setup) 메시지를 단말 2에 보내 연결을 요청한다.
4. 단말 2는 H.225 콜 프로시딩(proceeding) 메시지로 응답한다.
5. 단말 2는 게이트키퍼에 RAS ARQ 메시지를 보내 게이트키퍼에 등록을 요청한다.
6. 게이트키퍼는 RAS ACF 메시지를 통해 등록 허가를 단말 2에 알린다.
7. 단말 2는 단말 1에게 H.225 콜 얼러팅(alerting) 메시지를 전송한다.
8. 마지막으로 단말 2는 H.225 커넥트(connect) 메시지를 전송해 연결 설정이 수락됐음을 알린다.
9. H.245 제어채널이 단말 1과 단말 2에 성립된다. 단말 1은 H.245 TerminalCapabilitySet 메시지를 전송하고 단말 2와 성능(Capability)에 대한 정보를 교환한다.
10. 단말 2는 단말1의 성능 정보가 확인됐음을 Terminal CapabilitySetAck를 통해 알린다.
11. 단말 2는 단말 1에게 TerminalCapabilitySet을 전송해 자신의 성능 정보를 전송한다.
12. 단말 1 역시 동일하게 TerminalCapabilitySetAck를 전송해 단말 2의 성능 정보가 확인됐음을 알린다.
13. 단말 1은 단말 2에 RTCP 채널의 전송주소가 포함돼 있는 openLogicalChannel 메시지를 전송해 미디어 채널을 만든다.
14. 단말 2는 RTP 전송주소가 포함된 H.245 openLogical ChannelAck 메시지를 통해 단말 1에게 단방향의 논리 채널이 성립됐음을 알린다.
15. 단말 2는 RTCP 채널의 전송주소가 포함된 H.245 open LogicalChannel 메시지를 전송해 단말 1에 미디어 채널이 성립됐음을 통지한다.
16. 단말 1은 단말 2로 openLogicalChannelAck 메시지를 보냄으로써 단말 2로부터 단말 1까지의 단방향 논리 채널이 형성됐음을 통보한다. H.245 openLogicalChannelAck 메시지에는 단말 1의 RTP 주소가 포함돼 있으며, 이를 통해 양방향 미디어 실시간 통신이 가능하게 된다.
17. 단말 1은 RTP로 인코딩된 미디어 스트림을 단말 2로 전송한다.
18. 단말 2은 RTP로 인코딩된 미디어 스트림을 단말 1로 전송한다.
19. 단말 1은 RTCP 메시지를 단말 2로 전송한다.
20. 단말 2는 RTCP 메시지를 단말 1로 전송한다.
21. 단말 2가 H.245 EndSessionCommand 메시지를 단말 1로 전송해 연결 종료를 시도한다.
22. 단말 1은 H.245 EndSessionCommand 메시지를 단말 2로 전송함으로써 통신 종료를 준비한다.
23. 단말 2는 H.225 릴리즈 컴플릿(release complete) 메시지를 단말 1에 전송함으로써 콜을 종료한다.
24. 단말 1과 단말 2는 게이트키퍼에 RAS DRQ(Disengage ReQuest) 메시지를 전송해 게이트키퍼와의 접속을 해제한다.
25. 게이트키퍼는 단말 1과 단말 2에 DCF(Disengage ConFirmed) 메시지를 보냄으로써 접속해제를 알린다.

2. SIP
1) 개요
SIP(Session Initiation Protocol)는 인터넷을 포함하는 패킷 네트워크 상에서 통신하고자 하는 단말들을 식별하고 위치를 파악하며, 그들 상호간에 멀티미디어 통신 세션을 생성하거나 삭제, 변경하기 위한 절차를 명시한 애플리케이션 계층의 시그널링(signaling) 프로토콜이다. 또한 네트워크 전송 프로토콜과 미디어에 완벽하게 독립적이고 콘텐츠에 상관없이 어떻게 단말기의 연결을 생성하거나 변경 혹은 종료하는지를 정의한다.
SIP의 출현은 인터넷을 이용한 통신 서비스 시장에 큰 파급효과를 가져왔다. 기존의 VoIP 시스템은 대부분 ITU-T가 표준으로 채택한 H.323 프로토콜을 기반으로 구현돼 있다. H.323은 원래 패킷 교환 방식의 랜 망에서 다자간 음성, 화상, 데이터 통신을 가능케 하기 위해 개발된 기술 방식이므로 광대역 네트워크와 대규모 사용자를 지원하는 데 있어서는 기본적으로 한계점을 가지고 있었던 게 사실이다. VoIP 관련 시장 규모가 크게 성장함으로 인해 인터넷 전화 기술이 시장성 있는 기술로 각광을 받으면서 인터넷 상에서 양자간/다자간 통신을 하기 위한 시그널링 프로토콜인 SIP가 기존의 H.323을 대체하는 기술로 주목을 받게 됐다.
SIP는 MGCP(the Media Gateway Control Protocol)의 업그레이드된 프로토콜이다. MGCP는 PSTN의 음성 신호를 IP 데이터 패킷으로 변환시키는 프로토콜이었지만 확장성이 부족하고 음성신호만을 위한 표준이었으며 시그널링이 복잡한 프로토콜이었다. 특히 SIP는 MGCP의 단점을 해결한 프로토콜로 멀티미디어에 특화된 새로운 환경을 제시했다.
SIP는 HTTP와 매우 유사한 메시지 타입을 유지함으로써 개발자들이 자바 같은 대중적인 프로그래밍 언어를 통해 좀더 쉽고 빠르게 애플리케이션을 개발할 수 있게 한다. 또한 통신 사업자들에게도 CID(Caller ID) 서비스, 콜 대기(call waiting) 서비스 등 PSTN의 지능망에서 제공되는 여러 가지 프리미엄 서비스들을 동일하게 제공할 수 있다.
이렇듯 SIP의 유연한 확장성은 SIP를 VoIP 음성서비스의 새로운 표준으로 만드는데 기여했으며, 차세대 VoIP 프로토콜의 지배적인 표준으로서 입지를 굳혀나가고 있다. 또한 3G 협회는 SIP를 차세대 무선통신망의 세션 제어 메커니즘으로 선택했으며, 마이크로소프트는 윈도 운영체제, MSN 메신저 및 기타 애플리케이션의 실시간 통신을 위한 기본 프로토콜로 탑재할 것을 발표했다.

2) 주요 특징
SIP의 주요 특징은 세션을 성립시킬 때 세션의 타입을 정의하지 않고 어떻게 운영해야 될 지만 기술한다는 점이다. 이러한 유연성으로 인해 SIP는 VoIP 음성 서비스뿐만 아니라 온라인 게임, 컨퍼런싱 등의 많은 애플리케이션에 사용될 수 있다. 또한 SIP 메시지는 텍스트 기반으로 구성돼 있으므로, 해석과 디버그가 용이하며 새로운 서비스를 쉽고 간편하게 프로그래밍할 수 있다.
SIP는 MIME(Multipurpose Internet Mail Extensions) 타입 및 DNS(Domain Name System), RTP(Real-Time Transport Protocol), RTSP(Real Time Streaming Protocol) 등 현존하는 프로토콜을 재사용하기 때문에 더욱 최적화된 세션 설정이 가능하다. 또한 SIP를 지원하기 위한 또 다른 서비스를 정의할 필요가 없다.
SIP는 쉽게 확장할 수 있으며, 현존 네트워크 구조를 변경시키지 않고 새로운 애플리케이션 서비스가 가능하다. 이전 버전의 SIP 장비는 새로운 버전의 SIP를 기반으로 한 장비들과 충돌하지 않는다. 새로운 버전의 SIP는 구 SIP의 헤더 및 메소드를 무시하기 때문이다. 또한 전송계층에 독립적이기 때문에 ATM 망에서의 IP계층 위에서도 운용가능하며, 하부계층에 상관없이 UDP, TCP를 통한 전송이 가능하다.

3) 구성 요소
SIP 세션을 성립시키기 위해서는 SIP 유저 에이전트(UA), SIP 프록시 서버, SIP 레지스트라 서버(Registrar servers), 그리고 SIP 리다이렉트 서버가 필요하다. SIP 유저 에이전트는 휴대폰, PC 및 기타 SIP 사용 가능한 단말기를 통칭한다. SIP 세션을 설정하고 운영하며, SIP 연결을 요청한 단말을 클라이언트(UAC), 연결에 응답한 단말을 서버(UAS)로 분류한다.
SIP 레지스트라 서버는 데이터베이스, 도메인(domain)에 있는 모든 UA의 장소정보 및 IP 주소정보를 저장해 SIP 프록시 서버의 질의에 응답한다. SIP 프록시 서버는 SIP UA에서 요청하는 세션을 수락하고, 응답하는 UA의 주소정보를 SIP 레지스트라 서버에 질의하는 역할을 담당한다. 같은 도메인 상에 서버(UAS)가 존재시 세션 요청을 서버(UAS)에게 보내며, 서버(UAS)가 다른 도메인에 있을 경우에는 다른 도메인의 프록시 서버에 세션 요청을 전송한다.
SIP 리다이렉트 서버는 다른 도메인에 존재하는 SIP 세션 요청에 대해서 현존 도메인 내에 존재하는 SIP 프록시 서버가 직접적인 설정을 가능하게 한다.

4) 주소 및 메시지
SIP 주소형식은 기본적으로 이메일과 매우 유사한 sip:user_id@domain_name의 형식을 가지게 되며, 만약 DNS가 존재하지 않으면 domain_name 부분을 IP 주소로 대체할 수 있다. user_id 부분은 부여된 전화번호로 대체가 가능하다. 즉 sip:031xxxxxxx@62.xx.xx.xx;user=phone는 sip:user_id@domain_name와 SIP에서 동일한 주소를 나타낸다.
메시지는 텍스트 기반이며 전술한 바와 같이 HTTP를 재사용한다. 따라서 웹 서핑에서 발생되는 메시지와 동일성을 가진다. 크게 SIP 메시지는 클라이언트에서 요청하는 리퀘스트(Request)와 서버 응답인 리스펀스(Response)로 나눠진다. 메시지 타입은 다음과 같다.
5) 콜 셋업 과정
같은 도메인 내에 UAS가 존재할 경우에는 클라이언트(UAC) A와 서버(UAS) B는 IP 주소 및 수신가능 여부를 SIP 프록시 서버에 자동적으로 전송한다. 클라이언트(UAC) A가 콜을 설정 시 SIP 프록시 서버에 단말 B에 대한 통신 요구를 전송하면, SIP 프록시 서버는 SIP 레지스트라 서버에 주소 정보 요청을 통해 서버(UAS)의 IP 주소를 전송받는다. 그 후 SIP 프록시 서버는 클라이어트(UAC)의 인바이트(invite) 메시지를 서버(UAS)에 재전송하며 SDP에서 정의하는 클라이언트(UAC)가 세션에 사용하는 매체(음성, 영상 등)에 대한 정보가 포함된다.
서버(UAS)는 SIP 프록시 서버에게 콜 셋업이 가능한지와 수신 가능 여부를 회신하며, 마지막으로 SIP 프록시 서버가 클라이언트(UAC)에 정보를 전송함으로써 서버(UAS)와 클라이언트(UAC)간의 SIP 세션이 성립되는 절차를 따른다. 그 후 RTP를 이용한 통신이 P2P(Point-to-Point)로 이뤄지면서 실제적인 VoIP 음성서비스가 시작되게 된다.
만약 클라이언트(UAC)와 서버(UAS)가 동일한 도메인에 존재하지 않으면 절차가 달라진다. 클라이언트(UAS) A가 콜 설정시 SIP 프록서 서버에 단말 B에 대한 통신 요구를 전송하게 되는 것은 앞선 경우와 동일하나, SIP 프록시 서버가 도메인 B에 직접적으로 접속돼 있지 않으므로 같은 도메인 내의 SIP 레지스트라 서버는 도메인 B의 SIP 프록시 서버 주소를 전송한다. 도메인 A에 존재하는 프록시 서버는 도메인 B에 존재하는 프록시 서버에 콜을 넘겨주게 되며, 도메인 B에 존재하는 프록시 서버는 역시 같은 도메인 내에 존재하는 레지스트라 서버에 서버(UAS)의 주소를 질의한다.
도메인 B에 존재하는 레지스트라 서버는 서버(UAS)의 주소정보를 프록시 서버 B에 전송하고 서버(UAS) B는 프록시 서버 B에 응답 메시지를 전송한다. 이후 프록시 서버 B는 프록시 서버 A에 응답하며, 프록시 서버 A는 다시 클라이언트(UAC)에 응답 메시지를 전송하게 됨으로써 콜 셋업이 마무리된다.



3. H.323과 SIP 비교
VoIP 시스템에 적용되는 대표적인 두 가지 프로토콜인 H.323과 SIP는 다음과 같은 장단점을 가진다. 첫째로 H.323에 비해 SIP는 간편하고 간결한 장점으로 인해 새로운 기능 및 부가서비스 제공이 H.323에 비해 용이하다. 둘째로 H.323은 복잡한 프로토콜 구조로 인해 지연시간 증가와 과다한 자원요구 등의 단점을 가지고 있다. 마지막으로 SIP는 H.323보다 간단한 구조로 인해 통신사용자간 충분한 정보를 교환할 수 없다.
<표 2>와 같이 H.323은 좀더 현재의 PSTN망에, SIP는 인터넷 망에 각각 초점을 맞춰 발전했다. SIP가 지배적인 VoIP 시스템의 운용 프로토콜이 될 것으로 예상되지만, 그 과정에서 H.323의 장점을 적극 수용할 것으로 보인다.
이번 호는 VoIP 시스템을 구성하는 대표적인 프로토콜인 SIP와 H.323에 대해 알아봤다. 다음호에서는 VoIP 시스템의 네트워크 구조를 알아봄으로써 VoIP 시스템의 전체적인 구조를 파악해 보자. 



 

'Network > Netowrk_network' 카테고리의 다른 글

ENUM  (0) 2009.01.18
IPv4 Header  (0) 2009.01.18
VoIP 관련 표준 문서  (0) 2009.01.18
IP헤더  (0) 2009.01.18
IP Header 와 IP 서비스의 특징  (0) 2009.01.18
And

IPv4 Header

|

'Network > Netowrk_network' 카테고리의 다른 글

ENUM  (0) 2009.01.18
실시간 통신 시스템 위한 VoIP 표준 프로토콜 H.323과 ..  (0) 2009.01.18
VoIP 관련 표준 문서  (0) 2009.01.18
IP헤더  (0) 2009.01.18
IP Header 와 IP 서비스의 특징  (0) 2009.01.18
And

VoIP 관련 표준 문서

|
 
출처 reason4b님의 블로그 | 장병돈
원문 http://blog.naver.com/reason4b/80011755711

VoIP 관련 표준 문서



관련 working group     주요 프로토콜     RFCs     WG Drafts     Individual Drafts

IETF 관련 working group


주요 프로토콜

  • RFC2326: RTSP: Real Time Streaming Protocol, Standards Track, April 1998. new draft : RFC2326bis-08, October 2004.

  • RFC2327: SDP: Session Description Protocol, Standards Track, April 1998.
    new draft: RFC2327bis-08, April 2002.

  • RFC2705: MGCP: Media Gateway Control Protocol (MGCP) Version 1.0, Informational, October 1999.
  • RFC3435: MGCP: Media Gateway Control Protocol (MGCP) Version 1.0, Informational, January 2003.
    -RFC3441: Asynchronous Transfer Mode (ATM) Package for the Media Gateway Control Protocol (MGCP), Informational, January 2003.
    -RFC3660: Basic Media Gateway Control Protocol (MGCP)Packages, Informational, December 2003.
    -RFC3661: Media Gateway Control Protocol (MGCP) Return Code Usage, Informational, December 2003.

  • RFC2805: Media Gateway Control Protocol Architecture and Requirements, Informational, April 2000.

  • RFC2824: CPL: Call Processing Language Framework and Requirements, Informational, May 2000.
    draft: CPL: A Language for User Control of Internet Telephony Services, draft-ietf-iptel-cpl-09.txt, April 2004.

  • RFC2960: SCTP: Stream Control Transmission Protocol, Standards Track, October 2000.
    new draft: draft-ietf-tsvwg-rfc2960-bis-00.txt, May 7, 2001.

  • RFC3309: SCTP Checksum Change, Standards Track, October 2000.

  • RFC2974: SAP: Session Announcement Protocol, Experimental, October 2000.

  • RFC3015: MEGACO: Megaco Protocol Version 1.0, Standards Track, November 2000.
    New draft : draft-ietf-megaco-h248v2-04.txt, April 2003.

  • RFC3245: The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2), Informational, March 2002.

  • RFC3261: SIP: Session Initiation Protocol, Standards Track, June 2002.
    -RFC2543: SIP(Session Initiation Protocol), March 1999.

  • RFC3540: Robust ECN: Robust Explicit Congestion Notification (ECN) Signaling with Nonces, Experimental, June 2003.

  • RFC3550: RTP: A Transport Protocol for Real Time Applications, Standards Track, July 2003.
    -RFC1889: RTP, January 1996.

  • RFC3649: HighSpeed TCP for Large Congestion Windows, Experimental, December 2003.

  • RFC3920: Extensible Messaging and Presence Protocol (XMPP): Core, Standards, October 2004.
  • RFC3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence, Standards, October 2004.
  • RFC3922: Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM), Standards, October 2004.
  • RFC3923: End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP), Standards, October 2004.

Top


Working Group RFC 문서
(sip, sipping, sigtran, simple, mmusic, iptel, impp, megaco, enum, avt, spirit, pint)

Session Initiation Protocol (sip)

  • RFC2976 : The SIP INFO Method (S, 17736 bytes)
  • RFC3204 : MIME media types for ISUP and QSIG Objects (S, 19712 bytes)
  • RFC3262 : Reliability of Provisional Responses in Session Initiation Protocol (SIP) (S, 29643 bytes)
  • RFC3263 : Session Initiation Protocol(SIP)-Locating SIP Servers (S, 42310 bytes)
  • RFC3265 : Session Initiation Protocol (SIP)-Specific Event Notification (S, 89005 bytes)
  • RFC3310 : Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) (I, 36985 bytes)
  • RFC3311 : The Session Initiation Protocol (SIP) UPDATE Method (S, 28125 bytes)
  • RFC3312 : Integration of Resource Management and Session Initiation Protocol(SIP) (S, 65757 bytes)
    New draft : draft-ietf-sip-rfc3312-update-03.txt, September 2004.
  • RFC3323 : A Privacy Mechanism for the Session Initiation Protocol (SIP) (S, 54116 bytes)
  • RFC3325 : Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks (I, 36170 bytes)
  • RFC3326 : The Reason Header Field for the Session Initiation Protocol (SIP) (S, 15695 bytes)
  • RFC3327 : Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts (S, 36493 bytes)
  • RFC3329 : Security Mechanism Agreement for the Session Initiation Protocol (SIP) (S, 51503 bytes)
  • RFC3361 : Dynamic Host Configuration Protocol(DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers (S, 12549 bytes)
  • RFC3372 : SIP for Telephones (SIP-T): Context and Architectures (B, 49893 bytes)
  • RFC3420 : Internet Media Type message/sipfrag (S, 14745 bytes)
  • RFC3427 : Change Process for the Session Initiation Protocol(SIP) (S, 26907 bytes)
  • RFC3428 : Session Initiation Protocol (SIP) Extension for Instant Messaging (S, 41475 bytes)
  • RFC3486 : Compressing the Session Initiation Protocol (SIP) (S, 24181 bytes)
  • RFC3515 : The Session Initiation Protocol (SIP) Refer Method (S, 47788 bytes)
  • RFC3581 : An Extension to the Session Initiation Protocol(SIP) for Symmetric Response Routing (S, 66133 bytes)
  • RFC3608 : Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration (S, 35628 bytes)
  • RFC3840 : Indicating User Agent Capabilities in the Session Initiation Protocol (SIP) (S, 81360 bytes)
  • RFC3841 : Caller Preferences for the Session Initiation Protocol (SIP) (S, 61382 bytes)
  • RFC3853 : S/MIME Advanced Encryption Standard(AES) Requirement for the Session Initiation Protocol(SIP) (S, 10687 bytes)
  • RFC3891 : The Session Initiation Protocol (SIP) "Replaces" Header (S, 34180 bytes)
  • RFC3892 : The Session Initiation Protocol (SIP) Referred-By Mechanism (S, 52441 bytes)
  • RFC3893 : Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format (S, 28500 bytes)
  • RFC3911 : The Session Initiation Protocol (SIP) "Join" Header (S, 35373 bytes)
  • RFC3903 : Session Initiation Protocol (SIP) Extension for Event State Publication (S, 72062 bytes)
  • RFC3968 : The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP) (B, 20615 bytes)
  • RFC3969 : The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP) (B, 12119 bytes)

Session Initiation Proposal Investigation (sipping)

  • RFC3324 : Short Term Requirements for Network Asserted Identity (I, 21964 bytes)
  • RFC3351 : User Requirements for the Session Initiation Protocol(SIP) in support of deaf, hard of hearing and speech-impaired individuals (S, 33894 bytes)
  • RFC3398 : Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping (S, 166207 bytes)
  • RFC3455 : Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP) (S, 79620 bytes)
  • RFC3485 : The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp) (S, 80195 bytes)
  • RFC3578 : Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP) (S, 26667 bytes)
  • RFC3603 : Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling (I, 67509 bytes)
  • RFC3665 : Session Initiation Protocol (SIP) Basic Call Flow Examples (B, 163159 bytes)
  • RFC3666 : Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows (B, 200478 bytes)
  • RFC3680 : A Session Initiation Protocol (SIP) Event Package for Registrations (S, 35403 bytes)
  • RFC3702 : Authentication, Authorization, and Accounting Requirements for the Session Initiation Protocol(SIP) (I, 31243 bytes)
  • RFC3725 : Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP) (B, 77308 bytes)
  • RFC3824 : Using E.164 numbers with the Session Initiation Protocol (SIP) (I, 36535 bytes)
  • RFC3842 : A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (S, 36877 bytes)
  • RFC3959 : The Early Session Disposition Type for the Session Initiation Protocol (SIP) (S, 22160 bytes)
  • RFC3960 : Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP) (I, 31692 bytes)

Signaling Transport (sigtran)

  • RFC2719 : Framework Architecture for Signaling Transport (I, 48646 bytes)
  • RFC2960 : Stream Control Transmission Protocol (S, 297757 bytes)
  • RFC3057 : ISDN Q.921-User Adaptation Layer (S, 140327 bytes)
  • RFC3257 : Stream Control Transmission Protocol Applicability Statement (I, 24198 bytes)
  • RFC3331 : Signaling System 7 (SS7) Message Transfer Part 2(MTP2) - User Adaptation Layer (S, 210807 bytes)
  • RFC3332 : Signaling System 7 (SS7) Message Transfer Part 3(MTP3) - User Adaptation Layer (M3UA) (S, 265055 bytes) New draft : draft-ietf-sigtran-rfc3332bis-02.txt, October 2004.
  • RFC3788 : Security Considerations for Signaling Transport (SIGTRAN) Protocols (S, 27125 bytes)
  • RFC3807 : V5.2-User Adaptation Layer (V5UA) (S, 49748 bytes)
  • RFC3868 : Signalling Connection Control Part User Adaptation Layer (SUA) (S, 294116 bytes)
  • RFC3873 : Stream Control Transmission Protocol (SCTP) Management Information Base (MIB) (S, 82403 bytes)

SIP for Instant Messaging and Presence Leveraging (simple)

    No Request For Comments

Multiparty Multimedia Session Control (mmusic)

  • RFC2326 : Real Time Streaming Protocol (RTSP) (S, 195016 bytes)
  • RFC2327 : SDP: Session Description Protocol (S, 87096 bytes)
  • RFC2543 : SIP: Session Initiation Protocol (S, 338861 bytes)
  • RFC2974 : Session Announcement Protocol (E, 40129 bytes)
  • RFC3108 : Conventions for the use of the Session Description Protocol (SDP)for ATM Bearer Connections (S, 248037 bytes)
  • RFC3259 : A Message Bus for Local Coordiantion (I, 84125 bytes)
  • RFC3264 : An Offer/Answer Model with Session Description Protocol(SDP) (S, 60854 bytes)
  • RFC3266 : Support for IPv6 in Session Description Protocol(SDP) (S, 8693 bytes)
  • RFC3388 : Grouping of Media Lines in Session Description Protocol (SDP) (S, 39365 bytes)
  • RFC3407 : Session Description Protocol(SDP) Simple Capability Declaration (S, 21133 bytes)
  • RFC3524 : Mapping of Media Streams to Resource Reservation Flows (S, 11249 bytes)
  • RFC3605 : Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP) (S, 17270 bytes)
  • RFC3856 : A Presence Event Package for the Session Initiation Protocol (SIP) (S, 62956 bytes)
  • RFC3857 : A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP) (S, 46221 bytes)
  • RFC3858 : An Extensible Markup Language (XML) Based Format for Watcher Information (S, 26416 bytes)
  • RFC3890 : A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP) (S, 49894 bytes)

IP Telephony (iptel)

  • RFC2824 : Call Processing Language Framework and Requirements (I, 58711 bytes)
  • RFC2871 : A Framework for Telephony Routing over IP (I, 60664 bytes)
  • RFC3219 : Telephony Routing over IP (TRIP) (S, 184618 bytes)
  • RFC3508 : H.323 Uniform Resource Locator (URL) Scheme Registration (I, 10983 bytes)
  • RFC3872 : Management Information Base for Telephony Routing over IP (TRIP) (S, 98614 bytes)
  • RFC3880 : Call Processing Language (CPL): A Language for User Control of Internet Telephony Services (S, 154991 bytes)
  • RFC3966 : The tel URI for Telephone Numbers (S, 40783 bytes) /Obsoletes: RFC2806

Instant Messaging and Presence Protocol (impp)

  • RFC2778 : A Model for Presence and Instant Messaging (I, 35150 bytes)
  • RFC2779 : Instant Messaging / Presence Protocol Requirements (I, 47420 bytes)
  • RFC3339 : Date and Time on the Internet: Timestamps (S, 47420 bytes)

Media Gateway Control (megaco)

  • RFC2805 : Media Gateway Control Protocol Architecture and Requirements (I, 88290 bytes)
  • RFC2885 : MEGACO Protocol (S, 344871 bytes)
  • RFC2886 : Megaco Errata (S, 41311 bytes)
  • RFC3015 : Megaco Protocol Version 1.0 (S, 385432 bytes)
  • RFC3054 : Megaco IP Phone Media Gateway Application Profile (I, 31971 bytes)
  • RFC3525 : Gateway Control Protocol Version 1 (S, 439674 bytes)/Obsoletes: RFC3015
  • RFC3624 : The Media Gateway Control Protocol (MGCP) Bulk Audit Package (I, 34391 bytes)

Telephone Number Mapping (enum)

  • RFC3482 : Number Portability in the Global Switched Telephone Network (GSTN): An Overview (I, 78552 bytes)
  • RFC3761 : The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) (S, 41559 bytes)/Obsoletes: RFC2916
  • RFC3762 : Telephone Number Mapping (ENUM) Service Registration for H.323 (S, 8450 bytes)
  • RFC3764 : The Enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record (S, 17604 bytes)

Audio/Video Transport (avt)

  • RFC2029 : RTP Payload Format of Sun's CellB Video Encoding (S, 11216 bytes)
  • RFC2032 : RTP Payload Format for H.261 Video Streams (S, 27408 bytes) -RFC2032bis-04 (04 / December 2004 / 37110 bytes)
  • RFC2035 : RTP Payload Format for JPEG-compressed Video (S, 30275 bytes)
  • RFC2038 : RTP Payload Format for MPEG1/MPEG2 Video (S, 23266 bytes)
  • RFC2190 : RTP Payload Format for H.263 Video Streams (S, 26409 bytes)
  • RFC2198 : RTP Payload for Redundant Audio Data (S, 25166 bytes)
  • RFC2250 : RTP Payload Format for MPEG1/MPEG2 Video (S, 34293 bytes)
  • RFC2343 : RTP Payload Format for Bundled MPEG (S, 16557 bytes)
  • RFC2354 : Options for Repair of Streaming Media (I, 28876 bytes)
  • RFC2429 : RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) (S, 43166 bytes) -RFC2429bis-04 (04 / December 2004 / 61669 bytes)
  • RFC2431 : RTP Payload Format for BT.656 Video Encoding (S, 22323 bytes)
  • RFC2435 : RTP Payload Format for JPEG-compressed Video (S, 54173 bytes)
  • RFC2508 : Compressing IP/UDP/RTP Headers for Low-Speed Serial Links (S, 60474 bytes)
  • RFC2733 : An RTP Payload Format for Generic Forward Error Correction (S, 53120 bytes)
  • RFC2736 : Guidelines for Writers of RTP Payload Format Specifications (B, 24143 bytes)
  • RFC2762 : Sampling of the Group Membership in RTP (E, 25796 bytes)
  • RFC2793 : RTP Payload for Text Conversation (S, 20674 bytes)
    -RFC2793bis-09 (09 / November 2004 / 46012 bytes)
  • RFC2833 : RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals (S, 68786 bytes)
    -RFC2833bis-06 (06 / November 2004 / 116418 bytes)
  • RFC2862 : RTP Payload Format for Real-Time Pointers (S, 12031 bytes)
  • RFC2959 : Real-Time Transport Protocol Management Information Base (S, 62063 bytes)
  • RFC3009 : Registration of parityfec MIME types (S, 16022 bytes)
  • RFC3016 : RTP Payload Format for MPEG-4 Audio/Visual Streams (S, 47070 bytes)
  • RFC3047 : RTP Payload Format for ITU-T Recommendation G.722.1 (S, 16292 bytes)
  • RFC3119 : A More Loss-Tolerant RTP Payload Format for MP3 Audio (S, 37796 bytes)
    -RFC3119bis-03 (03 / October 2004 / 37018 bytes)
  • RFC3158 : RTP Testing Strategies (I, 48208 bytes)
  • RFC3189 : RTP Payload Format for DV Format Video (S, 25991 bytes)
  • RFC3190 : RTP Payload Format for 12-bit DAT, 20- and 24-bit Linear Sampled Audio (S, 34977 bytes)
  • RFC3267 : Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband(AMR-WB) Audio Codecs (S, 110652 bytes)
  • RFC3389 : Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN) (S, 17018 bytes)
  • RFC3497 : RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video (S, 26094 bytes)
  • RFC3545 : Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering (S, 48278 bytes)
  • RFC3550 : RTP: A Transport Protocol for Real-Time Applications (S, 259985 bytes)/Obsoletes: RFC1889
  • RFC3551 : RTP Profile for Audio and Video Conferences with Minimal Control (S, 106621 bytes)/Obsoletes: RFC1890
  • RFC3555 : MIME Type Registration of RTP Payload Formats (S, 56618 bytes)
  • RFC3556 : Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth (S, 15310 bytes)
  • RFC3557 : RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Standard ES 201 108 Distributed Speech Recognition Encoding (S, 29692 bytes)
  • RFC3558 : RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV) (S, 49787 bytes)
  • RFC3611 : RTP Control Protocol Extended Reports (RTCP XR) (S, 126736 bytes)
  • RFC3640 : RTP Payload Format for Transport of MPEG-4 Elementary Streams (S, 102606 bytes)
  • RFC3711 : The Secure Real-time Transport Protocol (SRTP) (S, 134270 bytes)
  • RFC3839 : MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files (S, 15645 bytes)
  • RFC3951 : Internet Low Bit Rate Codec (iLBC) (E, 373442 bytes)
  • RFC3952 : Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech (E, 28655 bytes)

Service in the PSTN/IN Requesting InTernet Service (spirits)

  • RFC1889 : Pre-SPIRITS Implementations of PSTN-initiated Services (I, 96427 bytes)
  • RFC3136 : The SPIRITS Architecture (I, 19241 bytes)
  • RFC3298 : Service in the Public Switched Telephone Network/Intelligent Network(PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements (I, 37515 bytes)
  • RFC3910 : The SPIRITS (Services in PSTN requesting Internet Services) Protocol (S, 110515 bytes)

PSTN and Internet Internetworking (pint)

  • RFC2458 : Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations (I, 139154 bytes)
  • RFC2848 : The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services (S, 168851 bytes)

  • RFC3689 : General Requirements for Emergency Telecommunication Service (ETS) (I, 13919 bytes)
  • RFC3690 : IP Telephony Requirements for Emergency Telecommunication Service (ETS) (I, 21680 bytes)

  • RFC3708 : Using TCP Duplicate Selective Acknowledgement(DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions (E, 20818 bytes)
  • RFC3758 : Stream Control Transmission Protocol (SCTP) Partial Reliability Extension (S, 50999 bytes)
  • RFC3782 : The NewReno Modification to TCP's Fast Recovery Algorithm (S, 49603 bytes)/Obsoletes: RFC2582
  • RFC3828 : The Lightweight User Datagram Protocol (UDP-Lite) (S, 27193 bytes)

  • RFC3726 : Requirements for Signaling Protocols (I, 98020 bytes)

  • RFC3773 : High-Level Requirements for Internet Voice Mail (I, 19156 bytes)

Top


Working Group Drafts
(sip, sipping, sigtran, simple, mmusic, iptel, impp, megaco, enum, avt, spirit, pint)

Session Initiation Protocol (sip)


Session Initiation Proposal Investigation (sipping)


Signaling Transport (sigtran)


SIP for Instant Messaging and Presence Leveraging (simple)


Multiparty Multimedia Session Control (mmusic)


IP Telephony (iptel)


Instant Messaging and Presence Protocol (impp)


Media Gateway Control (megaco)


Telephone Number Mapping (enum)


Audio/Video Transport (avt)


Service in the PSTN/IN Requesting InTernet Service (spirits)


PSTN and Internet Internetworking (pint)

Top

Individual Drafts

Top 

'Network > Netowrk_network' 카테고리의 다른 글

실시간 통신 시스템 위한 VoIP 표준 프로토콜 H.323과 ..  (0) 2009.01.18
IPv4 Header  (0) 2009.01.18
IP헤더  (0) 2009.01.18
IP Header 와 IP 서비스의 특징  (0) 2009.01.18
IP (Internet Protocol)  (0) 2009.01.18
And

IP헤더

|
 
출처 미래소년코난 | 미소코난
원문 http://blog.naver.com/impro/2952851



Version number
4비트 크기의 필드로 IP의 버전 번호를 담는다.  현재의 버전은 4이다.

 

Length
이것은 IP 헤더의 길이를 표시한다.  가장 짧은 길이는 5개의 워드로 구성되며 보통의 경우 대부분의 IP 패킷은 45(16)로 시작한다.  선택사항인 항목들이 추가됨에 따라 프로토콜의 헤더의 길이는 증가하며 헤더를 해석하기 위해서는 정확한 길이를 알아야 한다.

 

Type of service
이 항목은 고정된 규칙에 따라 메세지를 처리하도록 하기위한, IP 프로토콜 장치에 대한 입력을 담고 있다. 아래에 자세한 이 항목의 자세한 구조를 보였다. 실제로 두 컴퓨터간에는 질적으로 차이가 나는 서로 다른 경로가 존재하는 경우가 거의 없기 때문에 값 0은 거의 항상 사용된다.  게다가 알려진 바에 의하면 어떠한 UNIX IP 구현들도 이 항목을 검토하도록 하지 않는다(이것은 아마도 이 항목을 채워넣을 프로그램 인터페이스가 없기 때문일 것이다).

 

Bits            If 0                                       If 1
0-2             Precedence        

3                Normal delay                        Low dealy 

4                Normal throughput               High throughput

5                Normal reliability                   High reliability  

6-7             Reserver

                  0     1       2       3       4       5      6      7

                  Precedence       D       T       R      O     O
                      

Packet length
이 항목은 프로토콜 헤더를 포함한 패킷의 길이를 담고 있다.  이 항목은 데이타의 길이를 결정하고 후에 트랜스포트 프로토콜로 건네어진다.  16비트 크기의 항목이므로 IP 패킷은 최대 길이가 65,535(216-1)바이트가 된다.  IP 명세서는 모든 호스트 컴퓨터는 512 바이트의 데이타와 프로토콜 헤더를 첨가한, 576바이트의 패킷들을 수신하여 재결합할 수 있을 것을 요구한다.  일반적으로 컴퓨터들은 이 보다 더 큰 패킷들을 처리할 수 있는데 최소한 그들이 연결되어 있는 네트워크에서의 최대 크기의 패킷을 처리할 수 있다.

 

Identification
이것은 송신 호스트에 의하여 생성되는 유일한 식별자이다.  이 항목은 단편들을 재합성하는데 있어 단편들의 연결 조각을 식별하기 위해 사용된다.

 

Flags
DF(Don't Fragment)와 MF(More Fragment) 두 비트는 단편화의 경우 패킷의 처리를 제어한다.  만약 DF 비트가 세트되면 IP 패킷은 어떠한 상황에서도, 예를 들어 더 이상 전달되지 못하고 버려져야 하는 경우에도 단편화되지 않는다.  MF 비트는 더 이상의 추가적인 서브 패킷이 있는 지를 나타낸다.  이 항목의 첫 비트는 사용되지 않는다.  단편화의 알고리즘은 이 장의 뒷부분에서 더 자세히 알아보겠다.

 

Fargment offset
MF 비트가 세트되었다면 이 항목은 패킷에 든 서브 메세지의 전체 메세지의 시작으로부터의 상대적인 위치를 나타낸다.  수신 호스트는 이 항목을 이용하여 원래의 패킷으로 올바르게 재합성할 수 있다.  위에서 언급한 플래그로 인하여 이 항목은 13비트의 크기를 가진다. 그래서 오프셋은 8바이트 단위로 계산되며 결국 IP 패킷의 최대 길이는 65,535(8*213 - 1)이다.

 

Time to live
송신 호스트는 패킷이 버려지기까지 얼마나 오랫동안 네트워크상에 존재할 수 있는 지를 확정한다.  RFC 791은 이 항목에서 사용되는 단위를 초로 명세하고 있으며 비록 처리 시간이 1초미만이라도 각각 노드는 이 값을 최소한 1 이상 감소할 것을 요구한다.  따라서 TTL은 일반적으로 패킷이 지나갈 수 있는 최대의 노드의 수와 같다.  만약 이 항목이 0의 값을 갖는다면 현재의 처리기에 의해서 이 패킷은 버려져야 한다.  이로서 패킷이 네트워크에서 무한정 회전하는 것을 막을 수 있다.  이 경우 송신 개체는 이 사건(수명이 다한 패킷의 폐기)에 대한 ICMP 메세지를 받게 된다.  대체로 UNIX 시스템은 이 값을 15(4.2BSD)에서 30(4.3BSD)사이의 값으로 설정한다. 4.2BSD에 기반한 오래된 IP 구현에서는 이 항목의 값을 5씩 감소시킨 반면 새로운 버전에서는 단지 1씩만 감소시킨다.

 

Transport protocol
이 항목은 패킷이 전송되어져야 할 트랜스포트 프로토콜의 ID를 담는다.  예를 들어 TCP인 경우 6을, UDP인 경우 17을, ICMP인 경우 1의 값을 갖는다.  이러한 값들은 NIC에 의하여 결정된다.  현재 대략 50개의 공식적인 상위 프로토콜들이 존재한다.  표.3.1에 현재 번호가 할당되어진 트랜스포토 프로토콜들의 예가 나와있다.

 

No                Abbreviation          Name
1                  ICMP                      Internet Control Message
2                  IGMP                      Internet Group Management
3                  GGP                       Gateway-to-Gateway
6                  TCP                        Transmission Control
17                UDP                        User Datagram
29                ISO TP4                  ISO Transport Protocol Class 4
86                DGP                        Dissimiliar Gateway
89                OSPF                      Open Shortest Path First

 

Header checksum
이 항목은 프로토콜 헤더에 대한 체크섬을 갖는다.  이것을 통하여 호스트는 노드들이 잘못된 데이타를 이용하여 작업하는 것을 막을 수 있다.  효율성을 위하여 사용자 데이타에 대한 검사는 하지 않는다.  IP 패킷은 모든 노드에서 TTL 항목을 감소시키기 위하여 변경된다.  따라서 체크섬이 매우 효율적으로 생성되는 것이 매우 중요하다.  TCP/IP 구조에서는 모든 프로토콜에 Internet checksum이라는 방법이 사용된다.  이것은 검사대상이 되는 데이타를 16비트의 크기의 워드로 나누어 합하고 이것의 결과인 16비트 크기의 값에 대하여 다시 1의 보수를 취하여 얻어진다.
이 알고리즘은 간단하고 빨르다. 이것은 노드들의 효율적인 작동을 위하여 필요한 것이다.  그러나 이 방벙의 에러 감지의 능력은 한정되어 있다.  단순히 덧셈으로만 이루어져 있으므로, 예를 들어 0으로만 이루어진 16비트 워드가 분실되는 경우 이것을 감지할 수 없다.  TCP와 UDP의 체크섬은 데이타 항목뿐만 아니라 감지되지 않은 데이타의 분실을 실질적으로 제거하기 위해 다른 항목들(길이, 송신 개체, 수신 개체등등)까지 검사한다.

 

Source and destination address
32비트 크기의 Internet address가 이 부분에 들어간다.

 

Options and padding
특별한 작업(네트워크 관리, 보안)등을 위하여 IP 프로토콜의 헤더는 다음에 알아볼 추가사항들을 포함하도록 확장된다.  IP 프로토콜 헤더의 크기는 4의 배수가 되도록 하기 위하여 필요한 경우 padding 문자들을 삽입한다.

 


'Network > Netowrk_network' 카테고리의 다른 글

실시간 통신 시스템 위한 VoIP 표준 프로토콜 H.323과 ..  (0) 2009.01.18
IPv4 Header  (0) 2009.01.18
VoIP 관련 표준 문서  (0) 2009.01.18
IP Header 와 IP 서비스의 특징  (0) 2009.01.18
IP (Internet Protocol)  (0) 2009.01.18
And

IP Header 와 IP 서비스의 특징

|
사용자 삽입 이미지

IP 서비스의 특징
Unreliable datagram service
Out of order Datagrams
Duplicates may be received

 
Fragmentation and Reassembly

Fragmentation :

IP datagram이 순서가 지켜지지 않는 원인 중의 하나인데, IP datagram을 라우터 상에서 잘라서 전송하는 경우가 발생한다. 즉 링크 레이어의 페이로드보다 크기가 큰 경우에는 더 작은 TCP segment들로 쪼개서 전송하게 된다. 만일에 하나의 프래그먼트가 유실되면 전체 IP datagram 은 버려진다. 결구 TCP time-out 이 발생하고 전체 TCP segment는 재전송될 것이다.

Reassembly :

이러한 Fragmented 된 segment를 받은 경우 해당 IP header의 flag 정보를 통해서 fragment 되었다는 사실을 알게되고 다시 수신 측에서 reassemble 하게 된다.

fragmentation & reassembly는 g/w 또는 router 가 이러한 작업을 할 수도 있지만 병목현상이 발생할 수 있으므로 미리 해두는 것이 좋다.

'Network > Netowrk_network' 카테고리의 다른 글

실시간 통신 시스템 위한 VoIP 표준 프로토콜 H.323과 ..  (0) 2009.01.18
IPv4 Header  (0) 2009.01.18
VoIP 관련 표준 문서  (0) 2009.01.18
IP헤더  (0) 2009.01.18
IP (Internet Protocol)  (0) 2009.01.18
And

IP (Internet Protocol)

|

윤 상배

dreamyun@yahoo.co.kr

교정 과정
교정 0.8 2003년 3월 19일 23시
이미지추가

차례
1절. 소개
2절. IP (Internet Protocol)
2.1절. IP 란
2.2절. IP 헤더
2.3절. 경로배정(routing)
2.4절. 데이타 단편화 (fragmentation)
2.4.1절. MTU(Maximum Transmission Unit)
2.4.2절. 단편화및 재조립
2.5절. IP 헤더의 예
3절. 결론

1절. 소개

우리는 그동안 몇번의 기사를 통해서 IP에 대해서 이미 알아보았다. 이번에는 IP에 대한 좀더 자세한 내용을 알아보도록 하겠다.

이문서는 여러분이 TCP/IP 에 대한 기본적인 이해를 하고 있다고 가정할것이다. 이 문서를 읽기전에 TCP/IP 개요, TCP/IP 개요(2), TCP/IP 개요(3) 에 대한 문서를 먼저 읽어서 TCP/IP 에 대한 어느 정도의 이해를 해놓길 바란다.


2절. IP (Internet Protocol)

2.1절. IP 란

IP 는 인터넷으로 연결된 호스트 사이에 bit 데이터 (인터넷 데이타 그램)의 교환을 가능하도록 하기 위해 만들어진 프로토콜이다. IP는 인터넷 환경에서 host 간 데이타 그램의 교환을 목적으로 하므로 host-to-host 프로토콜이라고 불리우기도 한다.

IP는 addressing(주소지정) 과 데이타 그램의 단편화를 통해서 데이타 그램을 교환한다. 일단 보내고자 하는 크기의 데이타가 있다면, IP는 이 데이타를 한꺼번에 보내지 않고, 여러개의 조그만 데이타 그램으로 단편화 (fragmentation) 작업을 수행하게 된다. 그리고 이러한 단편화된 데이타 앞에 목적지로 찾아갈수 있도록 하기 위한 여러가지 정보 들을 채워 넣게 된다 (이것을 IP Header 이라고 한다).

그림 1. 단편화된 데이타들

위의 그림을 보면 하나의 Internet Data 를 보내기 위해서 3개의 조그만 데이타로 쪼개고 이앞에 IP Header 을 붙였음을 알수 있다.

IP 프로토콜은 다음과 같은 몇가지 특징을 가지고 있다.

비신뢰성(unreliable)

IP 는 데이타 그램이 목적지로 전달될 것이라는 것을 보증하지 않는다. IP 데이타 그램은 목적지로 가는 도중 여러가지 원인에 의해서 손실될수도 있는데, IP 헤더에는 이러한 손실을 복구하기 위한 어떠한 장치도 마련되어 있지 않다. 대신에 TCP 에 이러한 데이타 손실을 복구하기 위한 장치를 마련한다.

비연결지향성(connectionless)

호스트와 호스트간에 데이타 그램을 전달하기 위하여서 세션을 개설하지 않는다. 모든 데이타 그램은 각각 독립적으로 전달되게 된다. 받는 호스트에서는 해당 데이타 그램간의 연관성에 대해서 전혀 알지 못한다. 만약 A와 B 데이타가 호스트로 전달되고, A가 첫번째 데이타 B가 두번째 데이타라고 한다면, 받은측에서는 어느 데이타가 첫번째 데이타인지 알지 못한다. 또한 B데이타가 A데이타 보다 먼저 전달될수도 있는데, IP는 이를 교정할수 있는 장치를 가지지 않는다.


2.2절. IP 헤더

이번장에서는 IP 프로토콜의 헤더 포맷에 대해서 알아보도록하겠다.

그림 2. IP 헤더

Version: 4bits

IP 포맷의 버젼을 나타낸다. 현재는 주로 IPv4 가 가장 널리 쓰이며, 차세대 포맷으로 IPv6 가 제안되어서 조금씩 사용범위가 늘어나고 있는 추세이다.

IHL(Internet Header Length): 4bits

IP 헤더의 길이다. 보통은 32bit 크기를 가지는 5개의 열로 이루어진다. 나마지 하나의 열은(Options, Padding)는 옵션사항이다.

Type of Service: 8 bits

인터넷에는 다양한 종류의 데이타 그램이 돌아다닌다. 이중 어떤것은 상대적으로 중요한 데이터 그램이라서 데이타 전송에 있어서 다른 데이타 그램보다 전송에 있어서 우선순위를 두어야 하는 그런경우가 있을것이다. 이럴때 Type of Service 를 이용함으로써, 데이타 그램의 전송에 대한 우선순위 등을 제어할수 있다. 간단한 형태의 QOS(Quality of service) 라고 볼수 있다.

Total Length: 16 bits

IP 헤더와 실제 데이타의 크기를 모두 합친 크기이다.

Identification: 16 bits

보내고자 하는 데이타 그램에 단편화(fragmentation)가 일어났을경우 단편화된 각 데이타 그램을 구분할수 있는 일련의 번호이다. 이 값을 이용해서 이 데이타 그램이 어떤 데이타 그램에서 단편화 된것인지를 알수 있다.

Flags: 3bits

데이타 그램의 단편화에 대한 정보를 알려주기 위해서 사용된다. 첫번째 비트는 예비로 사용되며, 0으로 세팅된다. 두번째 비트와 세번째 비트는 단편화된 데이타그램의 정보를 세팅하기 위해서 사용된다. 두번째 비트가 0으로 세팅되었을경우 단편화된 데이타임을 의미하며, 1일경우 단편화 되지 않은 데이타를 의미한다. 3번째 비트가 0일경우 마지막 단편화 데이타 임을 나타내며, 1일경우에는 단편화된 데이타가 더 있다는것 나타낸다.

표 1. Flags 세팅

0 예비 : 반드시 0
1 (DF) 0 = 단편화되었음, 1 = 단편화되지 않았음
2 (MF) 0 = 마지막 단편화 데이타, 1 = 단편화 데이타 더 있음

     0   1   2
+---+---+---+
| | D | M |
| 0 | F | F |
+---+---+---+
Fragment Offset: 13bits

데이타그램에 대한 단편화가 일어났을경우 현재 데이타 그램이 원래 데이타 그램의 몇번째 위치부터 단편화가 이루어 졌는지를 나타낸다.

Time To Live: 8bits

TTL 이라고 불리우는 값으로 데이타 그램이 살아있을 시간을 지정한다. 시간 이라고 해서 1시간 2시간 하는 시간이 아닌, 몇개의 라우터를 이동할수 있는지를 명시함으로써 데이타 그램의 생존기간을 명시한다. IP 데이타 그램이 라우터를 경유하게 되면 라우터는 TTL 필드를 조사해서 TTL의 값에 1을 빼준다. 만약 TTL 에 16의 값이 세팅되어 있다면 16번째 라우터를 지날때 TTL 값은 0이 될것이며, 라우터는 이 데이타 그램을 전달하지 않고 drop 시켜버린다. TTL 값을 명시하는 이유는 데이타 그램이 라우터 상에서 무한 순환 하는 사태가 발생할수 있기 때문이다.

Header Checksum: 16bits

Header 정보는 고정된게 아니고 필요에 따라 바뀌게 된다(TTL 과 같은정보). 그러므로 헤더를 체크할수 있는 장치를 필요로 한다.

Source Address: 32bits

데이타그램을 보내는 측의 IP 주소이다.

Destination Address: 32bits

데이타그램을 받는측의 IP 주소이다.

Options: 크기변화

프로그램의 특성에 의해서 특정한 기능을 추가하기 위해서 사용된다. 이 필드는 필수적인 것이 아니다. 데이타 그램에 보안기능을 추가하거나, QOS 와 같은 기능, 혹은 라우팅관련된 부가적인 여러 기능을 추가하기 위해서 사용된다.

Padding: 크기변화

특별한 사용용도는 없다. 단지 32bit 크기를 맞추기 위해서 사용되며, 0으로 세팅된다.


2.3절. 경로배정(routing)

IP 데이타 그램의 목적지까지의 경로 배정은 Destination Address 필드에 세팅되어 있는 IP 주소를 통하여서 이루어진다. 일단 데이타 그램이 보내질 목적지가 LAN 상에 존재하면, 데이타 그램은 곧바로 해당 목적지 호스트로 보내어진다. 그렇지 않을경우 데이타 그램은 설정되어 있는 default gateway(router) 로 보내어진다. 이것은 router 의 ip routing table 에 의해서 목적지까지 경우되어서 최종 호스트로 도착하게 된다. 여기에 대한 내용들은 이미 다른 기사에서 자세히 언급되어 있음으로 이정도에서 끝내도록 하겠다.



2.4절. 데이타 단편화 (fragmentation)

위에서 IP 헤더 필드를 설명하면서 "데이타 단편화" 에 대한 언급을 했었다. 이번장에서는 이러한 데이타 단편화가 일어나는 원인과 어떻게 단편화된 데이타를 재조합 할수 있는지에 대해서 알아보도록 하겠다.


2.4.1절. MTU(Maximum Transmission Unit)

MTU 란 다음 호스트에 한번에 보낼수 있는 데이타 그램의 크기이다. 어쨋든 데이타를 한번에 몽땅 보낼수는 없으므로 호스트에서는 이것을 적당한 크기로 잘라내야 할것이다. 그런데 이 적당한 크기라는게 말그대로 적당한 크기로 망에 따라서 약간씩 그 크기가 다르며, 각 망에서 통신하기에 가장 최적화된 크기의 MTU를 가지고 있다. MTU 사이즈는 헤더를 제외한 data 만의 크기이다.

이러한 MTU 사이즈는 여러번의 테스트를 걸쳐서 각망에 최적화된다라고 생각되는 실험적인 크기로 정해진다. 우리가 보통 사용하는 이더넷 망의 경우 1500, ATM 망의 경우 9600 의 사이즈를 가지며, SLIP 의 경우 576 의 크기를 가진다. 또한 이 값은 망 상태에 따라서 네트웍 관리자에 의해서 임의로 조정될수 있다.

[root@localhost root]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:50:BF:2C:7B:B2
inet addr:192.168.0.4 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:355481 errors:1 dropped:0 overruns:0 frame:0
TX packets:360573 errors:0 dropped:0 overruns:0 carrier:0
collisions:5023
RX bytes:369176288 (352.0 Mb) TX bytes:33374363 (31.8 Mb)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:68 errors:0 dropped:0 overruns:0 frame:0
TX packets:68 errors:0 dropped:0 overruns:0 carrier:0
collisions:0
RX bytes:3400 (3.3 Kb) TX bytes:3400 (3.3 Kb)
이러한 MTU 의 크기는 ifconfig 를 통해서 확인 가능하며, 변경도 가능하다. 위의 ifconfig 정보는 필자의 리눅스박스에서 측정한 크기이다. 필자의 리눅스 박스는 보통의 이더넷카드를 이용하므로 MTU 1500 으로 세팅되어 있다.

2.4.2절. 단편화및 재조립

인터넷은 다양한 환경을 가지는 망으로 서로 연결되어 있음으로, 데이타 그램이 목적지로 이동하는 동안 다양한 MTU 크기를 가지는 망을 통과하게 된다. 만약 1500 의 MTU 크기를 가지는 호스트에서 만들어진 데이타 그램이 576 MTU 크기를 가지는 SLIP 를 통과하게 되면 어떻게 될까 ? 1500 의 크기로는 576 크기를 통과할수 없음으로, 576 크기에 맞도록 데이타가 단편화 되게 된다.

   IPH : IP Header
+-----+------------------------+
| IPH | 1500 |
+-----+------------------------+

+-----+-----+ +-----+-----+ +-----+-----+
| IPH | 576 | | IPH | 576 | | IPH | 348 |
+-----+-----+ +-----+-----+ +-----+-----+
위의 그림처럼 1500 데이타는 2개의 576크기를 가지는 데이타 그램과 348 크기를 가지는 데이타 그램으로 단편화 되게 될것이다. 또한 이 데이타 그램은 단편화 된다고 하더라도, IP 데이타 그램의 특성을 가져야 함으로 각각 IP 헤더를 가지는 완전한 IP 데이타 그램의 형태가 될것이다.

이렇게 단편화 되어서 전송되는 데이타 그램의 경우 목적지에 서로 다른 순서로 도달할수가 있을것이다. 그러므로 단편화 작업을 수행할때, 각각의 단편화된 데이타 그램이 원래의 데이타그램의 어떤 위치에서 단편화 되었는지등의 정보를 넣어둠으로써 최종도착지점에서 단편화된 데이타를 다시 조립할수 있도록 만들어줘야 할것이다. 이러한 작업은 커널의 IP를 담당하는 모듈에서 자동적으로 수행하며, IP 테이블의 Flags 와 Fragment Offset 필드를 수정함으로써 단편화 정보를 유지하게 된다. 여기에는 현재의 데이타 그램의 단편화가 되어있는지 단편화가 되어 있다면, 어떤 데이타그램에서 단편화 된것인지, 몇번째 단편화 데이타 인지, 마지막 단편화 데이타 인지, 원래 데이타 그램에서 offset 은 어느정도가 되는지등의 정보가 들어가게 된다. 최종적으로 목적지에서는 데이타 그램의 Identification 과 Flag, Fragment Offset 을 이용해서 단편화된 데이타를 재조립하게 될것이다.


2.5절. IP 헤더의 예

다음은 IP 헤더의 가장간단한 예로 단편화가 일어나지 않은 데이타 그램의 IP 헤더의 형태이다.

    0                   1                   2                   3  
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service| Total Length = 168 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=0| Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 123 | Protocol = 1 | header checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+
데이타 그램의 총 크기는 168bit 이고, 이중 헤더의 크기가 160bit 데이타의 크기가 8bit 임을 알수 있다. IPv4 버전이며, 단편화가 일어나지 않았(Flg=0)음을 알수 있다.

이번에는 좀더 복잡한 예로, 단편화가 일어난 데이타 그램의 경우이다. MTU 사이즈는 2048 이며, 보내고자 하는데이타의 크기는 2500 이라고 가정하겠다.

이것은 첫번째 데이타 그램이다.

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service| Total Length = 2208 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 112 |Flg=1| Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 119 | Protocol = 6 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |


| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
데이타 그램의 총크기는 2048 + (32*5) = 2208 이 될것이다. 데이타 그램의 단편화가 이루어졌음으로 Flg = 1 이 세팅된다. 그리고 단편화된 데이타 중 첫번째 데이타 그램이므로 Fragment Offset 는 0이 될것이다.

다음은 두번째 데이타 그램이다.

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service| Total Length = 612 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 112 |Flg=0| Fragment Offset = 2048 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 119 | Protocol = 6 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |


| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Identification 이 112 임을 주목하라. 마지막 단편화 데이타 이므로 (더이상 단편화된 데이타가 없음) Flg 가 0으로 세팅되어있다. 이 데이타 그램의 Total Length 는 (32 * 5) + ( 2500 - 2048 ) = 612 가 될것이다. 그리고 이 단편화된 데이타 그램이 원래 데이타 그램에서 단편화된 위치는 2048 이 될것임으로 Fragment Offset 는 2048 이 될것이다.

3절. 결론

이상 IP 프로토콜에 대한 좀더 자세한 내용들을 알아보았습니다. 이러한 내용들에 대한 좀더 자세한 내용을 원한다면 RFC791 와 W. Richard Stevens 의 TCP/IP Illustrated Volume 1 을 참고하기 바랍니다.


'Network > Netowrk_network' 카테고리의 다른 글

실시간 통신 시스템 위한 VoIP 표준 프로토콜 H.323과 ..  (0) 2009.01.18
IPv4 Header  (0) 2009.01.18
VoIP 관련 표준 문서  (0) 2009.01.18
IP헤더  (0) 2009.01.18
IP Header 와 IP 서비스의 특징  (0) 2009.01.18
And
prev | 1 | next