UPNP Stack 및 정리

UPnP정의

UPnP는 PC, 주변장치, 지능형 가전제품, 무선 장비등과 같은 장치들을 네트웤에 접속시켰을 때, 인터넷과 웹 프로토콜을 사용하여 서로를 자동으로 인식할 수 있도록 해주는 표준이다.

사용자가 어떤 장치를 네트웍에 추가하면 그 장치는 스스로 구성을 완료하며,

TCP/IP 주소를 받고, 다른 장치들에게 자신의 존재를 알리기 위해 인터넷 HTTP에 기반을 둔 발견 프로토콜을 사용하게 된다.

예를 들어, 현재 네트웍에 접속되어 있는 카메라와 프린터가 있고, 그 프린터를 통해 사진을 출력하려고 할 때, 카메라의 단추를 누르면, 카메라가 "발견 요청" 신호를 네트웍에 보냄으로써, 이용 가능한 프린터가 네트웍 상에 있는지  찾도록 할 수 있다. 그 후 신호를 받은 프린터는 자신의 위치를 URL의 형태로 카메라에게 응답하게 된다.

카메라와 프린터는 공용의 언어로 XML을 사용하거나, 또는 프로토콜 협상을 통해 어떤 방식으로 의사소통을 할 것인지를 정할 수 있게 된다. 의사소통을 위한 공용언어가 결정되면, 

카메라는 프린터를 제어하고 선택된 사진을 출력할 수 있게 된다. 마이크로소프트와 그밖에 UPnP를 후원하는 28개 회사들은 UPnP가 소켓에 전구를 꼽는 것 만큼이나, 쉽게 어떤 장치나 가전제품들을 가정이나 회사의 데이터 네트웍에 쉽게 추가할 수 있게 되기를 희망하고 있다.

[http://conanoc.egloos.com/4750149 conan's 님 글 발췌]

UPnP에 대한 오해

UPnP(Universal Plug and Play)라는 홈네트워크 분야의 표준 네트워크 프로토콜이 있다.
우선, 흔한 오해 한가지. 과거 윈도우즈95 때 등장했던 Plug and Play 와 이름이 비슷한 탓으로 Plug and Play의 네트워크 버전으로 오해하기 쉽다. 장치를 네트워크 케이블에 연결하기만 하면 바로 인터넷을 사용할 수 있게 하는 기술 정도로 오해한다. (이건 DHCP 정도에 해당하겠지)

이런 오해를 돕는 또한가지 측면은 UPnP에 이와 비슷한 기능이 포함되어 있기도 하다는 것이다. 바로 NAT traversal 이란 기능으로, IGDP(Internet Gateway Device Protocol)를 이용해서 네트워크 장비와 라우터가 대화를 나눌 수 있다. 예를들어, NAT 라우터 밑에 있는 장치가 1234번 incoming port를 사용해야 한다면 기업에서는 라우터 관리자가 라우터에 port mapping을 해서 1234번 port로 들어오는 패킷을 해당 장치로 포워딩 시켜준다. 그런데 가정에서는 일반인이 라우터 port map을 변경할 능력도 권한도 없어서 문제가 된다. 이를 위해서 장치와 라우터가 직접 통신해서 지들끼리 알아서 port map을 변경하도록 한게 IGDP다. 보안 측면에서 위험한거 아니냐고 생각할 수도 있겠지만 잘 생각해보면 그렇지 않다. (각자 생각해 보기)
IGDP를 지원하는 라우터들은 꽤 많지만 이게 대세인지는 모르겠다. 보통 UPnP를 지원하는 라우터라고 표시되어 있다.

UPnP와 UPnP 서비스 시나리오

UPnP는 홈네트워크에 있는 네트워크 장치들이 서로 연동될 수 있도록 하는 범용 표준 프로토콜이다. 라우터도 네트워크 장치니까 라우터와도 연동을 하고, TV나 오디오, 디지털 액자나 전등과도 연동을 할 수 있을 것이다. 수많은 제조사들에서 만드는 각기 다른 제품들이 서로 연동될 수 있는걸까? 범용성이란 측면때문에 기능들은 당연히 제한될 수 밖에 없다. 전원을 끄고 켜거나 기기에 대한 정보를 주고 받거나 멀티미디어 데이타를 주고 받는 정도다.

UPnP는 UDP, HTTP, XML 정도의 기술을 조합해서 정의되어 있다. 장치들은 UDP broadcast를 통해서 자신을 알리고 주변의 다른 장치에 대한 정보를 등록한다. 사용자는 하나의 Display 장치를 통해 다른 장치들의 정보를 볼 수 있고, 그 장치들이 가지고 있는 컨텐츠 목록도 볼 수 있고, 그 컨텐츠가 영화 파일이라면 특정 장치로 그 파일을 재생시킬 수 있다. 특히 오디오와 비디오 장치를 위해서 UPnP AV 라는 규격을 정의하고 있고, 멀티미디어 파일을 공급하는 장치를 Media Server, 멀티미디어 파일을 재생하는 장치를 Media Renderer, 사용자가 목록을 골라서 Play/Pause/Stop 시킬 수 있도록 해주는 장치를 Media Controller라고 정의한다.

Media Controller라는 장치는 좀 애매한데 보통 TV를 예로 보면, TV는 영화를 Play하는 Renderer 역할을 하지만 Play 할 영화의 목록을 보여주고 Pause/Stop도 TV 리모콘을 통해 하게 되니까 Controller의 역할도 하게된다. 따라서 TV는 보통 Media Renderer + Media Controller가 된다. 하지만 분명 Renderer와 Controller를 분리시키면 다음과 같이 좀더 나이스한 시나리오가 가능해진다: UPnP를 지원하는 외장 하드에 영화파일이 10편쯤 들어있다. iPhone에서 이 영화들의 목록을 살펴보다가 하나를 선택한다. 그러면 TV가 켜지면서 이 영화가 재생된다.
국내에 출시되는 UPnP 지원 TV는 삼성 PAVV의 몇몇 기종이 유일한데, 이 TV들은 모두 Renderer+Controller 조합으로 구성되어 있고 Renderer만의 기능은 제공하지 않는다. 즉 다른 Controller로는 컨트롤을 할 수 없다는 얘기다.

-----------------------------------------------------------------------------------

사용 프로토콜

TCP/IP, HTTP, HTTPU, HTTPMU, SSDP, GENA, SOAP, XML

UPnP 네트워킹 단계

1. addressing

2. discovery (SSDP / GENA)

3. description (HTTP  : XML)

4. control (SOAP)

5. eventing (GENA)

6. presentation (HTTP : HTML)

- 상세 내용 -

1. addressing

-> 주소지정

각 장치는 네트워크에 접속시 주소를 할당받게 된다. DHCP서버를 검색하여 DHCP 서버가 존재시 주소가 자동 할당되며 DHCP 서버가 존재하지 않는다면 Auto IP를 사용한다.

Auto IP는 사설 IP 169.254/16 영역에서 IP주소를 자동 할당하고 IP의 사용 여부를 검사하며 IP사용시 새로운 IP를 재할당하고 IP 사용 여부가 없을 때 까지 이 동작을 반복한다.

IP할당후에도 장치는 네트워크상의 DHCP서버가 사용 가능한지 주기적으로 계속 검사한다.

2-1. Discovery - Advertisement

-> 검색 - 알림

새로운 장치에 주소가 할당되면 이 장치는 네트워크상의 제어 포인트(장치)들에게 자신의 접속 상태를 알립니다.

접속 상태를 알릴때에는 표준형 멀티캐스트용 주소(239.255.255.250 : 1900 HTTPU)로 멀티캐스트 하며 알림 내용에는 타임 스탬프를 포함시켜 자신의 유효 기간을 알려줍니다.

이 장치는 유효 기간이 만료하기 전에 알림 내용을 재 전송합니다. 그렇지 않으면 제어 포인트는 이 장비가 더 이상 유효하지 않다고 인식합니다. 또한 장치가 오프라인 모드로 전환시 연결끊김 메시지도 반디시 전송해야 합니다.

2-2. Discovery - Search

- 검색

제어 포인트가 네트워크에 추가 되었거나 장치 및 서비스를 검색하기 위해서는 SSDP 검색 메시지를 멀티캐스트하여 원하는 장치 및 서비스를 검색합니다.(표준형 멀티캐스트용 주소(239.255.255.250 : 1900 HTTPU) 모든 장치는 메시지를 수신하고 검색조건에 일치하면 응답을 합니다. 응답은 SSDP 헤더를 가진 유니캐스트 UDP를 사용하여 전송됩니다.

3. Description

-> 설명

검색 요청에 의한 응답에는 장치 설명서를 제공하는 URL을 포함하고 있습니다.

제어 포인트는 그 URL을 토하여 HTTP GET 요청을 수행하고 장치는 장치 설명서를 보내줍니다. 장치 설명서에는 서비스 설명도 동일하게 존재하며 HTTP GET요청을 수행하여 서비스 설명도 검색가능합니다.

장치에 대한 UPnP 설명은 XML 문서로서 공급업체와 관련된 정보, 포함되어 있는 장치에 대한 정의, 장치 공급 URL, 제공하는 모든 서비스 내용, 제품 제어 및 이벤트용 URL 등에 관한 정보를 포함하고 있습니다. UPnP 관련 제품 공급업체는 표준형 장치 및 서비스 설명서를 확장하여 추가적인 상태 변수, 동작 및 전체 서비스까지도 포함할 수 있습니다. 이러한 방법으로 UPnP는 기본적 표준을 준수하면서도 유연성을 제공합니다. 장치 및 서비스 설명서 샘플은 UPnP 장치 구조 문서에 포함되어 있습니다.

예 : 검색 메세지

NOTIFY * HTTP/1.1

HOST: 239.255.255.250:1900

CACHE-CONTROL: max-age=180

Location: http://192.168.1.1:5431/dyndev/uuid:0014-bf09 //<-- 설명 XML URL

NT: upnp:rootdevice

NTS: ssdp:alive

SERVER:LINUX/2.4 UPnP/1.0 BRCM400/1.0

USN: uuid:0014-bf09::upnp:rootdevice

 

설명 XML URL 내부에는 제어 URL과 이벤트 URL, SCPD URL(가용한 기능 설명)을 포함한다.

<service>

<serviceType>urn:schemas-upnp-org:service:

WANIPConnection:1</serviceType>

<serviceId>urn:upnp-org:serviceId:WANIPConnection</serviceId>

<controlURL>/ipc</controlURL>

<eventSubURL>/ipc</eventSubURL>

<SCPDURL>/ipc.xml</SCPDURL>

</service>

4. control

-> 제어

제어 포인트는 장치의 제어 URL을 통하여 장치를 제어할수 있습니다. 동작을 실행시키는 것은 일종의 원격 프로시저 호출입니다.

 

제어 메시지에는 동작 이름과 이 메시지에 포함된 독립변수 이름 및 변수를 정의하고 이들 정보는 UPnP용 포맷으로 캡슐화 되고 SOAP를 사용하여 포맷된후 TCP/IP를 통한 HTTP를 사용하여 전송됩니다.

장치는 반드시 제어 요청에 30초 이내에 응답해야 합니다. 또한 제어 포인트는 특정 서비스 변수의 상태를 질의할 수도 있습니다. 예를 들어 DVD플레이어는 DVD 시간을 포함하는 상태 병수를 알려주는 서비스를 가지고 있을 수 있고 제어 포인트를 이를 질의할수 있습니다. 그러나 각각의 질의(쿼리문)문에 대해서는 하나의 변수만이 전송됩니다.

 

 

5. eventing

-> 이벤트

장치는 자신의 이벤트에 등록된 네트워크 상의 제어 포인트에게 자신의 변화 상태를 송신할수 있습니다. 장치의 업데이트를 발행하는 것입니다. 제어포인트는 장치의 이벤트를 수신을 취소하는 것도 가능합니다. 제어포인트의 이벤트 수신 취소시 장치는 이벤트 목록에서 해당 제어포인트를 삭제합니다.

장치가 보내는 이벤트 메시지에는 구독용 URL, 구독기간, 특정 변수 값 및 변수 이름이 포함되어있고 GENA를 사용하여 포맷후 TCP/IP를 사용하여 전송합니다.

 

6. presentation

-> 표현

프리젠테이션 페이지에 대한 URL은 장치 설명서에 포함되어 있습니다. 이 페이지를 검색하려면 프리젠테이션 URL로 HTTP GET 요청을 발행할 제어 포인트가 필요합니다. 그러면 장치가 프리젠테이션 페이지 정보를 반환합니다.

UPnP Device Architecture 문서는 이 페이지를 HTML로 작성해야 한다고 명시하고 있습니다. 이 과정에서는 아버지가 제어를 위하여 장치를 조회한다는 점을 제외하고는 웹 브라우징 기법과 비슷합니다.

 

프리젠테이션 페이지의 기능은 전적으로 UPnP 제품 공급업체 의하여 지정됩니다. 프리젠테이션 페이지를 구현하기 위하여 UPnP 제품 공급업체는 장치의 기존 기능을 최대한 활용하면서 제어 기능 및 이벤트를 위한 UPnP 기능을 사용하기 원할 것입니다. 프리젠테이션과 관련하여 정의된 UPnP Forum 구성요소는 전혀 없고 전적으로 공급업체에 의하여 결정된다는 점에 유의하십시오.

UPnP에 사용되는 프로토콜 설명

종류 : 

SSDP(장치 검색 discovery), 

GENA(통보 event), 

SOAP(제어 control), 

TCP/IP, HTTP, HTTPU, HTTPMU

1. TCP/IP

TCP/IP 네트워킹 프로토콜 스택은 나머지 모든 UPnP 프로토콜을 구축하는 기반 역할을 합니다. 널리 사용되는 이 표준 TCP/IP 프로토콜을 사용함으로써 UPnP는 다른 물리적 매체를 수용하는 능력을 최대한 활용하여 다양한 공급자들이 제공하는 제품들 사이의 상호 운용성을 보장합니다.

UPnP 장치들은 TCP/IP 서비스(DHCP, DNS 등) 뿐만 아니라 TCP, UDP, IGMP, ARP , IP 등 TCP/IP 스택에 있는 많은 프로토콜을 사용합니다. 이 섹션에서 다른 프로토콜들에 대해서도 설명하고 다음 섹션에서 UPnP의 작동원리를 설명하면, 여러분들은 UPnP에 기능 구현을 위하여 이들 프로토콜이나 서비스를 사용하는 방법을 명확하게 이해할 수 있을 것입니다.

TCP/IP는 가장 널리 사용되는 네트워킹 프로토콜이므로 UPnP 기능을 가진 제품을 개발하거나 찾아서 검토하기가 비교적 쉽습니다.

이 문서는 독자가 TCP/IP 프로토콜의 기본 사항은 이해하고 있음을 전제로 하고 작성되었습니다. TCP/IP에 관한 자세한 정보를 원하시면 이 문서 끝에 있는 참고 문헌을 확인하십시오.

UPnP 프로토콜을 구축하는 기반 역할을 한다. 즉 UPnP 포로토콜을 캡슐화하는 역할을 하는 것으로 송수신의 순서 및 전달을 보장한다.

2. HTTP, HTTPU, HTTPMU

TCP/IP는 UPnP 장치들 간의 네트워크 연결성을 제공하는 기본적 프로토콜 스택을 제시합니다. 인터넷의 성공에 엄청난 기여를 한 HTTP도 물론 UPnP의 핵심적 부분입니다. UPnP의 모든 측면은 HTTP 및 이의 파생 프로토콜 기반 위에서 구축되었습니다. HTTPU (HTTPMU 포함)는 HTTP의 파생 프로토콜로서 TCP/IP가 아닌 UDP/IP를 기반으로 한 메시지 전달을 위하여 정의된 것입니다.

이 프로토콜들은 SSDP가 활용하며, 이 내용은 나중에 설명합니다. 이들 프로토콜이 사용하는 기본적 메시지 포맷은 HTTP 메시지 포맷을 따르며, 이 포맷은 멀티캐스트 통신을 하는 경우, 그리고 메시지 전달 시에 신뢰성과 관련된 오버헤드를 요구하지 않을 경우에 모두 사용됩니다.

높은 수준의 프로토콜 및 UPnP의 활용 기법에 대한 설명 내용은 여러분이 HTTP 프로토콜에 대한 기본 사항은 파악하고 있음을 전제로 합니다. HTTP에 관한 자세한 정보를 원하시면 이 문서 끝에 있는 참고 문헌을 확인하십시오.

HTTP를 기본 프로토콜로하여 유니캐스트, 멀티캐스트를 지원하는 프로토콜이다. UPnP는 모든 측면에서 HTTP 및 이의 파생 프로토콜 기반위에서 구축되었다. HTTP는 TCP/IP기반이고 HTTPU, HTTPMU는 UDP/IP 기반 위에서 동작한다.

3. SSDP

SSDP(Simple Service Discovery Protocol)는 네트워크 서비스를 네트워크 상에서 검색하는 방법을 정의합니다. SSDP는 HTTPU 및 HTTPMU 기반 위에 구축되며, 제어 포인트가 네트워크 상에서 원하는 리소스를 검색하는 방법 및 장치들이 네트워크상에서 자신들이 가용상태에 있음을 알리는 방법을 정의합니다. 검색 요청 및 가용성 알리는 방법을 정의함으로써 SSDP는 이 두 가지 방법 중에서 하나만 사용할 경우에 요구되는 오버헤드를 없애줍니다. 그 결과, 네트워크 상의 모든 제어 포인트는 네트워크 트래픽을 많이 발생시키지 않으면서도 네트워크 상태에 관한 정보를 완벽하게 파악하게 됩니다.

제어 포인트 및 장치 모두가 SSDP를 사용합니다. UPnP 제어 포인트는 부팅이 되자마자 SSDP 검색 요청(HTTPMU을 사용함)을 보내서 네트워크에서 활용 가능한 장치와 서비스를 검색합니다. 제어 포인트는 검색 결과 데이터를 정리하여 단지 특정 장치(예, VCR), 특정 서비스 또는 특정 장치만을 원하는 대로 선별할 수도 있습니다.

UPnP 장치는 멀티캐스트 포트 정보를 수신합니다. 검색 요청을 수신하자마자 장치는 일치 여부를 확인하기 위하여 검색 조건을 점검합니다. 만약 일치된 것이 발견되면 유니캐스트 SSDP (HTTPU를 사용) 응답이 제어 포인트로 전송됩니다.

이와 유사하게, 장치는 네트워크에 연결되자마자 지원하는 서비스의 사용 여부를 알리기 위하여 여러 개의 SSDP presence announcements(가용 상태 알림 정보)를 전송합니다.

presence announcements(가용 상태 알림 정보) 및 유니캐스트 장치 응답 메시지는 모두 장치 설명서의 위치 포인터를 포함하며, 여기에는 이 장치의 기본정보 및 제공 서비스에 관한 정보가 들어 있습니다.

위에서 설명한 검색 능력 외에도 SSDP는 장치 및 장치 관련 서비스가 네트워크와의 연결을 원활하게 끊는 방법을 포함하고 있으며, 또한 자체적인 문제 해결을 위하여 유해 정보를 정화하는데 사용되는 캐시 타임아웃(cache timeouts)을 포함하고 있습니다.

SSDP는 네트워크 서비스를 네트워크상에서 검색하는 방법을 정의한다. SSDP는 HTTPU 및 HTTPMU 기반 위에 구축되며 제어포인트가 네트워크 상에서 원하는 리소스를 검색하는 방법 및 장치들이 네트워크상에서 자신들이 가용 상태에 있음을 알리는 방법을 정의합니다. 제어포인트 및 장치 모두가 SSDP를 사용합니다.

제어포인트는 네트워크 접속시 멀티캐스트 HTTPMU를 기반으로한 SSDP를 송신하고 장치들은 이를 수신하여 검색조건에 맞을시 유내캐스트 HTTPU를 기반으로한 SSDP를 송신합니다. 또한 장치는 자신의 가용 상태를 알리는 정보를 GENA를 통해 같이 전송합니다.

SSDP는 장치를 원할히 끊는 방법을 포함하고 또한 타임스탬프가 존재하여 장치의 가용 시간을 정해줍니다.

4. GENA

GENA (Generic Event Notification Architecture)는 TCP/IP를 통한 HTTP 및 멀티캐스트 UDP를 사용하여 통보(notifications)를 송수신하는 기능을 제공하기 위하여 정의되었습니다. 또한 GENA은 이벤트 실행을 위하여 가입자 및 통보 발행자의 개념을 정의합니다.

UPnP는 GENA 포맷을 사용하여 존재 발표 내용을 생성한 후에 SSDP 프로토콜을 통하여 전송하고 UPnP 이벤트 작업의 서비스 상태 변화를 신호로 알려주는 기능을 합니다. 이벤트 통보를 수신 받고자 하는 제어 포인트는 원하는 서비스, 이벤트 송신 위치 및 이벤트 통보 구독 시간을 포함하는 요청을 송신함으로써 이벤트 소스에 가입합니다.

가입 내용은 주기적으로 갱신되어 지속적으로 통보되며, GENA를 사용하여 가입을 취소하는 것도 가능합니다.

GENA는 장치의 알림을 송수신하기 위한 기능을 제공합니다. 

장치의 접속을 알리는 단계에서는 HTTPMU(UDP/IP)기반에서 적용되고 , 알림(eventing) 단계에서는 HTTP 기반의 TCP/IP에서 동작합니다. 중요한 것은 GENA는 결국 알림을 위하여 존재하는 프로토콜입니다. 또한 GENA는 가입자 및 통보 발행자의 개념이 존재합니다. 

UPnP는 GENA 포맷을 사용하여 존재 발표 내용을 생성한 후에 SSDP 프로토콜을 통하여 전송하고 UPnP 이벤트 작업의 서비스 상태 변화를 신호로 알려주는 기능을 합니다. 

이벤트 통보를 수신 받고자 하는 제어 포인트는 원하는 서비스, 이벤트 송신 위치 및 이벤트 통보 구독 시간을 포함하는 요청을 송신함으로써 이벤트 소스에 가입합니다. 

가입 내용은 주기적으로 갱신되어 지속적으로 통보되며, GENA를 사용하여 가입을 취소하는 것도 가능합니다.

 

5. SOAP

SOAP (Simple Object Access Protocol)는 XML 및 HTTP의 용법을 정의하여 원격 프로시저 호출을 실행합니다. 이것은 인터넷을 통한 RPC 기반 통신의 표준이 되어가는 추세이며, 기존의 인터넷 인프라를 통하여 방화벽 및 프록시에서 아주 효율적인 기능을 수행합니다. SOAP는 또한 보안용으로 SSL (Secure Sockets Layer)을 활용하고 HTTP의 연결 관리 기능을 활용함으로써 인터넷을 통한 분산형 통신을 웹 페이지에 접속하는 것 만큼이나 쉽게 만듭니다.

원격 프로시저 호출과 유사하게, UPnP는 SOAP를 사용하여 제어 메시지를 장치들로 전송하며 그 결과 및 오류 내역을 제어 포인트로 반환합니다.

각 UPnP 제어 요청은 실행할 동작 및 일련의 매개 변수를 포함하는 SOAP 메시지 입니다. 그 응답도 또한 SOAP 메시지이며 상태, 반환 값(return value) 및 모든 반환 매개 변수를 포함하고 있습니다.

SOAP는 XML 및 HTTP의 용법을 정의하여 원격 프로시저 호출을 실행합니다. 이것은 인터넷을 통한 RPC기반 통신의 표준이 되어가는 추세입니다. 원격 프로시저 호출과 유사하게, UPnP는 SOAP를 사용하여 제어 메시지를 장치들로 전송하며 그 결과 및 오류 내역을 제어 포인트로 반환합니다. 각 UPnP 제어 요청은 실행할 동작 및 일련의 매개 변수를 포함하는 SOAP 메시지 입니다. 그 응답도 또한 SOAP 메시지이며 상태, 반환 값(return value) 및 모든 반환 매개 변수를 포함하고 있습니다.

6. XML

XML(Extensible Markup Language)은 웹 상의 구조화된 데이터를 위한 범용 포맷을 말합니다. 달리 표현하면 XML을 사용하면 거의 모든 형태의 구조화된 데이터를 텍스트 파일로 만들 수 있습니다.

XML은 태그와 특성(tags, attributes)을 사용한다는 측면에서 보면 HTML과 유사한 점이 많습니다. 하지만, XML은 그러한 태그와 특성들이 일반적으로 정의된 것이 아니라 사용되는 컨텍스트 내에서 해석된다는 관점에서 보면 상당히 다릅니다. XML의 이러한 특징 때문에 다양한 문서 형태에 적합한 스키마를 정의하는데 아주 적합하다는 것입니다. 스키마 언어로서의 XML 사용법은 W3C에 의하여 정의되었습니다.

XML은 장치 및 서비스 설명서, 제어 메시지 및 이벤트에 사용되는 UPnP의 핵심적 부분입니다.