Analysis on recent hot issues and key technologies
10월 6일에 ETRI에서 발표한 자료입니다.
목차는 다음과 같습니다.
1. Overview (10-Year Trend)
2. Walled-Garden CDN
3. OTT (Over-The-Top) 서비스 및 기술 분석
4. Operator CDN
5. CDN Comparison (Pure-Play CDN, Operator CDN)
10/20/2011 | CDN, BT, Akamai, Walled Garden CDN, Operator CDN
OTT (Internet Video) 서비스에 대한 통신 사업자의 대응 분석 보고서의 두 번째로 통신 사업자가 OTT 서비스와 경쟁을 하기 위해 내놓고 있는 통신 사업자의 TV Everywhere (Multi-Screen) 서비스의 현황을 분석한 보고서입니다. OTT 사업자가 처음에는 PC에서 서비스를 시작하여 모바일 단말과 TV로 서비스 가능한 단말을 확장해 나가는 추세이고 통신 사업자는 처음에는 집TV상으로 Live TV와 VoD 서비스를 제공하다가 OTT와 경쟁하기 위해 PC와 모바일 단말에서도 Live TV, Vod 등의 서비스를 제공하기 시작하고 있습니다. 본 보고서에서는 이러한 통신 사업자의 Multi-Screen 서비스 현황에 대해 자세히 ...
08/17/2011 | OTT, CDN, Operator CDN, Wholesale CDN, Multi-Screen
북미에서는 OTT (Internet Video) 사업자들이 기존의 통신 사업자들이 제공하던 비디오 서비스에 큰 위협을 주고 있습니다. Netflix, Huluplus, Amazon 등 많은 OTT 사업자들이 있지만 본 보고서에서는 유료 가입자수와 매출액 측면에서 제 1 사업자인 Netflix를 분석하였습니다. Netflix는 기존의 방송 서비스 업계의 골리앗인 Comcast의 유료 TV 가입자수를 누른 최초의 유료 비디오 사업자입니다. 본 보고서에서는 OTT 서비스의 정의, Netflix의 성공, 그리고 성공 요인을 분석하였습니다.
08/13/2011 | OTT, Netflix, HTTP Adaptive Streaming
Analysis on all aspects of network core technology
EMM 절차 문서 중 두 번째 문서로, EMM 시나리오 편에서 정의했던 EMM Case 2, 즉 LTE 망에서 서비스를 이용 중이던 사용자가 Detach 하는 경우에 대한 Detach 절차를 다룬다. Detach triggering이 발생하는 엔터티별로 UE-initiated Detach, MME-initiated Detach 및 HSS-initiated Detach 절차를 기술하고, Detach 절차 전•후로 EPS 엔터티 내에 정보들이 어떻게 변경되는지 살펴본다.
LTE, EMM
LTE EMM Procedure: 1. Initial Attach for Unknown UE 1편에 이어 EMM Case 1에 대한 망 초기 접속 절차를 다룬다. 이번 글(2편)에서는 처음으로 망에 접속하는 사용자의 초기 접속 절차를 (1) Acquisition of IMSI, (2) Authentication, (3) NAS Security Setup, (4) Location Update, (5) EPS Session Establishment로 나누어 상세히 소개한다.
LTE, EMM
EMM 절차 문서 중 첫 번째 문서로, EMM 시나리오 편에서 정의했던 EMM Case 1, 즉 LTE 망에 처음으로 접속하는 사용자에 대한 초기 접속 절차를 두 차례에 걸쳐서 다룬다. 먼저 1편(이번 글)에서는 여러 초기 접속 형태를 구분하고 초기 접속 절차를 구성하는 기능 단위를 구별하여, 초기 접속 형태별로 다른 초기 접속 절차를 설명한다. 이어서 2편(다음 글)에서는 EMM Case 1 초기 접속 절차를 상세히 기술하고, 초기 접속 절차 전•후로 EPS 엔터티 내에 정보들이 어떻게 변경되는지 살펴본다.
LTE, EMM
Netmanias blog that talks about network technolgoies easily
오늘은 유선통신사업자망에서 사용되는 DHCP Option 82에 대해서 설명드리겠습니다.이 글을 보시는 대부분은 집에서 KT나 SKT, LG U+의 유선 인터넷 서비스를 사용하고 계실 것입니다. 통신사업자에 가입하여 인터넷을 사용한다는 것은 곧 "가입자는 통신사업자에 월정액을 지불하고 통신사업자가 제공하는 인터넷 서비스를 사용한다"는 것인데요. 그렇다면 통신사업자는 가입자를 식별하여 내 가입자인지 아닌지, 혹은 월정액을 잘 내고 있는 가입자인지 아닌지를 판단하고 그에 따라 인터넷 서비스를 제공하는 것이 일반적인 룰일 것입니다.그렇다면 유선통신사업자는 어떻게 가입자를 식별하여 인터넷 서비스를 제공할지 아니면 차단할지 결정할 수 있을까요?혹시 기억하실 지 모르겠지만, 예전에는 PPP라는 걸 사용해서 "가입자 식별/인증"과 "IP 주소 할당"을 했었는데요. 근데 PPP를 사용하려면 PC에 PPP 프로그램이 설치되야 하고 매번 PC를 킬 때마다 ID/PW 입력을 해야 하고... 이게 영 불편하잖아요. 또한 PPP 프로그램 인스톨/설정이 잘 안되어 통신사업자에 AS 신청하는 고객이 자꾸 늘어나 통신사업자 입장에서는 AS 비용이 늘어나는 문제(OPEX 증가)도 있었구요.그래서 지금은 대부분 PPP를 사용하지 않고 DHCP를 사용해서 가입자 단말에 "IP 주소"을 할당합니다. 근데 DHCP 프로토콜은 "가입자 인증" 방법을 제공하지 않습니다. (ID/PW 기반의 인증이 없다는 거죠) 그래서 Option82가 나오게 된 것이구요. 이 DHCP Option 82를 "회선 인증"이라고도 부릅니다. 집안에 PC와 연결된 첫번째 네트웍 장비(DSLAM, OLT 혹은 L2 switch - 우리 집은 L2 switch에 연결됨)에서 Option 82를 지원하게 되면, PC에서 보낸 DHCP 패킷에 이 네트웍 장비가 Option 82 필드를 붙여서 DHCP 서버에 전달합니다. 그리고 DHCP 서버는 Option 82 필드가 유효한 경우에만 가입자에게 IP 주소를 할당해 주고요. 이와 같이 Option82를 통해 가입자를 식별 및 인증을 하게 되는 것입니다.예를 들어 설명드리겠습니다. 우리집 PC는 KT L2 switch 1번 포트에 연결되어 있습니다. (매달 2만5천원씩 내고 인터넷 사용하는 아주 정상적인 가입자죠) 근데 옆집은 KT 가입자가 아닌데, 관리사무소장이랑 친해서 아파트내 KT L2 switch 있는 곳으로 잠입하여 자기집과 연결된 포트를 KT L2 switch 2번 포트에 연결한 것입니다.(당근 KT 모르게...) 이 경우, 우리집은 정상적으로 KT에 가입한 것이므로 KT가 L2 switch 1번 포트에서 들어오는 DHCP 메시지에는 Option 82 필드를 설정(Provisioning)해 놓았을 것이지만, L2 switch 2번 포트에는 설정을 해 놓지 않았겠죠 (왜냐면 KT 가입자가 연결되어 있지 않은 Port 이므로...) 이 경우 우리 옆집은 PC를 켜도 KT DHCP 서버에서 IP 주소를 할당 받지 못할 것입니다. 왜냐면 DHCP 패킷에 Option 82 필드가 없을테니까요... (제가 예를 KT로 들었지만, 현재 국내통신사업자는 Option 82를 사용하고 있지 않는 것으로 알고 있습니다. KT의 경우 "신인증"이란 개념으로 가입자를 식별/인증하고 (MAC 기반 인증), SKT, LG U+는 현재 인증을 하고 있지 않는 것으로 알고 있습니다.)아래 그림은 앞에 설명드린 개념을 도식화한 것입니다. (그림상에 Option 60, 61이 함께 표시되어 있는데 이는 일단 무시하세요~) 가입자와 연결되어 있는 첫번째 네트웍 장비(L2 SW or DSLAM)에서 가입자가 보낸 DHCP 패킷에 Option 82를 붙여 주기 위해서는 다음 기능들이 준비되어 있어야 합니다.먼저 L2 SW/DSLAM/OLT는 DHCP Snoop 기능을 지원해야 합니다. DHCP Snoop이란 쉽게 말해서 "나를 목적지를 오는 패킷(DHCP)이 아닌데 중간에서 이 패킷을 까보고, 필요하면 이 패킷의 필드를 수정 혹은 새로운 필드(Option 82)를 추가하는 기능" 입니다.L2 SW/DSLAM/OLT의 각 가입자 포트마다 서로 다른 Option 82 필드를 붙여 주어야 하는데, 이를 위해 L2 SW/DSLAM/OLT의 각 가입자 포트별로 서로 다른 Option 82 필드가 Provisioning 되어 있어야 합니다.DHCP 서버 역시 Option 82 필드를 미리 DB에 가지고 있어, 유효한 Option 82 필드를 달고 DHCP 패킷(DHCP Discover/DHCP Request)이 들어온 경우에만 이에 대한 응답(DHCP Offer/DHCP Ack)을 주어야 합니다.이 Option 82 필드의 생김이 궁금하신 분을 위하여 예전에 ADSL2+ 기반의 TPS 망 컨설팅시에 사용되었던 예를 보이면서 오늘 글을 마치겠습니다.-///@MDF-location: DSLAM이 위치한 MDF site의 코드명DSLAM-location: MDF내에 여러개의 RACK에 장비들이 있을텐데, 여기서 DSLAM의 위치를 식별할 unique한 코드Slot: 유효한 가입자가 연결된 DSLAM의 slot #Port: 유효한 가입자가 연결된 DSLAM의 port #VPI/VCI (PVC): ADSL2+는 ATM 기술을 사용하였으므로 Port내의 VPI/VCI #MDF-name: MDF의 unique한 이름예제) Asd-Blm (네덜란드 암스테르담에 위치한 어느 MDF)에 위치한 DSLAM의 slot 3번, port 16번에 VPI/VCI=1/34에 대한 Option 82 string 20058-008/03/16/1/34@Asd-Blm
01/27/2012 | DHCP, DHCP Option 82
P2P(Peer-to-Peer) 혹은 BitTorrent라는 프로그램에 대해서 많이 들어 보셨을 겁니다. BitTorrent는 P2P 방식의 대표적인 프로그램이지요.
그럼 현재의 P2P는 과연 장점만 가지고 있을까요?
이번 코너에서는 P2P를 사용자 입장과 통신사업자 입장으로 나누어 그 장단점을 소개할까 합니다.
먼저 좋은 얘기부터 시작 하지요.
아래 그림을 보시면 일반적인 "서버-클라이언트" 방식의 파일 다운로드(좌측)와 "P2P" 방식의 파일 다운로드(우측) 방식의 비교를 나타낸 것입니다. 그림 하단의 그래프를 보시면 아시겠지만(실제 테스트 결과) 사용자 입장에서는 P2P 방식의 파일 다운로드 속도가 기존 방식(서버-클라이언트 방식) 대비 현저하게 빠름을 볼 수 있습니다. 사용자 입장에서는 다운로드 속도가 빠른게 장땡이지요~*
P2P는 하나의 파일을 작은 단위로 쪼개어 (이를 Piece라 부름) 다수의 클라이언트(여러분들이 사용하는 PC)들로 부터 서로 다른 조각(Piece)들을 다운로드를 받기 때문에 기존 방식 대비 그 속도가 빨라진 것입니다. 파일을 다운로드 받는 다수의 클라이언트를 Peer들 혹은 Peer List라고 부릅니다. P2P 방식에 대한 자세한 설명은 다음에 하겠습니다.
그러면 이번에는 좀 더 큰 그림(아래 그림)을 보여 드리도록 하겠습니다. 지구상에는 여러 나라가 있고, 각 나라마다 통신사업자가 있습니다(대한민국에 KT, SKT, LG U+가 있고, 일본에는 NTT, KDDI등이 있고, 미국에는 AT&T, Verizon등이 있는 있음).
P2P의 문제는 내가 다운로드 받고자 하는 파일을 내가 위치한 지역과 가까운 곳에서 다운로드 받으면 좋은데 그렇지를 못합니다. 즉, 아래 그림과 같이 한국에 있는 "길동이"가 "혹성탈출"을 다수의 클라이언트들(Peer들)로 부터 다운로드 받는데, 그 다수의 클라이언트들이 한국에만 위치해 있는게 아니고, 미국, 동남아, 남미, 중동 등 여러나라에 흩어져 있는 것이지요. 그 이유는 "혹성탈출"을 공유해 줄 수 있는 클라이언트들(Peer List)을 Tracker라는 서버(일반 개인이 운영하는 서버임. 예. torrentdown.kr)가 무작위로 선정하여 "길동이"에게 알려주기 때문입니다. 이렇게 되면 사용자나 통신사업자 입장에서 그리 유쾌하지 않은 이슈가 발생하는데요.
[사용자 입장]
근접한 지역에서 다운로드 받을 때와 비교했을때 다운로드 속도가 느리겠지요.
[통신사업자 입장]
일전에 TIC(Transparent Internet Caching)에서도 설명을 드렸던 내용인데요. 일반적으로 통신 사업자는 전세계 어느 곳과도 통신이 가능하도록 하기 위해 타사업자와 Internet 연결을 하고, 트래픽 사용량 만큼 서로간 돈을 지불하는 식입니다. 만약 KT 가입자인 "길동이"가 "혹성탈출"을 KT 가입자들만 구성된 Peer List로 부터 다운로드 받으면 KT는 돈이 들 필요가 없는데, 이와 같이 미국, 동남아, 중동 등에서 가지고 오게 되므로 타사업자와의 Internet 연결에 트래픽이 계속 발생하여 그 사용량 만큼 타사업자에게 돈을 지불해야 하는 상황이 발생합니다.
요약해서 설명드리자면.
[사용자 입장]
기존 "클라이언트-서버" 방식 대비 다운로드 속도가 빨라서 좋다!
하지만 더 빠르면 좋겠다! 어떻게? 나와 근접한 Peer들로 부터 다운로드를 받으면 되는데 현재는 그런 로직이 없다. 그래서 재수 없으면 미국, 동남아, 중동, 남미 같은데서 다운로드 받을 수도 있다.
[통신사업자 입장]
내 가입자 안에서만 Peer들 선택이 되면 돈 들일이 없는데, Peer들이 무작위로 선정되는 바람에 타사업자에게 Internet Transit 비용을 지불해야 한다.
01/25/2012 | P2P, BitTorrent
어제 올린 문제 "왜 두 서버간에 통신이 되지 않을까요?"에 대한 답변 시간입니다.
아래 그림을 보면서 설명 드리겠습니다.
(1) 먼저 Server 1의 IP 주소와 Subnet Mask를 보면 10.25.2.4/25입니다. 이를 IPSubnetter 프로그램을 통해 살펴 보면, 10.25.2.4/25와 동일 네트웍(동일 서브넷, 동일 LAN)에 있는 IP 주소 Range는 그림의 붉은색 박스와 같이 10.25.2.1 ~ 10.25.2.126입니다. 즉, 이 주소 대역의 Host와는 라우터(Default Gateway)를 거칠 필요 없이 바로 통신이 가능하다고 Server 1은 생각합니다.
(2) 이제 Server 1에서 ping 10.25.2.68을 합니다.
(3) Destination IP 주소인 10.25.2.68은 (1)에서 설명드린 Server 1과 같은 네트웍(10.25.2.1 ~ 10.25.2.126)에 속한 주소입니다. 따라서 Server 1은 이 목적지 주소가 자기와 동일 네트웍에 있다고 판단하고 이 목적지 주소로 바로 ARP Request를 보냅니다(브로드캐스트). ARP Reqeust를 하는 목적은 목적지 Host의 MAC 주소(이 경우는 Server 2의 MAC 주소)를 알아내기 위함입니다.
(4) 본 ARP Request(Target IP = 10.25.2.68)는 이제 Router로 도달하게 됩니다. 근데 Router가 받은 ARP Request의 Target 주소는 자신의 주소(10.25.2.1)가 아닌 다른 주소(10.25.2.68)인거죠. 이런 경우 즉, ARP Request의 Target 주소가 자신이 아닌 경우 라우터는 ARP Request 패킷을 무시합니다.
이와 같이 되면 Server 1은 ARP Request에 대한 응답을 받지 못하게 되고, 결국 Server 1은 Ping(정확히는 ICMP Echo Request 패킷이라 부르죠) 패킷을 내보내 보지도 못하게 됩니다.
그래서 두 서버간에 통신이 되지 않게 되는 겁니다 (물론 Server 2에서 Server 1으로의 Ping도 안됩니다.)
본 문제는 실제 말레이지아 Y사의 IMS 망 구축시에 있었던 이슈로 서버 담당자가 Subnet Mask를 잘못 설정하여 발생하였던 것입니다. 그럼 이제 정상적인 설정하에 두 서버간에 Ping 통신에 대해서 보여 드리도록 하겠습니다.
일단 두 서버의 Subnet Mask를 "/25"에서 "/26"으로 수정해야 합니다.
(1) Server 1의 IP 설정 10.25.2.4/26을 IPSubnetter 프로그램을 통해 살펴 보면, Server 1과 동일 네트웍에 있는 IP 주소 Range는 10.25.2.1 ~ 10.25.2.62가 됩니다. (이제는 Server 1과 Server 2가 다른 네트웍으로 나누어 진거죠)
(2) Server 1에서 Ping 10.25.2.68을 합니다.
(3) Destination IP 주소 10.25.2.68은 Server 1과 다른 네트웍에 존재하는 Host입니다. (10.25.2.62까지가 Server 1과 동일 네트웍임) 따라서 Server 1은 목적지 주소인 10.25.2.68에 대한 ARP Request를 하지 않고, 자신에게 설정된 Default Gateway(그림에서는 보이지 않았으나 Server 1과 연결된 Router의 Interface 주소인 10.25.2.1로 설정되어 있다고 가정함)로 ARP Request를 보냅니다.
(4) ARP Request(Target IP=10.25.2.1)를 수신한 Router는 자신의 Interface 주소 10.25.2.1에 대한 MAC 주소를 실어서 ARP Reply 패킷을 Server 1으로 보냅니다.
(5) 이제 Server 1은 "10.25.2.68를 목적지로 하는 Ping" 패킷에 대한 Destination MAC 주소(여기서는 Router MAC)를 알았으므로 Ping 패킷을 Router로 보내게 됩니다. 그리고 이를 수신한 라우터는 자신의 라우팅 테이블을 참조하여 이 패킷을 Server 2로 전송하게 됩니다. (Router에서 Server 2로 Ping 패킷을 보내기 전에도 ARP operation이 있으나 생략)
01/20/2012 | Subnet, Routing
Technology wallchart that shows trends and technologies into one page
Microsoft Silverlight Smooth Streaming - Workflow
Microsoft Silverlight Smooth Streaming - Workflow
북미 Operator Multi-Screen (TV Everywhere) Service Deployment (Part 2)
Operator Multi-Screen (TV Everywhere) Service Deployment in North ...
Netmanias Site News
ContentShare
인터넷 자료실입니다.
Netmanias Research
Click above image for details
Netmanias Consulting Services
