KR101803332B1 - 사물 인터넷 네트워크 시스템 - Google Patents

Abstract

본 발명은 사물 인터넷(IoT; Internet of Things)의 패킷 제어를 SDN(Software Defined Network) 기반의 네트워크에서 제어하는 네트워크 시스템에 관한 것으로, 서비스 기능을 가상화하고 일련의 서비스 기능이 적용되도록 하여, 운용의 자동화 및 IoT 장치별로 소프트웨어의 유지/보수 및 업그레이드를 용이하게 할 수 있는 네트워크 시스템에 관한 것으로, 상기 시스템은, 공통 게이트웨이로서, 복수의 IoT(Internet of Things) 장치와 통신하는 서로 다른 인터페이스 모듈을 구비하는 통신부; 및 상기 통신부를 통해 인입한 플로우에 상기 플로우의 패킷이 인입한 인터페이스를 식별하는 인터페이스 식별자를 구비하는 서비스 식별자를 상기 플로우에 할당하는 오픈플로우(openflow) 기반의 게이트웨이 스위치를 구비하는 상기 공통 게이트웨이; 및 상기 공통 게이트웨이로부터 전달받은 플로우에 상기 인터페이스 식별자에 대응하여 인터페이스 별로 일련의 서비스 기능을 제공하는 서비스 기능 클라우드를 포함할 수 있다.

Description

사물 인터넷 네트워크 시스템{NETWORK SYSTEM FOR INTERNET OF THINGS}

본 발명은 사물 인터넷(IoT; Internet of Things)의 패킷 제어를 SDN(Software Defined Network) 기반의 네트워크에서 제어하는 네트워크 시스템에 관한 것으로, 서비스 기능을 가상화하고 일련의 서비스 기능이 적용되도록 하여, 운용의 자동화 및 IoT 장치별로 소프트웨어의 유지/보수 및 업그레이드를 용이하게 할 수 있는 네트워크 시스템에 관한 것이다.

기존 게이트웨이의 경우, IoT 장치의 인터페이스 중심으로 제어 및 관리가 되도록 되어 있다. 이에 IoT 장치의 프로토콜 마다 개별 게이트웨이가 존재해야 한다. IoT 장치들이 통합되어 운영되는 경우 각 장치의 프로토콜 스택들(소프트웨어) 사이에 충돌이 발생하여 게이트웨이의 안전성과 성능에 문제가 있을 수 있다. 또한 IoT 장치별로 소프트웨어 유지/보수 및 업그레이드가 용이하지 않을 수 있다.

1. OpenFlow Switch Specification version 1.4.0(Wire Protocol 0x05), October 14, 2013 [https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.4.0.pdf] 2. Software-Defined Networking: The New Norm for Netwrks, ONF White Paper, April 13, 2012 [https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-papers/wp-sdn-newnorm.pdf] 3. ETSI GS NFV 002 v1.1.1 (2013-10) [http://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.01.01_60/gs_NFV002v010101p.pdf]

본 발명의 목적은 네트워크 인터페이스가 상이한 IoT 장치의 프로토콜을 지원하며, IoT 장치의 네트워크 인터페이스별로 서비스 체이닝을 설정 가능하도록 하는 네트워크 시스템을 제공하는 것이다.

본 발명의 일실시예에 따른 IoT 네트워크 시스템은, 공통 게이트웨이로서, 복수의 IoT(Internet of Things) 장치와 통신하는 서로 다른 인터페이스 모듈을 구비하는 통신부; 및 상기 통신부를 통해 인입한 플로우에 상기 플로우의 패킷이 인입한 인터페이스를 식별하는 인터페이스 식별자를 구비하는 서비스 식별자를 상기 플로우에 할당하는 오픈플로우(openflow) 기반의 게이트웨이 스위치를 구비하는 상기 공통 게이트웨이; 및 상기 공통 게이트웨이로부터 전달받은 플로우에 상기 인터페이스 식별자에 대응하여 인터페이스 별로 일련의 서비스 기능을 제공하는 서비스 기능 클라우드를 포함할 수 있다.

또한, 상기 서비스 식별자는 IoT 장치 식별자를 더 구비하고, 상기 서비스 기능 클라우드는 상기 장치 식별자에 대응하여 상기 플로우의 드롭 여부를 결정하는 필터링 서비스 기능을 더 구비할 수 있다.

또한, 상기 서비스 기능 클라우드는 상기 서비스 식별자에 대응하여 IoT 장치의 대역폭 사용률을 제한하는 대역폭 서비스 기능을 더 구비할 수 있다.

또한, 상기 서비스 기능 클라우드는 복수의 서비스 노드 그룹으로서, 서비스 노드 그룹은 동일한 서비스 기능을 제공하는 서비스 노드들을 집합인, 상기 복수의 서비스 노드 그룹; 및 서비스들의 종류 및 순서가 정의된 서비스 리스트들의 집합에서 상기 서비스 식별자에 대응하는 서비스 리스트에 대응하는 일련의 서비스가 상기 플로우에 제공되도록, 상기 플로우를 복수의 포트 중 어느 한 포트로 전달하는 오픈플로우 기반의 클라우드 스위치를 포함하고, 상기 복수의 포트는 중 어느 하나는 상기 복수의 서비스 노드 그룹 중 어느 한 서비스 노드 그룹 및 다른 클라우드 스위치 중 어느 하나와 연결될 수 있다.

또한, 상기 서비스 식별자는 상기 적어도 하나의 클라우드 스위치에 유입되는 플로우의 포트 정보에 기초하여 업데이트될 수 있는 오더 아이디를 더 포함하고, 상기 클라우드 스위치는 포트에 유입되는 플로우에 대해 상기 서비스 식별자에 대응하는 액션을 처리할 수 있다.

또한, 상기 클라우드 스위치는 상기 플로우가 유입되는 포트가 상기 다른 클라우드 스위치와 연결된 포트인 경우, 상기 오더 아이디를 업데이트할 수 있다.

또한, 상기 복수의 서비스 노드 그룹 중 어느 한 서비스 노드 그룹의 서비스 노드들의 개수는 적어도 네트워크 상태에 기초하여 변동될 수 있다.

또한, 상기 클라우드 스위치의 상기 서비스 노드 그룹에 연결된 포트는 논리 포트일 수 있다.

본 발명에 따르면, 다양한 프로토콜의 IoT 장치를 통합 지원할 수 있으며, 네트워크 인터페이스별로 가상화된 서비스 기능을 운용할 수 있고, 이에 의해 IoT 장치별로 해당 소프트웨어의 유지 보수를 효율적으로 할 수 있다.

도 1은 본 발명의 일실시예에 따른 SDN 네트워크 시스템의 블록 구성도(block diagram),
도 2는 도 1의 네트워크 시스템의 제어기의 블록 구성도,
도 3은 도 1의 네트워크 시스템의 스위치의 블록 구성도,
도 4는 플로우 엔트리의 필드 테이블 및 플로우 엔트리에 따른 동작 종류를 나타내는 동작 테이블,
도 5는 그룹 및 미터 테이블의 필드 테이블,
도 6은 본 발명의 일 실시예에 따른 IoT 네트워크 시스템의 구조도,
도 7은 본 발명의 일 실시예에 따른 공통 게이트웨이의 블록 구성도,
도 8은 도 7의 서비스 기능 클라우드의 구조도,
도 9는 도 8의 클라우드 스위치의 내부 블록 구성도,
도 10은 도 7의 제어기의 블록 구성도,
도 11은 본 발명의 일 실시예에 따른 서비스 리스트 데이터 베이스 테이블,
도 12는 본 발명의 일 실시예에 따른 서비스 기능 클라우드의 구조도,
도 13은 도 11 및 도 12에 따른 플로우 테이블,
도 14는 본 발명의 다른 실시예에 따른 서비스 기능 클라우드의 구조도, 및
도 15는 도 11 및 도 14에 따른 플로우 테이블이다.

이하, 도면을 참조하여 본 발명을 보다 상세하게 설명한다.

제1, 제2 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 발명의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 명명될 수 있다. 및/또는 이라는 용어는 복수의 관련된 기재된 항목들의 조합 또는 복수의 관련된 기재된 항목들 중의 어느 항목을 포함한다.

어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다. 또한 네트워크 상의 제1 구성요소와 제2 구성요소가 연결되어 있거나 접속되어 있다는 것은, 유선 또는 무선으로 제1 구성요소와 제2 구성요소 사이에 데이터를 주고 받을 수 있음을 의미한다.

또한, 이하의 설명에서 사용되는 구성요소에 대한 접미사 "모듈" 및 "부"는 단순히 본 명세서 작성의 용이함만이 고려되어 부여되는 것으로서, 그 자체로 특별히 중요한 의미 또는 역할을 부여하는 것은 아니다. 따라서, 상기 "모듈" 및 "부"는 서로 혼용되어 사용될 수도 있다.

이와 같은 구성요소들은 실제 응용에서 구현될 때 필요에 따라 2 이상의 구성요소가 하나의 구성요소로 합쳐지거나, 혹은 하나의 구성요소가 2 이상의 구성요소로 세분되어 구성될 수 있다. 도면 전체를 통하여 동일하거나 유사한 구성요소에 대해서는 동일한 도면 부호를 부여하였고, 동일한 도면 부호를 가지는 구성요소에 대한 자세한 설명은 전술한 구성요소에 대한 설명으로 대체되어 생략될 수 있다.

SDN은 패킷을 전달하는 데이터 플레인과 패킷의 흐름을 제어하는 제어 플레을 분리된 개념이다. SDN에서 패킷이 발생했을 때, 네트워크 장비는 패킷을 어디로 전달할지 SDN 제어 소프트웨어(제어기)에게 물어보고, 그 결과를 반영하여 패킷을 전송하는 경로와 방식을 결정한다. SDN은 이론적인 개념으로, 실제로 적용하기 위해 오픈플로우(Openflow)가 등장하였다. 즉 오픈플로우는 SDN을 구현하기 위해 제정된 표준 인터페이스이다. 오픈플로우는 오픈플로우 제어기와 오픈플로우 스위치로 구성되어, 플로우 정보를 제어하여 패킷의 전달 경로 및 방식을 결정한다. 본 명세서 전반에서, 오픈플로우와 SDN는 서로 동일한 의미로 사용되거나 혼용하여 사용될 수 있다.

플로우(flow)는 하나의 스위치 관점에서 적어도 하나의 헤더 필드의 값을 공유하는 일련의 패킷들 또는 다중 스위치의 여러 플로우 엔트리(flow entry)들의 조합에 따른 특정 경로의 패킷 흐름을 의미할 수 있다. 오픈플로우 네트워크는 플로우 단위로 경로 제어, 장애 회복, 부하 분산 및 최적화를 행할 수 있다. 본 명세서에서 플로우는 특정 패킷을 의미할 수 있으며, 특정 패킷과 인입 포트 등 다른 메타데이터를 포함하는 것을 의미할 수도 있다.

도 1은 본 발명의 일실시예에 따른 SDN 네트워크 시스템의 블록 구성도(block diagram), 도 2는 도 1의 네트워크 시스템의 제어기의 블록 구성도, 도 3은 도 1의 네트워크 시스템의 스위치의 블록 구성도, 도 4는 플로우 엔트리의 필드 테이블 및 플로우 엔트리에 따른 동작 종류를 나타내는 동작 테이블, 도 5는 그룹 및 미터 테이블의 필드 테이블이다.

도 1(a)를 참조하면, 본 발명에 일 실시예에 따른 SDN 네트워크 시스템은 제어기(contoller)(10), 복수의 스위치(20) 및 복수의 네트워크 디바이스(30)를 포함할 수 있다.

네트워크 디바이스(30)는 데이터나 정보를 주고 받고자 하는 사용자 단말 장치, 또는 특정 기능을 수행하는 물리 장치 또는 가상 장치를 포함할 수 있다. 하드웨어 관점에서, 네트워크 디바이스(30)는 PC, 클라이언트 단말기, 서버, 워크스테이션, 수퍼컴퓨터, 이동통신 단말기, 스마트폰, 스마트패드 등이 있을 수 있다. 또한 네트워크 디바이스(30)는 물리 장치 상에 생성된 가상 머신(VM)일 수 있다.

네트워크 디바이스(30)는 네트워크 상의 여러가지 기능을 수행하는 네트워크 기능(network function)으로 지칭될 수 있다. 네트워크 기능은 안티(anti) DDoS, 침입 감지/차단(IDS/IPS), 통합 보안 서비스, 가상 사설망 서비스, 안티 바이러스, 안티 스팸, 보안 서비스, 접근관리 서비스, 방화벽, 로드 밸런싱, QoS, 비디오 최적화 등을 포함할 수 있다. 이러한 네트워크 기능은 가상화될 수 있다.

가상화된 네트워크 기능으로 ETSI(유럽전기통신표준협회)에서 발행한 NFV 관련 백서(비특허문헌 3 참조)에서 정의된 네트워크 기능 가상화(Network Function Virtualiztion; NFV)가 있다. 본 명세서에서 네트워크 기능(NF)은 네트워크 기능 가상화(NFV)와 혼용하여 사용될 수 있다. NFV는 테넌트(tenant)별 필요한 L4-7 서비스 연결을 동적으로 생성하여 필요한 네트워크 기능을 제공하거나, DDoS 공격의 경우 정책 기반으로 필요한 방화벽, IPS 및 DPI 기능 등을 일련의 서비스 체이닝으로 빠르게 제공되는데 이용될 수 있다. 또한 NFV는 방화벽이나 IDS/IPS를 쉽게 온오프 할 수 있으며, 자동으로 프로비저닝(provisioning)할 수 있다. NFV는 오버 프로비저닝의 필요성도 줄일 수 있다.

제어기(controller)(10)는 SDN 시스템을 제어하는 일종의 지휘 컴퓨터로서, 다양하고 복잡한 기능들, 예를 들어, 라우팅, 정책 선언, 및 보안 체크 등을 할 수 있다. 제어기(10)는 하위 계층의 복수의 스위치(20)에서 발생하는 패킷의 플로우를 정의할 수 있다. 제어기(10)는 네트워크 정책 상 허용되는 플로우에 대해 네트워크 토폴로지 등을 참조하여 플로우가 경유할 경로(데이터 경로)를 계산한 후, 경로 상의 스위치에 상기 플로우의 엔트리가 설정되도록 할 수 있다. 제어기(10)는 특정 프로토콜, 예를 들어, 오픈플로우 프로토콜을 이용하여 스위치(20)와 통신할 수 있다. 제어기(10)와 스위치(20)의 통신 채널은 SSL에 의해 암호화 될 수 있다.

도 2를 참조하면, 제어기(10)는 스위치(20)와 통신하는 스위치 통신부(110), 제어부(100), 및 저장부(190)를 포함할 수 있다.

저장부(190)는 제어부(100)의 처리 및 제어를 위한 프로그램을 저장할 수 있다. 저장부(190)는 입력되거나 출력되는 데이터들(패킷, 메시지 등)을 임시 저장을 위한 기능을 수행할 수 있다. 저장부(190)는 플로우 엔트리를 저장하는 엔트리 데이터베이스(DB)(191)를 포함할 수 있다.

제어부(100)는 통상적으로 상기 각 부의 동작을 제어하여 제어기(10)의 전반적인 동작을 제어할 수 있다. 제어부(100)는 토폴로지 관리 모듈(120), 경로 계산 모듈(125), 엔트리 관리 모듈(135) 및 메시지 관리 모듈(130)을 포함할 수 있다. 각 모듈은 제어부(100) 내에 하드웨어로 구성될 수 있고, 제어부(100)와 별개의 소프트웨어로 구성될 수도 있다.

토폴로지 관리 모듈(120)은 스위치 통신부(110)를 통하여 수집된 스위치(20)의 접속 관계를 기초로 네트워크 토폴로지 정보를 구축 및 관리 할 수 있다. 네트워크 토폴로지 정보는 스위치들 사이의 토폴로지 및 각 스위치에 연결되어 있는 네트워크 디바이스들의 토폴로지를 포함할 수 있다. 토폴로지 정보는 저장부(190)에 저장될 수 있다.

경로 계산 모듈(125)은 토폴로지 관리 모듈(120)에서 구축된 네트워크 토폴로지 정보를 기초로 스위치 통신부(110)를 통해 수신한 패킷의 데이터 경로 및 상기 데이터 경로 상의 스위치에서 실행될 액션 열을 구할 수 있다.

엔트리 관리 모듈(135)는 경로 계산 모듈(125)에서 계산된 결과, QoS 등의 정책, 사용자 지시 등을 기초로 플로우 테이블, 그룹 테이블, 및 미터 테이블 등의 엔트리로서 엔트리 DB(191)에 등록할 수 있다. 엔트리 관리 모듈(135)은 스위치(20)에 미리 각 테이블의 엔트리가 등록되도록 하거나(proactive), 스위치(20)로부터의 엔트리의 추가 또는 갱신 요구에 응답(reactive)할 수 있다. 엔트리 관리 모듈(135)은 필요에 따라 또는 스위치(10)의 엔트리 소멸 메시지 등에 의해 엔트리 DB(191)의 엔트리를 변경하거나 삭제할 수 있다.

메시지 관리 모듈(130)은 스위치 통신부(110)를 통해 수신한 메시지를 해석하거나, 스위치 통신부(110)를 통해 스위치로 전송되는 후술할 제어기-스위치 메시지를 생성할 수 있다. 제어기-스위치 메시지 중 하나인 상태 변경 메시지는 엔트리 관리 모듈(135)에 의해 생성된 엔트리 또는 엔트리 DB(191)에 저장된 엔트리에 기초하여 생성될 수 있다.

스위치(20)는 오픈플로우 프로토콜을 지원하는 물리적인 스위치 또는 가상 스위치일 수 있다. 스위치(20)는 수신한 패킷을 처리하여, 네트워크 디바이스(30) 사이의 플로우를 중계할 수 있다. 이를 위해 스위치(20)는 하나의 플로우 테이블 또는 비특허문헌 1에 상술되어 있는 파이프라인(pipeline) 처리를 위해 다중 플로우 테이블을 구비할 수 있다.

플로우 테이블은 네트워크 디바이스(30)의 플로우를 어떻게 처리할 지의 규칙을 정의한 플로우 엔트리를 포함할 수 있다.

스위치(20)는 다중 스위치의 조합에 따른 플로우의 입구 및 출구 측 에지 스위치(edge switch)(ingress switch and egress switch)와 에지 스위치 사이의 코어 스위치(core switch)로 구분될 수 있다.

도 3을 참조하면, 스위치(20)는 다른 스위치 및/또는 네트워크 디바이스와 통신하는 포트부(205), 제어기(10)와 통신하는 제어기 통신부(210), 스위치 제어부(200), 및 저장부(290)를 포함할 수 있다.

포트부(205)는 스위치 또는 네트워크 디바이스와 연결된 한 쌍의 포트를 다수 구비할 수 있다. 한 쌍의 포트는 하나의 포트로 구현될 수 있다.

저장부(290)는 스위치 제어부(200)의 처리 및 제어를 위한 프로그램을 저장할 수 있다. 저장부(290)는 입력되거나 출력되는 데이터들(패킷, 메시지 등)을 임시 저장을 위한 기능을 수행할 수 있다. 저장부(290)는 플로우 테이블, 그룹 테이블, 및 미터 테이블 등의 테이블(291)을 구비할 수 있다. 테이블(230) 또는 테이블의 엔트리는 제어기(10)의 메시지에 기초하여 추가, 수정, 삭제될 수 있다. 테이블 엔트리는 스위치(20)에 의해 자체적으로 파기될 수 있다.

플로우 테이블은 오픈플로우의 파이프라인(pipeline)을 처리하기 위해 다중 플로우 테이블로 구성될 수 있다. 도 4를 참조하면, 플로우 테이블의 플로우 엔트리는 패킷과 매치하는 조건(대조 규칙)을 기술한 매치 필드(match fields), 우선 순위(priority), 매치되는 패킷이 있는 경우 업데이트되는 카운터(counters), 플로우 엔트리에 매치되는 패킷이 있으면 발생하는 다양한 액션들의 집합인 인스트럭션(instruction), 스위치에서 파기될 시간을 기술하는 타임아웃(timeouts), 제어기에 의해 선택되어지는 오파큐(opaque) 타입으로, 제어기에 의해 플로우 통계, 플로우 변경, 및 플로우 삭제를 필터하기 위해 사용될 수 있으며, 패킷 처리시 사용되지 않는 쿠키(cookie) 등의 튜플(tuple)을 포함할 수 있다.

인스트럭션(instruction)은 다른 플로우 테이블로 패킷을 전달하는 것과 같은 파이프라인 프로세싱을 변경할 수 있다. 또한 인스트럭션은 액션 셋(action set)에 액션을 더하는 액션(action)들의 집합, 또는 패킷에 바로 적용하기 위한 액션들의 리스트를 포함할 수 있다. 액션(action)은 특정 포트로 패킷을 전송하거나, TTL 필드를 감소시키는 것과 같이 패킷을 수정하는 작업을 의미할 수 있다. 액션은 플로우 엔트리와 연관된 인스트럭션 집합의 일부 또는 그룹 엔트리와 연관된 액션 버킷에 속할 수 있다. 액션 셋(action set)은 각 테이블에서 지시된 액션이 누적된 집합을 의미한다. 액션 셋은 매치되는 테이블이 없을 때 수행될 수 있다. 도 5는 플로우 엔트리에 의한 여러 패킷 처리를 예시한다.

파이프라인(pipleline)은 패킷과 플로우 테이블 사이의 일련의 패킷 처리 과정을 의미한다. 스위치(20)에 패킷이 유입되면, 스위치(20)는 첫번째 플로우 테이블의 우선 순위가 높은 순서대로 패킷과 매칭되는 플로우 엔트리를 탐색한다. 매칭이 되면 해당 엔트리의 인스트럭션을 수행한다. 인스트럭션은 매칭되면 바로 수행하는 명령(apply-action), 액션 셋의 내용을 지우거나 추가/수정하는 명령(clear-action; write-action), 메타데이터(metadata) 수정 명령(write-metadata), 지정된 테이블로 메타데이터와 함께 패킷을 이동시키는 고우투 명령(goto-table) 등이 있다. 패킷과 매칭되는 플로우 엔트리가 없는 경우, 테이블 설정에 따라 패킷을 폐기(drop)하거나 제어기(10)로 패킷을 패킷-인 메시지(packet-in message)에 실어서 보낼 수 있다.

그룹 테이블은 그룹 엔트리들을 포함할 수 있다. 그룹 테이블은 플로우 엔트리에 의해 지시되어 추가적인 포워딩 방법들을 제시할 수 있다. 도 5(a)를 참조하면, 그룹 테이블의 그룹 엔트리는 다음과 같은 필드를 구비할 수 있다. 그룹 엔트리를 구분할 수 있는 그룹 식별자(group identifier), 그룹 엔트리에 정의된 액션 버킷들을 일부(select) 또는 전부(all) 수행할 것이 여부에 대한 규칙을 명시한 그룹 타입(group type), 플로우 엔트리의 카운터와 같이 통계를 위한 카운터(counters), 및 그룹을 위해 정의된 파라미터들과 연관된 액션들의 집합인 액션 버킷(action buckets)을 포함할 수 있다.

미터 테이블(meter table)은 미터 엔트리들(meter entries)로 구성되며, 플로우 미터-당(per-flow meters)을 정의한다. 플로우 미터-당은 오픈플로우가 다양한 QoS 작동을 적용될 수 있도록 할 수 있다. 미터(meter)는 패킷의 레이트(rate of packets)를 측정 및 제어할 수 있는 일종의 스위치 요소이다. 도 5(b)를 참조하면, 미터 테이블(meter table)은 미터를 식별하는 미터 식별자(meter identifier), 밴드(band)에 지정된 속도와 패킷 동작 방법을 나타내는 미터 밴드(meter bands), 및 패킷이 미터에서 동작될 때 업데이트되는 카운터(counters) 필드들로 구성된다. 미터 밴드(meter bands)는 패킷이 어떻게 처리되는 지를 나타내는 밴드 타입(band type), 미터에 의해 미터 밴드를 선택하는데 사용되는 레이트(rate), 미터 밴드에 의해 패킷들이 처리될 때 업데이트되는 카운터(counters), 및 선택적인 아규먼트(argument)를 가지는 배드 타입들인 특정 아규먼트 타입(type specific argument)과 같은 필드들로 구성될 수 있다.

스위치 제어부(200)는 통상적으로 상기 각 부의 동작을 제어하여 스위치(20)의 전반적인 동작을 제어할 수 있다. 스위치 제어부(200)는 테이블(291)을 관리하는 테이블 관리 모듈(240), 플로우 검색 모듈(220), 플로우 처리 모듈(230), 및 패킷 처리 모듈(235)를 포함할 수 있다. 각 모듈은 제어부(200) 내에 하드웨어로 구성될 수 있고, 제어부(200)와 별개의 소프트웨어로 구성될 수도 있다.

테이블 관리 모듈(240)은 제어기 통신부(210)를 통해 제어기(10)로부터 수신한 엔트리를 적절한 테이블에 추가하거나, 타임 아웃(time out)된 엔트리를 주기적으로 제거할 수 있다.

플로우 검색 모듈(220)은 유저 트래픽으로서 수신한 패킷으로부터 플로우 정보를 추출할 수 있다. 플로우 정보는 에지 스위치의 패킷 유입 포트인 입구 포트(ingress port)의 식별 정보, 해당 스위치의 패킷 유입 포트(incoming port)의 식별 정보, 패킷 헤더 정보(송신원 및 목적지의 IP 주소, MAC 주소, 포트, 및 VLAN 정보 등), 및 메타데이터 등을 포함할 수 있다. 메타데이터는 이전 테이블에서 선택적으로 추가되거나, 다른 스위치에서 추가된 데이터일 수 있다. 플로우 검색 모듈(220)은 추출한 플로우 정보를 참조하여 테이블(291)에 수신 패킷에 대한 플로우 엔트리가 있는지 검색할 수 있다. 플로우 검색 모듈(220)은 플로우 엔트리가 검색되면, 플로우 처리 모듈(260)에 검색된 플로우 엔트리에 따라 수신 패킷을 처리하도록 요청할 수 있다. 만일 플로우 엔트리 검색이 실패하면, 플로우 검색 모듈(220)은 수신 패킷 또는 수신 패킷의 최소한의 데이터를 제어기 통신부(210)를 통해 제어기(10)로 전송할 수 있다.

플로우 처리 모듈(230)는 플로우 검색 모듈(220)에서 검색된 엔트리에 기술된 절차에 따라 패킷을 특정 포트 또는 다중 포트로 출력하거나, 드롭시키거나 또는 특정 헤더 필드를 수정하는 등의 액션을 처리할 수 있다.

플로우 처리 모듈(230)는 플로우 엔트리의 파이프라인 프로세스를 처리하거나 액션을 변경하기 위한 인스트럭션을 실행하거나 다중 플로우 테이블에서 더 이상 다음 테이블로 갈 수 없을 때 액션 세트를 실행할 수 있다.

패킷 처리 모듈(235)은 플로우 처리 모듈(230)에 의해 처리된 패킷을 플로우 처리 모듈(230)에서 지정한 포트부(205)의 하나 또는 2 이상의 포트로 실제로 출력할 수 있다.

도 1(b)를 참조하면, SDN 네트워크 시스템은 오케스트레이터(1)를 더 포함할 수 있다. 오케스트레이터(1)는 가상 네트워크 디바이스, 가상 스위치 등을 생성, 변경 및 삭제할 수 있다. 오케스트레이터(1)에서 가상 네트워크 디바이스를 생성하는 경우, 오케스트레이터(1)는 가상 네트워크가 접속할 스위치의 식별 정보, 해당 스위치에 연결되는 포트 식별 정보, MAC 주소, IP 주소, 터넨트(tenant) 식별 정보 및 네트워크 식별 정보 등의 네트워크 디바이스의 정보를 제어기(10)로 제공할 수 있다.

제어기(10) 및 스위치(20)는 오케스트레이터(1)와 별도의 인터페이스로 통신하거나, 제어기(10)의 스위치 통신부(110) 및 스위치(20)의 제어기 통신부(210)를 통해 오케스트레이터(1)와 통신할 수 있다. 스위치(20)는 제어기(10)를 통해 오케스트레이터(1)와 메시지를 주고 받을 수 있다.

제어기(10)와 스위치(20)는 다양한 정보를 주고 받는데, 이를 오픈플로우 프로토콜 메시지(openflow protocol message)라 칭한다. 이러한 오픈플로우 메시지는 제어기-스위치 메시지(controller-to-switch message), 비동기 메시지(asynchronous message), 및 대칭 메시지(symmetric message) 등의 타입이 있다. 각 메시지는 엔트리를 식별하는 트랜잭션 식별자(transaction id; xid)를 헤더에 구비할 수 있다.

제어기-스위치 메시지는 제어기(10)가 생성하여 스위치(20)에 전달하는 메시지로써, 주로 스위치(20)의 상태를 관리하거나 점검하기 위해 사용된다. 제어기-스위치 메시지는 제어기(10)의 제어부(100), 특히 메시지 관리 모듈(130)에 의해 생성될 수 있다.

제어기-스위치 메시지는 스위치의 능력(capabilities)을 문의하는 기능(features), 스위치(20)의 구성 매개 변수 등의 설정을 문의하고 설정하기 위한 설정(configuration), 오픈플로우 테이블의 플로우/그룹/미터 엔트리들을 추가/삭제/수정하기 위한 상태 변경 메시지(modify state message), 패킷-인 메시지를 통해 스위치로부터 수신한 패킷을 해당 스위치 상의 특정한 포트로 전송하도록 하는 패킷-아웃 메시지(packet-out message) 등이 있다. 상태 변경 메시지는 플로우 테이블 변경 메시지(modify flow table message), 플로우 엔트리 변경 메시지(modify flow entry message), 그룹 엔트리 변경 메시지(modify group entry message), 포트 변경 메시지(prot modification message), 및 미터 엔트리 변경 메시지(meter modification message) 등이 있다.

비동기 메시지는 스위치(20)가 생성하는 메시지로서, 스위치의 상태 변경 및 네트워크 이벤트 등을 제어기(10)에서 업테이트하기 위해 사용된다. 비동기 메시지는 스위치(20)의 제어부(200), 특히 플로우 검색 모듈(220)에 의해 생성될 수 있다.

비동기 메시지로 패킷-인 메시지(packet-in message), 플로우 삭제 메시지(flow-removed), 에러 메시지 등이 있다. 패킷-인 메시지는 스위치(20)가 제어기(10)에게 패킷을 전송하여 패킷에 대한 제어를 받기 위해 사용된다. 패킷-인 메시지는 스위치(20)가 미지의 패킷을 수신한 경우, 데이터 경로를 요구하기 위해, 오픈플로우 스위치(20)에서 제어기(10)로 전송되는 수신 패킷 또는 그 사본의 전부 또는 일부를 포함하는 메시지이다. 유입 패킷에 연관된 엔트리의 액션이 제어기로 보내라고 정해져 있을 때에도 패킷-인 메시지가 사용된다. 삭제된 플로우(flow-removed) 메시지는 플로우 테이브에서 삭제할 플로우 엔트리 정보를 제어기(10)로 전달하기 위해 사용된다. 이 메시지는 제어기(10)가 스위치(20)에 해당 플로우 엔트리 삭제를 요청하였거나 플로우 타임아웃(timeout)에 의한 플로우 만기 처리(flow expiry process)에서 발생한다.

대칭 메시지는 제어기(10) 및 스위치(20) 모두에서 생성되며, 상대방의 요청이 없어도 전송되는 특징이 있다. 제어기와 스위치 간에 연결을 개시할 때 사용되는 헬로(hello), 제어기 및 스위치 간 연결에 이상이 없음을 확인하기 위한 에코(echo), 및 제어기나 스위치에 의해 사용되며 문제를 반대측에 알리기 위한 에러 메시지(error message) 등을 포함할 수 있다. 에러 메시지는 대부분 제어기에 의해 개시된 요청에 따른 실패를 나타나기 위해 스위치에서 사용된다.

도 6은 본 발명의 일 실시예에 따른 IoT 네트워크 시스템의 구조도, 도 7은 본 발명의 일 실시예에 따른 공통 게이트웨이의 블록 구성도, 도 8은 도 7의 서비스 기능 클라우드의 구조도, 도 9는 도 8의 클라우드 스위치의 내부 블록 구성도, 및 도 10은 도 7의 제어기의 블록 구성도이다.

도 6을 참조하면, 본 실시예에 따른 IoT(Internet of Things) 네트워크 시스템은 오케스트레이터(1), 제어기(10), 공통 게이트웨이(30), 및 서비스 기능 클라우드(60)을 포함할 수 있다.

공통 게이트웨이(30)는 다양한 IoT 장치(50)로부터 수집되는 데이터를 서비스 기능 클라우드(60)로 전송하여 다양한 서비스 운용이 가능하도록 할 수 있다. IoT 오픈 플랫폼(90)은 서비스 기능 클라우드(60)에서 처리된 데이터를 취합할 수 있다. IoT 오픈 플랫폼(90)은 취합한 데이터를 고객에게 직접 제공하거나 다양한 서비스로 제공할 수 있다. IoT 오픈 플랫폼(90)이 고객에게 제공하는 서비스는 제3자 그룹(3rd party) 등이 취합된 데이터를 가공하여 다양한 프로토콜의 서비스로 고객에게 제공할 수 있다. IoT 오픈 플랫폼(90)은 개방형 OS 기반 플랫폼/SDK 제공을 통해 누구에게나 IoT 응용 서비스 개발 환경을 제공할 수 있다.

IoT 장치(50)는 사물 인터넷(IoT; Internet of Things)이 적용된 다양한 장치(TV, 냉장고, 청소기, 세탁기, 보일러, 휴대폰, 자판기, 자동차)나 센서 장치를 의미한다. IoT 장치(50)는 네트워크 기능이 강화된 장치로, 다양한 유/무선 통신 인터페이스를 구비할 수 있다. 예를 들어, IoT 장치(50)는 WLAN(Wireless LAN)(Wi-Fi), Wibro(Wireless broadband), Wimax(World Interoperability for Microwave Access), HSDPA(High Speed Downlink Packet Access) 등의 IP 기반 네트워크, 지그비(ZigBee), 블루투스(Bluetooth), RFID(Radio Frequency Identification), 적외선 통신(IrDA, infrared Data Association), UWB(Ultra Wideband), NFC(Near Field Communication), 셀룰러 네트워크(Cellular networks), CAN(Controller Area Networks) 등의 비 IP 기반 네트워크를 사용할 수 있다.

복수의 IoT 장치(50)는 위에서 언급한 바와 같이, 다양한 이기종의 네트워크 인터페이스를 가질 수 있다. 기존 IoT 게이트웨이는 다양한 이종 IoT 망으로부터 수집되는 대량 데이터로 인한 네트워크 병목 현상을 해소하기 어렵다. 이에 본 발명은 SDN 기반의 IoT 게이트웨이 기술을 통해, 네트워크 신뢰성 확보 및 센서 데이터의 시의성 확보를 할 수 있다. 또한, 인터넷과의 통합 관리 기능이나 이종 IoT 센서 네트워크 사이의 정보 전달 및 액츄에이터 동작을 위해서는 유연한 네트워크 설정 및/또는 운용이 필수적인데, 이는 본 발명에 따른 SDN 기술을 통해 적용할 수 있다.

IoT 장치(50)는 장치 식별자, 장치명, 모델명, 제조사, 위치정보, 장치상태 정보 등의 IoT 장치 정보를 구비할 수 있다. 장치 식별자는 IoT 장치(50)의 MAC 주소가 사용될 수 있다. 이러한 IoT 장치 정보는 공통 게이트웨이(30)로 전달되는 트래픽을 통해 공통 게이트웨이(30)로 전달될 수 있다.

도 7을 참조하면, 공통 게이트웨이(30)는 게이트웨이 통신부(32) 및 게이트웨이 스위치(34)를 포함할 수 있다.

게이트웨이 통신부(32)는 복수의 IoT(Internet of Things) 장치(50; 51~54)와 통신하는 서로 다른 인터페이스 모듈을 구비할 수 있다. 게이트웨이 통신부(32)는 블루투스, WiFi, 지그비, 및 Z-wave 인터페이스를 가지는 각각의 모듈(32-1 ~ 32-4)을 구비할 수 있다. 게이트웨이 통신부(32)는 이 외에도 다양한 인터페이스 모듈을 구비할 수 있다.

게이트웨이 통신부(32)는 각 인터페이스 모듈(32-1 ~ 32-4)을 통해 IoT 장치(50)로부터 수신한 패킷을 게이트웨이 스위치(34)로 전달할 수 있다.

게이트웨이 스위치(34)는 오픈플로우(openflow) 기반의 스위치로, 도 3의 스위치의 구성 요소 전부 또는 그 일부를 구비할 수 있다.

게이트웨이 스위치(34)는 게이트웨이 통신부(32)를 통해 인입한 플로우에 인터페이스 식별자를 할당할 수 있다. 게이트웨이 스위치(34)는 포트부(205)의 복수의 포트(p1 ~ p4) 중 어느 포트로 패킷이 인입하는 알 수 있다. 포트부(205)의 각 포트(p1 ~ p4)는 게이트웨이 통신부(32)의 어느 인터페이스 모듈과 연결되어 있는 지 알 수 있다. 따라서, 게이트웨이 스위치(34)는 플로우의 인입 포트에 대응하여, 인터페이스 식별자를 플로우에 할당할 수 있다. 게이트웨이 스위치(34)는 플로우의 메타데이터를 인터페이스 식별자로 사용하거나, 인입 패킷의 메타데이터 또는 인입 패킷의 특정 필드를 인터페이스 식별자로 사용할 수 있다. 인터페이스 식별자는 서비스 식별자에 포함될 수 있다. 서비스 식별자에 대한 자세한 설명은 후술한다.

서비스 기능 클라우드(60)는 인터페이스 식별자에 대응하여, 공통 게이트웨이(30)로부터 전달 받은 플로우에 일련의 서비스 기능(SF; Service Function)을 제공할 수 있다. 도 8를 참조하면, 서비스 기능 클라우드(60)는 복수의 클라우드 스위치(cSW) 및 복수의 서비스 기능(SF1 ~ SF7)을 구비할 수 있다.

클라우드 스위치(cSW)는 도 3에서 언급한 오픈플로우 스위치의 구성요소 전부 또는 그 일부를 포함할 수 있다. 클라우드 스위치(cSW)는 도 8(a) 내지 도 8(c)와 같이, 다양한 토폴로지를 구성할 수 있다. 복수의 클라우드 스위치(cSW)는 도 8(a)와 같이 모든 클라우드 스위치가 서비스 기능을 제공하거나, 도 8(b)와 같이 하나의 클라우드 스위치가 공통 게이트웨이(30) 및 IoT 오픈 플랫폼(90)을 연결하고 나머지 클라우드 스위치가 서비스 기능을 제공하거나, 도 8(c)와 같이 두 개의 클라우드 스위치 각각이 공통 게이트웨이(30) 및 IoT 오픈 플랫폼(90)과 연결되고 나머지 클라우드 스위치에서 서비스 기능을 제공할 수 있다. 이에 한정되지 않고, 다양한 실시례가 사용될 수 있다.

서비스 기능은 도 1에서 언급한 가상 네트워크 기능(NFv; Network Function Virtualization)에 의해 구현될 수 있다. 서비스 기능(SF1 ~ SF7)은 다양할 수 있다. 예를 들어, 서비스 기능은 안티(anti) DDoS, 침입 감지/차단 (IDS/IPS), 통합 보안 서비스, 가상 사설망 서비스, 안티 바이러스, 안티 스팸, 보안 서비스, 접근관리 서비스, 방화벽, 로드 밸런싱, QoS, 비디오 최적화 등 이외에, 심층 패킷 분석(DPI; Deep Packet Inspection), CoAP (Constrained Application Protocol), MQTT(MQ Telemetry Transport), IPv6 등이 있다.

DPI 기능은 아직까지 표준화된 기술이 아니어서 그 정의가 유동적이나 일반적으로 패킷의 콘텐츠가 담긴 심층부분까지 검사할 수 있는 기술로 통용된다. DPI 기능은 이미 식별된 패킷의 종류에 매칭시킬 수 있는 충분한 정보를 가질 때까지 수십만의 패킷을 메모리에 저장할 수 있다. 일단 새로운 패킷이 이미 장비에 의해 식별된 패킷 리스트에 매칭되면, DPI 기능은 무슨 애플리케이션이 패킷을 생성하고 보내는지를 알게 되고 패킷 전송을 허용할지 말지의 규칙을 적용할 수 있다. 만일 DPI 기능이 패킷 헤더와 페이로드 부분까지 검사를 해도 애플리케이션을 식별할 수 없으면, DPI 기능은 컴퓨터간에 패킷이 어떻게 교환되는지 그 패턴을 검토할 수 있다.

CoAP 기능은 센서 네트워크 프로토콜 형식으로 디자인된 저전력용 네트크 프로토콜이다. CoAP 기능은 부하를 최대한 줄이기 위해 바이너리 헤더를 적용하여 네트워크 오버헤드를 최소할 시킬 수 있다. CoAP 기능은 UDP 기반의 프로토콜을 사용한다. MQTT 기능은 경량의 메시징 프로토콜로, M2M(machine-to-machine)와 IoT(Internet of things)에서의 사용을 목적으로 만들었다. 이를 위해서 낮은 전력, 낮은 대역폭 환경에서도 사용할 수 있도록 설계됐다. IPv6 기능은 기존의 IPv4 주소 체계를 IPv6 체계로 변환하는 기능을 제공한다.

복수의 클라우드 스위치은 인터페이스 식별자에 기반한 플로우 엔트리를 구비하여, 플로우의 인터페이스 식별자에 따라 플로우를 복수의 서비스 기능(SF1 ~ SF7) 중 특정 서비스 기능에 특정 순서로 전달할 수 있다.

이와 같이 서비스 기능 클라우드(60)의 서비스 기능으로 가상화로 인하여, IoT 장치별로 소프트웨어 어플리케이션의 유지 보수 및 업그레이드를 용이하게 할 수 있다.

도 9는 특히, 서비스 기능을 제공하는 클라우드 스위치의 내부의 일부 블록 구성도이다. 앞서 설명한 바와 같이, 서비스 기능은 네트워크 기능 가상화(NFv; Network Function Virturalisatoin) 노드로 구현될 수 있다. 서비스 기능은 네트워크 기능 그룹인 것이 바람직하다. 네트워크 기능 그룹은 동일한 기능의 네트워크 기능 가상화들로 구성될 수 있다.

도 9를 참조하면, 동일 기능 그룹의 NFv 노드들은 동일한 기능의 NFv 노드들(301 ~ 304)로 구성될 수 있다. 동일 기능 그룹의 NFv 노드들은 오픈플로우 스위치(20)의 논리 포트에 연결되어 하나의 네트워크 디바이스처럼 작동되도록 집성(aggregation)화 되어 있는 것이 바람직하다.

클라우드 스위치(cSW)의 포트부(205)는 논리 포트(205-1, 205-2)를 포함할 수 있다. 클라우드 스위치(cSW)의 패킷 처리 모듈(235)은 발산 유닛(236) 및 수렴 유닛(237)을 포함할 수 있다.

발산 유닛(236)은 논리 출력 포트(205-1)에서 유입되는 패킷을 복수의 NFv 노드(301~304) 중 어느 하나로 전달할 수 있다. 앞서 설명한 바와 같이, 복수의 NFv 노드(301~304)는 동일한 네트워크 기능을 제공한다. 수렴 유닛(237)은 복수의 NFv 노드(301~304) 중 어느 한 노드에서 처리된 패킷을 수신하여, 수신한 패킷을 논리 입력 포트(205-2)로 전달할 수 있다. 클라우드 스위치(cSW)의 논리 포트(205-1, 205-2) 및 발산/수렴 유닛(236, 237)의 집성화 기능(aggregation)은 복수의 NFv(301~304) 노드가 하나의 NFv 노드 처럼 기능하도록 할 수 있다.

패킷 처리 모듈(235)은 스위치 SW2의 논리 출력 포트(205-1)를 통해 유입되는 패킷을 포트의 연결 상태, 트랙픽 상태 등을 고려하여 복수의 NFv(301~304) 중 적절한 NFv 노드로 전달되도록 발산 유닛(236)을 제어할 수 있다.

클라우드 스위치(cSW)에 연결되는 NFv의 생성 및 삭제는 오케스트레이터(1)에 의해 실행될 수 있다. 오케스트레이터(1)는 트래픽 상태 등에 따라 논리 포트에 연결되는 동일 기능 그룹에 속한 NFv들의 개수를 조정할 수 있다.

이러한 논리 포트 및 집성 기능은 제어기(10) 및 스위치 SW2가 패킷 경로 상의 NFv 타입만 고려하게 할 수 있다. 패킷 경로 및 플로우 엔트리 등은 해당 기능의 NFv 그룹의 논리 포트로 간단히 기술될 수 있다.

도 10을 참조하면, 제어기(10)는 공통 게이트웨이(30) 및 클라우드 스위치(cSW)와 통신하는 스위치 통신부(110), 제어기 제어부(100), 및 저장부(190)를 포함할 수 있다. 제어기 제어부(100)는 토폴로지 관리 모듈(120), 경로 계산 모듈(125), 메시지 관리 모듈(130), 엔트리 관리 모듈(135), 및 서비스 기능 관리 모듈(140)을 구비할 수 있다. 동일한 도면 부호에 대한 구성요소의 설명은 도 2를 참조한다.

서비스 기능(SF; Service Function) 관리 모듈(이하, 'SF 관리 모듈')(140)은 공통 게이트웨이(30) 또는 클라우드 스위치(cSW)로부터 수신한 패킷-인 메시지(packet-in message)에 서비스 식별자를 할당하거나, 플로우에 서비스 식별자가 정의되도록 제어할 수 있다. SF 관리 모듈(140)은 서비스 식별자에 대응하여 플로우에 일련의 서비스 기능(서비스 체이닝; service chaining)이 제공되도록 제어할 수 있다. SF 관리 모듈(140)의 플로우의 서비스 기능 적용은 메시지 관리 모듈(130) 및/또는 엔트리 관리 모듈(135)에 의해 보조될 수 있다.

서비스 식별자는 서비스 기능 클라우드(60)에서 제공할 수 있는 서비스의 타입을 나타낸다. 서비스 식별자는 IoT 장치(50)의 네트워크 인터페이스를 나타내는 인터페이스 식별자, 및 IoT 장치(50)를 구별하는 IoT 장치 식별자를 포함할 수 있다.

서비스 식별자는 IoT 장치(50)에서 특별히 특정 서비스를 요청하는 서비스 요청 식별자를 더 포함할 수 있다. IoT 장치(50)와 제어기(10)와의 기설정된 정책에 따라, IoT 장치(50)에서 패킷에 서비스 요청 식별자를 미리 할당할 수 있다.

서비스 식별자는 클라우드 스위치(cSW)에 플로우가 유입되는 포트 정보에 기반하여 업데이트될 수 있는 오더 식별자를 더 포함할 수 있다.

서비스 식별자는 위에서 언급했듯이, 인터페이스 식별자, IoT 장치 식별자, 서비스 요청 식별자, 및 오더 식별자 중 적어도 인터페이스 식별자를 포함할 수 있다. 본 명세서 전반에서 서비스 식별자 중 오더 식별자를 제외한 나머지를 서비스 체인 식별자로 칭하기로 한다. 즉 서비스 식별자는 인터페이스 식별자로만 구성되거나, 인터페이스 식별자/IoT 장치 식별자, 인터페이스 식별자/오더 식별자, 인터페이스 식별자/IoT 장치 식별자/오더 식별자 등과 같이 여러 조합이 나올 수 있다.

서비스 식별자의 정의 방법은, 패킷에 미리 정의 되어 있는 필드 중 특정 필드에 서비스 식별자를 할당하거나, 패킷에 서비스 종류를 나타내는 메타데이터를 추가하는 방법을 포함할 수 있다. 서비스 식별자는 플로우의 메타데이터 중 어느 한 필드에 할당될 수도 있다.

서비스 식별자가 정의될 패킷 필드는 UDP 소스(source) 주소, vLAN(virtual Local Area Network) 필드, vxLAN(eXtendsible vLAN) 필드 등이 사용될 수 있다.

서비스 식별자가 정의된 플로우(또는 패킷)의 필드는 플로우가 공통 게이트웨이(30) 및/또는 복수의 클라우드 스위치(cSW)를 지나가면서 변경될 수 있다. 예를 들어, 공통 게이트웨이(30)에서 패킷의 UDP 소스 주소 필드를 서비스 식별자로 정의되고, 복수의 클라우드 스위치(cSW) 중 어느 스위치에서는 인입 포트를 서비스 식별자로 재정의되어 사용될 수 있다.

저장부(190)는 제어부(100)의 처리 및 제어를 위한 프로그램을 저장할 수 있다. 저장부(190)는 입력되거나 출력되는 데이터들(패킷, 메시지 등)을 임시 저장을 위한 기능을 수행할 수 있다. 저장부(190)는 엔트리 DB(191), 서비스 리스트 DB(192), 토폴로지 DB(193), IoT 장치 DB(194), 서비스 DB(195), 및 통계 DB(196)를 포함할 수 있다.

토폴로지 DB(193)는 토폴로지 관리부(130)에 의한 공통 게이트웨이(30), 복수의 클라우드 스위치(cSW), 클라우드 스위치(cSW)들 각각에 연결된 서비스 기능들(SF1 ~ SF7)의 연결 정보를 포함할 수 있다.

서비스 DB(195)는 서비스 엔트리를 저장 및 관리할 수 있다. 서비스 엔트리는 서비스 기능 클라우드(60)에서 제공하는 서비스의 타입을 구분하도록 할 수 있다. 서비스 엔트리는 서비스 기능 클라우드(60)의 서비스 기능(SF1 ~ SF7)의 종류를 정의하며, 서비스 식별자와 연결될 수 있다.

서비스 리스트 DB(192)는 서비스 식별자와 서비스 기능들을 한 집합으로 하는 서비스 리스트들을 저장할 수 있다. 서비스 리스트에 포함된 서비스 기능들은 일련의 서비스들로 특정 종류의 서비스들이 순서를 가지는 서비스 체이닝을 구성한다. 즉 서비스 리스트는 서비스 식별자와 서비스 체이닝을 하나의 집합으로 한다.

서비스 기능들의 순서는 서비스 기능들의 토폴로지 상태나 트래픽 처리 상태 등을 반영하여 동적으로 변경될 수 있다. 서비스 엔트리나 서비스 리스트의 저장이나 업데이트는 SF 관리 모듈(140)에 의해 관리될 수 있다.

서비스 리스트는 특정 물리 계층 인터페이스에 따른 트래픽에 특화된 서비스 체이닝이 구성되도록 할 수 있다. 예를 들어, 서비스 식별자 또는 인터페이스 식별자로 UDP 소스 주소를 사용하는 경우, 공통 게이트웨이(30)에서 블루트스 IoT 장치의 패킷의 UDP 소스 주소에 8000번으로 할당하고, WiFi의 경우 8001을 할당되도록 하고, 서비스 기능 클라우드(60)에 배치된 클라우드 스위치(cSW)에서 UDP 소스 주소를 체크하여 해당 인터페이스 트래픽에 특화된 서비스 체이닝을 운용할 수 있다. 이러한 패킷 경로가 발생되도록 제어기(10)는 공통 게이트웨이(30)의 게이트웨이 스위치(34) 및 서비스 기능 클라우드(60)의 클라우드 스위치(cSW)에 플로우 엔트리를 미리 배포할 수 있다.

IoT 장치 DB(194)는 IoT 장치 정보를 저장할 수 있다. IoT 장치 DB(194)는 특히 IoT 장치 식별자를 저장 관리할 수 있으며, IoT 장치 식별자는 IoT 장치의 MAC 주소가 이용될 수 있다.

엔트리 DB(191)는 토폴로지 DB(193), 서비스 리스트 DB(192), 및/또는 서비스 정보 DB(195)를 기초로 작성된 적절한 패킷 경로에 대한 엔트리들을 저장 및 관리할 수 있다.

통계 DB(196)는 각 플로우 마다의 트래픽 양, 처리 속도, 경유한 서비스 기능의 개수 및 그 타입, IoT 장치의 대역폭 사용률, 유해 트래픽 정보 등의 통계를 저장 및 관리할 수 있다.

제어기 제어부(100)는 통계 DB(196)의 유해 트랙픽 정보를 이용하여, 특정 트래픽이 차단되도록 플로우 엔트리를 구성 및 오픈플로우 스위치(게이트웨이 스위치(34) 및/또는 클라우드 스위치(cSW))에 배포할 수 있다. 예를 들어, 특정 블루투스를 사용하는 IoT 장치로부터 유해 트래픽이 감지된 경우, 해당 블루투스 장치의 트래픽을 차단시킬 수 있다. 이 경우, 서비스 식별자 중 IoT 장치 식별자(MAC 주소)를 기반으로 차단되도록 할 수 있다. 또는 서비스 식별자 중 목적지 UDP 주소, 또는 목적지 TCP 주소와 같이 사용되는 서비스 별로 차단 정책이 설정될 수도 있다. 이러한 필터링 기능은 서비스 기능 클라우드(60)에서 필터링 서비스 기능으로 구현되거나, 클라우드 스위치(cSW)의 플로우 정책으로 구현될 수 있다. 다만 이에 한정되지 않고, 필터링 기능은 공통 게이트웨이(30)의 게이트웨이 스위치(34)에서 구현될 수도 있다.

제어기 제어부(100)는 통계 DB(196)의 IoT 장치의 대역폭 사용률에 기반하여 각 IoT 장치(50)의 특성에 맞게 대역폭 자원이 관리되도록 할 수 있다. 이는 특정 물리 계층(통신 인터페이스) IoT 장치가 대역폭을 모두 사용하여, 다른 물리 계층 IoT 장치에 영향을 최소로 미치게 할 수 있다. 이에 의해, 서로 다른 물리 계층 IoT 장치들 각각에 자원을 공평하게 사용할 수 있도록 하거나, 각 IoT 장치의 특성에 맞게 대역폭 자원이 관리 될 수 있다. 이러한 대역폭 기능은 서비스 기능 클라우드(60)에서 대역폭 서비스 기능으로 구현되거나, 클라우드 스위치(cSW)의 플로우 정책으로 구현될 수 있다. 다만 이에 한정되지 않고, 대역폭 서비스 기능은 공통 게이트웨이(30)의 게이트웨이 스위치(34)에서 구현될 수도 있다.

도 11은 본 발명의 일 실시예에 따른 서비스 리스트 데이터 베이스 테이블, 도 12는 본 발명의 일 실시예에 따른 서비스 기능 클라우드의 구조도, 도 13은 도 11 및 도 12에 따른 플로우 테이블, 도 14는 본 발명의 다른 실시예에 따른 서비스 기능 클라우드의 구조도, 도 15는 도 11 및 도 14에 따른 플로우 테이블이다. 도 1 내지 도 10을 참조한다.

도 11을 참조하면, 제어기(10)는 서비스 체인 식별자와 해당 서비스 체인 식별자에 해당하는 서비스 체이닝(일련의 서비스 기능들의 특정 조합 및 그 순서)을 하나의 집합으로 하는 서비스 리스트들의 테이블을 생성할 수 있다. 예를 들어, 본 실시예에 따른 테이블은 서비스 체인 식별자가 100이면 패킷이 서비스 기능 A가 적용되도록 하며, 서비스 체인 식별자가 300이면 서비스 기능 A, B, 및 C 순으로 적용되도록 하는 테이블이다.

제어기(10)는 서비스 리스트 데이터베이스 및 스위치 토폴로지에 기초하여, 각 서비스 체인 식별자에 따른 패킷의 경로를 도출할 수 있다. 제어기(10)는 도출된 경로에 기초하여, 각 오픈플로우 스위치에 전달될 엔트리 리스트를 생성할 수 있다. 제어기(10)는 생성된 엔트리 리스트를 해당 경로의 오픈플로우 스위치들에 엔트리 리스트에 따른 엔트리 변경 메시지를 전송할 수 있다. 이러한 엔트리 변경 메시지는 오픈플로우 스위치에 미리 전송하여, 각 오픈플로우 스위치가 해당 엔트리 정보를 가지게 하는 것이 바람직하다. 오픈플로우 스위치에서 패킷이 유입되면 즉시 처리할 수 있기 때문이다. 경우에 따라서는 사용률이 적을 것 같은 플로우에 해당하는 엔트리는 선-배포(proactive)하지 않고, 오픈플로우 스위치로부터 패킷-인 메시지를 수신한 경우에 해당 엔트리를 배포할 수도 있다.

제어기(10)는 선 배포하는 플로우 엔트리의 타임아웃 값을 최대값 또는 0으로 지정할 수 있다. 타임아웃 값이 0인 경우 오픈플로우 스위치는 해당 엔트리의 히트(hit) 여부와 무관하게 엔트리가 존속할 수 있어, 영구 배포가 가능하다. 본 명세서가 작성되는 시점의 오픈플로우 스위치 백서 1.4.0은 타임아웃 값으로 idle_timeout 및 hard_timeout의 두 종류를 정의하고 있다. 엔트리가 영구 존속되도록 설정하려는 경우, idle_timeout 및 hard_timeout 모두 0으로 지정한다. 필요에 의해 제어기(10)는 0으로 지정된 플로우 엔트리를 삭제하거나 0이 아닌 타임아웃 값으로 변경하는 메시지를 오픈플로우 스위치로 전송할 수 있다.

도 12를 참조하면, 서비스 기능 클라우드(60)는 공통 게이트웨이(30)로부터 패킷을 수신하는 베이스 오픈플로우 스위치(61), 서비스 기능 노드들과 연결된 서비스 기능 오픈플로우 스위치(62), 및 복수의 NFv 그룹(G1~G4)를 포함할 수 있다. 본 토폴로지는 도 9(B)와 유사할 수 있다.

베이스 오픈플로우 스위치(61) 및 서비스 기능 오픈플로우 스위치(62)는 오픈플로우 프로토콜의 스위치이다. 베이스 오픈플로우 스위치(61)는 공통 게이트웨이(30) 및 IoT 오픈 플랫폼(90)에 직접 연결된 오픈플로우 스위치이다. 베이스 오픈플로우 스위치(61)는 직접 서비스 기능 노드가 연결되어, 서비스 기능을 제공 할 수도 있다.

서비스 기능 오픈플로우 스위치(62)는 베이스 오픈플로우 스위치(61)와 직접 또는 다른 가상 스위치와 연결된 오픈플로우 스위치로 가상 머신에 의해 생성될 수 있으나, 이에 한정되지 않고 실제 물리적인 스위치일 수도 있다. 다만 NFv와의 연동을 위해 가상 스위치인 것이 바람직하다.

복수의 NFv 그룹(G1~G4)는 각기 다른 기능, 즉 서로 다른 서비스를 제공할 수 있다. 복수의 NFv 그룹(G1~G4)은 서비스 기능 오픈플로우 스위치(62)에 연결되어, 통과하는 패킷에 일련의 서비스 즉 서비스 체인을 제공할 수 있다. 각 NFv 그룹은 하나 이상의 NFv 노드를 포함할 수 있다. 도 9와 같이, NFv 룹에 속한 NFv 노드들은 오픈플로우 스위치의 하나의 논리 입출력 포트로 집성(aggregation) 되어 연결되어 있는 것이 바람직하다. 동일 그룹에 속한 NFv 노드들이 오픈플로우 스위치의 여러 입출력 포트에 연결되어 있는 경우, 패킷 포워딩, 트래픽 분배, 로드 밸런싱 등이 플로우 테이블을 통해 제어 또는 관리되어야 한다. 플로우 테이블 변경을 통해 로드 밸런싱 등을 하는 것 보다 하나의 논리 입출력 포트로 로드 밸런싱 등을 하는 것이, 트래픽 제어 또는 트래픽 효율 등의 면에서 더 유리하다.

제어기(10)는 오픈플로우 스위치(30, cSW)가 구동(power on; wake up)되면, 오픈플로우 스위치의 메시지를 통해, 스위치 간의 토폴로지 및 각 스위치에 연결된 네트워크 디바이스들(NFv)의 위치 정보를 알 수 있다.

도 13은 특히 서비스 기능 오픈플로우 스위치(62)의 플로우 테이블에 관한 것으로, 서비스 기능 오픈플로우 스위치(62)는 서비스 체인 식별자와 유입 포트의 정보만으로 매치 필드를 가지는 플로우 엔트리를 운용할 수 있다. 도 11과 같이, 서비스 체인 식별자가 100인 경우, 패킷이 유입되는 포트 정보에 따라 패킷이 전달될 유출 포트가 각기 정해진다. 본 실시예와 같이 서비스 기능 노드들이 하나의 서비스 기능 오픈플로우 스위치(62)에 연결되어 있는 경우, 서비스 식별자는 오더 식별자를 구비할 필요가 없다. 이 경우, 메모리를 절약할 수 있으며, 플로우 정보에 매칭하는 엔트리를 검색하는 시간을 단축할 수 있다.

도 14를 참조하면, 서비스 기능 클라우드(60)는 공통 게이트웨이(30)로부터 패킷을 수신하는 베이스 오픈플로우 스위치(65), 서비스 기능 노드들과 연결된 제1 및 제2 서비스 기능 오픈플로우 스위치(66, 67), 및 복수의 NFv 그룹(G1~G4)를 포함할 수 있다. 도 9의 서비스 기능 클라우드(60)과 비교하면, 본 실시예에 따른 서비스 기능 클라우드(60)은 서비스 기능 오픈플로우 스위치의 개수가 2 이상인 경우를 예시한다. 가상 스위치가 2 이상인 경우, 도 15와 같이 서비스 체인 식별자는 오더 식별자를 구비해야 하는 것이 바람직하다. 이하, 도 12와의 차이점을 중점으로 기술한다.

도 15는, 도 11의 서비스 체인 식별자가 350인 플로우 테이블을 도시하고 있다. 클라우드 오픈플로우 스위치는 제어기(10)로부터 플로우 엔트리를 미리 배포 받아, 플로우 테이블로 저장할 수 있다. 도 15(a)는 베이스 오픈플로우 스위치(65), 도15(b)는 제1 서비스 기능 오픈플로우 스위치(66), 도 15(c)는 제2 서비스 기능 오픈플로우 스위치(67)의 플로우 테이블을 예시한다.

서비스 체인 식별자가 350인 경우의 서비스 리스트는 도 11을 참조하면, A -> C -> B 이다. 서비스 체인 식별자 및 인입 포트만으로 플로우 테이블의 매치 필드를 구성하는 경우 다음과 같은 문제점이 발생할 수 있다. 패킷이 베이스 오픈플로우 스위치(65)의 3번 포트에서 제1 서비스 기능 오픈플로우 스위치(66)의 11번 포트로 유입되는 경우, 패킷을 NFv 그룹 G1(서비스 A) 및 G2(서비스 B) 중 어느 그룹으로 보내야할지 알 수 없다. 이에 본 발명은 NFv와 관련된 오픈플로우 스위치 또는 NFv 그룹을 통과할 때, 업데이트되는 값(오더 식별자)을 패킷 또는 테이블과 관련된 메타데이터에 삽입하여 정확한 출력 포트를 지정할 수 있도록 하였다. 즉 서비스 식별자를 서비스 체인 식별자와 오더 식별자로 구성하여, 서비스 식별자로 사용되는 필드 중 일부는 서비스 체인 식별자로 나머지는 오더 식별자로 구성하여, NFv 그룹와 직접 연결된 오픈플로우 스위치가 2 이상이어도 패킷 흐름에 지장이 없도록 하였다.

오더 식별자 업데이트는 오픈플로우 스위치의 임의의 포트로 패킷이 유출될 때, 임의의 포트에서 패킷이 유입될 때, 및 NFv 그룹과 직접 연결되어 있는 다른 오픈플로우 스위치와 연결된 포트에서 패킷이 유입될 때 중 어느 한 경우 또는 조합으로 실행되도록 할 수 있다. 다만 이에 한정되지 않고, 패킷이 유출될 포트를 정확히 지정할 수 있는 오더 식별자 업데이트 요건이면 본 발명에 해당할 수 있다. 메모리 절약, 오더 식별자 업데이트 실행회수의 최소화 등을 위해, NFv 그룹과 직접 연결되어 있는 다른 오픈플로우 스위치에 연결된 포트에서 패킷이 업데이트되는 경우에 오더 식별자를 업데이트하는 것이 바람직하다. 아울러 도 11의 서비스 체인 식별자 100 또는 200과 같이, 하나의 오픈플로우 스위치에서 서비스 체이닝이 일어날 경우, 오더 식별자 업데이트는 이루어지지 않도록 하는 것이 자원 소모를 줄일 수 있어서 바람직하다.

구체적으로 베이스 오픈플로우 스위치(65)에 유입된 패킷의 서비스 체인 식별자가 350인 경우를 패킷의 흐름에 따라 예시한다. 오더 식별자의 초기값은 0으로 한다. 제어기(10)는 후술할 패킷 경로를 기초로 도 15의 (a) 내지 (c)와 같은 플로우 엔트리를 생성하여, 베이스 오픈플로우 스위치(65), 제1 서비스 기능 오픈플로우 스위치(66), 및 제2 서비스 기능 오픈플로우 스위치(67) 각각에 엔트리 생성(변경) 메시지를 전송할 수 있다.

우선 베이스 오픈플로우 스위치(65)는 1번 포트로 유입된 패킷을 3번 포트로 포워딩한다. 해당 서비스 체인 식별자의 초기 경로이므로, 오더 식별자와 무관하다. 이에 오더 식별자의 매칭 여부는 생략할 수 있다. 오더 식별자 매칭 생략을 통해, 검색 시간을 단축시킬 수 있다. 이와 대응하는 플로우 엔트리의 오더 식별자는 마스크하여 구현될 수 있다.

제1 서비스 기능 오픈플로우 스위치(66)는 오더 식별자가 0인 11번 포트로 유입된 패킷을 1번 포트로 포워딩한다. 제1 서비스 기능 오픈플로우 스위치(66)는 2번 포트로 유입된 패킷을 12번 포트로 포워딩한다. 해당 서비스 체인 식별자의 경우, NFv 그룹에서 유입되는 모든 패킷은 베이스 오픈플로우 스위치(65)의 12번 포트로 포워딩하면 되므로, 오더 식별자는 마스킹하고 인입 포트(in port)는 2번 또는 4번 포트로 매치 필드를 구성할 수 있다.

베이스 오픈플로우 스위치(65)는 오더 식별자가 0인 4번 포트로 유입된 패킷의 오더 식별자를 업데이트(1단계 상승)한 후, 패킷을 5번 포트로 포워딩한다. NFv 그룹과 직접 연결되어 있는 오픈플로우 스위치에서 인입된 패킷이기 때문이다.

제2 서비스 기능 오픈플로우 스위치(67)는 21번 포트로 유입된 패킷을 1번 포트로 포워딩한 후, 2번 포트로 유입된 패킷을 22번 포트로 포워딩한다. 해당 서비스 체인 식별자의 경우, 오더 식별자와 무관하게 패킷 포워딩을 할 수 있다. 다만 패킷 흐름에 에러가 있는 지 판단하기 위한 요건으로, 오더 식별자가 정확한지 판단하기 위해 오더 식별자를 마스크하지 않을 수도 있다. 도 15(c)를 참조하면, 제2 서비스 기능 오픈플로우 스위치(67)의 플로우 테이블 중 21번 포트로 유입되는 패킷과 관련된 플로우 엔트리에 오더 식별자가 매치되도록 하여 에러 탐색을 할 수 있도록 하였다.

베이스 오픈플로우 스위치(65)는 6번 포트로 유입된 패킷을 3번 포트로 포워딩한다. 이 경우 오더 식별자는 무관하므로, 오더 식별자 필드는 마스킹할 수 있다. 다만 베이스 오픈플로우 스위치(65)는 패킷을 3번 포트로 포워딩하기 전에 해당 패킷의 오더 식별자를 업데이트해야 한다.

제1 서비스 기능 오픈플로우 스위치(66)는 오더 식별자가 2인 11번 포트로 유입된 패킷을 3번 포트로 포워딩한 한다. 제1 서비스 기능 오픈플로우 스위치(66)는 4번 포트로 유입된 패킷을 12번 포트로 포워딩한다. 이 경우, 오더 식별자는 무관하므로 마스킹할 수 있다. 앞서 서술한 바와 같이, 해당 플로우 엔트리는 인입 포트가 2번인 포트와 통합될 수 있다.

베이스 오픈플로우 스위치(65)는 4번 포트로 유입된 패킷을 2번 포트로 포워딩하여 서버로 전송한다. 더 이상 오더 식별자가 사용되지 않으므로, 오더 식별자를 업데이트할 필요는 없다.

위에 설명한 바와 같이, 각 오픈플로우 스위치는 제어기(10)로부터 해당 플로우 엔트리를 미리 배포받아, 엔트리 테이블로 저장할 수 있다.

상기 본 발명은 하드웨어 또는 소프트웨어에서 구현될 수 있다. 구현은 상기 본 발명은 또한 컴퓨터로 읽을 수 있는 기록매체에 컴퓨터가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 컴퓨터가 읽을 수 있는 기록매체는 컴퓨터 시스템에 의하여 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 컴퓨터가 읽을 수 있는 기록매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피 디스크, 광 데이터 저장장치 등이 있으며, 또한 캐리어 웨이브(예를 들어 인터넷을 통한 전송)의 형태로 구현되는 것도 포함한다. 또한 컴퓨터가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 컴퓨터가 읽을 수 있는 코드가 저장되고 실행될 수 있다. 그리고 본 발명을 구현하기 위한 기능적인(functional) 프로그램, 코드 및 코드 세그먼트들은 본 발명이 속하는 기술분야의 프로그래머들에 의해 용이하게 추론될 수 있다.

본 발명의 실시예들은 여기에 설명된 방법들 중 하나가 실행되는 프로그램가능 컴퓨터 시스템으로 운영될 수 있는, 전자적으로 판독가능한 제어 신호들을 갖는 캐리어 웨이브를 포함할 수 있다. 본 발명의 실시예들은 프로그램 코드를 갖는 컴퓨터 프로그램 제품으로서 구현될 수 있으며, 프로그램 코드는 컴퓨터 프로그램이 컴퓨터 상에서 구동될 때 방법들 중 하나를 실행하기 위하여 운영된다. 프로그램 코드는 예를 들면 기계 판독가능 캐리어 상에 저장될 수 있다. 본 발명의 일실시예는 컴퓨터 프로그램이 컴퓨터 상에 구동될 때, 여기에 설명된 방법들 중 하나를 실행하기 위한 프로그램 코드를 갖는 컴퓨터 프로그램일 수 있다. 본 발명은 위에서 설명한 방법들 중 하나를 실행하기 위한 컴퓨터, 또는 프로그램가능 논리 장치를 포함할 수 있다. 위에서 설명한 방법들의 일부 또는 모든 기능을 실행하기 위하여 프로그램가능 논리 장치(예를 들면, 필드 프로그램가능 게이트 어레이, 상보성 금속 산화물 반도체 기반 논리 회로)가 사용될 수 있다.

또한, 이상에서는 본 발명의 바람직한 실시예에 대하여 도시하고 설명하였지만, 본 발명은 상술한 특정의 실시예에 한정되지 아니하며, 청구범위에서 청구하는 본 발명의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형실시들은 본 발명의 기술적 사상이나 전망으로부터 개별적으로 이해되어져서는 안 될 것이다.

1: 오케스트레이터 10: 제어기
30: 공통 게이트웨이 32: 게이트웨이 통신부
34: 게이트웨이 스위치 50: IoT 장치
60: 서비스 기능 클라우드 90: IoT 오픈 플랫폼
236: 발산 유닛 237: 수렴 유닛

Claims (8)

1. 공통 게이트웨이로서,
   복수의 IoT(Internet of Things) 장치와 통신하는 서로 다른 인터페이스 모듈을 구비하는 통신부; 및
   상기 통신부를 통해 인입한 플로우에 상기 플로우의 패킷이 인입한 인터페이스를 식별하는 인터페이스 식별자를 구비하는 서비스 식별자를 상기 플로우에 할당하는 오픈플로우(openflow) 기반의 게이트웨이 스위치를 구비하는 상기 공통 게이트웨이; 및
   상기 공통 게이트웨이로부터 전달받은 플로우에 상기 인터페이스 식별자에 대응하여 인터페이스 별로 일련의 서비스 기능을 제공하는 서비스 기능 클라우드를 포함하고,
   상기 서비스 기능 클라우드는
   복수의 서비스 노드 그룹으로서, 서비스 노드 그룹은 동일한 서비스 기능을 제공하는 서비스 노드들을 집합인, 상기 복수의 서비스 노드 그룹; 및
   서비스들의 종류 및 순서가 정의된 서비스 리스트들의 집합에서 상기 서비스 식별자에 대응하는 서비스 리스트에 대응하는 일련의 서비스가 상기 플로우에 제공되도록, 상기 플로우를 복수의 포트 중 어느 한 포트로 전달하는 오픈플로우 기반의 클라우드 스위치를 포함하고,
   상기 복수의 포트는 중 어느 하나는 상기 복수의 서비스 노드 그룹 중 어느 한 서비스 노드 그룹 및 다른 클라우드 스위치 중 어느 하나와 연결된, 네트워크 시스템.
2. 제 1 항에 있어서,
   상기 서비스 식별자는 IoT 장치 식별자를 더 구비하고,
   상기 서비스 기능 클라우드는 상기 장치 식별자에 대응하여 상기 플로우의 드롭 여부를 결정하는 필터링 서비스 기능을 더 구비하는, 네트워크 시스템.
3. 제 1 항에 있어서,
   상기 서비스 기능 클라우드는 상기 서비스 식별자에 대응하여 IoT 장치의 대역폭 사용률을 제한하는 대역폭 서비스 기능을 더 구비하는, 네트워크 시스템.
4. 삭제
5. 제 1 항에 있어서,
   상기 서비스 식별자는 상기 적어도 하나의 클라우드 스위치에 유입되는 플로우의 포트 정보에 기초하여 업데이트될 수 있는 오더 아이디를 더 포함하고,
   상기 클라우드 스위치는 포트에 유입되는 플로우에 대해 상기 서비스 식별자에 대응하는 액션을 처리하는, 네트워크 시스템.
6. 제 5 항에 있어서,
   상기 클라우드 스위치는 상기 플로우가 유입되는 포트가 상기 다른 클라우드 스위치와 연결된 포트인 경우, 상기 오더 아이디를 업데이트하는, 네트워크 시스템.
7. 제 1 항에 있어서,
   상기 복수의 서비스 노드 그룹 중 어느 한 서비스 노드 그룹의 서비스 노드들의 개수는 적어도 네트워크 상태에 기초하여 변동되는, 네트워크 시스템.
8. 제 1 항에 있어서,
   상기 클라우드 스위치의 상기 서비스 노드 그룹에 연결된 포트는 논리 포트인, 네트워크 시스템.

Images