DPDK 2.0

Release note from

Changelog (main changes since 1.8.0)
– enhancements:
* ABI versioning
* x32 ABI
* non-eal thread supports
* multi-pthread per core
* enable big contigmem blocks in BSD
* port hotplug
* jobstats library
* reorder library
* memcpy optimization
* acl for AVX2
* crc hash arch-independent
* uio_pci_generic support
* kni optimizations
* vhost-user support
* virtio (link, vlan, mac, port IO, perf)
* ixgbevf RSS
* i40e hash filtering
* i40e nvgre offloading
* i40e TSO
* fm10k driver
* mlx4 driver
* bonding mode 4 tests
* bonding mode 6
* Rx/Tx callbacks
* unified flow types
* remove old filtering API (flow director, flex, ethertype, syn, ntuple)
* remove static tailqs from EAL
* remove device arguments limit
* add indirect attached mbuf flag
* use default port configuration in testpmd
* tunnel offloading in testpmd
* PDF doc output
* NICs guide
– fixes for:
* build
* memory leaks
* big endian
* devargs
* kvargs
* cmdline
* timer
* lpm
* pipeline
* bonding
* vhost
* virtio
* pcap
* igb
* ixgbe
* i40e
* enic
* testpmd


Charting the path to RAN virtualization

Charting the path to RAN virtualization

C-RAN means

  • Centralized : Centralized processing resource pool supports 10-10,000 cells
  • Collaborative : Multicell joint scheduling and interference management
  • Cloud
  • Clean


  • H/W accelerator for L1 function FFT/IFFT channel encoding/decoding
  • “Recent Progress on C-RAN Centralisation and Cloudification” Chih-Lin I
  • CPRI compression
  • RAN and core within the shared NFV platform -> closer to each other and remove the sharp demarcation line that has separated the two.


  • One fiber connection provides 6Gbps
  • 9.8Gbps per carrier(FA). Doubled for bi-direction.
  • 3 carrier = 9.8G23 = 58.8Gbps
  • CPRI compression ration 50%
  • WDM(Wavelength-Division Multiplexing) : fewer finer connection compared to dark fiber which is native frontal solution that has the best performance
  • Three way for C-RAN/v-RAN adoption
    • Reduce frontal requirements by using functional split – enable some functions to be virtualised while the others remain distributed
    • Improve the efficiency of the fronthaul – pack more traffic
    • Use wireless alternative where fiber is not unavailable or too expensive

Dark-Fiber alternative

  • OTN(Optical Transport Network)
  • PON(Passive Optical Network)
  • CPRI over Ethernet(CoE)
    *outdoor small cell frontal in dense urban areas

    • higher latency than Dark-fiber
  • Wireless
    • outdoor small cell frontal
    • Suitable for short distance and relatively low capacity requirement

CPRI alternative

  • CPRI : 0.4ms latency, very low jitter
    • But not standard-based
    • ETRI’s ORI – Standardized CPRI for interoperability
  • Ethernet : should be carefully managed end-to-end to meet the CPRI’s performance

Split funtionalities

Functional split to reduce fronthaul requirement
PHY is L1 function which requires FFT/IFFT


Need 20-50x bandwidth than PHY-MAC
eICIC and CoMP can be implemented effectively, so the C-RAN can manage interference effectively.


  • Coordinated transmission can not implemented in the pooled BBU as there are L1 functions instantiated at the cell sited(PHY)
  • Macro-only network, this can be acceptable trade-off

Central scheduler based scheduling can be another option. MAC-level coordination among cells has lower latency and bandwidth requirements and ethernet can be used for this.

Functions in each layer

  • L3
    • Control RRC
  • L2
    • PDCP
    • RLC
    • Transport MAC
  • L1
    • CoMP
    • eICIC
    • Channel decoding/coding
    • Quantization/De-
    • Resource Block mapping
    • Sampling/De-
    • Modulatio/De-
    • FFT/iFFT

Cost reduction with vRAN

  • 30% in capex – mainly from equipment and installation cost
  • 54% in opex – lower site rental
  • Resource utilization
  • Mobility management
  • Robust interference management

Leveraging uneven traffic distribution



The OpenConfig work group, led by Google, has taken a step toward a vendor-neutral model for network configuration and policy.

OpenConfig와 NetConf간의 관계는 어떻게 되는 걸까?

BGP Configuration Model for Service Provider Networks describes a Yang data model for configuring and managing BGP routing implementations.



nDPI : Open-Source High-Speed Deep Packet Inspection pdf

논문을 다 읽고 나니 ntop을 만든 곳에서 만든 거라는 걸 알게 되었다.

기존에 존재하는 OpenDPI가 개발자가 상용화로 방향을 바꿔 더 이상 관리가 되지 않아 이를 개량한 것이 nDPI라고.
철저하게 open source로 개발하고, OpenDPI가 제공하지 않는 meta data extraction도 제공한단다. Open source로 개발하는 이유는 DPI 특성상 계속해서 라이브러리의 개량이 필요한데 한 두 사람이 할 수 있는 일이 아니라고 생각했기 때문이라고. 물론 상용화를 해서 그 일만 담당하는 직원이 있어도 가능하겠지만, 현실적으로 기존에 존재하는 major vendor와의 경쟁을 생각하면 그리 쉬운 일은 아닐 거다. 기존 업체가 제공하지 않는 기능을 제공하거나 정확도 혹은 성능이 좋은 제품을 제공하면서 동시에 많은 protocol을 인식해야 할 텐데 그럴려면 많은 투자가 필요한데 기능, 성능의 우수성은 차지하고 protocol 개수는 닭과 달걀의 문제가 될 수 있다. 그런 면에서 open source로 개발한 것은 좋은 판단이라고 생각되는데 nDPI를 이용한 reference system의 발굴이 더욱 중요하다.

DPI is a time-consuming activity as protocols (in particular P2P) change quite often. This means that it’s necessary to update the code from time to time and add extensions. We would encourage anyone out there to help us adding or enhancing new protocols: we will put your contributions on our SVN and make them available to everyone free of charge. In fact the main reason why we decided to go for nDPI instead of using the original library, is that the company behind OpenDPI has never replied to our offers to merge the extensions we coded onto the original source code

C로 작성되어 있고, core library와 plugin dissector로 구성되어 있다(Wireshark과 유사한 구조. Wireshark도 지속적으로 추가될 프로토콜을 지원하기 위해 이런 구조를 가지고 있다)

OpenDPI가 가졌던 non-thread safe 구조를 개선해서 많은 global 변수 등을 제거했다고.

동적으로 configuration을 변경할 수 있어 동작 중에도 protocol header만으로 판단할 수 있는 경우를 손쉽게 추가할 수 있다고(반면 OpenDPI는 모든 지원 프로토콜은 dissector를 가져야 한다고 가정해서 새로운 프로토콜을 지원하려면 무조건 라이브러리를 변경해야 했다고. 반면 nDPI는 configuration을 통해 TCP/port-X는 protocol Y와 같이 추가할 수 있다고)

nDPI는 linux kernel 혹은 user-space application으로 사용할 수 있음.

잘 알려진 UDP 기반 프로토콜 – DNS, NetFlow 그리고 SNMP등은 1개 패킷만으로 판단이 가능하지만, BitTorrent는 8개 가량의 패킷이 필요했다고

HTTPS의 경우 초반에 SSL 동작에 필요한 initial key exchange를 분석해서 판단한다고. 이때 접근하는 서버의 이름을 통해 대략적인(?) 서비스를 추정한다고.

The trend of Internet traffic is going towards encrypted content often using SSL. In order to let nDPI support encrypted connections, we have added a decoder for SSL (both client and server) certificates, thus we can figure out the protocol using the encryption certificate. This allows us to identify protocols such as Citrix Online and Apple iCloud that otherwise would be undetected.

필요한 경우 IP 기반의 검출도 수행. iTunes나 iMessages는 Apple이 소유한 IP주소의 서버로 메시지를 보내므로 이 정보를 활용



ZeroMq aka ZMQ.

Message-oriented communication

기존의 BSD socket이 Stream(TCP) 혹은 Datagram(UDP) 의 2가지 서로 다른 방식을 제공하고, 각각의 socket을 사용하기 위해서는 socket을 여는 함수인 socket()을 제외하곤 서로 다른 API를 사용해야 했다. 이와 달리 ZeroMq는 Message oriented 통신 방법이라고.

ZMQ의 특징을 기술한 말을 보면

abstract some of the low-level details of different socket types, connection handling, framing or even routing
zero-copy semantics, optimized framing and no locking data structure

TCP와 달리 application에서 buffering이나 framing을 고민할 필요가 없다고.

Feature list는 여기 참고

Stream/Datagram 방식에서 message-oriented model로 변경한 것이 어떤 의미가 있는 지 실감되지 않는데… 특징을 보면 충분히 매력적으로 보인다.


  • Transport agnostic sockets
  • In-process, IPC, multicast, TCP 등을 지원하고, 4가지 방식 사이에서 원하는 방식으로 간단하게 바꿀 수도 있고, 동시에 두 가지 이상의 방식을 사용할 수도 있는 듯
  • 덕분에 처음 한 가지 방식으로 구현한 후 필요에 따라 다른 방식으로 변경하는 것이 bind 명령어 옵션만 바꾸면 된다고.
  • Routing & Topology aware sockets
  • 하나의 socket이 2개 이상의 다른 port에 bind해서 메시지를 수신할 수도 있고, 하나의 API 호출로 서로 다른 여러 socket에 메시지를 보내는 것도 가능하다
  • Publisher/Subscriber – unidirectional from publisher to subscriber. 하나의 send 호출이 모든 subscriber에 메시지를 보냄.
  • Request/Reply – bidirectional. 하나의 server에 여러 client가 연결되어 있을 때는 자동으로 message는 load balancing되어 오직 하나의 client에만 전달 될 수 있다. (FIXME. 어떤 방식으로 load balancing selection되는 지 확인 필요)
  • Push/Pull – unidirectional and load balanced.
  • 별도의 message broker나 load balancer가 필요하지 않음.

ZMQ socket을 열면 library 내부에서 하나의 I/O thread를 생성하고, 이 thread가 connection setup, teardown, reconnect 등을 수행함.

활용 예) Mongrel 2

외부에서의 request를 처리하기 위해 request를 받은 후 Push/Pull 형태의 ZMQ 소켓을 이용하여 여러 client중 하나에게 보내 처리하게 함. 별도로 application에서 load balancer를 구현할 필요가 없어 간단함.


출처 ZeroMQ : Modern & Fast Networking Stack



예전에 같이 일하던 직원이 수년 전에 퇴사했는데 어쩌다 보니 최근 각광받고 있는 어떤 기술에 대한 국내 첫번째 책의 공동저자였다.

난 그동안 뭘 한거지? 사내 정치에 환멸을 느끼며, 불합리한 프로세스에 불만만 가지고 있었지 정작 제대로 아는 게 없다.

자괴감이 든다.

news, note

Open Source NFP

NFV Approaches Phase 2, With Help from the Linux Foundation

ETSI는 코드를 만들어내지 않지만, 이제 대략적으로 뭘 원하는 지 정리가 되었으니(아직 NFV Group Specifciation 업데이트 된 게 나와야겠지만) 실제 동작하는 코드가 필요하다고. OpenDayLight(ODL)이 그랬던 것처럼 실제로 동작하는 Reference code가 있어야 개발 속도를 높일 수 있다. 문제(?)는 ODL이 그랬던 것처럼 하나의 reference system이 만들어지면 그 reference system과는 다른 것들은 모두 죽어버린다는 것.

이번에도 Linux Foundation이 실질적인 리드를 하기 위해 7/1일에 AT&T, HP, Intel, Linux Foundation 담당자들이 모였다고 한다.Open Source NFV Plans