KR101344014B1

KR101344014B1 - 제로 지연 큐잉 방법 및 그 시스템

Info

Publication number: KR101344014B1
Application number: KR1020070012740A
Authority: KR
Inventors: 김병철
Original assignee: 삼성전자주식회사
Priority date: 2007-02-07
Filing date: 2007-02-07
Publication date: 2014-01-06
Also published as: US7911957B2; US20080186989A1; KR20080073908A

Abstract

본 발명의 일측면에 따른 제로 지연 큐잉 방법은 제로 지연 큐잉을 수행하는 것으로 설정된 클래스의 패킷인 경우 제로 지연 큐로 전송하는 단계, 패킷 크기가 해당 클래스에 설정된 CR(Committed Rate)값을 초과하지 않는 경우 패킷을 strict priority 전송 큐로 전송하는 단계 및 상기 strict priority 전송 큐에 존재하는 패킷을 일반 데이터 전송 큐에 존재하는 패킷보다 우선적으로 포워딩하는 단계를 포함하며, 이에 의할 때 실시간 전송이 요구되는 특정 트래픽을 지연 없이 포워딩할 수 있고, 나아가 제로 지연 큐에 해당하는 패킷들에 대해서 CR 값과 PR(Peak Rate) 값을 동시에 보장하여 서비스 할 수 있는 효과가 있다.

Description

제로 지연 큐잉 방법 및 그 시스템{Zero Delay Queuing Method and System}

도 1은 기본적인 큐잉 메커니즘을 도시한 도면.

도 2는 기존의 클래스 기반 큐잉 시스템의 구성을 도시한 도면.

도 3은 기존의 클래스 기반 큐잉 시스템에서 패킷을 전송하는 과정을 도시한 도면.

도 4는 본 발명에 따른 제로 지연 큐잉을 제공하는 클래스 기반 큐잉 시스템의 구성을 도시한 도면.

도 5는 본 발명에 따른 제로 지연 큐잉 과정을 도시한 도면.

*도면의 주요 부분에 대한 부호의 설명*

410: CBQ 스케줄러 412: 등급 분류기

415: 제로 지연 큐 416: 일반 데이터 큐 1

417: 일반 데이터 큐 2 418: 일반 데이터 큐 3

420: 드라이버 Mux 430: 드라이버 큐 1

432: strict priority 전송 큐 1 434: 일반 데이터 전송 큐1

440: 드라이버 큐 2 442: strict priority 전송 큐 2

444: 일반 데이터 전송 큐 2 450: 드라이버 큐 3

452: strict priority 전송 큐 3 454: 일반 데이터 전송 큐 3

460: 드라이버 큐 4 462: strict priority 전송 큐 4

464: 일반 데이터 전송 큐 4

본 발명은 제로 지연 큐잉 방법 및 그 시스템에 관한 것으로, 보다 자세하게는 클래스 기반 큐잉 스케줄러에서 실시간 전송이 요구되는 특정 트래픽을 지연 없이 전송하고, 나아가 트래픽 폭주시에도 일정한 Committed Rate(CR)와 Peak Rate (PR)를 보장하기 위해서 Phase 1 내지 Phase 3을 거쳐 큐잉을 수행하는 제로 지연 큐잉 방법 및 그 시스템에 관한 것이다.

다양한 대역폭을 가지는 인터페이스를 지원하는 라우팅 시스템에서는, 대역폭이 큰 input 인터페이스에서 대역폭이 작은 output 인터페이스로 트래픽이 전송될 때 병목 현상이 발생한다. 이 경우 QoS 스케줄러는 병목 지점에서 선택적으로 패킷을 폐기(drop)하거나, 패킷들을 큐잉(queuing) 메커니즘에 의하여 전송함으로써 전체적인 트래픽의 흐름을 조절한다.

패킷을 선택적으로 폐기하여 트래픽의 흐름을 조절하는 경우, 패킷의 버퍼링으로 인한 지연이 없다, 그러나 패킷의 유실로 정상적인 정보가 전달되지 못할 수 있다.

한편, 큐잉 메커니즘에 의하여 패킷을 전송하는 경우, QoS 스케줄러는 패킷의 폐기없이 트래픽이 일정하게 전송될 수 있도록 shaping 기능을 수행한다. shaping 기능이란 전송되는 패킷의 대역폭을 조절하기 위하여, 오버 플로우되는 패킷을 버퍼링하였다가 전송하는 것을 말한다. Shaping 기능을 수행하는 경우, QoS 스케줄러는 클래스 별로 할당된 대역폭의 기준 값을 초과하는 트래픽을 버퍼링하여 트래픽의 정보를 보존한다. 따라서 트래픽의 손실을 감소시킬 수 있다. 그러나 패킷을 버퍼링하였다가 전송하는 것이므로, 이 경우 전송 지연이 발생한다.

도 1은 기본적인 큐잉 메커니즘을 도시한 도면이다.

기본적으로 큐잉 시스템은 대기열(110)과 서버(120)를 포함하여 구성되어 진다. 가장 기본적인 큐잉 모델에 의할 때, λ는 큐잉 시스템에 도착하는 패킷의 도착 비율(패킷/sec)이다. 예를 들어 라우터에 도착하는 패킷 비율을 뜻한다. 만약 특정 시각에 패킷이 도착했을 때, 대기열(Queue)(110)에서 서비스를 기다리고 있는 패킷이 없다면 그 패킷은 지연 없이 전송될 수 있다.

ω는 대기열(110)에서 서비스를 기다리고 있는 패킷의 평균 개수이다. Tω 는 대기열(110)에서 기다려야 하는 평균 시간이다. 여기서 평균이라 함은 패킷이 기다리지 않는 시간까지 함께 포함한다.

Ts는 서버(120)가 패킷에게 서비스를 제공하는 시간이다. ρ(로)는 서버 유틸라이제이션(utilization)으로서, 서버(120)가 일을 하고 있는 비율을 말한다. 예 를 들어, 서버 유틸라이제이션이 1인 경우는 서버(120)가 100% 일을 하고 있다는 의미이므로, 도착한 패킷들은 서버(120)에서 서비스를 제공받을 수 없으며, 대기열(110)에서 대기해야 한다.

만일 서버(120)가 100%(ρ=1)로 일을 하고 있다면, 큐잉 시스템에서 전송되는 패킷의 시간 비율은 도착하는 패킷의 시간 비율과 상관없이 항상 일정하다. 이러한 제한적 환경에서 시스템이 최대로 해결할 수 있는 도착하는 패킷의 시간 비율은 이론적으로 다음과 같이 나타낼 수 있다.

하나의 패킷(=m)이 도착했다고 가정할 때, m의 앞에는 평균적으로 ω개의 패킷이 대기열(110)에서 전송될 순서를 기다리고 있다. m이 대기열(110)을 떠나 전송되면, 대기열(110)에는 다시 ω개의 패킷이 기다리게 된다. 그리고 Tω는 평균 대기 시간이 된다.

병목 지점에서는 상기 대기열(110)에서 전송 순서를 기다리는 패킷들이 증가하며, 이에 따라 패킷을 전송하는데 있어서 지연이 발생할 수 밖에 없다.

현재 네트워크 상에서 제공되는 실시간 컨텐츠 및 스트리밍 컨텐츠 서비스는 서비스가 이루어지고 있는 동안 지연이나 끊김이 없어야 한다. 이를 위해서는 일정 기준값 이상의 대역폭을 보장하는 것과 동시에, 패킷의 전송 지연이 최소 한도로 발생하도록 하여야 한다.

특정 패킷의 전송 지연을 완화하는 방법으로 CBQ 서비스를 생각할 수 있다. CBQ(Class Based Queuing) 서비스는 패킷 클래스에 기반하여 큐잉을 수행한다. 이러한 CBQ 서비스는 주기적으로 동작하는 CBQ 스케줄러에 의하여 제공되며, CBQ 스케줄러는 패킷 클래스에 기반하여 차별화된 패킷 전송을 한다. 따라서 실시간으로 데이터의 전송이 요구되는 서비스를 상위 클래스로 설정하고, 상위 클래스에 해당되는 패킷을 우선적으로 전송하는 방법에 기반하여 큐잉을 수행하는 경우, 패킷의 전송 지연을 최대한 완화할 수 있다.

도 2는 기존의 클래스 기반 큐잉 시스템의 구성을 도시한 도면이다.

CBQ 시스템은 CBQ 스케줄러(210)와 드라이버 Mux(220) 및 다수의 드라이버 큐(232, 234, 236, 238)를 포함하여 구성된다.

CBQ 스케줄러(210)는 패킷 클래스에 기반하여 큐잉을 수행한다. CBQ 스케줄러(210)는 등급 분류기(212)를 포함하며, 등급 분류기(212)는 입력되는 패킷의 특성에 따라 클래스를 구별하여 분류한다. 등급 분류기(212)는 수신된 패킷의 헤더를 참조하여 해당 패킷의 QoS 클래스를 확인한다. 이 경우 CBQ 스케줄러(210)는 대기열의 해당 클래스 큐에 상기 패킷을 대기시킨다.

CBQ 스케줄러(210)는 CBQ 스케줄러(210)의 동작 주기인 경우, 해당 클래스의 패킷을 드라이버 Mux(220)로 전송한다.

드라이버 Mux(220)는 패킷을 각각의 드라이버 큐(232, 234, 236, 238)로 송 신한다. 이 경우 CBQ 스케줄러(210)는 패킷 사이즈가 해당 클래스에 할당된 대역폭을 초과하는 경우, 해당 인터페이스에 사용하지 않는 여분의 가용 대역폭을 최대한 더 할당하여 패킷을 드라이버 Mux(220)로 전송한다.

드라이버 큐(driver queue)(232, 234, 236, 238)는 드라이버 Mux(220)로부터 수신한 패킷을 전송한다. 도 2에 도시된 클래스 기반 큐잉 시스템은 드라이버 큐 1(232), 드라이버 큐 2(234), 드라이버 큐 3(236) 및 드라이버 큐 4(238)를 가진다는 것을 알 수 있다.

도 3은 기존의 클래스 기반 큐잉 시스템에서 패킷을 전송하는 과정을 도시한 도면이다.

패킷이 도착하는 경우(S301), 클래스 기반 큐잉(Class Based Queuing: CBQ) 스케줄러(210)가 enable 되었는지 판단한다(S302). CBQ 스케줄러(210)가 enable 되어 있지 않은 경우 패킷은 CBQ 스케줄러(210)에서의 큐잉 과정을 거치지 않고 드라이버 큐로 전송된다.

그러나 CBQ 스케줄러(210)에 빈 대기열이 있어 패킷이 입력될 수 있는 경우, CBQ 스케줄러(210)는 등급 분류기(212)에 의하여 입력된 패킷의 클래스를 판별한다(S303). 이 경우 CBQ 스케줄러(210)는 대기열의 해당 클래스 큐에 상기 패킷을 큐잉시킨다(S304).

CBQ 스케줄러(210)는 스케줄러의 동작 주기인지 판단한다(S305). 스케줄링 주기가 아닌 경우 CBQ 스케줄러(210)는 패킷을 전송하지 않으며, S301 단계로 되돌 아가 그 후의 과정을 수행한다. 스케줄링 주기인 경우, CBQ 스케줄러(210)는 패킷 사이즈가 해당 클래스에 할당된 대역폭을 초과하는지 판단한다(S306).

해당 클래스에 할당된 대역폭을 초과하는 경우, CBQ 스케줄러(210)는 해당 인터페이스에 사용하지 않는 여분의 대역폭이 존재하는지 판단한다(S307). 여분의 대역폭이 존재한다면, 가용할 수 있는 대역폭을 최대한 더 할당하여(S308) 패킷을 드라이버 큐(232, 234, 236, 238)로 전송한다(S309). 여분의 대역폭이 존재하지 않는 경우에는, S305 단계로 되돌아 간다.

만일 S306 단계에서 할당된 대역폭을 초과하지 않는 경우라면, CBQ 스케줄러(210)는 패킷을 드라이버 큐(232, 234, 236, 238)로 송신한다.

드라이버 큐(232, 234, 236, 238)는 CBQ 스케줄러(210)로부터 수신한 패킷을 포워딩한다. 앞서 보았지만 S302 단계에서 CBQ 스케줄러(210)가 enable 되지 않은 경우, 패킷은 CBQ 스케줄러(210)에서의 큐잉 과정을 거치지 않고 드라이버 큐(232, 234, 236, 238)로 바로 전송된다. 이로써 CBQ 스케줄러(210)에서의 패킷 전송 과정이 모두 종료한다.

앞서 살펴보았듯 CBQ 스케줄러는 패킷 클래스에 기반하여 큐잉을 수행한다. 대역폭이 작은 인터페이스(예를 들어, T1/E1, T3, 이더넷 등)로 트래픽이 폭주하는 경우, 클래스 기반 큐잉 스케줄링을 제공하기 위해서는, CBQ 스케줄러의 동작 오버 헤드를 고려하여 스케줄러 동작 주기가 필요하다. 이 경우 스케줄러가 동작되는 수 milliseconds(ms)의 주기 동안 패킷은 각 클래스 큐에서 전송을 대기하여야 하며, 이에 따라 트래픽의 큐잉 또는 스케줄링 지연이 발생한다. 즉 CBQ 스케줄러는 패킷의 전송 지연을 어느 정도 완화할 수는 있지만, 근본적으로 패킷의 전송 지연 자체를 발생하지 않게 할 수는 없다.

현재 CBQ 스케줄러에서 특정 트래픽, 예를 들어 실시간 전송을 요구하는 트래픽을 큐잉 또는 스케줄링 지연 없이 전송하는 방법은 존재하지 않는다. 또한 해당 인터페이스에 트래픽이 폭주하는 경우, 큐잉 또는 스케줄링 지연 없이 전송해야 하는 트래픽에 대해서 일정한 전송량을 보장해 줄 수 있는 Committed Rate(CR)와 스케줄링 주기 동안 해당 인터페이스에 대역폭 가용량이 있으면 트래픽의 Peak Rate(PR)를 보장하여 전송할 수 있는 방법 역시 제공하지 못하고 있다.

따라서 클래스 기반 큐잉 스케줄러에서 전송 지연 없이 패킷을 전송하고, 나아가 트래픽 폭주 시에도 일정한 Committed Rate(CR)와 트래픽의 Peak Rate(PR)를 보장하여 패킷을 전송할 수 있는 제로 지연 큐잉 메커니즘이 요구된다.

따라서 본 발명의 목적은 클래스 기반 큐잉(CBQ) 스케줄러가 실시간 전송을 요구하는 트래픽을 큐잉 또는 스케줄링 지연 없이 전송할 수 있는 제로 지연 큐잉 방법을 제공하고, 나아가 트래픽이 폭주하는 상황에서도 일반 데이터나 제로 지연 큐잉을 수행하는 데이터 패킷의 Committed Rate(CR) 와 Peak Rate(PR)를 보장할 수 있는 CBQ 스케줄링 방법을 제공함에 있다.

상기한 목적을 달성하기 위한 본 발명의 일 측면에 따른 제로 지연 큐잉 방법은, 제로 지연 큐잉을 수행하는 것으로 설정된 클래스의 패킷인 경우, 제로 지연 큐로 전송하는 단계, 패킷 크기가 해당 클래스에 설정된 CR(Committed Rate)값을 초과하지 않는 경우, 패킷을 strict priority 전송 큐로 전송하는 단계 및 상기 strict priority 전송 큐에 존재하는 패킷을 일반 데이터 전송 큐에 존재하는 패킷보다 우선적으로 포워딩하는 단계를 포함한다.

상기 제로 지연 큐잉 방법에 있어서, 제로 지연 큐잉을 수행하는 것으로 설정된 클래스의 패킷이 아닌 경우, 일반 데이터 큐로 전송하는 것을 특징으로 한다.

상기 제로 지연 큐잉 방법에 있어서, 패킷 크기가 설정된 CR 값을 초과하는 경우, 제로 지연 큐와 일반 데이터 큐의 CR 설정값 중 여분의 대역폭을 더 할당하여 해당 클래스의 PR(Peak Rate)값을 보장한 후, 패킷을 strict priority 전송 큐로 전송하는 것을 특징으로 한다.

상기 제로 지연 큐잉 방법에 있어서, 여분의 대역폭이 존재하지 않는다고 판단되는 경우 패킷을 큐잉시키고, 각 일반 데이터 큐에 큐잉된 패킷 클래스들의 CR값으로부터 사용되지 않는 대역폭을 더 할당하여 패킷을 strict priority 전송 큐로 전송한다.

상기 제로 지연 큐잉 방법에 있어서, 각 일반 데이터 큐에 큐잉된 패킷 클래스들의 CR값으로부터 구해지는 사용되지 않는 대역폭은, 제로 지연 큐를 제외한 모든 큐에 해당하는 클래스들에 설정된 CR bytes 총합과, 현재 스케줄링 주기동안 클래스 큐에 큐잉되어 서비스를 대기 중인 패킷 bytes와 클래스에 설정된 CR bytes 중 작은 값을 취해 이들의 총합을 구한 후, 상기 총합들의 차이값을 구하여 계산하는 것을 특징으로 한다.

상기 제로 지연 큐잉 방법은, 해당 스케줄러 동작 주기가 만료된 경우, CR bytes refresh 루틴을 통해 CR값을 재설정하고, 다음 스케줄링 주기 동안 제로 지연 큐의 클래스들에 CR값을 보장하는 단계를 더 포함한다.

한편, 상기한 목적을 달성하기 위한 본 발명의 다른 측면에 따른 제로 지연 큐잉 시스템은, 제로 지연 큐잉을 수행하는 것으로 설정된 클래스의 패킷을 제로 지연 큐로 전송하고, 제로 지연 스케줄링을 수행한 후 드라이버 Mux로 전송하는 클래스 기반 큐잉 스케줄러와 상기 제로 지연 큐에 해당하는 패킷을 일반 데이터 패킷에 우선하여 포워딩하는 드라이버 큐를 포함한다.

상기 제로 지연 큐잉 시스템에 있어서, 상기 클래스 기반 큐잉 스케줄러는, 제로 지연 큐잉을 수행하는 것으로 설정된 클래스의 패킷을 큐잉없이 바로 드라이버 큐로 전송하는 제로 지연 큐와 클래스 기반 큐잉 스케줄러 해당 동작 주기마다 큐잉된 패킷을 드라이버 큐로 전송하는 일반 데이터 큐를 포함한다.

상기 제로 지연 큐잉 시스템에 있어서, 상기 드라이버 큐는, 일반 데이터 전송 큐보다 우선적으로 패킷을 포워딩하는 strict priority 전송 큐와 패킷을 큐잉시키고, 일정한 순서에 따라 포워딩하는 일반 데이터 전송 큐를 포함한다.

상기 제로 지연 큐잉 시스템에 있어서, 상기 제로 지연 스케줄링은, 제로 지 연 스케줄링 Phase 1 내지 제로 지연 스케줄링 Phase 3으로 구성되는 것을 특징으로 한다.

상기 제로 지연 큐잉 시스템에 있어서, 제로 지연 스케줄링 Phase 1은, 제로 지연 큐잉을 수행하는 것으로 설정된 클래스의 패킷 크기가 해당 클래스에 설정된 CR 값을 초과하지 않는 경우에는 패킷을 strict priority 전송 큐로 전송하고, 패킷 크기가 해당 클래스에 설정된 CR 값을 초과하는 경우에는 제로 지연 스케줄링 Phase 2를 수행한다.

상기 제로 지연 큐잉 시스템에 있어서, 상기 제로 지연 스케줄링 Phase 2는, 제로 지연 큐와 일반 데이터 큐 클래스들의 CR 설정값을 조사하여 여분의 대역폭이 있는 경우에는 해당 클래스의 PR 값을 보장하여 패킷을 strict priority 전송 큐로 전송하고, 여분의 대역폭이 없는 경우에는 제로 지연 스케줄링 Phase 3을 수행한다.

상기 제로 지연 큐잉 시스템에 있어서, 상기 제로 지연 스케줄링 Phase 3은, 패킷을 큐잉시키고, 각 일반 데이터 큐에 큐잉된 패킷들의 length로부터 사용되지 않는 CR값을 계산하여 대역폭이 있다고 판단되는 경우 이를 더 할당하여 패킷을 strict priority 전송 큐로 전송하고, 사용되지 않는 대역폭이 없다고 판단되는 경우에는 해당 패킷을 폐기시키는 것을 특징으로 한다.

상기 제로 지연 큐잉 시스템은, 클래스 기반 큐잉 스케줄러로부터 수신한 패킷을 드라이버 큐로 전송하는 드라이버 Mux를 더 포함한다.

상기 제로 지연 큐잉 시스템에 있어서, 상기 클래스 기반 큐잉 스케줄러는, 수신된 패킷의 헤더를 참조하여 해당 패킷의 클래스를 구분하여 분류하는 등급 분류기를 더 포함한다.

이하 본 발명에 따른 제로 지연 큐잉 방법 및 그 시스템을 첨부한 도면을 참조하여 상세히 설명한다.

도 4는 본 발명에 따른 제로 지연 큐잉을 제공하는 클래스 기반 큐잉 시스템의 구성을 도시한 도면이다.

본 발명에 따른 클래스 기반 큐잉 시스템의 기본적인 구성은 종래의 클래스 기반 큐잉 시스템과 기본적으로 동일하며, 그 구성 요소의 기능 또한 기존의 것과 크게 다르지 않다. 따라서 하기에서는 중복되는 설명은 생략하고 종래의 구성 요소와 다른 부분에 대해서만 기술하기로 한다.

상기 클래스 기반 큐잉 시스템은 CBQ 스케줄러(410), 드라이버 Mux(420) 및 다수의 드라이버 큐(430, 440, 450, 460)를 포함하여 구성된다.

CBQ 스케줄러(410)는 슈도코드(pseudocode)로 구성된 프로그램에 따라 제로 지연 큐잉을 실시한다. pseudocode란 소프트웨어 개발시 각 모듈의 작동 논리를 표현하기 위해 사용되는 언어이다. pseudocode는 프로그램 설계 언어의 한 형태로 실제 프로그램 작성 언어가 아니고, 단지 그 프로그램의 개발자나 사용자에게 그 모듈이 하는 일과 작동 방식을 설명하기 위한 것이다. 상기 언어로 작성하는 경우 프로그램의 논리를 이해하는 것이 용이하다. 본 발명에서 제안하는 제로 지연 큐잉을 수행하는 pseudocode에 대해서는 추후 상세하게 설명하도록 하겠다.

상기 프로그램이 수행되는 경우, CBQ 스케줄러(410)는 최상위 우선 전송 순위를 가지는 큐(queue)를 제로 지연 큐(zero delay queue)(415)로 지정한다. CBQ 스케줄러(410)에 의하여 제로 지연 큐(415)로 지정되지 않은 큐들은, 일반 데이터 큐(416, 417, 418)가 된다.

일반 데이터 큐(416, 417, 418)에 큐잉된 패킷들은 주기적인 CBQ 스케줄러(410)의 구동에 의해서 전송된다. 그렇지만 제로 지연 큐(415)에 해당하는 패킷들은 큐잉 또는 스케줄링 지연 없이, 바로 드라이버 큐(430, 440, 450, 460)의 strict priority 전송 큐(432, 442, 452, 462)로 전송된다.

또한 CBQ 스케줄러(410)는 제로 지연 큐(415)에 위치하는 클래스들에 CBQ 스케줄러(410)의 다른 일반 데이터 큐(416, 417, 418)에 위치하는 클래스와 마찬가지로, CR 값과 PR 값을 설정할 수 있다. CBQ 스케줄러(410)는 제로 지연 큐(415)에 설정된 CR 값과 PR 값을 지원하기 위해서, Phase 1 내지 Phase 3의 스케줄링을 실시한다.

드라이버 Mux(420)는 CBQ 스케줄러(410)의 제로 지연 큐(415)로부터 패킷을 수신하는 경우, 이를 strict priority 전송 큐(432, 442, 452, 462)로 전송한다. 또한 CBQ 스케줄러(410)의 일반 데이터 큐(416, 417, 418)로부터 패킷을 수신하는 경우에는, 이를 일반 데이터 전송 큐(434, 444, 454, 464)로 전송한다.

각각의 드라이버 큐(430, 440, 450, 460)는 strict priority 전송 큐(432, 442, 452, 462)와 일반 데이터 전송 큐(434, 444, 454, 464)로 구성된다. 드라이버 큐는 2가지의 큐를 관리하면서, 각각의 큐에 있어서 패킷 전송 방법을 다르게 적용 한다. 일반 데이터 전송 큐(434, 444, 454, 464)는 모든 패킷을 대기열에 저장하고, 일정한 순서에 따라 패킷을 포워딩한다. 반면 strict priority 전송 큐(432, 442, 452, 462)는 해당 큐에 패킷이 존재하면, 항상 일반 데이터 전송 큐(434, 444, 454, 464)보다 우선하여 패킷을 포워딩한다. 예를 들어, 드라이버 큐 1(430)의 경우, strict priority 전송 큐 1(432)에 존재하는 패킷은 일반 데이터 전송 큐 1(434)에 존재하는 패킷보다 먼저 포워딩된다.

본 발명에 따른 클래스 기반 큐잉 시스템은 특정 패킷을 큐잉 없이 바로 전송하기 위해서 제로 지연 큐와 strict priority 전송 큐를 두고 있다.

큐잉 지연없이 패킷을 전송하는 제로 지연 큐잉은 기존의 스케줄링 알고리즘에 의해서는 지원될 수가 없다. 제로 지연 큐에 해당하는 패킷들은 큐잉을 하지 않기 때문에, 제로 지연 큐에 데이터가 폭주하는 경우 일반 데이터 큐에 대해서 CR값을 보장할 수 없으며, 이에 따라 제로 지연 큐잉을 수행하는 스케줄러는 대역폭 관리 기능을 수행할 수 없기 때문이다. 다시 말해, 우선 순위에 해당하는 패킷들을 먼저 전송하다 보면, 일반 데이터나 제로 지연 큐잉을 수행하는 데이터 패킷들의 경우 일정한 CR값과 PR값을 보장할 수 없다. 따라서 본 발명에 따른 CBQ 스케줄러는, 제로 지연 큐에 해당하는 클래스에 대해 CR값과 PR값을 보장하기 위해서 3 Phase 스케줄링을 한다. 본 발명에서 상기 Phase 1 내지 Phase 3의 스케줄링은 pseudocode로 이루어진 프로그램에 의하여 수행된다.

Phase 1 스케줄링은 제로 지연 큐(415)에 해당하는 클래스의 CR 설정값에 따 라 큐잉 지연없이 패킷을 전송하는 CR 보장 단계이다. Phase 2 스케줄링은 제로 지연 큐(415)에 해당하는 클래스들이 해당 스케줄링 주기에서 설정된 CR 값을 넘는 경우, 제로 지연 큐(415)와 일반 데이터 큐(416, 417, 418)에 해당하는 클래스들의 CR 설정값을 조사하여, 여분의 대역폭(unreserved bandwidth)이 있는 경우 해당 대역폭을 사용하는 PR 보장 단계이다. Phase 3 스케줄링은 Phase 2 스케줄링을 통해서도 전송되지 못한 제로 지연 큐(415)에 해당하는 클래스의 패킷들에 대해서, 일반 데이터 큐(416, 417, 418)에 해당하는 클래스들의 CR 설정 대비 사용하지 않는 여분의 대역폭을 더 할당하여 포워딩 해주는 단계이다.

본 발명에 따른 제로 지연 큐잉을 지원하는 스케줄러의 pseudocode는 다음과 같다.

Read packet from input interface; ---------------------> step 1

routing; ------------------------------------ -----> step 2

if (output interface CBQ enabled) ---------------------> step 3

{

packet classification; ------------------------------> step 4

if (packet is classified to zero delay queue) -----------> step 5

zero_delay_queue_scheduler_phase_1( ); -------------> step 6

else

enqueue packet; --------------------------------> step 7

}

else

packet transmission; -------------------------------> step 8

if (cbq_scheduler timer expired)

run cbq_scheduler( ); -------------------------------> step 9

1단계(Step 1)에서 input 인터페이스를 통해 패킷을 읽어 오면, 2단계(step 2)에서는 라우팅을 결정한다. 이 경우 output 인터페이스의 클래스 기반 큐잉(CBQ) 스케줄러(410)가 enable 되었는지 여부에 따라, 패킷의 처리 방법이 달라진다.

CBQ 스케줄러(410)가 enable 되었다면, 3단계(step 3) 내지 7단계(step 7)를 거쳐 큐잉을 수행한다. 그렇지만 CBQ 스케줄러(410)가 enable 되지 않은 경우, 8단계(step 8)를 거쳐 큐잉없이 패킷을 포워딩한다. 8단계(step 8)에서는 output 인터페이스로의 패킷 포워딩시 가용 대역폭을 넘는 경우라 하더라도, 선별적인 패킷 폐기 등의 차별화된 패킷 포워딩 서비스를 제공할 수 없다.

만일 out 인터페이스의 CBQ 스케줄러(410)가 enable 되었다면, 4단계(step 4)에서는 패킷 분류 과정을 통해 해당 패킷이 어떤 클래스에 해당하며, 이에 따라 어떤 서비스 클래스 큐에 큐잉되어야 하는지 결정한다.

5단계(step 5)에서는 패킷이 제로 지연 큐(415)에 해당하는지 판단한다. 제로 지연 큐(415)에 해당하는 패킷들은 6단계(step 6)에서 제로 지연 큐 스케줄링 Phase 1을 통해 큐잉을 수행한다. 그러나 제로 지연 큐(415)를 제외한 각 일반 데이터 큐(416, 417, 418)에 해당하는 패킷들은 7단계(step 7)에서 일반적인 큐잉을 수행한다.

7단계(step 7)를 통해 제로 지연 큐(415)를 제외한 각 일반 데이터 큐(416, 417, 418)에 큐잉된 패킷들은 9단계(step 9)를 통해 일정한 스케줄링 주기마다 포워딩된다. 그러나 제로 지연 큐(415)를 통해 큐잉되는 패킷들은 앞서 설명한 도 4의 드라이버 큐(430, 440, 450, 460)에 위치하는 strict priority 전송 큐(432, 442, 452, 462)를 통하여 우선적으로 포워딩된다.

CBQ 스케줄러가 수행하는 제로 지연 스케줄링은 모든 클래스의 큐에 큐잉된 패킷을 설정된 CR값에 맞추어 전송하는 CR 스케줄링 단계와, 모든 클래스의 CR값을 준수하여 패킷을 전송한 후 전송해야 할 패킷이 더 있는 클래스들에 대해서 해당 스케줄링 주기 동안 가용한 대역폭이 있으면 클래스에 설정된 PR값에 따라 패킷을 전송하는 PR 스케줄링 단계로 진행된다. 다음은 CR 스케줄링 단계와 PR 스케줄링 단계를 수행하는 pseudocode이다.

cbq_scheduler()

{

/* CR scheduling */

while (every queue in CBQ)

{

Get packet from class in queue;

if (packet size > class's CR) --------> (a)

Get packet from next class;

else

transmit packet;

}

/* PR scheduling */

if (avail_bandwidth > 0)

{

while (every queue in CBQ)

{

Get packet from class in queue;

if (packet size < class's PR) ------> (b)

transmit packet;

}

상기 Pseudocode를 보면 (a)단계에서는 각 클래스 큐에 설정된 CR 값에 맞 추어 큐잉된 패킷을 전송하고 있다는 것을 알 수 있다. (b)단계에서는 (a)단계를 거치고도 전송해야 할 패킷이 더 남은 클래스들에 대해서, 해당 스케줄링 주기 동안 가용한 대역폭이 있으면 PR값을 보장하여 패킷을 전송한다.

도 5는 본 발명에 따른 제로 지연 큐잉 과정을 도시한 도면이다.

CBQ 스케줄러(410)에 패킷이 입력되는 것으로 절차는 시작된다(S501). CBQ 스케줄러(410)는 등급 분류기(412)에 의하여 해당 패킷의 클래스를 판별한다 (S502). CBQ 스케줄러(410)는 상기 패킷이 제로 지연 큐(415)에 해당하는 지 판단한다(S503).

만일 제로 지연 큐(415)에 해당하는 클래스의 패킷이라고 판단되는 경우라면, CBQ 스케줄러(410)는 제로 지연 스케줄링 Phase 1을 수행한다(S504). CBQ 스케줄러(410)는 패킷 크기가 해당 클래스에 설정된 CR값을 초과하는지 판단한다(S505). 패킷 크기가 해당 클래스에 설정된 CR 값을 초과하지 않는 경우에는, 패킷을 strict priority 전송 큐(432, 442, 452, 462)로 전송한다 (S513).

그러나 패킷 크기가 설정된 CR 값을 초과하는 경우에는 제로 지연 스케줄링 Phase 2를 수행한다(S506). CBQ 스케줄러(410)는 제로 지연 큐와 일반 데이터 큐 클래스들의 CR 설정값을 조사하여 여분의 대역폭이 존재하는지 판단한다(S507). 여분의 대역폭이 존재하는 경우, 이를 사용하여 해당 클래스의 PR 값을 보장한다 (S508). 이후, CBQ 스케줄러(410)는 해당 패킷을 strict priority 전송 큐(432, 442, 452, 462)로 전송한다(S513).

그러나 상기 S507 단계에서 여분의 대역폭이 없다고 판단되면, CBQ 스케줄러(410)는 제로 지연 스케줄링 Phase 3을 수행한다(S509).

제로 지연 스케줄링 Phase 2는 사용자가 설정한 제로 지연 큐와 일반 데이터 큐 클래스들의 CR 설정값에서 여분의 대역폭을 사용하여 PR값을 보장한다. 이에 반하여 제로 지연 스케줄링 Phase 3은 각 일반 데이터 큐(416, 417, 418)에 큐잉된 패킷 클래스들의 CR값으로부터 사용되지 않는 가용 대역폭을 계산하여 이를 사용한다. 제로 지연 스케줄링 Phase 3에서는 CR bytes refresh 루틴을 통해 제로 지연 큐의 클래스들은 다음 스케줄링 주기 동안 CR bytes를 보장받는다.

CBQ 스케줄러(410)는 제로 지연 스케줄링 Phase 3을 수행하는 경우, 패킷을 큐잉시킨다(S510). 이 경우 CBQ 스케줄러(410)는 스케줄러 동작 주기가 만료되었는지 판단한다(S511). CBQ 스케줄러(410)의 해당 동작 주기가 만료되지 않은 경우에는, 새로운 스케줄링 주기가 시작될 때까지 패킷을 큐잉시킨다.

CBQ 스케줄러(410)의 해당 동작 주기가 만료하여 새로운 스케줄링 주기가 시작되면, 각 일반 데이터 큐(416, 417, 418)에 큐잉된 패킷 클래스들의 CR값으로부터 사용되지 않는 가용 대역폭이 더 있는지 판단한다(S512). 가용 대역폭이 있는 경우라면, CBQ 스케줄러(410)는 대역폭을 더 할당하여 패킷을 strict priority 전송 큐(432, 442, 452, 462)로 전송한다(S513). 그러나 일반 데이터 큐 클래스들의 CR 설정 대비 사용하지 않는 여분의 대역폭이 존재하지 않는 경우에는 새로운 스케줄링 주기가 시작될 때까지 패킷을 큐잉시킨다.

strict priority 전송 큐(432, 442, 452, 462)에서는 패킷을 다른 일반 데 이터 전송 큐(434, 444, 454, 464)에 존재하는 패킷에 우선하여 포워딩하며, 이 경우 모든 절차는 종료한다.

만일 S503 단계에서 해당 패킷이 제로 지연 큐(415)가 아닌 일반 데이터 큐(416, 417, 418)에 해당하는 클래스의 패킷이라 판단되면, S510 단계로 이동하여 패킷을 큐잉시키고 이후의 절차를 거친다.

이제 각 단계(Phase)별로 제로 지연 큐잉을 수행하기 위한 클래스 기반 스케줄러의 동작을 상세히 설명해 보기로 하자.

다음은 제로 지연 스케줄링 Phase 1을 수행하기 위한 pseudocode를 나타낸 것이다. 앞서 살펴보았지만 제로 지연 스케줄링 Phase 1은 제로 지연 큐(415)에 해당하는 클래스에 설정된 CR 설정값을 보장해 주는 단계이다.

zero_delay_queue_scheduler_phase_1 ( )

{

Get class's max forward CR bytes; -------------------> step 1

if (available max forward CR bytes)

packet transmission; -----------------------------> step 2

else

zero_delay_queue_scheduler_phase_2 (); ------------> step 3

}

상기 pseudocode의 2단계(step 2), 즉 큐잉없이(제로 지연) 패킷을 전송하기 위한 알고리즘은 다음과 같은 pseudocode에 의하여 이루어진다.

if (p_class_cr_bytes - p_size) > 0)

{

p_class_cr_bytes = p_class_cr_bytes - p_size;

packet transmission;

}

이 경우 p_class_cr_bytes 라는 변수는 패킷이 속하는 해당 클래스가 스케줄링 주기 동안 전송할 수 있는 CR 값을 byte로 계산한 값이다. p_size는 패킷 크기이다. 즉 패킷이 속하는 클래스가 해당 패킷을 전송할 수 있는 충분한 CR 대역폭을 가지고 있을 경우, CBQ 스케줄러(410)는 큐잉없이 패킷을 전송한다. 이 경우 패킷을 지연 없이 포워딩하게 되며, 동시에 제로 지연 큐잉을 하는 해당 클래스에 설정된 CR 값을 보장할 수 있다.

만일 해당 패킷 클래스에 해당 패킷을 전송할 수 있는 CR 대역폭이 남아 있지 않은 경우라면, CBQ 스케줄러(410)는 제로 지연 스케줄링 Phase 2를 통해 output 인터페이스에 존재하는 여분의 대역폭(unreserved bandwidth)을 사용한다.

다음은 제로 지연 스케줄링 Phase 2를 수행하는 pseudocode를 나타낸 것이 다.

zero_delay_queue_scheduler_phase_2( )

{

Get interface max forwarding bytes; -----------------> step 1

Get all outbound classes's CR bytes; ----------------> step 2

Get available unreserved forwarding bytes

(interface max forwarding bytes -

all classes's CR bytes); -------> step 3

if (available unreserved forwarding bytes)

packet transmission; ----------------------------> step 4

else

enqueue packet; -------------------------------> step 5

}

1단계(step 1)에서는 해당 output 인터페이스의 스케줄링 주기 동안 전송할 수 있는 CR bytes를 계산한다. 2단계(step 2)는 output 인터페이스중 해당 클래스를 제외한 모든 outbound 클래스에 대해 설정된 각 CR 값들의 합을 구한다.

3단계(step 3)에서는 1단계(step 1)에서 구한 CR bytes값과 2단계(step 2)에서 구한 값의 차이를 구하여, 여분의 대역폭을 계산한다. 4단계(step 4)에서는 여분의 대역폭이 존재하는 경우, PR 값을 보장하여 패킷을 포워딩한다. 그러나 여분 의 대역폭이 존재하지 않는 경우에는, 제로 지연 스케줄링 Phase 3을 통해 패킷이 전송될 수 있도록 5단계(step 5)에서 패킷은 큐잉된다. 결국 제로 지연 스케줄링 Phase 2는 여분의 대역폭이 존재하는 경우, 제로 지연 큐(415)에 위치하는 패킷 클래스들의 PR을 보장한다.

이제 남은 건 제로 지연 스케줄링 Phase 3이다. 제로 지연 스케줄링 Phase 3을 수행하는 pseudocode는 다음과 같다.

cbq_scheduler( )

{

if (zero delay queue is not empty) ------------------> step 6

{

zero_delay_queue_scheduler_phase_3: --------------> step 7

Get all classes's available CR bytes; ---------------> step 8

if (available CR bytes)

packet transmission; --------------------------> step 9

else

packet drop; ---------------------------------> step 10

}

Refresh classes max CR bytes in zero delay queue; ----> step 11

CR scheduling;

PR scheduling;

}

8단계(step 8)에서는 각 일반 데이터 큐(416, 417, 418)에 큐잉된 패킷 클래스들의 CR bytes 로부터 사용되지 않는 가용 대역폭을 계산한다. 이 경우 CR bytes 로부터 가용 대역폭을 구하는 계산식은 다음 (식 1) 과 같다.

avail_cr_bytes =

∑class CR bytes - ∑ MIN(class queuing bytes, class CR bytes)

(식 1)

가용 대역폭은 상기 (식 1)에서 알 수 있듯이, 제로 지연 큐(415)를 제외한 모든 큐에 해당하는 클래스들에 설정된 CR bytes 총합과, 현재 스케줄링 주기동안 클래스 큐에 큐잉되어 서비스를 대기 중인 패킷 bytes와 클래스에 설정된 CR bytes 중 작은 값을 취해 이들의 총 합을 구한 후, 상기 값들의 차이값을 구하여 얻을 수 있다.

가용 대역폭이 있는 경우에는, 9단계(step 9)를 통해 패킷을 전송한다. 그러나 가용 대역폭이 존재하지 않는 경우에는 10단계(step 10)에서 제로 지연 큐(415)의 패킷은 폐기된다.

이 경우 11단계(step 11)에서는 CR bytes refresh 루틴을 거치며, 이를 통해 제로 지연 큐(415)에 해당하는 클래스들은 다음 스케줄링 주기 동안 CR bytes를 보장받는다.

아래 [표 1]은 본 발명에 따른 제로 지연 큐잉의 성능을 측정한 결과이다. 성능 측정의 환경은 T3 인터페이스에 64 bytes 패킷을 1초당 3500 프레임의 비율로 30초 동안 전송하였으며, 트래픽 클래스는 실시간 전송 클래스(Real time class)와 일반 데이터 클래스(Data class)로 분류하여 2개의 클래스를 생성하였다. 실시간 전송 클래스를 제로 지연 큐에 할당하여 서비스 할 경우 전송 지연은 458us로서, 큐잉을 하지 않고 서비스를 제공하는 NO CBQ 서비스의 454us의 전송 지연과 거의 비슷하게 나왔다. 또한 데이터 클래스는 CBQ가 적용된 경우 3ms의 전송지연을 보였다.

[표 1]

본 발명에 따른 제로 지연 큐잉을 통해 실시간 전송이 요구되는 특정 트래픽에 지연 없는 포워딩을 제공할 수 있으며, 제로 지연 큐에 해당하는 패킷들에 대해서 CR 값과 PR 값을 동시에 보장하여 서비스 할 수 있다. 또한 클래스 기반 큐잉 에 기반하는 것이므로, 대역폭 조절이 가능하다.

Claims

제로 지연 큐잉을 수행하는 것으로 설정된 클래스의 패킷인 경우, 제로 지연 큐로 전송하는 단계;

패킷 크기가 해당 클래스에 설정된 CR(Committed Rate)값을 초과하지 않는 경우, 패킷을 strict priority 전송 큐로 전송하는 단계; 및

상기 strict priority 전송 큐에 존재하는 패킷을 일반 데이터 전송 큐에 존재하는 패킷보다 우선적으로 포워딩하는 단계를 포함하고,

패킷 크기가 설정된 CR 값을 초과하는 경우,

상기 패킷을 strict priority 전송 큐로 전송하는 단계에서, 제로 지연 큐와 일반 데이터 큐의 CR 설정값 중 여분의 대역폭을 더 할당하여 해당 클래스의 PR(Peak Rate)값을 보장한 후, 패킷을 strict priority 전송 큐로 전송하는 제로 지연 큐잉 방법.
제1항에 있어서,

제로 지연 큐잉을 수행하는 것으로 설정된 클래스의 패킷이 아닌 경우, 일반 데이터 큐로 전송하는 제로 지연 큐잉 방법.
삭제
제1항에 있어서,

여분의 대역폭이 존재하지 않는다고 판단되는 경우 패킷을 큐잉시키고, 각 일반 데이터 큐에 큐잉된 패킷 클래스들의 CR값으로부터 사용되지 않는 대역폭을 더 할당하여 패킷을 strict priority 전송 큐로 전송하는 제로 지연 큐잉 방법.
제4항에 있어서,

각 일반 데이터 큐에 큐잉된 패킷 클래스들의 CR값으로부터 구해지는 사용되지 않는 대역폭은, 제로 지연 큐를 제외한 모든 큐에 해당하는 클래스들에 설정된 CR bytes 총합과, 현재 스케줄링 주기동안 클래스 큐에 큐잉되어 서비스를 대기 중인 패킷 bytes와 클래스에 설정된 CR bytes 중 작은 값을 취해 이들의 총합을 구한 후, 상기 총합들의 차이값을 구하여 계산하는 것을 특징으로 하는 제로 지연 큐잉 방법.
제5항에 있어서,

해당 스케줄러 동작 주기가 만료된 경우,

CR bytes refresh 루틴을 통해 CR값을 재설정하고, 다음 스케줄링 주기 동안 제로 지연 큐의 클래스들에 CR값을 보장하는 단계를 더 포함하는 제로 지연 큐잉 방법.
제로 지연 큐잉을 수행하는 것으로 설정된 클래스의 패킷을 제로 지연 큐로 전송하고, 제로 지연 스케줄링을 수행한 후 드라이버 Mux로 전송하는 클래스 기반 큐잉 스케줄러;

상기 제로 지연 큐에 해당하는 패킷을 일반 데이터 패킷에 우선하여 포워딩하는 드라이버 큐를 포함하고,

상기 클래스 기반 큐잉 스케줄러는,

제로 지연 큐잉을 수행하는 것으로 설정된 클래스의 패킷을 큐잉없이 바로 드라이버 큐로 전송하는 제로 지연 큐; 와

클래스 기반 큐잉 스케줄러 해당 동작 주기마다 큐잉된 패킷을 드라이버 큐로 전송하는 일반 데이터 큐를 포함하는 제로 지연 큐잉 시스템.
삭제
제7항에 있어서,

상기 드라이버 큐는,

일반 데이터 전송 큐보다 우선적으로 패킷을 포워딩하는 strict priority 전 송 큐; 와

패킷을 큐잉시키고, 일정한 순서에 따라 포워딩하는 일반 데이터 전송 큐를 포함하는 제로 지연 큐잉 시스템.
제7항에 있어서,

상기 제로 지연 스케줄링은,

제로 지연 스케줄링 Phase 1 내지 제로 지연 스케줄링 Phase 3으로 구성되는 제로 지연 큐잉 시스템.
제10항에 있어서,

제로 지연 스케줄링 Phase 1은,

제로 지연 큐잉을 수행하는 것으로 설정된 클래스의 패킷 크기가 해당 클래스에 설정된 CR 값을 초과하지 않는 경우에는 패킷을 strict priority 전송 큐로 전송하고, 패킷 크기가 해당 클래스에 설정된 CR 값을 초과하는 경우에는 제로 지연 스케줄링 Phase 2를 수행하는 제로 지연 큐잉 시스템.
제11항에 있어서,

상기 제로 지연 스케줄링 Phase 2는,

제로 지연 큐와 일반 데이터 큐 클래스들의 CR 설정값을 조사하여 여분의 대역폭이 있는 경우에는 해당 클래스의 PR 값을 보장하여 패킷을 strict priority 전송 큐로 전송하고, 여분의 대역폭이 없는 경우에는 제로 지연 스케줄링 Phase 3 을 수행하는 제로 지연 큐잉 시스템.
제12항에 있어서,

상기 제로 지연 스케줄링 Phase 3은,

패킷을 큐잉시키고, 각 일반 데이터 큐에 큐잉된 패킷 클래스들의 CR값으로부터 사용되지 않는 대역폭이 있다고 판단되는 경우 이를 더 할당하여 패킷을 strict priority 전송 큐로 전송하는 제로 지연 큐잉 시스템.
제7항에 있어서,

클래스 기반 큐잉 스케줄러로부터 수신한 패킷을 드라이버 큐로 전송하는 드라이버 Mux를 더 포함하는 제로 지연 큐잉 시스템.
제7항에 있어서,

상기 클래스 기반 큐잉 스케줄러는,

수신된 패킷의 헤더를 참조하여 해당 패킷의 클래스를 구분하여 분류하는

등급 분류기를 더 포함하는 제로 지연 큐잉 시스템.