KR101590740B1

KR101590740B1 - 네트워크 통신 장치 및 전송 프레임의 우선적 대역 제한 방법

Info

Publication number: KR101590740B1
Application number: KR1020147013058A
Authority: KR
Inventors: 시호미 마쯔무라; 마사노리 다까시마; 요지 스즈끼
Original assignee: 닛본 덴끼 가부시끼가이샤
Priority date: 2011-11-15
Filing date: 2012-11-15
Publication date: 2016-02-01
Also published as: BR112014011652A2; EP2782298A1; CA2855762A1; EP2782298A4; IN2014CN03581A; CN103947167B; WO2013073639A1; RU2586062C2; KR20140073589A; RU2014119522A; US20150063116A1; JPWO2013073639A1; JP5668868B2; US9525635B2; CN103947167A

Abstract

네트워크 통신 기기에서 각 전송 프레임에 우선도를 부여한 전송 및 폐기 처리를 실현할 때, 전송 수신처 장치의 폭주를 방지하기 위한 대역 제한을 행한다. 구체적으로는, 우선도마다 버킷을 제공하고, 우선도에 따른 양의 토큰을 보충한다. 또한, 버킷 평가 전에, 하나의 공유 버킷을 제공한다. 일정 기간마다, 우선도마다 제공된 버킷 내에 존재하는 토큰을 모두 공유 버킷에 할당한다. 공유 버킷의 깊이를 초과해서 넘친 토큰은 폐기한다. 공유 버킷에 토큰이 존재하는 한, 프레임의 우선도에 상관없이 모든 프레임을 평등하게 평가하고 전송한다. 공유 버킷에 토큰이 없는 경우에, 우선적 제한으로 전환하고, 각 우선도 버킷을 평가한다. 해당 프레임의 우선도에 대응하는 버킷을 확인하고 토큰이 존재하는 경우에, 프레임의 전송 처리를 행한다. 토큰이 없는 경우에, 프레임의 폐기 처리를 행한다.

Description

네트워크 통신 장치 및 전송 프레임의 우선적 대역 제한 방법{NETWORK COMMUNICATION APPARATUS AND METHOD OF PREFERENTIAL BAND LIMITATION OF TRANSFER FRAME}

본 발명은 네트워크 통신 장치에 관한 것으로, 특히 네트워크 통신 장치에서 전송 프레임을 우선적으로 대역 제한하는 방법에 관한 것이다.

종래의 네트워크 기기는 외부 기기로부터 부하 분산이나 치우친 상태 등 유연한 제어를 할 수 없다고 하는 문제가 있었다. 이 때문에, 네트워크의 규모가 커지면, 시스템의 거동의 파악과 개선이 곤란하게 되어, 설계나 구성의 변경에 많은 코스트를 필요로 한다는 문제가 있었다.

상기 과제를 해결하기 위한 기술로서, 네트워크 기기의 패킷 전송 기능과 경로 제어 기능을 분리하는 방법이 고려되고 있다. 예를 들면, 패킷 전송 기능을 네트워크 기기가 담당하고, 제어 기능을 네트워크 기기로부터 외부에 분리된 제어 장치가 담당한다. 이런 식으로, 제어 장치가 패킷의 전송을 관리할 수 있고, 유연한 네트워크를 구축할 수 있다.

(CD 분리형 네트워크의 설명)

기능을 분리한 집중 관리형의 네트워크의 하나로서, 컨트롤 플레인 측의 제어 장치가 데이터 플레인 측의 노드 장치를 제어하는 CD(C: 컨트롤 플레인/D: 데이터 플레인) 분리형 네트워크가 제안되어 있다.

CD 분리형 네트워크의 일례로서, 컨트롤러가 스위치를 제어하여 네트워크의 경로 제어를 행하는 오픈 플로우(OpenFlow) 기술을 이용한 오픈 플로우 네트워크를 들 수 있다. 오픈 플로우 기술의 상세는 비특허 문헌 1에 기재되어 있다. 오픈 플로우 네트워크는 일례에 불과하다는 점에 주목한다.

(오픈 플로우 네트워크의 설명)

오픈 플로우 네트워크에서는, MAC 어드레스, IP 어드레스, 포트 번호 등의 조합에 기초하여 결정되는 일련의 통신을 "플로우"라고 정의한다. 플로우 단위로 경로 제어, 장애 회복, 부하 분산, 및 최적화를 행한다.

오픈 플로우 네트워크에서는, 제어 장치로서의 오픈 플로우 컨트롤러(OFC: OpenFlow Controller)가 노드 장치에 상당하는 오픈 플로우 스위치(OFS: OpenFlow Switch)의 경로 제어에 관한 플로우 테이블을 조작하여, 오픈 플로우 스위치의 거동을 제어한다.

컨트롤러와 스위치는 전용선이나 SSL(Secure Socket Layer)에 의해 보호된 통신로인 시큐어 채널(Secure Channel)을 통해 서로 접속되어 있다. 컨트롤러와 스위치는 시큐어 채널을 통하여, 오픈 플로우 규약(OpenFlow Protocol)에 기초한 오픈 플로우 메시지(OpenFlow Message)를 서로 송수신한다.

오픈 플로우 네트워크에서의 스위치는 오픈 플로우 네트워크를 형성하고 컨트롤러의 제어하에 있는 에지 스위치 및 코어 스위치를 포함한다. 에지 스위치는 오픈 플로우 네트워크와 다른 네트워크와의 경계에 위치하는 스위치라는 점에 주목한다. 또한, 코어 스위치는 오픈 플로우 네트워크 내에서 패킷의 중계에 사용되는 스위치이다. 오픈 플로우 네트워크에 있어서, 컨트롤러는 경로 상의 스위치의 플로우 테이블을 조작하고 입력 측 에지 스위치(Ingress)에서의 패킷의 수신(inflow)으로부터 출력 측 에지 스위치(Egress)에서의 패킷의 송신(outflow)까지의 일련의 흐름을 제어할 수 있다.

패킷은 프레임(frame)이라고도 읽을 수 있다. 패킷과 프레임 간의 차이는 프로토콜에서 취급되는 데이터의 단위(PDU: Protocol Data Unit)의 차이에 불과하다. 패킷은 "TCP/IP" (Transmission Control Protocol/Internet Protocol)의 PDU이다. 한편, 프레임은 "Ethernet(등록 상표)"의 PDU이다.

플로우 테이블은 플로우로서 취급되는 패킷을 특정하기 위한 판별 조건(룰); 패킷이 룰에 적합(매치)한 횟수를 나타내는 통계 정보; 및 패킷에 대하여 행해지는 처리 내용(액션)의 조합을 각각 정의한 플로우 엔트리의 집합이다.

플로우 엔트리의 룰은 패킷의 헤더 영역(필드)에 포함되는 각 프로토콜 계층의 데이터의 어느 하나 또는 모두의 다양한 조합에 기초하여 정의되고, 이 룰은 구별가능하다. 각 프로토콜 계층의 정보의 예로서, 송신 수신처 어드레스(Destination Address), 송신원 어드레스(Source Address), 송신 수신처 포트(Destination Port) 및 송신원 포트(Source Port) 등을 들 수 있다. 상기의 어드레스는 MAC 어드레스(Media Access Control Address)이나 IP 어드레스(Internet Protocol Address)인 것으로 한다는 점에 주목한다. 또한, 상기 외에, 입구 포트(Ingress Port)의 데이터도 플로우 엔트리의 룰로서 사용가능하다. 또한, 플로우 엔트리의 룰로서, 플로우로서 취급되는 패킷의 헤더 영역의 값의 일부(또는 전부)의 정규 표현이나 와일드 카드(wildcard) "*" 표현을 설정할 수도 있다.

플로우 엔트리의 액션은 "패킷을 특정한 포트에 출력/전송한다", "패킷을 파기/폐기한다(삭제한다)", 또는 "패킷의 헤더를 재기입한다"라고 하는 동작을 나타낸다. 예를 들면, 스위치는 플로우 엔트리의 액션이 출력 포트의 식별 데이터(출력 포트 번호 등)이 나타낸다면, 이 식별 데이터에 해당하는 포트에 패킷을 출력하고, 출력 포트의 식별 데이터가 나타내져 있지 않으면, 스위치는 패킷을 파기한다. 혹은, 플로우 엔트리의 액션이 헤더 데이터를 나타낸다면, 스위치는 해당 헤더 데이터에 기초하여 패킷의 헤더를 재기입한다.

스위치는 플로우 엔트리의 룰에 적합한 패킷 군(패킷 계열)에 대한 플로우 엔트리의 액션을 실행한다. 구체적으로는, 패킷을 수신하면, 스위치는 수신한 패킷의 헤더 데이터에 적합한 룰을 갖는 플로우 엔트리를 플로우 테이블로부터 검색한다. 검색의 결과, 수신한 패킷의 헤더 데이터에 적합한 룰을 갖는 플로우 엔트리가 발견된 경우에, 스위치는 해당 플로우 엔트리의 통계 데이터를 갱신하고, 수신한 패킷에 대하여, 해당 플로우 엔트리의 액션으로서 지정된 동작을 실시한다. 한편, 검색의 결과, 수신한 패킷의 헤더 데이터에 적합한 룰을 갖는 플로우 엔트리가 발견되지 않은 경우에, 스위치는 해당 수신한 패킷을 최초의 패킷이라고 판단하고, 제어 채널을 통하여 오픈 플로우 네트워크에서의 컨트롤러에 수신한 패킷(또는 그 카피)을 전송하고, 수신한 패킷의 송신원·송신 수신처(어드레스)에 기초한 패킷의 경로 계산을 요구하고, 응답으로서 플로우 엔트리의 설정용 메시지를 수신한 다음에 플로우 테이블을 갱신한다.

플로우 테이블에는 낮은 우선도로 모든 패킷의 헤더 데이터에 적합한 룰을 갖는 디폴트 엔트리가 등록되어 있다는 점에 주목한다. 수신한 패킷에 적합한 플로우 엔트리가 발견되지 않은 경우에, 수신한 패킷은 이 디폴트 엔트리에 적합하다. 디폴트 엔트리의 액션은 "컨트롤러에의 해당 수신한 패킷의 문의 정보의 송신"이다.

(오픈 플로우 네트워크의 과제)

통상적으로, 오픈 플로우 네트워크 시스템에서는, 컨트롤러와 스위치는 "1:N (다수)"의 접속 관계에 있는 경우가 많다.

따라서, 컨트롤러는 다수의 스위치로부터 비제어 요구를 수취하는 경우가 있기 때문에, 그 처리 능력의 한계를 초과할 가능성이 있다.

컨트롤러가 처리 능력의 한계를 초과한 요구를 수취해서 처리 불능 상태로 되면, 각 스위치는 제어 기능을 상실하고, 각 스위치와 네트워크가 단절된다. 그러므로, 스위치가 컨트롤러의 처리 능력의 한계를 고려해서 요구를 할 필요가 있다.

또한, 컨트롤러의 처리 능력의 보호 외에, 스위치 자신의 처리 능력을 보호할 필요도 있었다.

따라서, 컨트롤러의 처리 능력의 보호와 스위치의 처리 능력의 보호의 양면으로부터, 컨트롤러와 스위치 간의 대역 제한이 필요했다.

그러나, 컨트롤러와 스위치 간의 대역 제한은, 메시지의 종별에 따라 오픈 플로우 기능으로서의 목적이나 중요도가 다르기 때문에, 우선적으로 행할 필요가 있다.

우선도 제어에서는, 낮은 우선도의 프레임이 무전송 상태로 되는 것을 피해야 한다는 과제도 있다.

(관련 기술)

관련 기술로서, 특허 문헌 1(특허 공개 2005-244417A호)에 대역 제어 장치, 대역 제어 방법 및 대역 제어 프로그램이 개시되어 있다. 이 관련 기술에서는, 대역 제한 처리부가 토큰 버킷(token bucket)에 잔존하는 잔존 토큰량 X를 기억한다. 토큰량 감시부가 기억된 잔존 토큰량과 최대 버스트 토큰량을 비교한다. 우선도 제어부가 그 비교 결과에 기초하여 대역 보증형 통신에 할당된 통신 회선 용량을 최선 노력형(best effort type) 통신에 할당한다.

버킷은 페일(pail)을 나타내며, 전송해야 할 네트워크 트래픽을 수집하도록 추상화된 컨테이너라는 점에 주목한다.

특허 공개 2005-244417A호

"OpenFlow Switch Specification, Version 1.0.0", [online], (2009년 12월 31일), 인터넷 (URL:http://www.openflowswitch.org/documents/openflow-spec-v1.0.0.pdf)

네트워크 통신 장치에서 전송 수신처 장치의 폭주를 방지하기 위한 대역 제한을 행하는 경우에, 각 전송 프레임에 우선도를 부여하고 전송 및 폐기 처리를 실현하는 것이 과제이다.

또한, 종래의 우선도 제어 방식인 PQ(Priority Queuing)와 같이, 높은 우선도의 프레임을 대량으로 수신한 경우에, 낮은 우선도의 프레임이 전혀 전송되지 않는다는 문제를 해결할 필요가 있다.

상기의 문제에 대응하는 WFQ(Weighted Fair Queuing) 및 CBWFQ(Class-Based Weighted Fair Queuing) 등의 방식이 존재한다. 그러나, 이러한 방식은 전송 우선도마다 제공된 복수의 서브 큐(sub queue)에 채워진 프레임을 우선적으로 전송 제어하는 방식이다. 서브 큐를 위해 메모리 리소스가 요구되기 때문에, 리소스 배분의 문제가 있다.

또한, 장치가 폭주 상태에 있지 않을 때에는, 프레임의 우선도에 상관없이 평등하게 전송을 행하고 평등한 버스트 전송도 허용하는 것이 적절하다.

본 발명의 목적은 상기의 과제를 해결하는 것 외에 전송 수신처 장치의 폭주를 방지하기 위해서 대역 제한을 행하는 네트워크 통신 장치를 제공하는 것이다.

본 발명에 따른 네트워크 통신 장치는 컨트롤러에 의한 제어 하에서 수신한 프레임을 플로우로서 일률적으로 제어하기 위한 룰과 액션을 정의한 플로우 엔트리를 플로우 테이블에 등록하는 오픈 플로우 처리부(21), 모든 프레임에 대응하는 공유 버킷 및 컨트롤러 행인 프레임마다의 우선도에 대응하는 우선도 버킷을 제공하는 버킷 제공부, 수신한 프레임이 컨트롤러 행인지를 평가하고 컨트롤러 행인 프레임에 대하여 공유 버킷을 평가하는 공유 버킷 평가부(23), 공유 버킷의 평가의 결과 전송 프레임의 우선적 대역 제한을 행하는 경우에 해당 프레임의 우선도에 대응하는 우선도 버킷을 평가하여 전송 또는 폐기를 결정하는 우선도 버킷 평가부(24)를 포함한다.

본 발명에 따른 전송 프레임의 우선적 대역 제한 방법은 네트워크 통신 장치에 의해 실시되는 방법으로서, 컨트롤러에 의한 제어 하에서 수신한 프레임을 플로우로서 일률적으로 제어하기 위한 룰과 액션을 정의한 플로우 엔트리를 플로우 테이블에 등록하는 단계; 상기 컨트롤러 행인 프레임모두에 대한 공유 버킷 및 프레임마다의 우선도에 대한 우선도 버킷을 제공하는 단계; 수신한 프레임이 상기 컨트롤러 행인지를 평가하고, 상기 컨트롤러 행인 프레임에 대하여 공유 버킷을 평가하는 단계; 및 공유 버킷의 평가의 결과 전송 프레임의 우선적 대역 제한을 행하는 경우에 해당 프레임의 우선도에 대응하는 우선도 버킷을 평가하여 전송 또는 폐기를 결정하는 단계를 포함한다.

본 발명에 따른 프로그램은 상기의 전송 프레임의 우선적 대역 제한 방법에서의 처리를 네트워크 통신 장치에게 실행시키기 위한 프로그램이다. 또한, 본 발명에 따른 프로그램은 기억 장치 및 기억 매체에 저장하는 것이 가능하다.

높은 우선도의 프레임이 대량으로 도착한 경우에도 각 버킷에는 일정 기간마다 우선도에 기초하여 결정된 양의 토큰이 보충되기 때문에, 낮은 우선도의 버킷에의 프레임의 전송이 전혀 중지되지 않는다. 또한, 각 버킷에 남아 있었던 토큰은 일정 기간마다 우선도에 상관없이 모두 공유 버킷에 보충되기 때문에, 공유 버킷에서 전송 프레임의 평등한 전송이 이루어질 수 있다. 프레임은 도착 순서대로 평가되어 토큰의 사용 유무에 기초하여, 프레임이 전송 또는 폐기되어야 한다는 판단이 이루어진다. 우선도마다 서브 큐를 제공할 필요가 없고, 동시에 대역 제한이 가능하다.

도 1은 오픈 플로우 네트워크 시스템의 구성 예를 도시하는 도면.
도 2는 본 발명에서의 우선적 대역 제한을 도시하는 개념도.
도 3은 공유 버킷에 토큰이 존재하는 사례를 도시하는 도면.
도 4는 우선도 버킷에 토큰이 존재하는 사례를 도시하는 도면.
도 5는 버킷 둘 다에 토큰이 존재하지 않는 사례를 도시하는 도면.
도 6은 본 발명에 따른 스위치(네트워크 통신 장치)의 동작을 도시하는 플로우차트.
도 7은 공유 버킷에 토큰이 존재하는 경우의 프레임 처리를 도시하는 도면.
도 8은 우선도 버킷에 토큰이 존재하는 경우의 프레임 처리를 도시하는 도면.
도 9는 버킷 둘 다에 토큰이 존재하지 않는 경우의 프레임 처리를 도시하는 도면.
도 10은 본 발명에 따른 스위치(네트워크 통신 장치)의 기본적인 구성 예를 도시하는 도면.
도 11은 본 발명에 따른 스위치(네트워크 통신 장치)의 상세한 구성 예를 도시하는 도면.

본 발명은 CD 분리형 네트워크 시스템을 대상으로 삼고 있다. 여기서, CD 분리형 네트워크 시스템의 하나인 오픈 플로우(OpenFlow) 네트워크 시스템을 예로 들어 설명한다. 그러나, 실제로는, 본 발명은 오픈 플로우 네트워크 시스템에 한정되지 않는다.

<실시예>

본 발명의 실시예에 대해서 첨부된 도면을 참조하여 이하에 설명한다.

(시스템 구성)

도 1에 도시한 바와 같이, 오픈 플로우 네트워크 시스템은 컨트롤러(10) 및 스위치(20)(20-i, i=1∼n: n은 임의)를 포함한다.

컨트롤러(10)는 서버 장치이며 스위치(20)(20-i, i=1∼n) 각각에 대하여, 수신한 프레임에 우선도를 부여한다. 여기서, 컨트롤러(10)는 수신한 프레임의 거동이 정의된 플로우 엔트리에 우선도 데이터를 부가하여 스위치(20)(20-i, i=1∼n) 각각에 설정한다.

스위치(20)(20-i, i=1∼n) 각각은 네트워크 통신 장치이며 수신처로서 컨트롤러(10) 내로 유입하는 프레임에 우선적 대역 제한을 행한다. 스위치(20)(20-i, i=1∼n) 각각은 수신처로서 컨트롤러(10) 내로 유입한 프레임을 규정된 복수의 우선도에 기초하여 분류한다.

여기서, 스위치(20)(20-i, i=1∼n) 각각은, 프레임 수신시에, 플로우 엔트리가 등록되어 있는 플로우 테이블에서 프레임을 평가한다. 우선도가 설정되어 있는 경우에, 스위치(20)(20-i, i=1∼n) 각각은 프레임의 우선도에 따라서 수신한 프레임의 전송 제한을 행한다.

스위치(20)(20-i, i=1∼n) 중, 컨트롤러(10)에 프레임을 전송하는 처리를 행하는 스위치는 입력 측 에지 스위치에 상당하는 스위치만일 수 있다는 점에 주목한다. 즉, 오픈 플로우 네트워크의 외부로부터 최초로 프레임을 수신한 스위치(20)가 본 발명의 주요 대상이 된다. 물론, 코어 스위치에 상당하는 스위치도 컨트롤러(10)에 프레임을 전송하는 처리를 행할 수 있기 때문에, 본 발명의 대상일 수 있다.

본 발명에서의 우선적 대역 제한은 토큰 버킷(token bucket) 방식을 채용하여 실현한다.

본 실시 형태에서는, 스위치(20)(20-i, i=1∼n) 중의 하나이며 프레임을 수신한 스위치(20)는 컨트롤러(10)로 지정된 프레임에 대하여 하나의 공유 버킷(우선도에 의존하지 않는 공통의 버킷) 및 복수의 우선도 버킷(우선도별의 버킷)을 제공한다. 이들 버킷에서는 토큰량과 버킷의 평가만 행해지는 것으로 한다. 이들 버킷은 평가를 위한 행렬, 및 수신으로부터 송신까지 사용된 버퍼나 큐(queue)로서 사용되지 않는다. 본 실시 형태에서는, 스위치(20)는 수신 버퍼로부터 프레임을 취출하고 해당 프레임에 대응하는 어느 하나의 버킷에 토큰이 존재하는지를 확인한다. 어느 하나의 버킷에 토큰이 존재하는 경우에, 스위치(20)는 송신 버퍼에 프레임을 전송한다. 어느 하나의 버킷에도 토큰이 존재하지 않는 경우에, 프레임은 폐기된다. 토큰이나 버킷의 평가에 있어서, 프레임이 버퍼링되지 않는다.

우선, 프레임을 수신할 때, 스위치(20)는 수신한 프레임이 컨트롤러(10)로 지정되는지를 평가하고, 컨트롤러(10)로 지정된 프레임에 대하여 공유 버킷을 평가한다.

공유 버킷에 충분한 양의 토큰이 없는 경우에, 프레임을 수신한 스위치(20)는 그 프레임의 우선도에 대응하는 우선도 버킷을 평가하여 그것이 전송 또는 폐기되어야 하는지를 결정한다.

(하드웨어의 예시)

본 발명에 따른 컨트롤러(10) 및 스위치(20)(20-i, i=1∼n) 각각을 실현하기 위한 구체적인 하드웨어 구성에 대해서 이하에 설명한다.

컨트롤러(10)의 예로서, PC(퍼스널 컴퓨터), 어플리언스(appliance), 씬 클라이언트(thin client) 서버, 워크스테이션, 메인프레임, 및 슈퍼컴퓨터 등의 계산기를 상정하고 있다. 컨트롤러(10)는 단말기나 서버에 한하지 않고, 중계 기기나 주변 기기일 수 있다는 점에 주목한다. 또한, 컨트롤러(10)는 계산기 등에 탑재되는 확장 보드, 및 물리 머신 위에 구축된 가상 머신(VM: virtual machine)일 수 있다.

스위치(20)(20-i, i=1∼n) 각각의 예로서, 네트워크 스위치, 라우트, 프록시, 게이트웨이, 파이어월, 로드 평형 장치(부하 분산 장치), 대역 제어 장치(packet shaper), 시큐러티 감시 제어 장치(SCADA: Supervisory Control And Data Acquisition), 게이트 키퍼(gate keeper), 기지국, 액세스 포인트(AP), 통신 위성(CS), 또는, 복수의 통신 포트를 갖는 계산기 등이 생각된다.

상기 컨트롤러(10) 및 스위치(20)(20-i, i=1∼n) 각각은 프로그램을 실행하여 소정의 처리를 행하는 프로세서; 해당 프로그램 및 각종 데이터를 기억하는 메모리; 및 네트워크와의 통신에 이용되는 인터페이스를 사용하여 실현된다.

상기 프로세서의 예로서, CPU(Central Processing Unit), 네트워크 프로세서(NP), 마이크로프로세서, 마이크로컨트롤러, 또는, 전용의 기능을 갖는 반도체 집적 회로(LSI: Large Scale Integration) 등을 들 수 있다.

상기 메모리의 예로서, RAM(Random Access Memory), ROM(Read Only Memory), EEPROM(Electrically Erasable and Programmable Read Only Memory) 및 플래시 메모리 등의 반도체 기억 장치, HDD(Hard Disk Drive) 및 SSD(Solid State Drive) 등의 보조 기억 장치, 또는, DVD(Digital Versatile Disk) 등의 리무버블 디스크, 및 SD 메모리 카드(Secure Digital memory card) 등의 기억 매체 등을 들 수 있다. 또한 이것은 버퍼, 레지스터 등일 수 있다. 혹은, 이것은 DAS(Direct Attached Storage), FC-SAN(Fibre Channel - Storage Area Network), NAS(Network Attached Storage), IP-SAN(IP - Storage Area Network) 등을 이용한 스토리지 장치일 수 있다.

상기 프로세서 및 상기 메모리는 단일 칩 내로 일체화될 수 있다는 점에 주목한다. 예를 들면, 최근에는, 마이크로컴퓨터 등의 원칩(one chip) 구성이 진행된다. 따라서, 전자 기기 등에 탑재되는 원칩 마이크로컴퓨터가 상기 프로세서 및 상기 메모리를 구비하고 있는 사례도 생각된다.

상기 인터페이스의 예로서, 네트워크 통신에 대응한 기판(마더보드, I/O 보드), 칩 등의 반도체 집적 회로, NIC(Network Interface Card) 등의 네트워크 어댑터 및 유사한 확장 카드, 안테나 등의 통신 장치, 접속구(커넥터) 등의 통신 포트를 들 수 있다.

또한, 네트워크의 예로서, 인터넷, LAN(Local Area Network), 무선 LAN, WAN(Wide Area Network), 백본(back bone), 케이블 텔레비전(CATV) 회선, 고정 전화망, 휴대 전화망, WiMAX(IEEE 802.16a), 3G(제3 세대), 전용선(lease line), IrDA(Infrared Data Association), Bluetooth(등록 상표), 시리얼 통신 회선, 데이터 버스 등이 생각된다.

컨트롤러(10), 및 스위치(20)(20-i, i=1∼n) 각각의 내부의 구성 요소는 모듈, 컴포넌트, 전용 디바이스, 또는 이들의 기동(호출) 프로그램일 수 있다는 점에 주목한다.

그러나, 실제로는, 본 발명은 이들 예에 한정되지 않는다.

(우선적 대역 제한)

본 발명에서의 우선적 대역 제한에 대해서 이하에 상세하게 설명한다.

스위치(20)(20-i, i=1∼n) 중의 하나이며 프레임을 수신한 스위치(20)는 2종류의 토큰 버킷을 이용해서 수신한 프레임의 대역 제한 평가 및 우선도 평가를 행한다.

우선, 프레임을 수신할 때, 스위치(20)는 프레임의 우선도에 대응하는 버킷을 제공한다.

프레임을 수신한 스위치(20)는 프레임의 우선도마다 제공된 버킷에, 각 우선도에 기초하여 결정된 양의 토큰을 보충한다.

또한, 프레임을 수신한 스위치(20)는 그들 버킷의 평가 전에 하나의 공유 버킷을 제공한다.

도 2에 도시한 바와 같이, 프레임을 수신할 때, 스위치(20)는 일정 기간마다, 그 시점에서 우선도마다 제공된 버킷 내에 존재하는 토큰을 모두 공유 버킷에 전달한다.

그러나, 공유 버킷의 깊이(용량)는 장치의 버스트 전송 허용량으로 고정되어 있다. 공유 버킷의 깊이(용량)의 한도를 초과해서 토큰이 넘치는 경우에, 프레임을 수신한 스위치(20)는 넘친 토큰을 폐기한다.

도 3에 도시한 바와 같이, 프레임을 수신한 스위치(20)는 공유 버킷 내에 토큰이 존재하는 한, 프레임의 우선도에 상관없이, 모든 프레임을 평등하게 평가하고 전송한다.

공유 버킷 내에 토큰이 없는 경우에, 프레임을 수신한 스위치(20)는 후 단계인 우선적 대역 제한으로 전환하여 우선도마다 제공된 버킷을 평가한다.

도 4에 도시한 바와 같이, 우선적 제한으로 전환할 때, 프레임을 수신한 스위치(20)는 각각의 프레임에 대해서 플로우 식별시에 결정된 우선도에 대응하는 우선도 버킷을 확인하고, 해당 우선도에 대응하는 우선도 버킷 내에 토큰이 존재하는 경우에 전송 처리를 행한다.

도 5에 도시한 바와 같이, 프레임을 수신한 스위치(20)는 우선도 버킷 내에 토큰이 존재하지 않는 경우에, 프레임의 폐기 처리를 행한다.

프레임을 수신한 스위치(20)는 높은 우선도의 프레임이 대량으로 도착한 경우에도, 각 우선도 버킷에 대하여 일정 시간마다 우선도에 기초하여 결정된 양의 토큰을 보충한다는 점에 주목한다. 그 때문에, 모든 우선도 버킷에서 일정 시간마다 일정량의 토큰이 보충되므로, 낮은 우선도의 버킷에서도 프레임이 무전송 상태에 빠지는 경우는 없다.

또한, 프레임을 수신한 스위치(20)는 일정 기간 후에, 프레임의 우선도에 상관없이, 우선도 버킷 내의 토큰을 모두 공유 버킷에 보충한다. 그 때문에, 일정 기간마다 공유 버킷 내에 토큰이 존재하게 되어, 프레임의 우선도에 상관없이 모든 프레임을 평등하게 평가하고 전송할 수 있다.

프레임을 수신한 스위치(20)는 프레임을 프레임의 도착 순서대로 평가하여 토큰의 사용 유무에 기초하여, 프레임이 전송 또는 폐기되어야 하는지를 판단한다.

프레임을 수신한 스위치(20)는 우선도별의 서브 큐를 제공할 필요가 없고 동시에 대역 제한을 행할 수 있다.

(스위치 동작)

도 6을 참조하여 본 발명에서의 스위치의 동작에 대해서 이하에 설명한다.

(1) 단계 S101

스위치(20)(20-i, i=1∼n) 중, 어느 하나의 스위치는 도착한 프레임을 수신한다.

(2) 단계 S102

프레임을 수신한 스위치(20)는 해당 프레임을 이용하여 플로우 테이블을 검색한다. 즉, 프레임을 수신한 스위치(20)는 해당 프레임에 대해서 플로우 테이블을 검색한다.

(3) 단계 S103

프레임을 수신한 스위치(20)는 해당 프레임이 플로우 엔트리에 히트하는지를 확인한다.

(4) 단계 S104

해당 프레임이 플로우 엔트리에 히트하는 경우에(단계 S103에서 예), 프레임을 수신한 스위치(20)는 그 플로우 엔트리의 액션이 컨트롤러(10)로의 전송을 표시하는지를 확인한다.

(5) 단계 S105

해당 프레임이 플로우 엔트리에 히트하여도, 그 플로우 엔트리의 액션이 컨트롤러(10)로의 전송 이외의 액션인 경우에(단계 S104에서 아니오), 프레임을 수신한 스위치(20)는 액션에 따른 프레임 처리를 행한다. 따라서, 이 경우는 본 발명의 동작에 포함되지 않는다. 즉, 일반적인 오픈 플로우 네트워크 시스템에서의 프레임 처리를 행한다.

또한, 해당 프레임이 플로우 엔트리에 히트하지 않고 미지의 프레임이라는 검색 결과를 컨트롤러(10)에 통지하는 오픈 플로우 특유의 처리를 행하는 경우에(단계 S103에서 아니오), 프레임을 수신한 스위치(20)는 컨트롤러(10) 행의 프레임의 처리를 행한다. 이 동작은 본 발명의 동작에 포함되고, 공유 버킷과 우선도 버킷의 평가를 행한다.

또한, 해당 프레임이 플로우 엔트리에 히트하고, 나아가 그 플로우 엔트리의 액션이 컨트롤러(10)로의 전송을 표시하는 경우에(단계 S104에서 예), 프레임을 수신한 스위치(20)는 마찬가지로 본 발명의 동작에 포함되는, 공유 버킷과 우선도 버킷의 평가를 행한다.

(6) 단계 S106

프레임을 수신한 스위치(20)는, 스위치(20)가 해당 프레임이 플로우 엔트리에 히트하지 않고 미지의 프레임이라는 검색 결과를 컨트롤러(10)에 통지하는 오픈 플로우 특유의 처리를 행하는 경우에(단계 S103에서 아니오), 혹은 해당 프레임이 플로우 엔트리에 히트하고 그 플로우 엔트리의 액션이 컨트롤러(10) 행의 전송을 표시하는 경우에(단계 S104로 예), 공유 버킷 내의 토큰의 양을 측정하고 공유 버킷 내에 토큰이 존재하는지를 확인한다.

(7) 단계 S107

공유 버킷 내에 토큰이 존재하지 않는 경우에(단계 S106에서 아니오), 프레임을 수신한 스위치(20)는 우선도마다 제공된 버킷 내에 토큰이 존재하는지를 확인한다.

(8) 단계 S108

프레임을 수신한 스위치(20)는, 공유 버킷 내에 토큰이 존재하는 경우에(단계 S106에서 예), 혹은 공유 버킷 내에 토큰이 존재하지 않고 해당 프레임의 우선도 버킷 내에 토큰이 존재하는 경우에(단계 S107에서 예), 컨트롤러(10) 행의 프레임을 전송한다.

이때, 도 7에 도시한 바와 같이, 공유 버킷 내에 토큰이 존재하는 경우에, 프레임을 수신한 스위치(20)는 전송된 프레임(들)의 양에 대응하는 토큰(들)을 공유 버킷으로부터 감산하는 처리를 행한다.

또한, 도 8에 도시한 바와 같이, 해당 프레임에 대응하는 우선도 버킷 내에 토큰이 존재하는 경우에, 프레임을 수신한 스위치(20)는 전송된 프레임(들)의 양에 대응하는 토큰(들)을 해당 우선도 버킷으로부터 감산하는 처리를 행한다.

(9) 단계 S109

프레임을 수신한 스위치(20)는 공유 버킷 내에 토큰이 존재하지 않고 해당 프레임의 우선도 버킷 내에도 토큰이 존재하지 않는 경우에(단계 S107에서 아니오), 해당 프레임의 폐기 처리를 행한다.

즉, 도 9에 도시한 바와 같이, 프레임을 수신한 스위치(20)는 공유 버킷 및 우선도 버킷의 양쪽의 평가에서 토큰이 확보되지 않은 경우에, 해당 프레임의 폐기 처리를 행한다.

프레임을 수신한 스위치(20)는 우선도 버킷에, 일정 시간마다, 각 우선도에 따라서 가중치 부여되거나 결정된 양의 토큰을 보충한다.

즉, 토큰의 보충량은 우선도 버킷마다 상이하다.

이때, 우선도 버킷에 보충된 토큰의 총량은 프레임을 수신한 스위치(20)가 컨트롤러(10)에 전송할 수 있는 최대 전송량과 일치하고 있다.

우선도 버킷에의 토큰의 보충 후, 프레임을 수신한 스위치(20)는 일정 시간마다, 모든 우선도 버킷 내의 토큰을 모두 무조건 공유 버킷에 부여하고, 결과적으로 공유 버킷에 토큰을 보충한다.

그러나, 공유 버킷의 깊이(용량)는 최대 버스트 전송량과 일치한다. 따라서, 프레임을 수신한 스위치(20)는 깊이(용량) 이상의 토큰을 공유 버킷에 보충하지 않고, 남은 토큰을 폐기한다.

프레임을 수신한 스위치(20)는, 비워진 우선도 버킷에, 규정 시간 후에, 다시 가중치 부여된 양의 토큰을 보충한다.

즉, 프레임을 수신한 스위치(20)는 모든 우선도 버킷이 비워진 후에, 우선도 버킷에 토큰을 보충한다. 프레임을 수신한 스위치(20)는 우선도 버킷을 비우는 타이밍과 규정량의 토큰을 보충하는 타이밍을 관리하고 주기적으로 반복한다.

그러나, 도 2에 도시한 바와 같이, 공유 버킷의 보충에 대해서는, 공유 버킷이 비어 있을 필요는 없다.

(효과)

본 발명에서는, 최종 평가로 간주되는 우선도 버킷에 보충되는 최대량이 장치의 최대 전송량으로서 규정되고 있다. 그러므로, 보충 전에 한번 모든 우선도 버킷을 비우는 동작으로 인해 어느 시점에서도 최대 전송량을 초과하는 경우는 없다. 그 때문에, QoS 등의 대역 제어가 아니고, 전송 수신처 장치의 처리 능력에 기초한 제어와 수신 허용 범위를 초과하는 것을 방지하는 제어가 이루어질 수 있다.

또한, 우선도 제어의 관점에서 보면, WFQ와 유사한 효과가 기대된다. 또한, 주기적으로 우선도 버킷의 토큰이 공유 버킷에 수집되어 공유 버킷의 범위 내이면 프레임 종별에 상관없이 평등하게 버스트 전송을 허용할 수 있는 토큰 버킷 방식의 특성 효과도, 상기 효과와 동시에 실현 가능하다.

종래의 토큰 버킷 방식은 대역 제한과 우선도 제어를 위해 사용되는 것이 아니라, 대역량을 측정하기 위해 사용된다는 점에 주목한다.

한편, 본 발명에서는 토큰 버킷 방식을 응용하고 우선도마다 버킷을 제공함으로써 우선적 대역 제한을 실현하고 있다. 그 때문에, 우선도 버킷에서는, 모든 버킷에 토큰이 보충된다. 그러므로, 모든 우선도의 대역 보증이 실현 가능하고, 낮은 우선도의 프레임에 관해서도 대역을 보증할 수 있다.

또한, 본 발명에서는, 프레임의 우선도 등급 분별에서, 종래의 우선 제어 방식과는 다르게, 우선도마다 프레임을 저장하기 위한 버퍼를 제공할 필요가 없기 때문에, 메모리 리소스를 절약할 수 있고 실장이 용이하다.

<부기>

본 발명에 따른 스위치(20)(20-i, i=1∼n) 각각은 이하의 부기와 같이 기재하는 것도 가능하다. 그러나, 본 발명은 이하의 기재 예에 한정되지 않는다. 여기서, 기재의 간략화를 위해, 스위치(20)(20-i, i=1∼n) 각각을 "스위치(20)"라고 표기한다.

<부기 1>

도 10을 참조하여 본 발명에 따른 스위치(20)의 기본적인 구성예에 대해서 이하에 설명한다.

본 발명에 따른 스위치(20)는 오픈 플로우 처리부(21), 버킷 설정부(22), 공유 버킷 평가부(23), 및 우선도 버킷 평가부(24)를 포함한다.

오픈 플로우 처리부(21)는 컨트롤러(10)에 의한 제어에 따라서, 수신한 프레임을 플로우로서 일률적으로 제어하기 위한 룰과 액션이 정의된 플로우 엔트리를 플로우 테이블에 등록한다.

버킷 설정부(22)는 컨트롤러(10) 행인 프레임에 대하여, 모든 프레임에 대응하는 공유 버킷; 및 각 프레임의 우선도에 대응하는 우선도 버킷을 제공한다.

공유 버킷 평가부(23)는 수신한 프레임이 컨트롤러(10) 행인지를 평가하고 컨트롤러(10) 행인 프레임에 대하여, 공유 버킷을 평가한다.

공유 버킷의 평가의 결과, 전송 프레임의 우선적 대역 제한을 행하는 경우에, 우선도 버킷 평가부(24)는 각 프레임의 우선도에 대응하는 우선도 버킷을 평가하고 프레임이 전송 또는 폐기되어야 하는지를 결정한다.

<부기 2>

도 11을 참조하여 본 발명에 따른 스위치(20)의 상세한 구성 예에 대해서 설명한다.

도 10과 공통되는 내용의 설명은 생략한다는 점에 주목한다.

버킷 설정부(22)는 우선도 버킷 설정부(221) 및 공유 버킷 설정부(222)를 포함한다.

우선도 버킷 설정부(221)는 수신한 프레임의 우선도마다 버킷을 제공한다.

공유 버킷 설정부(222)는 우선도마다 제공된 버킷의 평가 전에, 하나의 공유 버킷을 제공한다.

본 발명에 따른 스위치(20)는 토큰 처리부(25)를 더 포함한다.

토큰 처리부(25)는 토큰 보충부(251), 토큰 이전부(252) 및 토큰 폐기부(253)를 포함한다.

토큰 보충부(251)는 우선도마다 제공된 버킷에, 우선도에 기초하여 결정된 양의 토큰을 보충한다.

토큰 이전부(252)는 일정 기간마다 그 시점에서 우선도마다 제공된 버킷 내에 존재하는 토큰을 모두 공유 버킷에 전달한다.

토큰이 공유 버킷의 용량을 초과해서 넘치는 경우에, 토큰 폐기부(253)는 넘친 토큰을 폐기한다.

공유 버킷 내에 토큰이 존재하는 한, 공유 버킷 평가부(23)는 수신한 프레임의 우선도에 상관없이, 모든 프레임을 평등하게 평가하고 전송한다.

공유 버킷 내에 토큰이 존재하지 않는 경우에, 우선도 버킷 평가부(24)는 우선적 대역 제한으로 전환하고 우선도마다 제공된 버킷을 평가하고, 수신한 프레임의 우선도에 대응하는 버킷 내에 토큰이 존재하는지를 확인한다. 우선도 버킷 평가부(24)는 확인한 결과, 수신한 프레임의 우선도에 대응하는 우선도 버킷 내에 토큰이 존재하는 경우에, 수신한 프레임의 전송 처리를 행한다. 또한, 우선도 버킷 평가부(24)는 수신한 프레임의 우선도에 대응하는 버킷 내에 토큰이 존재하지 않는 경우에, 수신한 프레임의 폐기 처리를 행한다.

<부기 3>

도 10 및 도 11을 참조하여, 상기의 구성에 대해서 이하에 더욱 상세하게 설명한다.

오픈 플로우 처리부(21)는 도착한 프레임에 기초하여 플로우 테이블을 검색하여 해당 프레임이 플로우 엔트리에 히트하는지를 확인한다. 오픈 플로우 처리부(21)는, 해당 프레임이 플로우 엔트리에 히트하는 경우에, 해당 플로우 엔트리의 액션이 컨트롤러(10) 행의 전송을 표시하는지를 확인한다. 해당 플로우 엔트리의 액션이 컨트롤러(10) 행의 전송 이외의 액션인 경우에, 오픈 플로우 처리부(21)는 해당 액션에 따라 프레임의 처리를 행한다.

공유 버킷 평가부(23)는, 해당 프레임이 플로우 엔트리에 히트하지 않고, 미지의 프레임이라는 것을 컨트롤러(10)에 통지하는 처리를 행하는 경우에, 혹은 해당 프레임이 플로우 엔트리에 히트하고 해당 플로우 엔트리의 액션이 컨트롤러(10) 행의 전송인 경우에, 공유 버킷 내의 토큰의 양을 측정하고, 공유 버킷 내에 토큰이 존재하는지를 확인한다.

우선도 버킷 평가부(24)는, 공유 버킷 내에 토큰이 존재하지 않는 경우에, 우선도마다 제공된 버킷 내에 토큰이 존재하는지를 확인한다.

오픈 플로우 처리부(21)는, 공유 버킷 내에 토큰이 존재하는 경우에, 혹은 공유 버킷 내에 토큰이 존재하지 않고 해당 프레임의 우선도 버킷 내에 토큰이 존재하는 경우에, 컨트롤러(10) 행의 프레임을 전송한다.

공유 버킷 내에 토큰이 존재하는 경우에, 공유 버킷 평가부(23)는 전송된 프레임(들)의 양에 대응하는 토큰(들)을 공유 버킷으로부터 감산 처리한다.

해당 프레임의 우선도 버킷 내에 토큰이 존재하는 경우에, 우선도 버킷 평가부(24)는 전송된 프레임(들)의 양에 대응하는 토큰(들)을 해당 우선도 버킷으로부터 감산 처리한다.

오픈 플로우 처리부(21)는, 공유 버킷 내에 토큰이 존재하지 않고 해당 프레임의 우선도 버킷 내에도 토큰이 존재하지 않는 경우에, 해당 프레임의 폐기 처리를 행한다.

<부기 4>

상기 구성은 프로그램에 기초하여 구동되어 소정의 처리를 실행하는 프로세서; 해당 프로그램과 각종 데이터를 기억하는 메모리; 및 네트워크와의 통신에 이용되는 인터페이스를 사용하여 실현된다는 점에 주목한다.

<비고>

이상, 본 발명의 실시예를 상세히 설명하였다. 실제로는, 본 발명은 상기의 실시예에 한정되지 않는다. 따라서, 본 발명의 요지 및 범위를 벗어나지 않는 범위 내의 변경은 본 발명에 포함된다.

본 출원은 일본 특허 출원 2011-250191호에 기초하는 우선권을 주장하고, 그 개시 내용은 본 출원에 참고로 병합된다는 점에 주목한다.

Claims

컨트롤러에 의한 제어에 기초하여, 수신한 프레임을 플로우의 일부로서 일률적으로 제어하기 위한 룰과 액션이 정의된 플로우 엔트리를 플로우 테이블에 등록하는 수단;
상기 컨트롤러로 향하는 모든 프레임에 대한 공유 버킷 및 프레임마다의 우선도에 대응하는 우선도 버킷을 제공하는 수단;
상기 수신한 프레임이 상기 컨트롤러로 향하는지를 평가하고, 상기 컨트롤러로 향하는 프레임에 대하여 상기 공유 버킷을 평가하는 수단; 및
상기 공유 버킷을 평가한 결과, 전송 프레임의 우선적 대역 제한을 행하는 경우에 해당 프레임의 우선도에 대응하는 상기 우선도 버킷을 평가하여 전송 또는 폐기를 결정하는 수단
을 포함하는 네트워크 통신 장치.
제1항에 있어서,
상기 수신한 프레임의 우선도마다 상기 우선도 버킷을 제공하는 수단;
우선도마다 제공된 상기 우선도 버킷에 상기 우선도에 기초하여 결정된 양의 토큰을 보충하는 수단;
우선도마다 제공된 상기 우선도 버킷의 평가 전에 상기 공유 버킷을 제공하는 수단;
일정 기간마다 그 시점에서 우선도마다 제공된 상기 우선도 버킷 내에 존재하는 토큰을 모두 상기 공유 버킷에 전달하는 수단;
토큰이 상기 공유 버킷의 용량을 초과하는 경우에 넘친 토큰을 폐기하는 수단;
상기 공유 버킷 내에 토큰이 존재하는 한, 상기 수신한 프레임의 우선도에 상관없이 모든 프레임을 평등하게 평가하고 전송하는 수단;
상기 공유 버킷 내에 토큰이 존재하지 않는 경우에 우선적 대역 제한으로 전환하여, 우선도마다 제공된 우선도 버킷을 평가하고, 상기 수신한 프레임의 우선도에 대응하는 상기 우선도 버킷 내에 토큰이 존재하는지를 확인하는 수단;
상기 수신한 프레임의 우선도에 대응하는 상기 우선도 버킷 내에 토큰이 존재하는 경우에 상기 수신한 프레임의 전송 처리를 행하는 수단; 및
상기 수신한 프레임의 우선도에 대응하는 상기 우선도 버킷 내에 토큰이 존재하지 않는 경우에 상기 수신한 프레임의 폐기 처리를 행하는 수단을 더 포함하는 네트워크 통신 장치.
제1항 또는 제2항에 있어서,
도착한 프레임에 기초하여 상기 플로우 테이블을 검색하는 수단;
해당 프레임이 플로우 엔트리에 히트하는지를 확인하는 수단;
해당 프레임이 상기 플로우 엔트리에 히트하는 경우에 해당 플로우 엔트리의 액션이 상기 컨트롤러로 향하는 전송인지를 확인하는 수단;
해당 플로우 엔트리의 액션이 상기 컨트롤러로 향하는 전송 이외의 액션인 경우에 해당 액션에 기초하여 상기 프레임의 처리를 행하는 수단;
해당 프레임이 플로우 엔트리에 히트하지 않고 상기 프레임이 미지의 프레임이라는 검색 결과를 상기 컨트롤러에 통지하는 처리를 행하는 경우에, 혹은 해당 프레임이 플로우 엔트리에 히트하고 해당 플로우 엔트리의 액션이 상기 컨트롤러로 향하는 전송인 경우에, 상기 공유 버킷 내의 토큰의 양을 측정하여 상기 공유 버킷 내에 토큰이 존재하는지를 확인하는 수단;
상기 공유 버킷 내에 토큰이 존재하지 않는 경우에 우선도마다 제공된 상기 우선도 버킷 내에 토큰이 존재하는지를 확인하는 수단;
상기 공유 버킷 내에 상기 토큰이 존재하는 경우에 혹은 상기 공유 버킷 내에 토큰이 존재하지 않고 해당 프레임의 상기 우선도 버킷 내에 토큰이 존재하는 경우에 상기 컨트롤러로의 프레임의 전송을 행하는 수단;
상기 공유 버킷 내에 상기 토큰이 존재하는 경우에 상기 전송된 프레임의 양에 대응하는 토큰을 상기 공유 버킷으로부터 감산하는 수단;
해당 프레임의 상기 우선도 버킷 내에 토큰이 존재하는 경우에 상기 전송된 프레임의 양에 대응하는 토큰을 해당 우선도 버킷으로부터 감산하는 수단; 및
상기 공유 버킷 내에 토큰이 존재하지 않고 해당 프레임의 상기 우선도 버킷 내에도 토큰이 존재하지 않는 경우에 해당 프레임을 폐기하는 수단을 더 포함하는 네트워크 통신 장치.
네트워크 통신 장치에 의한 전송 프레임의 우선적 대역 제한 방법으로서,
컨트롤러에 의한 제어 하에서, 수신한 프레임을 플로우로서 일률적으로 제어하기 위한 룰과 액션을 정의한 플로우 엔트리를, 플로우 테이블에 등록하는 단계;
상기 컨트롤러로 향하는 프레임 모두에 대한 공유 버킷 및 프레임마다의 우선도에 대한 우선도 버킷을 제공하는 단계;
상기 수신한 프레임이 상기 컨트롤러로 향하는지를 평가하고 상기 컨트롤러로 향하는 프레임에 대하여 상기 공유 버킷을 평가하는 단계; 및
상기 공유 버킷을 평가한 결과, 전송 프레임의 우선적 대역 제한을 행하는 경우에 해당 프레임의 우선도에 대응하는 상기 우선도 버킷을 평가하여 전송 또는 폐기를 결정하는 단계
를 포함하는 전송 프레임의 우선적 대역 제한 방법.
제4항에 있어서,
상기 수신한 프레임의 우선도마다 버킷을 제공하는 단계;
우선도마다 제공된 상기 우선도 버킷의 우선도에 기초하여 결정된 양의 토큰을 보충하는 단계;
우선도마다 제공된 상기 우선도 버킷의 평가 전에 하나의 공유 버킷을 제공하는 단계;
일정 기간마다 그 시점에서 우선도마다 제공된 상기 우선도 버킷 내에 존재하는 토큰을 모두 상기 공유 버킷에 전달하는 단계;
토큰이 상기 공유 버킷의 용량을 초과해서 넘치는 경우에 넘친 토큰을 폐기하는 단계;
상기 공유 버킷 내에 토큰이 존재하는 한, 상기 수신한 프레임의 우선도에 상관없이 모든 프레임을 평등하게 평가하고 전송하는 단계;
상기 공유 버킷 내에 토큰이 존재하지 않는 경우에 우선적 대역 제한으로 전환하고, 상기 우선도마다 제공된 상기 우선도 버킷을 평가하여, 상기 수신한 프레임의 우선도에 대응하는 상기 우선도 버킷 내에 토큰이 존재하는지를 확인하는 단계;
상기 수신한 프레임의 우선도에 대응하는 상기 버킷 내에 토큰이 존재하는 경우에 상기 수신한 프레임의 전송 처리를 행하는 단계; 및
상기 수신한 프레임의 우선도에 대응하는 상기 버킷 내에 토큰이 존재하지 않는 경우에 상기 수신한 프레임의 폐기 처리를 행하는 단계를 더 포함하는 전송 프레임의 우선적 대역 제한 방법.
제4항 또는 제5항에 있어서,
도착한 프레임에 기초하여 상기 플로우 테이블을 검색하는 단계;
해당 프레임이 플로우 엔트리에 히트하는지를 확인하는 단계;
해당 프레임이 상기 플로우 엔트리에 히트하는 경우에 해당 플로우 엔트리의 액션이 상기 컨트롤러로의 전송인지를 확인하는 단계;
해당 플로우 엔트리의 액션이 상기 컨트롤러로의 전송 이외의 액션인 경우에 해당 액션에 기초하여 프레임 처리를 행하는 단계;
해당 프레임이 플로우 엔트리에 히트하지 않고 상기 프레임이 미지의 프레임이라는 검색 결과를 상기 컨트롤러에 통지하는 처리를 행하는 경우에, 혹은 해당 프레임이 상기 플로우 엔트리에 히트하고 해당 플로우 엔트리의 액션이 상기 컨트롤러로 향하는 전송인 경우에, 상기 공유 버킷 내의 토큰의 양을 측정하여 상기 공유 버킷 내에 토큰이 존재하는지를 확인하는 단계;
상기 공유 버킷 내에 토큰이 존재하지 않는 경우에 우선도마다 제공된 상기 우선도 버킷 내에 토큰이 존재하는지를 확인하는 단계;
상기 공유 버킷 내에 토큰이 존재하는 경우에 혹은 상기 공유 버킷 내에 토큰이 존재하지 않고 해당 프레임의 상기 우선도 버킷 내에 토큰이 존재하는 경우에 상기 컨트롤러로의 프레임의 전송을 행하는 단계;
상기 공유 버킷 내에 토큰이 존재하는 경우에 상기 전송된 프레임의 양에 대응하는 토큰을 상기 공유 버킷으로부터 감산하는 단계;
해당 프레임의 상기 우선도 버킷 내에 토큰이 존재하는 경우에 상기 전송된 프레임의 양에 대응하는 토큰을 해당 우선도 버킷으로부터 감산하는 단계; 및
상기 공유 버킷 내에 토큰이 존재하지 않고 해당 프레임의 상기 우선도 버킷 내에도 토큰이 존재하지 않는 경우에 해당 프레임의 폐기 처리를 행하는 단계를 더 포함하는 전송 프레임의 우선적 대역 제한 방법.
컨트롤러에 의한 제어 하에서 수신한 프레임을 플로우로서 일률적으로 제어하기 위한 룰과 액션을 정의한 플로우 엔트리를 플로우 테이블에 등록하는 단계;
상기 컨트롤러로 향하는 프레임에, 프레임 모두에 대응하는 공유 버킷 및 프레임마다의 우선도에 대한 우선도 버킷을 제공하는 단계;
상기 수신한 프레임이 상기 컨트롤러로 향하는지를 평가하고, 상기 컨트롤러로 향하는 프레임에 대하여 상기 공유 버킷을 평가하는 단계; 및
상기 공유 버킷을 평가한 결과, 전송 프레임의 우선적 대역 제한을 행하는 경우에 해당 프레임의 우선도에 대응하는 상기 우선도 버킷을 평가하여 전송 또는 폐기를 결정하는 단계
를 네트워크 통신 장치에게 실행시키기 위한 프로그램을 기록한 컴퓨터 판독 가능한 기록 매체.
제7항에 있어서, 상기 프로그램은:
상기 수신한 프레임의 우선도마다 버킷을 제공하는 단계;
우선도마다 제공된 상기 버킷에 우선도에 기초하여 결정된 양의 토큰을 보충하는 단계;
우선도마다 제공된 상기 버킷의 평가 전에, 하나의 상기 공유 버킷을 제공하는 단계;
일정 기간마다 그 시점에서 우선도마다 제공된 상기 버킷 내에 존재하는 토큰을 모두 상기 공유 버킷에 전달하는 단계;
토큰이 상기 공유 버킷의 용량을 초과해서 넘치는 경우에 넘친 토큰을 폐기하는 단계;
상기 공유 버킷 내에 토큰이 존재하는 한 상기 수신한 프레임의 각각의 우선도에 상관없이 모든 프레임을 평등하게 평가하고 전송하는 단계;
상기 공유 버킷 내에 토큰이 존재하지 않는 경우에 우선적 대역 제한으로 전환하고, 상기 우선도마다 제공된 상기 버킷을 평가하여 상기 수신한 프레임의 우선도에 대응하는 상기 버킷 내에 토큰이 존재하는지를 확인하는 단계;
상기 수신한 프레임의 우선도에 대응하는 상기 버킷 내에 토큰이 존재하는 경우에 상기 수신한 프레임의 전송 처리를 행하는 단계; 및
상기 수신한 프레임의 우선도에 대응하는 상기 버킷 내에 토큰이 존재하지 않는 경우에 상기 수신한 프레임의 폐기 처리를 행하는 단계를 상기 네트워크 통신 장치에게 더 실행시키기 위한 컴퓨터 판독 가능한 기록 매체.
제7항 또는 제8항에 있어서, 상기 프로그램은:
도착한 프레임에 기초하여 상기 플로우 테이블을 검색하는 단계;
해당 프레임이 플로우 엔트리에 히트하는지를 확인하는 단계;
해당 프레임이 상기 플로우 엔트리에 히트하는 경우에 해당 플로우 엔트리의 액션이 상기 컨트롤러로의 전송인지를 확인하는 단계;
해당 플로우 엔트리의 액션이 상기 컨트롤러로의 전송 이외의 액션인 경우에 해당 액션에 따라 프레임 처리를 행하는 단계;
해당 프레임이 플로우 엔트리에 히트하지 않고 상기 프레임이 미지의 프레임이라는 것을 상기 컨트롤러에 통지하는 처리를 행하는 경우에, 혹은 해당 프레임이 상기 플로우 엔트리에 히트하고 해당 플로우 엔트리의 액션이 상기 컨트롤러로의 전송인 경우에, 상기 공유 버킷 내의 토큰의 양을 측정하여 상기 공유 버킷 내에 토큰이 존재하는지를 확인하는 단계;
상기 공유 버킷 내에 토큰이 존재하지 않는 경우에 우선도마다 제공된 버킷 내에 토큰이 존재하는지를 확인하는 단계;
상기 공유 버킷 내에 토큰이 존재하는 경우에 혹은 상기 공유 버킷 내에 토큰이 존재하지 않고 해당 프레임의 상기 우선도 버킷 내에 토큰이 존재하는 경우에 상기 컨트롤러로의 프레임의 전송을 행하는 단계;
상기 공유 버킷 내에 토큰이 존재하는 경우에 상기 전송된 프레임의 양에 대응하는 토큰을 상기 공유 버킷으로부터 감산하는 단계;
해당 프레임의 상기 우선도 버킷 내에 토큰이 존재하는 경우에 상기 전송된 프레임의 양에 대응하는 토큰을 해당 우선도 버킷으로부터 감산하는 단계; 및
상기 공유 버킷 내에 토큰이 존재하지 않고 해당 프레임의 상기 우선도 버킷 내에도 토큰이 존재하지 않는 경우에, 해당 프레임의 폐기 처리를 행하는 단계를 상기 네트워크 통신 장치에게 더 실행시키기 위한 컴퓨터 판독 가능한 기록 매체.