'Quality of Service'에 해당되는 글 2건

  1. 2011.12.02 인터넷 QoS 지원 리눅스 기반 CBQ 연구
  2. 2009.05.14 [QoS] 트래픽 쉐이핑과 폴리싱
2011. 12. 2. 09:55

인터넷 QoS 지원 리눅스 기반 CBQ 연구




1. 리눅스 기반의 QoS 지원 기술.pdf

2. 인터넷 QoS 제공을 위한 CBQ 기반의 스케줄링 기법에 관한 연구.pdf

3. 지연시간 보장을 위한 향상된 CBQ 정책.pdf

4. Differentiated Service 제공을 위한 CBQ 기반의 패킷 전송 기법에 대한 연구.pdf


Trackback 0 Comment 0
2009. 5. 14. 23:03

[QoS] 트래픽 쉐이핑과 폴리싱

트래픽 쉐이핑과 폴리싱은 Diffserv의 컨디셔너 부분에 위치하며, 트래픽 대역폭을 제어하는 대표 기술로 꼽힌다. 쉐이핑과 폴리싱은 모두 토큰 버킷(Bc) 매커니즘을 사용해 구현된다. 단지 차이가 있다면 쉐이핑은 버퍼링을 사용하고, 폴리싱은 버퍼링을 사용하지 않는다는 것이다. 이번 호에는 트래픽 쉐이핑과 폴리싱의 작동 메커니즘과 실무 적용 방법에 대해 예제를 통해 살펴본다.

김화식 | zion@onsetel.co.kr | 온세통신 시설운영팀 CCIE
s12840@freechal.com | NRC Network+ 팀 마스터


지난호에서 Diffserv 모델에 대한 개요와 분류자, 미터, 마커에 대해 배웠다. 복습하는 의미에서 다시 한번 확인해보면, 인바운드(inbound) 트래픽에 대해 분류자(classifier : 보통은 ACL(Access Control List)을 이용한다)를 이용해 클래스별로 분류하고, 마커(marker)를 이용해 마킹한 후, 미터(meter)를 이용해 트래픽이 미리 협의된 임계값(threshold)을 초과하는지 관찰하는 방법까지 알아봤다.
쉐이핑(shaping)과 폴리싱(policing)은 그 다음 모듈인 컨디셔너 부분에 위치하며, 임계값을 초과한 트래픽에 대해 어떻게 처리할 것인가를 결정해주는 역할을 한다. 얼마 전까지만해도 쉐이핑과 폴리싱은 ISP에서만 제한적으로 사용하고 있었으나, QoS가 점점 중요해지고 대역폭 조절에 관심이 많아지면서 엔터프라이즈에서도 적용하는 사례가 증가하고 있다.
실제로 쉐이핑과 폴리싱을 이용하면 간단한 설정만으로 P2P 트래픽을 전체 대역폭의 20% 이하로 제한한다거나, DoS 공격에 대비해 핑(ping) 패킷을 전체 대역폭의 2%로 제한하는 설정도 가능하다.

쉐이핑과 폴리싱의 기본 알고리즘 '토근 버킷'
토큰 버킷(Token Bucket)은 트래픽 쉐이핑과 트래픽 폴리싱에서 사용하는 기본 알고리즘으로, CAR(Committed Access Rate), 클래스-기반 폴리싱, GTS(Generic Traffic Shaping), 프레임 릴레이 트래픽 쉐이핑에서 사용한다. 우선 토큰 버킷에서 사용되는 변수에 대해 알아보자.

CIR = Committed Information Rate(CIR), in bits per second
Bc = Conformed Burst Size(Bc), in bits
Be = Excess Burst Size(Be), in bits
Tc = Measuring Time Interval(Tc)

(그림 1)을 보면 Bc(양동이에 비유)가 수도꼭지를 이용해 물을 받고 있다. 이때 수도꼭지를 끝까지 돌려서 최고 속도로 물을 받을 수도 있고, 조금만 틀어 비교적 천천히 물을 받을 수도 있다. 이때 물이 공급되는 속도는 CIR이며, 양동이의 크기는 Bc이고, 양동이에 물이 가득 채우는데 걸리는 시간은 Tc이다.



예를 들어 양동이의 크기가 5리터이고 물이 양동이를 가득 채우는데 걸리는 시간을 30초라고 하면, 물이 공급되는 속도는 CIR = 5리터/30초다. 30초마다 5리터의 물을 사용할 수 있으므로, 최대 1분 동안 10리터, 1시간 동안은 600리터의 물을 사용할 수 있다. 1시간 동안 600리터의 물을 사용하기 위해서는 30초마다 양동이(5리터)의 물을 소비해야 하는데, 양동이의 특성상 처음 30초가 지났을 때 물을 사용하지 않으면 그 다음부터는 물이 양동이를 넘쳐나게 되기 때문이다.
또 다른 예를 들어 보자. 양동이(5리터) 밑에 또 하나의 양동이(5리터)를 두고 넘치는 물을 받는다고 하면, 30초가 지나면서 넘쳐서 사용하지 못했던 물을 이제는 5리터까지는 사용할 수 있다. 다시 말하면 기존에는 1분이 지난 후에 사용할 수 있는 물의 양이 5리터였는데, 물이 넘치는 것을 양동이(5리터)를 하나 더 추가하면 총 10리터의 물을 사용할 수 있다. 하지만 1분이 지나면 물이 넘치는 현상은 똑같이 재현된다.
이번에는 추가하는 양동이의 크기를 600리터로 가정하고 생각해보자. 추가된 양동이(600리터)의 양이 크기 때문에 1시간 동안 한번도 사용하지 않았다고 해도 600리터의 물을 한번에 받을 수 있다. 물론 물이 떨어지는 속도는 같기 때문에 1시간 동안 최대로 사용할 수 있는 물의 양은 어느 경우에나 똑같이 600리터다.
위의 예에서 추가하는 양동이를 Be라고 생각하면 된다. Be를 추가함으로써 버려지는 물의 양을 최소화해 효율성을 높이고, 단위시간에 사용할 수 있는 물의 양을 증가시켜 성능을 높이는 효과를 볼 수 있는 것이다.
실제로 프레임 릴레이(Frame Relay) 서비스를 할 때 토큰 버킷 알고리즘을 이용하는데 수도꼭지에서 나오는 물을 토큰(Token)이라고 생각하면 된다. 위의 예에서 수도꼭지에서 물이 끊임없이 쏟아져 나오는 것처럼, 토큰은 일정한 속도(CIR)로 끊임없이 공급이 되며, Tc의 시간이 되면 토큰이 버킷(Bucket)에 Bc만큼 채워진다.
이때 채워진 토큰 수만큼 데이터를 전송해 준다. 만약 이때 ISP측에서 허용한 Be(Excess burst)를 설정해 서비스한다면, 양동이를 하나 추가해서 그 이전 Tc의 시간에 다 쓰지 않고 남은 토큰이 있을 경우, 다시 축적(credit building)돼 최대 한번의 Tc 시간동안 Bc + Be까지도 전송할 수 있다는 것을 의미한다.

토큰의 활용 예
다음과 같이 구체적인 예를 통해 다시 확인해 보자.

CIR = 64000bps
Bc = 8000비트
Be = 8000비트
Tc = 125 msec

처음 버킷은 Bc, Be 2개가 있고, 처음 Bc가 텅빈 상태에서 125ms(Tc)가 지나면 Bc에 토큰이 8000개가 채워진다. 이때를 Tc(0)라고 하고, 다음과 같이 전송할 데이터가 있다고 가정하자(토큰 한 개는 1비트로 생각한다).

① Tc(0) : 큐에 대기하고 있는 전송할 데이터(0)=6000, Bc(0)=8000, Be(0)=0
- Bc에서 6000을 꺼내 데이터를 전송함. Bc에는 토큰이 2000 남는다.

② Tc(1) : 데이터(1)=6000, Bc(1)=8000, Be(1)=2000
- Tc인 125ms 동안 새롭게 추가된 토큰과 전에 쓰고 남은 토큰을 합해서 10000의 토큰이 있다. 역시 Bc에서 6000을 꺼내 데이터를 전송하면, 이제 Bc에는 2000, Be에는 2000이 남는다.

③ Tc(2) : 데이터(2)=0, Bc(2)=8000, Be(2)=4000
- 새롭게 추가된 토큰을 더해 Bc는 8000, Be는 4000이 있음.

④ Tc(3) : 데이터(3)=16000, Bc(3)=8000, Be(3)=8000
- 새롭게 추가된 토큰을 더해 Bc는 8000, Be는 4000 + 8000 = 12000이지만, 4000의 토큰은 흘러 넘친다. 보낼 데이터만큼의 토큰이 있으므로 16000 모두 전송된다. 이때 이렇게 전송된 데이터 중에서 ISP쪽에서 허용된 Bc인 8000 이상의 데이터외의 나머지 Be 8000은 DE 비트를 마킹해 프레임 릴레이 망으로 전송한다. 망 내에서 혼잡(congestion) 발생시 우선적으로 드롭된다. 이제 Bc, Be에 남아 있는 토큰은 없다.

⑤ Tc(4) : 데이터(4)=10000, Bc(4)=8000, Be(4)=0
- 새롭게 추가된 토큰을 더해 Bc가 8000이 됐지만, 이 경우에는 토큰이 부족하다. 이때 쉐이핑일 경우는 버퍼에 2000을 저장했다가 다음 Tc에 전송을 하고, 폴리싱일 경우는 드롭시킨다.

트래픽 쉐이핑의 이해
쉐이핑은 트래픽의 속도와 대역폭을 제한하는 기술로, 버퍼링을 사용해 목표 속도 이상으로 들어오는 트래픽을 잠시 저장했다가 나중에 서비스하는 방법을 이용한다. 쉐이핑은 오늘날 거의 대부분의 중요한 QoS 이슈들을 해결하는데 사용된다. 특히 폴리싱으로는 해결할 수 없는 출력 블록킹(egress blocking)에 의한 지연이나, 패킷 손실 문제를 해결할 수 있다.
쉐이핑은 어느 정도 버스트 트래픽을 수용할 수 있다는 점과 폴리싱에 비해 패킷 손실률을 줄이고, 전체적인 쓰루풋을 향상시킬 수 있다는 것이 장점이다. 하지만 버퍼링으로 인해 추가적인 지연이 더해질 수 있으므로, 커다란 버퍼를 사용하는 경우, 실시간 애플리케이션 트래픽에 영향을 미칠 수 있다.


(그림 2)는 초과된 트래픽(exceed traffic)에 대해 쉐이핑과 폴리싱의 처리 방법이 어떻게 다른지를 보여주는 그림이다. 쉐이핑은 초과된 트래픽을 잠시 저장하기 위해 버퍼나 큐를 사용하기 때문에 주로 출력 쪽에서 구현하는 것이 일반적이다. 쉐이핑을 적용해야 하는 경우는 다음과 같다.

사례 1 : ISP에서 폴리싱을 적용했을 경우
프레임 릴레이 서비스를 ISP로부터 구매할 때 256Kbps의 CIR를 구매했다면, 초당 256Kbps까지는 전송 속도를 보장받는다는 것을 의미한다. 만약 이때 포트 속도 역시 256Kbps라면 트래픽 쉐이핑은 의미가 없다. 어차피 물리적으로 256Kbps 이상은 전송할 수 없기 때문이다. 하지만, 만약 포트 속도가 E1이라면 이때는 트래픽 쉐이핑이 필요하다(실제로 라우터의 시리얼 인터페이스의 디폴트 설정은 E1이다). 쉐이핑을 해주지 않으면 ISP측에서 256Kbps가 넘은 트래픽은 드롭시키거나, DE 비트를 마킹하는 등의 폴리싱을 할 경우, 드롭되는 트래픽이 생기는데 이것이 만약 음성이거나 TCP 트래픽이라면 문제가 된다. 그래서 ISP에서 폴리싱을 하기 전에 미리 허용된 범위에 맞게 조절해 보내기 위해 쉐이핑을 사용한다.

사례 2 : 출력(egress) 블록킹 현상을 예방하기 위한 경우

==================================
▲ (그림 3) 프레임 릴레이 환경에서 출력 블록킹을 적용한 경우
라우터 1 라우터 2 라우터 3 라우터 24
128Kbps 128Kbps 128Kbps 128Kbps
Be를 포함한 최번시의 트래픽
24×128Kbps = 3.0Mbps
1.5Mbps 메인 라우터
======================================

WAN 구간의 멀티 액세스 환경(ATM 또는 프레임 릴레이)에서 동시에 한곳으로 트래픽이 몰릴 경우 혼잡이 발생한다. (그림 3)은 프레임 릴레이 서비스를 이용해 본사와 24개 지사가 연결돼 있는 환경으로, 본사는 1.5Mbps로 구성돼 있고 각 지사들은 128Kbps로 구성돼 있다. 이때 평상시에는 문제가 없지만 각 지사에서 동시에 본사에 연결하는 경우, 본사쪽 트렁크 회선 용량이 부족해 혼잡이 발생할 수 있다. 이런 경우를 출력 블록킹(egress blocking)이라고 표현한다.
그럼 이제부터는 연습문제를 풀어보면서 트래픽 쉐이핑에 대해 좀 더 알아보자.

☞ 연습문제 1

(그림 4)에서 라우터3쪽은 프레임 릴레이 128Kbps로 연결돼 있고, 라우터1쪽은 프레임 릴레이 64Kbps로 구성돼 있다. 다음의 조건을 만족하도록 라우터3에 설정하라.

1. 모든 트래픽을 64kbps로 쉐이핑을 적용하라.
2. Tc는 디폴트값을 적용하라.
3. Be는 사용하지 말아라.
4. 서브인터페이스를 사용해 설정하라
5. 프레임 릴레이 트래픽 쉐이핑을 이용해 설정하라


▲ =====================================
(그림 4) 연습문제 1
클라이언트 1 1.1 스위치1 1.252 2.252 s0/0 1001 1002 라우터1
2.253 s0/0.1 Fa0/0 3.253 스위치2 라우터4 3001 3002 서버1
3.100 라우터3

1. 64Kbps로 쉐이핑하라
2. Tc는 디폴트 값을 적용하라
3. Be는 사용하지 말아라
4. 서브 인터페이스를 사용해라
5. FRTS를 이용해 설정하라
==========================================

☞ 해결
프레임 릴레이 트래픽 쉐이핑 설정 순서는 다음과 같다.

① 프레임 릴레이 트래픽 쉐이핑을 적용할 물리적인 인터페이스에서 'frame-relay traffic-shape' 명령어를 사용해 트래픽 쉐이핑을 적용할 것임을 선언한다.
② 'map-class' 명령어를 이용해 CIR, Bc, Be 값을 세부적으로 설정한다.
③ ②번에서 만든 map-class 이름을 적용하고자 하는 인터페이스에서 frame-relay class 명령어를 이용해 적용한다. 다음은 트래픽 릴레이 트래픽 쉐이핑 설정 과정이다.

interface Serial 0/0
no ip address
encapsulation frame-relay
no fair-queue
clockrate 128000
frame-relay traffic-shaping → ① 프레임 릴레이 트래픽 쉐이핑을 선언하는 명령어
!
interface Serial 0/0.1 point-to-point
ip address 192.168.2.253 255.255.255.0
frame-relay class shape-all-64 → ③ ②에서 만든 map-class를 적용하는 모습
frame-relay interface-dlce 101
!
map-class frame-relay shape-all-64 → ② shape-all-64라는 이름의 map-class를 만듬
frame-relay cir 64000 → CIR를 64000으로 설정
frame-relay bc 8000 → bc를 8000으로 설정

트래픽 폴리싱의 이해
폴리싱은 트래픽의 속도와 대역폭을 제한하는 기술이다. 폴리싱이 쉐이핑과 가장 크게 다른 점은 버퍼링을 사용하지 않고 목표 속도 이상으로 들어오는 트래픽을 드롭시킨다는 것이다. 폴리싱은 네트워크 용량 부족 문제를 해결해주며, 네트워크 자원을 최대한 활용할 수 있게 하는 트래픽 엔지니어링을 지원한다.
폴리싱은 주로 ISP에서 가입자별로 과금에 맞는 대역폭을 할당하는 용도로 많이 사용됐으나 현재는 일반기업에서도 QoS 용도로 많이 사용하고 있다. 폴리싱은 작동 과정에서 지연이 생기지 않으며, 버퍼가 필요하지 않고 큐잉용 메모리를 많이 점유하지도 않는다. 때문에 쉐이핑을 적용할 때 라우터에 부하를 적게 준다. 라우터 구현시 입/출력 양쪽에서 구현이 가능하지만 주로 입력쪽에서 구현을 한다. 그럼 연습문제를 풀어보면서 트래픽 폴리싱에 대해 보다 확실하게 알아보자.

=========================
▲ (그림 5) 연습문제 2
클라이언트1 1.1 스위치1 1.252 라우터1 s0/0 Fa0/0 라우터3
2.253 3.253 스위치2 3.254 라우터4 서버1
3.100 3001 3002
2.252 s0/0 1001 1002

1. 모든 트래픽을 1.5Mbps로 제한하라
2. HTTP 트래픽은 1Mbps로 제한하라
3. FTP 트래픽은 512Kbps로 제한하라
4. P2P 트래픽은 256Kbps로 제한하라
5. Bc, Be 값은 권고안으로 설정하라
6. CAR를 이용해 설정하라
=====================================

☞ 연습문제 2

(그림 5)에서 다음의 조건을 만족하도록 라우터3에 설정하라.

1. 모든 들어오는 트래픽은 1.5Mbps 이하가 되도록 폴리싱을 적용하라.
2. HTTP 트래픽은 1Mbps까지만 허용되도록 폴리싱을 적용하라.
3. FTP 트래픽은 512Kbps까지만 허용되도록 폴리싱을 적용하라.
4. P2P(TCP 4662)트래픽은 256Kbps만 허용되도록 폴리싱을 적용하라.
5. Bc, Be 값들에 대해서는 권고안으로 설정하라.
6. CAR를 이용해 적용하라.

☞ 해결
분류자(ACL)를 이용해 클래스별로 분류한 다음, 미터로 각 클래스별로 설정한 임계값을 관찰하다가 임계값을 넘는 트래픽에 대해서는 폴리싱을 적용한다. 다음은 CAR(Committed Access Rate) 설정 과정이다.

interface Serial 0/0
no ip address
encapsulation frame-relay
load-interval 30
no fair-queue
clockrate 2015232
rate-linit input 1500000 281250 562500 conform-action continue exceed-action drop → 모든 들어오는 트래픽을 1.5Mbps까지만 허용한다.
rate-linit input access-group 101 1000000 187500 375000 conform-action transmit exceed-action drop → HTTP 트래픽은 1Mbps까지만 허용한다.
rate-linit input access-group 102 512000 96000 192000 conform-action transmit exceed-action drop → FTP 트래픽은 512Kbps까지만 허용한다.
rate-linit input access-group 103 256000 48000 96000 conform-action transmit exceed-action drop → TCP 4662 트래픽은 256Kbps까지만 허용한다.
!
Access-list 101 permit tcp any eq www any → HTTP를 분류하는 액세스 리스트
Access-list 101 permit tcp any any eq www
!
Access-list 102 permit tcp any eq ftp any → FTP를 분류하는 액세스 리스트
Access-list 102 permit tcp any any eq ftp
Access-list 102 permit tcp any eq ftp-data any
Access-list 102 permit tcp any any eq ftp-data
!
Access-list 103 permit tcp any eq 4662 any → P2P를 분류하는 액세스 리스트
Access-list 103 permit tcp any any eq 4662


CAR 명령어에 대한 세부 분석은 다음과 같다.

rate-limit input 64000 12000 24000 conform-action transmit exceed-action drop

들어오는 모든 패킷에 대해 64Kbps까지는 허용하고, 초과하는 트래픽은 드롭시킨다.
각 상수값의 의미는 다음과 같다.

CIR = 64000비트
Bc = 12000바이트
Be = 12000바이트(24000 = Bc + Be 값)
Bc의 값은 CIR /8×1.5(Round Trip time) 단위 바이트

여기서 1.5를 곱하는 이유는 TCP 트래픽이 전체의 80%를 상위할 경우, ACK를 받기 위해 기다리는 시간을 계산해 더해주는 의미이다. (표)는 CAR에서 Bc 값에 대한 설정 변경에 따른 UDP와 TCP의 제한결과 차이를 테스트한 내용이다.

▲ 표 ===============================
CAR 설정시 Bc값에 따른 적용 결과

CIR 값 BC 값 BC+BE 값 UTP 트래픽 TCP 트래픽
15,000,000 7,500 15,000 15,108,000bps 395,280bps
15,000,000 100,000 200,000 15,108,000bps 3,192,000bps
15,000,000 200,000 400,000 15,108,000bps 5,872,000bps
15,000,000 2,812,500 5,625,000 15,108,000bps 14,800,000bps

=======================

(표)를 보면 TCP 트래픽은 Bc 값에 의해 적용 결과가 결정되고, CIR/8×1.5를 계산했을 때 제한하고자 했던 값과 가장 비슷하게 적용됨을 알 수 있다.
이번 시간에는 Differ 모델의 컨디셔너(conditioner) 모듈인 트래픽 쉐이핑과 폴리싱에 대하여 알아봤다. 이들을 이용해 실제로 간단한 설정만으로 원하는 대로 대역폭을 조절할 수 있음을 확인할 수 있었으며, 아주 대단한 것 같은 QoS 설정도 별로 어렵지 않음을 알았을 것이다. 다음 시간에는 큐잉 메커니즘에 대해 소개한다.


출처 : http://www.ionthenet.co.kr/


Trackback 0 Comment 0