IP기반 통신서비스의 QoS 보장 방안

1. Introduction

  가. QoS(Quality of Service)의 정의

  나. Network quality issues(QoS Parameters)

      - 대역폭(Bandwidth)

      - 지연(Delay)

      - 지터(Jitter)

      - Reliability, 패킷 손실(Packet Loss)

2. QoS의 필요성

3. Implementation of QoS

  가. Classification

  나. Marking

  다. Queuing

4. Qos 향상 기술

  가. Scheduling

     1) FIFO(First Input First Output Queuing)

     2) 우선순위 Queuing(Priority Queuing

     3) Custom Queuing

     4) 가중공정 Queuing(Weighted Fair Queuing)

     5) CBWFQ(Class Based WFQ)

     6)  LLQ(Low Latency Queue)

   나. Traffic Shaping

      1) Leaky bucket

      2) Token bucket

     3) Dual leaky bucket

5. QoS model(QoS 보장 구조)

  1) Best effort service

  2) Integrated Services

  3) Differentiated Services

6. 통합서비스모델(Integrated Service Model)

7. 차등서비스모델(Differential Service Model)

8. Int-Serv와 Diff-Serv 비교

 

 

 

 

 

 

1. Introduction

  가. QoS(Quality of Service)의 정의

     - 망 사용자 입장: 특정 응용 서비스 사용에 만족하는 정도

     - 망 제공자 입장: 어느 수준 이상의 서비스 품질을 보장하도록 제어가 가능한 자원요소로써 측정이 가능하고 정량적으로 표현할 수 있는 값

     - 서비스를 사용하는 형태, 특성, 그리고 사용자의 요구에 적응할 수 있는 네트워크 서비스의 성능 지표

     - 일반적으로 통신서비스품질이란 트래픽이 통신망에 전달될 때 예측 가능하며 동시에 최소한으로 보장되어야 할 서비스의 요구사항 

  나. Network quality issues(QoS Parameters)

      - 대역폭(Bandwidth): 가장 좁은 Bandwidth가 전송 속도를 의미

      - 지연(Delay)

         ① Processing delay: 라우터가 패킷을 처리하는데 걸리는 시간

         ② Queuing delay: 라우터의 출력쪽에서 패킷이 대기하는 시간

         ③ Serialisation delay: 패킷데이터를 직렬로 배열하는데 걸리는 시간

         ④ Propagation delay: 라우터에서 다른 라우터로 패킷이 전송되는 시간

      - 지터(Jitter): 지연시간이 일정하지 않고 수시로 변하는 현상, 딜레이의 편차

      - Reliability, 패킷 손실(Packet Loss): 라우터의 버퍼 공간이 꽉 차서 패킷 로스가 발생

2. QoS의 필요성

  - IP Best effort의 문제점(데이터 전송을 위하여 최대의 노력을 하지만 확실한 전송의 보장을 하지는 않음. 즉, 데이터의 흐름이 많거나 적거나 간에 시간지연이 없도록 하는 등의 신뢰성을 보장하지 않음)

  - 다양한 멀티미디어 수용에 따라, 기존의 Internet은 가변적인 queuing 지연 및 패킷 손실, 대역폭 부족등의 근본적인 취약점이 나타남

  - QoS 비인식 네트워크: FTP Traffic이 가용 대역폭을 모두 소비하여 비디오 stream 서비스에 장애 발생

 - QoS 인식 네트워크: 비디오 Stream은 필요한 대역폭을 확보할 수 있다

 

3. Implementation of QoS

  가. Classification

     - 어플리케이션 QoS 요구 수준을 정의하고 이를 통해 우선 순위 구분 

      <참고> Traffic requirements              

구분	DATA(FTP)	Real time
		Voice	Video
허용지연시간	Delay 허용	≤150ms	≤150ms
지터	지터 허용	≤30ms	≤30ms
Loss	재전송허용	≤1%	≤1%
데이터 size	저용량/고용량 공존	저용량(60~120Byte)	일반적으로 고용량(코덱/해상도 의존)
스트림 유형	Random하며 가변적	주기적이며 일정	주기적이며 가변
중요도	중~하	상	상
목적	목적지까지 데이터 수신만 완료되면 별다른 문제 없음	패킷이 안정적으로 유지

   나. Marking

     - 애플리케이션별로 우선순위가 설정되었다면 패킷별로 Marking이 수행

   다. Queuing

     - Marking된 패킷이 들어오면 출력 Queue에 쌓아서 패킷을 우선순위별로 전송

                                                                 <출처> http://rikky13.files.wordpress.com/2010/10/qos-archi1.jpg

                 <출처> http://ptgmedia.pearsoncmg.com/images/1587052105/samplechapter/1587052105content.pdf4

4. Qos 향상 기술

  가. Scheduling

     - 입력 포트로 들어온 패킷을 어떠한 방식으로 분류하여 처리할 것인가에 따라서 여러가지 Queuing 기법이 있음

http://www.slideshare.net/thiland/QoS-in-the-Enterprise

     1) FIFO(First Input First Output Queuing)

        - 가장 기본적인 Queuing 구조로 먼저 들어온 패킷이 먼저 나가는 스케줄링 서비스 

        - 장점: 구현이 간단

        - 단점: 클래스의 구분이 없기 때문에 차등화된 서비스를 제공하는 것이 불가능

<출처> http://web.opalsoft.net/qos/default.php?p=whyqos-2421

     2) FQ(Fair Queuing, 공정 큐잉)

         - Round-Robin Scheduling

         - 입력 트래픽의 큐에 대하여 공평하게 서비스되도록 스케줄링 기법을 수행하는 메커니즘

 

http://www.cs.cmu.edu/~istoica/sig98talk/sld006.htm

         - Fair Queue 스케줄링 방식은 서비스 종료 시간을 기준으로 서비스 순서를 결정

          - 극장 매표소의 예

             4개의 영화표 줄이 있다고 생각, 3시에 1번 줄에 10명의 단체 손님이 왔고, 2번 줄에 3시 1분에 한명의 손님이 왔다면… 1번 줄에 온 단체 손님의 서비스 종료시간은 3시 10분이고 2번 줄에 혼자 온 손님의 서비스 종료 시간은 3시 2분이므로 2번 줄의 혼자 온 손님이 먼저 서비스를 받고 그 다음에 1번 줄의 단체 손님들이 서비스를 받게하는 것

     3) 우선순위 Queuing(Priority Queuing)

        - FIFO 큐잉의 단점인 클래스의 구분이 없기 때문에 차등화된 서비스를 제공하지 못하는 문제를 해결하기 위해 만들어짐

        - High, Medium, Normal, Low 4가지 클래스로 나눠서 차등화된 서비스를 제공하는 Queuing 기법

        - 낮은 우선순위 큐에 저장돼 있는 패킷들은 높은 우선순위 큐에 저장돼 있는 패킷들이 모두 서비스 된 이후에 서비스가 됨

           (낮은 우선순위 큐에 저장돼 있는 패킷이 서비스 되는 도중이라도 높은 우선순위 큐에 패킷이 입력되면, 낮은 우선순위 큐는 서비스를 잠시 멈추고 높은 우선순위 큐에 새로 도착한 패킷을 먼저 서비스 해주게 된다)

        - 장점: 간단한 방법(우선순위가 높은 패킷을 우선 서비스)으로 차등화된 서비스를 제공할 수 있다는 것이다. 이 때문에 실시간 애플리케이션의 지원이 가능하다

        - 단점: 높은 우선순위 큐에 패킷이 계속해서 입력될 때, 낮은 우선순위 큐에 저장된 패킷이 서비스가 되지 못하는 아사(starvation) 현상이 발생

<출처> http://web.opalsoft.net/qos/default.php?p=whyqos-2422

     4) Custom Queuing(맞춤 예약 큐잉)

         - CQ의 스케쥴링 방식은 Round-robin 서비스, 돌아 가면서 할당된 자원만큼만 서비스를 받는 방식입니다.

        - 관리자가 각 트래픽에 대하여 가용한 Bandwidth의 percentage를 할당하여 처리

        - Custom Queuing은 모든 트래픽에 대해 최소량의 대역폭만큼 예약토록 허용하므로 각각의 정의된 트래픽 등급에 대해서 일정 정도의 대역폭을 보장함

        - CQ는 사용자 정의하기에 따라서 16 큐까지 생성이 가능

        - 장점: PQ의 문제(우선순위가 높은 트래픽에 의해 우선순위가 낮은 트래픽이 서비스되지 못하는 현상)를 해결하기 위한 queuing 

        - 단점: 급한 서비스도 다른 서비스들과 같이 기다려야 한다는 것, 즉 실시간 애플케이션들에게 Delay가 발생할 수 있다는 것

        - 극장 매표소의 예

            A, B, C, D라는 4개의 줄이 있습니다. A라는 줄은 한번에 2명이 표를 살 수 있고, 나머지 줄은 한번에 한명이 표를 살 수 있다고 합시다. 처음에 A 줄에 있는 2명이 표를 삽니다. 그 후 B 줄에 있는 1명이 표를 삽니다. 그 다음 C 줄에 있는 1 명이 표를 삽니다. 그런 후에 D 줄에 있는 1명이 표를 삽니다. 그 후에 A 줄에 있는 2명이 표를 삽니다. 이렇게 Round-robin 서비스로 예약된 자원을 할당하는 방식을 CQ

<출처>  http://web.opalsoft.net/qos/default.php?p=whyqos-2423

     5) 가중공정 Queuing(Weighted Fair Queuing)

       - 각 traffic마다 IP Precedence(우선권)로 가중치를 부여

       - Weighted Fair Queue 스케줄링 방식은 가중치를 고려하여 bandwidth를 할당

       - 시스코 라우터의 WFQ에서는 기본적으로 256개의 큐를 운영

       - WFQ는 우선순위 큐잉의 단점인 우선순위가 낮은 클래스의 패킷들이 우선순위가 높은 트래픽에 의해 아사되는 문제를 해결하는 동시에 커스텀 큐잉 방식에서 차등화된 서비스를 제공하지 못하는 현상을 해소하기 위해 개발된 것이다.

       - WFQ 스케줄링은 Fair Queue 스케줄링과 어떻게 다르냐하면… 만약에 1번 줄에 3시에 10명의 단체 손님이 왔고, 2번 줄에 3시 1분에 혼자 손님이 왔고… 3번 줄에 3시 2분에 2명 커플 손님이 왔다고 가정합시다. 그런데.. 이 극장은 손님들의 실적에 따라 Premium, Gold, Silver, Bronze 손님으로 분류하고 Premium 손님에게는 서비스종료 시간에 10분을 빼주고, Gold 손님은 서비스종료 시간에 8분을 빼주고, Silver 손님은 5분을 빼주고, Bronze 손님에게는 아무런 혜택을 주지 않는 스케줄링 운영 규칙이 있습니다. 1번 줄의 단체 손님은 Premium 손님이고 2번 줄의 혼자 온 손님은 Bronze 손님이고 3번 줄의 커플은 Gold 손님일때… 서비스 종류 시간은 1번 손님인 경우 3시 정각이 되고, 2번 손님은 3시 2분, 3번 손님은 2시 56분이 됩니다… 따라서 WFQ로 서비스 받는 순서는 3번 커플, 1번 10명 단체 손님, 그리고 2번 손님이 되게 됩니다. WFQ에서 Premium, Gold 등이 되는 기준은 ToS 필드의 IP Precedence를 이용합니다. 

       - CQ와 비교

	CQ	WFQ
Classification	Class-based	Flow-based
traffic	특정 traffic	불특정 traffic
Bandwidth guarantee	guaranteed	no guranteed

<출처> http://web.opalsoft.net/qos/default.php?p=whyqos-2424

For example: Now if there are five traffics on the interface, and their precedence levels are 0, 1, 2, 3, 4, respectively, then the total bandwidth quota will be: the sum of total (precedence of traffic +1), i.e.

1 + 2 + 3 + 4 + 5 = 15

The bandwidth-occupying proportion for each traffic is: (priority + 1)/total quota of bandwidth, i.e. Bandwidth available for each traffic: 1/15, 2/15, 3/15, 4/15, 5/15.

     6) CBWFQ(Class Based WFQ)

       - WFQ의 확장판으로 각 class마다 Bandwidth, weight, Packet limit 정책을 정할 수 있다

     7)  LLQ(Low Latency Queue)

       - CBWFQ와 PQ를 혼합한 Queuing 기법으로 우선 처리해야할 트래픽은 PQ로 처리를 하고 나머지는 CBWFQ로 수행한다

  나. Traffic Shaping

     - 네트워크로 송신되는 Traffic amount와 Traffic rate를 제어하는 방법 

     1) Leaky bucket

       - 데이터율을 평균으로 만들어 버스트 트래픽을 고정데이터율 트래픽으로 조정한다

       - 만약 버킷이 가득차면 패킷을 자동 폐기한다

http://www.ktword.co.kr/abbr_view.php?id=559&m_temp1=2074&nav=2

     2) Token bucket

       - Leaky bucket의 큰 bursty traffic을 조절할 수 없다는 한계를 극복하기 위해서 제안

       - 규정된 최고의 데이터율만큼 버스트 트래픽을 허용

 

http://www.ktword.co.kr/abbr_view.php?id=559&m_temp1=2074&nav=2

    3) Dual leaky bucket

       - Token bucket에서 bucket size가 너무 크면 token bucket scheme은 아주 큰 burst가 network로 가게 하는데 이것은 큰 burst를 처리하지 못하는 network에게는 다루기 힘든 상황이 초래

       - 이 문제를 해결하기 위해 leaky bucket과 token bucket을 combine한 dual leaky bucket 제안

5. QoS model(QoS 보장 구조)

 1) Best effort service

    - 현재 대부분의 네트워크가 이 QoS 모델에 해당

    - 기본적으로 서비스에 대한 품질을 보장하지 않고 최단경로 라우팅을 통해 패킷이 전송

    - 확장성이 뛰어나 별도의 매커니즘이 필요없는 것이 장점이지만 어플리케이션별로 차등화된 서비스를 제공할 수 없는 것 단점

  2) Integrated Services

     - 트래픽별로 차별화된 서비스를 제공하기 위 양단간에 트래픽이 지나가는 모든 경로 RSVP로 자원예약을 수행하 차등화된 서비스가 보장되도 함

     - 가장 완벽한 QoS를 보장할 수 있는 모델

     - 확장성이 뛰어나지 못하고 플로우별 자원예약은 라우터에 과부하를 야기

  3) Differentiated Services

     - 트래픽을 같은 종류의 서비스를 보장 받도록 Class로 구분

     - 코어망에서는 애플리케이션이나 플로우별로 차등서비스를 제공할 필요없이 단순하게 Class별로만 차등서비스를 제 공

     - 확장성이 뛰어나면서 품질 보장이 가능     

6. 통합서비스모델(Integrated Service Model)

  1) 개요

    - 인터넷상의 QoS를 보장하기 위해 IETF에서 정의한 두가지 QoS모델 중의 하나이다(인터넷 QoS 기법)

    - 실시간 응용서비스에 발생되는 패킷의 흐름을 단위로 하여(Flow 기반) QoS 보장형 서비스와 비보장형 서비스 유형으로 구분하여 패킷을 전달함

    - QoS를 보장해 주어야 할 서비스에 대해서는 자원예약 프로토콜인 RSVP(Resource reSerVation Protocol)신호 프로토콜을 이용하여 사전에 연결 수락제어와 자원예약을 수행하여 원하는 품질의 서비스를 제공함

    - 이 모델은 각 패킷흐름에 대한 상태정보를 라우터가 유지해야하기 때문에 네트워크 규모가 커질 때 현실적으로 수용하기에는 문제점이 있음

  2) 구성요소

    - 통합서비스 모델에서는 패킷이 입력드라이버를 통해서 들어오게 되면 분류기를 거쳐 패킷 스케쥴러에 의해 출력됨

    - 이 때 라우터의 구성요소는 다음과 같음

      가. RSVP 프로세서

         - 자원예약 프로토콜을 수행하는 프로세서

         - 이는 종단의 호스트와 라우터 혹은 라우터 사이에서 응용서비스의 흐름에 대한 Flowspec의 생성과 관리를 담당함

      나. 연결수락제어 프로세서

         - 응용서비스의 흐름이 요구하는 자원을 할당할 것인지를 결정하는 알고리즘

         - 각 호스트(혹은 라우터)가 요구한 대역폭을 수용할 것인지를 결정하는 역할 수행

       다. 패킷 스케줄러

         - Queue의 scheduling을 통해서 패킷 스트림의 전송을 관리하는 역할

         - 이것은 OS의 측면에서는 출력 드라이버에 해당하며 링크계층의 프로토콜에 의존함

       라. 분류기(Classifier)

         - 트래픽 제어를 위해서, 특히 패킷 scheduling을 각 입력 패킷들을 등급을 나눠서 분류함

         - 이것은 입력된 패킷의 헤더에 기록된 필드정보에 의해서 수행

    3) 자원예약프로토콜(RSVP)

      - 응용서비스의 flow spec에 따라 네트워크에서 자원을 예약하기 위한 절차를 규정한 프로토콜

      - 비디오와 같은 멀티미디어 애플리케이션의 실시간 전송을 위한 자원 예약 프로토콜

      - IP multicast 서비스를 주대상으로 만들었기 때문에 단방향 모드로 동작하고 수신자 측에서 자원 할당을 수행함(수신자 관점의 대역폭 할당)

      - 동작과정

        ① 송신자는 트래픽 특성을 명시한 Path 메세지를 통해서 자신의 트래픽 특성을 수신자에게 알려줌

        ② Path message는 IP Routing Protocol에 의해 계산된 경로를 따라 전달됨

        ③ Path message가 지나가는 경로의 네트워크 노드는 경로상태를 기록하게 됨

        ④ Path 메세지를 받은 수신자는 송신자가 보내고자 하는 흐름의 특성(Flow spec)을 보고 자신이 원하는 대역폭을 결정하여 RESV(자원요청) 메시지를 통해 전달함

        ⑤ RESV 메세지에는 수신자가 원하는 서비스 요청사항이 실리게 되고 전달된 경로의 반대방향으로 전달됨

        ⑥ 만약 요구를 수락한다면 네트워크 노드는 패킷 스케줄과 패킷구분을 수행하여 패킷을 링크계층으로 전달함

        ⑦ 만약 RESV 요청이 거절되면 거절한 라우터는 오류 메시지를 수신자에게 전송하고 신호과정은 종료

        ⑧ 요청이 수락되면 해당 flow를 위한 링크대역폭과 버퍼공간이 할당되며 관련 flow 상태정보가 라우터에서 유지됨

     4) 서비스 유형

 

구분	특징	예	QoS 보장방법
Guaranteed Service(GS)	-모든 연결에 대해서 일정한 크기의 대역을 제공함 -단대단으로 확실한 지연을 보장하고 패킷손실이 없도록 함	실시간 응용 (음성, 비디오, 오디오)	-단대단 -최대대역예약 -RSVP 사용
Controlled Load Service(CLS)	-정량적 QoS 보장은 하지 않음 -한정된 정도의 패킷 지연이나 손실은 허용함 -네트워크가 혼잡하더라도 최소한의 대역폭은 보장	비실시간 데이터 (데이터 통신)	-단대단 -최소대역보장

     

     5) 통합 서비스 모델의 한계

       - 인터넷 백본망에서는 수많은 패킷 흐름이 존재하므로 이러한 모든 흐름에 대한 상태를 유지하기 위해서는 너무 큰 메모리 공간이 필요함

       - 수많은 흐름에 대해서 자원예약을 위한 제어 메세지를 처리하기 위해 라우터는 매우 빠른 처리 능력을 갖고 있어야 함

       - 패킷헤더의 정보를 통해서 패킷을 구분하기 위해 라우터는 고속의 패킷처리 능력이 필요

       - 자격이 없는 사용자로부터 자원예약을 방지하기 위해서는 보안기능이 요구

7. 차등서비스모델(Differential Service Model)

 1) 개요

   - 망규모가 커져서 복잡성, 확장성 문제가 있는 Int-serv, RSVP 단점을 보완하기 제안

   - 사용자 트래픽을 흐름들의 집합인 클래스 단위로 분류하고, 각 클래스별로 서비스를 차별화

   - 우선 순위에 기반하여 Hop 단위로 처리

   - 확장성이 뛰어난 구조로 대규모 Network에 적용이 가능

   - IPv4의 Header에는 TOS(Type of Service), IPv6에서는 Traffic Class 필드를 이용하여 우선순위를 정할 수 있음

 2) Diff-serv의 망구조

   - Edge Router: 패킷분류화(Classification) 및 트래픽조정(Conditioning), 망으로 유입되는 패킷들의 DS(Differentiated Service) 필드에 특정값 marking

   - Core Router: 패킷에 정보된 표시에 따라 단순히 패킷의 전달 기능만 수행

   - DS domain: 양 Edge간에 QoS를 제공하기 위해 Diff-serv를 사용하는 영역 

   - SLA(Service Level Agreement): Domain간 서비스 수준 협약

 3) Diff-serv의 주요 요소

    가. Packet Classifier

      - 최종적으로 어떤 PHB(Per-Hop Behaviour)를 할당할 것인지 패킷헤더를 분석

    나. DSCP(Differentiated Service Code Point)

      - Diff-serv에서는 모든 IP 헤더에 DSCP를 붙인다

      - IPv4 Header의 TOS 필드, IPv6 헤더의 Traffic class 필드에 8bit 등급 필드

      - 8 비트 중 앞 6비트에 차등 서비스 종류 또는 등급을 표시, 뒤 2비트는 미사용

      - Edge에서는 DSCP값을 정하고, Core에서는 DSCP 값에 따라 패킷을 분류하고 전달

     다. PHB(Per-Hop Behaviour, 홉별 행위)

      - Diff-serv가 구현된 라우터에서 다양한 등급으로 마킹되어진 일련의 들어오는 패킷들에 대해 어떤 일관된 행위를 통해 다음 홉으로 전달되는 방식을 결정하는 것을 말함

 

[출처] IntServ Integrated Service / |작성자 jh0110love

 

 

8. Int-Serv와 Diff-Serv 비교

구분	통합서비스모델	차등서비스모델
서비스 단위	개별적 flow 기반 개별적 flow당 QoS	flow의 집합 기반  Class당 QoS
서비스 범위	종단간	도메인간
패킷분류	모든 라우터	경계라우터
자원예약	모든 라우터에서 연결수락	경계노드에서 감시
확장성	어려움	용이
응용분야	가입자망	기간망

 

    <출처>

http://web.opalsoft.net/qos/default.php?p=cisco101-whyqos

http://www.h3c.com/portal/Products___Solutions/Technology/QoS/Technology_Introduction/200701/195599_57_0.htm

http://cafe.daum.net/networkmania