인터넷의 발전에 따라 사용자가 서비스에 대한 요구가 다양해지는 동시 서비스의 품질에 대한 요구가 높아지고 있다. 특히 멀티미디어 서비스의 도입에 따라 화상 전송과 같은 넓은 대역폭을 요구하는 서비스, 더 나아가 영상, 방송과 같은 높은 대역폭과 실시간 전송을 요구하는 서비스가 많이 도입된다. 많은 사용자가 요구하는 멀티미디어 서비스를 지원하기 위하여 망을 확장하는 동시에 기존 망을 효율적으로 최대 활용하는 방안에 대한 연구가 활발히 진행하고 있다.

기존의 인터넷은 Best Effort 서비스를 만 지원하며 서비스의 품질에 대한 고려는 미약하다. Ipv4에서는 패킷의 헤더 중 여러 종류의 서비스 클래스를 지원할 수 있는 TOS라는 8비트 필드가 규정되어 있지만, 현재까지 많이 사용하지 않는다. 서비스의 품질을 고려하지 않은 경우에 패킷을 빨리 처리할 수 있는 장점이 있지만 데이터 전송의 지연을 보장해 줄 수 없다. 인터넷의 사용자가 요구하는 서비스 품질은 목적에 따라 많이 다를 수 있다. 예를 들어 일반 피씨 통신 사용자는 연결만 요구하는 반면 인터넷 폰, 화상 회의와 같은 사용자는 실시간 데이터의 전송에 대한 보장을 요구한다.
 
인터넷의 표준화 기구인 IETF에서는 현재 인터넷 상에서 QoS를 제공하는 방법에 대하여 표준화 작업을 진행하고 있다. IntServ(Integrated Services) 모델, DiffServ(Differentiated Services) 모델 등은 IETF에서 제안된 대표적인 인터넷 QoS 방안이다. 현재 미국 Internet 2에서 DiffServ 모델에 의하여 Qbone라는 테스트 베드를 구성하고 있으며 멀지 않은 미래에 DiffServ를 지원하는 서비스가 나타날 것이다.
 
1. IntServ 모델

IntServ 모델은 Best Effort Services 외에 두 개의 새로운 서비스 클래스를 추가한다:
l Guaranteed Service: 수용할 수 있는 최대 지연 내 서비스를 제공해 주어야 하는 서비스
l Predictive Service: 통계적으로 수용할 수 있는 지연 내를 제공하여야 할 서비스

이러한 서비스를 추가하기 위하여 라우터에서는 특정한 패킷 Stream 또는 Flow에 대하여 요구된 서비스 품질을 보장하는 데 필요한 자원을 확보하여야 한다. 즉: 하나의 Stream 또는 Flow가 설정하기 전에 경유 된 라우터들에게서 사용자가 요구한 자원을 확보하여야 한다. 확보된 자원은 대역폭, Memory등이 포함되어 있다.

Stream 또는 Flow를 설정하기 위하여 라우터들간의 자원을 확보하기 위한 Signaling 프로토콜이 필요하다. IntServ 모델에서는 Signaling 프로토콜로 RSVP를 사용한다. RSVP를 사용해서 자원을 할당하는 과정은 그림 1 과 같다:

발신자가 연결을 설정 시 요구된 트래픽 특성 정보를 포함하는 PATH 메시지를 수신자측에 보낸다. 중간에서 경과된 라우터들은 PATH 메시지를 받을 때 라우팅 테이블을 이용하여 다음 허브로 전송한다. 수신자가 PATH 메시지를 수신한 후 RESV 메시지를 답장처럼 수신측으로 보내며 자원의 할당을 요청한다. 중간 라우터들은 RESV을 수신한 후 요구된 자원을 제공할 것인지에 따라 RESV 메시지를 허락하거나 거부할 수 있다. RESV 요구를 거부하는 라우터는 에러 메시지를 수신자에 전송하면 연결 설정은 실패로 종료된다. 모든 중간 라우터에서 요구된 연결을 설정이 가능한 경우에는 각 라우터에서 경로 설정 시 요구된 대역폭 및 Memory를 할당하고 연결 상태에 관련된 정보를 저장한다.

IntServ 모델을 지원하기 위하여 각 중간 라우터에서 Flow의 연결 상태에 관련된 정보를 저장하여야 하기 때문에 라우터에서 이런 정보를 저장하는 공간을 요구할 뿐만 아니라 라우터의 처리 Overhead가 커질 수 있다. 인터넷 백본 라우터인 경우 전송 속도가 상당히 높고  연결된 Flow의 개수가 많음으로 IntServ 모델을 지원하기는 힘든다;  IntServ 모델을 지원하기 위하여 라우터마다 RSVP, 연결 관리, 패킷의 스케쥴링 등 의 기능을 지원하여야 하며 라우터에 대한 요구가 높다. 그리고 IntServ 모델을 지원하기 위하여 모든 중가 라우터에서 IntServ모델을 지원하여야 한다. 이러한 요구로 인하여 IntServ는 모든 라우터가 IntServ를 지원하는 망에서만 사용할 수 있다.

2. DiffServ 모델

확장성 문제 때문에 IntServ 모델은 구현과 도입하는 데 문제가 있다. IETF에서 이러한 문제를 해결하기 위하여 DiffServ 모델을 도입한다. DiffServ 모델에서은 다양한 Flow가 많지 않은 서비스 클래스로 분류되며 중간 라우터에서는 이러한 서비스 클래스별로 처리한다. Diffserv 모델에서는 모든 라우터에 대하여 Flow 상태 관리 및 Signaling을 요구하지 않는다.  Diffserv는 IP 해더의 TOS의 부분 중의 6비트를 Qos를 정하는 부분으로 바꿨다. 이러한 방법은 모든 트래픽을  요구하는 Qos에 따라 나누고 이에 따라 트래픽을 Aggregation함으로써 스케쥴링 문제를 해결하였다. RSVP와는 달리 목적지와 원천지간의 어떠한 Qos 요구사항에 대한 정보교환이 일어나지 않게 함으로써 RSVP가 가지고 있던 연결설정 비용에 대한 문제를 제거하였다. Diffserv의 Short-lived Flow는 응답성을 개선하였으며 다른 호스트와의 Quick Discussion을 할 때 발생하던 과부하를 줄였다.

Diffserv에서 사용되는 Traffic Aggregation 모델은 예측성이 떨어진다는 단점이 있다. Reservation, Signaling mechanism, Traffic shaping이 Diffserv에서는 없기 때문에 트래픽의 수준은 매우 동적이다. 이러한 이유 때문에 Diffserv에서 특정한 수준의 서비스를 보장하는 것은 매우 어려운 일이 되었다. 따라서 Diffserv에서는 어떤 수준의 서비스를 보장하기 보다는 각각의 Aggregation에 대한 규칙에 근거하여 상대적으로 서비스가 제공되도록 한다. 즉 어떤 Aggregation은 다른 Aggregation보다 더 데이터를 잘 받거나 못 받도록 하는 것이다.

DiffServ Architecture
Diffserv Architecture에서는 트래픽에 대한 그룹화 과정을 통하여 되어 같은 aggregation으로 들어가기 전에 , 그 aggregation에 속하는 패킷은 반드시 확인이 되어야 한다. 각각의 Aggregation이 서비스를 보장 받는 것을 방지하기 위하여 한명의 사용자가 넣을 수 있는 트랙픽양이 정해져 있다. Diffserv architecture에서 라우터는 반드시 flow 안의 패킷에 대한 정보를 알고 있어야 하며 필요할 때는 그것을 버릴 수 있어야 한다. Diffserv Architecture에서는 네트웍의 edge 부분과 core부분에서의 policing과 classifying의 차이에 대해서도 언급하고 있다. 또 Diffserv Architecture에서는 multiple administrative domain간의 관계에 대해서도 정의하고 있다. 그리고 마지막으로 TOS byte 에서 새롭게 정의된 Diffserv(DS)field로의 변화에 의해 발생하는 backward compatibility(기존의 것과도 잘 맞도록 동작할 수 있도록 하는 것)에 대해서도 언급하고 있다.

Classifying
 Diffserv architecture는 라우터가 위에서 언급되었던 서비스를 지원하기 위해서 필요한 기능을 할 수 있어야 한다. 라우터는 각각의 패킷을 보고 그것이 어디에 속하는 가를 확인할 수 있어야 한다. 원천지와 목적지의 IP address와 목적지와 원천지의 포트번호(TCP, UDP)를 확인하는 것은 그 패킷의 flow를 확인하는 수단을 제공한다. 이와 같이 패킷의 flow를 확인하는 과정을 classification이라고 한다. 특별한 경우의 classification은 패킷의 DS field를 근거로 패킷의 aggregation이 어디에 속하는 가를 확인하는 능력이다. 그리고 이것은 다음 절에서 자세히 나온다.

Metering
패킷의 flow가 분류 된 다음, 그 패킷이 소비하는 자원을 반드시 알아야 한다. Flow가 자원의 소비제한을 초과하는지 아닌지를 판단하기 위해서는 라우터는 일정시간동안의 flow를 검사한다. 그러나 이러한 방법은 충분하지 않다. 왜냐하면 사용자가 보내는 데이터의 양은 매우 유동적이기 때문이다. 사용자가 데이터를 보낼 때 높은 비율을 데이터를 보낼 때 이로인한 flow를 bursty하다고 한다. 따라서 라우터는 flow rate를 측정할 수 있어야 할 뿐만 아니라 traffic burst의 크기도 측정할 수 있어야 한다. 그리고 이것은 사용자에게 요금을 부과하기 위해서도 중요하다. Flow rate와 burst size를 측정하는 것을 metering이라고 한다.

Shaping
Flow가 burst data를 포함하고 있을 때 라우터는 이를 처리하기 위해 여러 가지 방법을 택할 수 있다. 첫번째 방법은 그것이 미리 정의된 또는 협정된 한계를 초과하지 않는다면 보통의 데이터를 처리하듯이 처리하는 것이다. 두 번째 방법은 burst data를 흡수 한 다음 그것의 처리 속도를 느리게 하는 것이다. Burst data의 처리 속도를 조절하는 방법은 flow의 bursty를 완화시키거나 제거시키는 역할을 한다. 세 번째 방법은 만약 burst data가 일정한 한계를 넘으면 그것을 그냥 drop시키는 방법이다. 이 한계는 라우터가 한번에 가질 수 있는 패킷의 수이거나 데이터를 가지고 있을 수 있는 시간의 양이다. Burst 데이터를 처리하거나 트래픽의 속도를 조절하는 것을 Shaping이라고 한다.

Dropping
Flow가 협정된 rate나 한계 값을 넘어설 때 라우터는 flow에서 하나 이상의 패킷을 버리는데 이것을 dropping이라고 한다.
Policing
앞의 Metering, Shaping, Dropping을 종합하여 Policing이라고 한다.

Distinction between edge and core

DiffServ의 특징중의 하나가 AS내에서 edge와 core의 구분이다. IntServ는 classification과 policing을 예약을 만족하는 라우터 내에 있는 모든 패킷에 대하여 행한다. 이와는 달리, DiffServ는 대부분의 policing과 classification의 기능을 AS의 edge 부분에 할당하며 AS의 core 부분에서는 패킷 포워딩을 단순화 시킨다.

 AS의 edge와 core를 구성하는 장치들을 DiffServ domain이라고 한다. 그리고 이는 AS의 subset domain이다. 이렇게 AS domain과 DS domain을 구별하는 것은 첫째 많은 경우에 네트워크의 일부분은 DiffServ를 수용할 수 없기 때문에 이것은 DS domain으로 고려되어서는 안되기 때문이다. 두 번째 이유로는 만약 host가 domain의 정책에 따라 패킷의 DS field를 사용하지 않는다면 이 host또한 DS domain으로 고려되어서는 안되기 때문이다. 그리고 이러한 host는 domain의 정책에 따라 패킷을 분류하고 police하는 edge 라우터가 필요하다.
 패킷의 DS field를 이용하여 traffic aggregation을 확인함으로써 각각의 core router는 모든 패킷의 aggregation에 따라 처리방법을 동일하게 할 수 있다.
 Diffserv의 장점중의 하나가 네트워크의 중심부에 있는 라우터는 패킷의 포워딩을 DS field만 보고 할 수 있다는 것이다. 라우터는 다른 flow로 부터의 많은 패킷을 DS field값이 같다면 동일하게 처리 할 수 있다. 패킷을 DS field값에 따라 그룹화 시킴으로써 DiffServ는 traffic aggregation을 만들 수 있다.
 각각의 aggregation에 대한 한계는 두는 것이 만약 이득을 가져다 준다면 반드시 이것을 해야 한다. 따라서 host가 패킷을 어떤 DS field값을 가지고 보낼 때 , 이 패킷은 edge 라우터에 의해 분류되고 police된다. Edge 라우터는 호스트가 설정한 DS field값에 대한 서비스를 받을 수 있도록 하거나 DS field값에 따른 대역폭이나 burst 한계 값을 초과하지 않도록 해주는 역할을 한다. 사용자가 직접 패킷의 DS field의 값을 설정할 수 있지만 edge 라우터 또한 패킷의 DS field값을 AS의 정책에 근거하여 설정할 수 있다.

 Multiple administrative domain

지금 까지 우리는 single domain에서 DiffServ가 어떻게 패킷을 처리하는가에 대해서 보아왔다. 그럼 이제 multiple domain에서 DiffServ가 어떻게 패킷을 처리하는 가를 알아보자. Multiple domain에서 DiffServ는 이웃한 domain에 대해서는 앞에서 호스트에 대해서 처리하는 방법과 똑 같은 방법으로 처리한다. 그리고 이것은 그림 3에 나와있다.
패킷이 호스트 A에서 DS field값의 설정 없이 올 때 DiffServ를 제공하는 Domain Y의 edge 라우터는 직접 혹은 정책에 근거하여 그 패킷을 어떤 aggregation에 넣을 것이다. 이와 같이 DiffServ를 제공하지 않는 Domain X로부터 온 패킷은 DiffServ를 제공하는 Domain Y의 edge 라우터에 도착하게 될 것이다. 그러면 그 edge 라우터는 그 패킷의 DS field에다 정책에 근거하여 값을 할당할 것이다.
패킷이 만약 DiffServ를 알고있는 호스트로부터 오면, 그 패킷은 그 호스트의 profile과 연관하여 police 될 것이다. 이와 같이, 만약 패킷이 DiffServ를 제공하는 Domain Z로부터 오면 그 패킷은 Z domain의 profile에 근거하여 police 될 것이다. 만약 그 트래픽이 profile안에 있다면 그 패킷은 Z domain의 core 부분으로 포워딩 될 것이며, 만약 패킷이 profile을 초과한다면(한계이상을 요구) edge 라우터는 DS field값을 다시 할당하거나 그 패킷을 drop시킬 것이다. 또 다른 방법으로는 호스트 B나 Domain Z로 부터의 패킷을 DS field값의 변경 없이 그냥 통과 시키고 약간의 요금을 부과하는 방법이 있다. 이것은 보통 호스트(B)나 이웃 한 도메인(Z)이 목적지 도메인(Y)보다 중요한 flow와 중요하지 않은 flow를 훨씬 더 잘 구별할 수 있기 때문이다.

Service contracts

지금 부터는 패킷을 처리하는 규칙이나 정책이 어떻게 이루어지는지에 대해서 알아보자.
규칙이나 정책은 패킷을 보내는 도메인과 받는 도메인과의 명백한 계약이다. 이러한 계약은 오늘날 ISP와 ISP, ISP와 기업, 전화사업자간에 여러 가지 트래픽 형태에 대하여 요금을 부과하는 방법으로 존재한다. 그리고 이러한 계약은 보내는 자가 계약을 어기거나 받는자가 계약을 어기면 거기에 상당 하는 페널티는 준다. 이러한 형태의 계약을 service level aggrement(SLA)라고 한다.

TOS byte

전에도 언급 했듯이 DS field는 IP header의 TOS byte에 쓰이는 부분이다. 원래의 TOS bytes는 다음과 같은 기능을 제공하기 위해 만들어진 것이다.
1. 라우팅 프로토콜 패킷과 네트워크 메니지먼트 패킷은 라우터를 메니지하는데 쓰였다.
이러한 패킷이 네트워크 congestion에 상관없이 목적지에 도달할 수 있도록 하는 것은 중요하다.  TOS의 precedence field는 이러한 패킷들에게 우선순위(higher priority)를 주기위해 사용되었다.
2. TOS의 다른 부분인 TOS bits는 트래픽 타입 정보를 라우터에 제공하는 기능을 하였다. 이로 인해 라우터가 같은 홉 수를 가지지만 미디어 타입이 다른 경로가 있을 때 보다 효율적인 경로를 택할 수 있도록 해주었다.
 현재 존재하는 표준안 에는,  TOS 의 precedence field가 확실하게 정의되어 있지않다. 그래서 광범위한 해석과 구현이 이루어 졌다. 따라서 TOS byte는 ene-to-end 서비스를 제공하기에는 적당하지가 않다. 그래서 TOS byte는 표준안에서 사라지게 될 것이다. DiffServ Working Group은 이 byte에 대해 새롭게 정의할 것이며 이것을 DS field로 제명 할 것이다.
 

The DS field layout

위의 그림은 DS field의 포멧을 보인다. DS field에서 6-bit은 differentiated services code point(DSCP)로 되어있다. 이 부분에 할당되는 aggregation identifier를  code points라고 한다. 이 6-bit중 일부분은 end-to-end behavior를 위해 사용되며, 그리고 또 다른 부분은 domain-specific한 서비스를 제공하거나 또는 새로운 것에 대한 실험을 하기 위해 남겨져 있다.
 그리고 DS field의 나머지 2-bit는 현재는 사용되지 않으며 앞으로의 사용을 위해 남겨져 있다.

Backward Compatibility

현재 몇몇 라우터 벤더들은 최소한의 Qos를 지원하기위해 TOS byte의 precedence field를 사용한다. DiffServ를 지원할 수 있는 도메인 안에 non-DiffServ 도메인을 만드는 것은 매우 비 실용적이다. 그래서 DiffServ는 반드시 DiffServ를 지원하지 않는 기존의 라우터와 같이 존재하면서 이를 처리 할 수 있어야 한다. 이것을 하기위해서는 TOS byte의 precedence field의 값이 DSCP field에서는 지원이 되어야 한다. Precedence field에 3-bit가 할당되어 있기 때문에 DiffServ는 8개의 precedence 값에 대한 각각의 것을 지원을 해야 한다.

How to Support Service

라우터에서는 패킷에 대한 몇 가지 처리가 이루어진다. 패킷은 포워딩 될 수 있으며 또는 drop될 수 있으며 또는 지연 될 수도 있고 metering( 요금청구와 서비스 계약을 위해)될 수도 있다. 그러나 이러한 것들은 다양한 레벨의 정밀성과 함께 결합되어 지원될 수 있다.  DiffServ의 목적은 라우터가 패킷에 대해 행하는 기능들에 대한 결합이 표준화 되도록 하는 것이다. Standardized behavior는 위의 것들이 어떻게 동작을 하고 또 이것들이 서로간에 어떻게 상호작용을 하는가를 나타낸다.
 일단 한번 표준화 되면 라우터 벤더들은 표준화된 행동을 만족 하는 한 자기가 원하는 방법으로 위의 기능들을 구현 할 수 있다. 표준화된 기능은 interoperability와 implementation diversity를 제공한다.
 그러면 이렇게 라우터가 표준화된 똑 같은 기능을 제공하는데 각각의 도메인에서는 어떻게 자기 도메인만의 독특한 서비스를 제공할 수 있을까? 우선 각각의 도메인은 위의 기능들을 다른 방법으로 조합함으로써 다른 서비스를 제공할 수 있을 것이다. 두 번째는 각각의 도메인에서 각각의 aggregation에 들어갈 수 있는 트래픽 양을 다르게 함으로써 정책을 달리 할 수 있을 것이다. 그리고 마지막으로 요금청구는 기존의 fixed service charge의 형태에서 usage-based charges, distance-based charges의 형태로 바뀔 것이다.

DiffServ Behaviors and Services

특별한 Qos의 서비스류나 차원에 초점을 둔 다양한 표준화 제안이 제안 되어왔다. 이번 절에서는 이것들에 대해서 다루도록 하겠다

Best effort

현재 인터넷상에서 존재하는 모든 패킷에 대한 처리에 대해 적용할 수 있도록 정의된 서비스이다.  이로 인해 만약 DiffServ가 널리 구현되더라도 모든 패킷에 대해 특정한 기능을 요구하도록 할 필요가 없을 것이다. 왜냐하면 특정한 서비스 요구가 없는 패킷은 best effort서비스로 처리하면 되기 때문이다.

Expedited Forwarding

네트워크상에서 congestion이 발생했을 때 특정한 패킷의 지연을 최소화 하기 위해서 DSCP field에 이 패킷이  가장 좋은 링크를 통해 전달될 수 있도록 그 값을 설정해 주도록 하는 것이다. 게다가 EF(Expedited Forwarding)은 jitter가 다른 패킷에 비해 최소화 되는 기능도 제공한다. EF는 delay-sensitive한 application이 congestion 상태에 있는 네트워크에서도 잘 동작할 수 있도록 해준다.

Drop precedence

또 다른 형태의 기능은 네트워크가 congestion 상황에 있을 때 패킷의 drop에 대한 우선순위를 주는 것이다. 이러한 기능을 제공하기 위해서 제안된 메커니즘이 AF( Assured Forwarding)이다. 이것은 호스트에게 code point중 첫번째 비트만이 설정된 패킷에 대해서는 최소한의 대역폭을 제공한다. 그리고 호스트가 이 최소한의 대역폭을 초과하는 부가적인 패킷을 보낼 때에는  두 번째 code point를 설정하고 이를 보낼 수 있다. 만약 패킷이 이 최소한의 대역폭 안에 있을 때 이것을 in profile이라고 하며 만약 초과하면 out of profile이라고 한다. 만약 네트워크에 congestion이 발생했을 때 “out of profile”이면서 두 번째 codepoint가 설정된 패킷이 최우선적으로 drop된다. 또 다른 방법으로는 호스트가 사용하는 drop precedence에 따라 그 요금을 달리 하는 것이다. 즉 적은 비용을 내는 사용자의 패킷은 그렇지 않은 패킷보다 우선적으로 drop  되도록 하는 것이다.

Accounting and billing

DiffServ가 나오기 전에는 요금을 부과하는 것이 모두 best-effort서비스만을 지원 받기 때문에 매우 간단하였다. 그러나 DiffServ가 나오면서 여러 가지 서비스에 대해 여러 가지 요금을 과하는 것이 가능하게 되었다.
 인터넷은 client/server model에 근거하여 이루어져 있다. 이러한 구조의 인터넷에서는 패킷을 보내는 사람이 요금을 지불할 것인지 아니면 받는 사람이 지불할 것인지를 패킷에 반드시 표시하여야 한다.

Traffic isolation

링크를 여러 개의 부분으로 나누어 여러 개의 트래픽 계층을 만드는 것이 많이 제안되었다. 이것은 한 계층의 트래픽이 다른 계층의 트래픽에 영향을 주지 않는다. 트래픽을 여러 개의 계층으로 나누어 각각의 계층의 트래픽을 고립시키는 것은 트래픽 계층간의 scheduling 을 잘해주면 트래픽간의 경쟁을 최소화 할 수 있는 결과를 가져온다. 그러나 만약 도메인이 다르면 패킷을 분류하는  판단기준이 다르므로 end-to-end서비스에서는 이러한 트래픽의 고립화에 대한 기능을 제대로 수행하기가 어렵다.
그러나 일반적으로 라우터는 몇 개만의 트래픽 계층을 지원한다.(10보다 )

Proportional Share

Lucent사에서는 논리적인 대역폭을 각각의 호스트나 호스트 그룹에 할당하자는 제안을 하였다. 이것은 각각의 호스트나 호스트 그룹에게 할당되는 대역폭의 퍼센티지를 개인적인 할당을 한 다음 그것을 현재 흐르고 있는 flow에 할당된 총 대역폭으로 나누어서 결정하는 것이다.

Congestion notification

네트워크에 congestion이 발생했을 때 패킷을 drop시키는 것만으로는 congestion 상황을 해결하기에는 불충분하다. 대신에 패킷을 보낸 사람에게 다시 패킷을 congestion 경고와 함께 돌려보내는 feedback 메커니즘을 추가하였다. 이것은 보내는 자가 자신의 패킷의 손실 없이 대역폭을 줄 일수 있으며 그래서 네트워크의 효율성을 최대화 할 수 있다.
또 다른 방법으로는 패킷의 precedence value를 congestion의 레벨을 나타내는 것으로 재사용 할 수 있는 패킷을 사용하는 것이다. 각각의 라우터는 패킷의 DSCP field에서 precedence value를 본다. 그리고 패킷을 보낸 호스트에게 drop이 되지않는 packet의 precedence값 중 가장 큰 값을 알려준다. 그러면 패킷을 보내는 호스트는 앞에서 보고 받은 precedence 값보다 작은 패킷만을 보냄으로써 대역폭을 줄이는 것이다.

How IntServ Can Work with DiffServ

앞에서도 언급하였던 확장성의 문제 때문에 IntServ는 WAN상에서는 거의 구현 되지 않을 것이다. 그러나 IntServ는 enterprise networks에서 구현 될 수 있다. 그리고 WAN상에서는 DiffServ가 구현 될 것이다. 그러면 WAN은 DiffServ이고 LAN은 DiffServ와 IntServ가 혼합된 형태의 망에서 패킷을 보내는 사람과 받는 사람사이의 경로에서 WAN과 LAN의 자원을  사용하여야 한다면 어떻게 Qos 가 제공될 수 있을까?

 만약 호스트가 DiffServ를 사용한다면 이것을 다루기는 매우 쉽다. 그러나 만약 호스트가 IntServ를 사용한다면 문제가 있다. 그리고 DiffServ에서도 이 문제 해결을 위한 제안을 하였다. 그것은 LAN(1)에서는 대역폭을 예약하기 위하여 RSVP를 사용하고 아래 그림에서 L/W1로 표시된 LAN과 WAN의  경계에서는 WAN 라우터가 패킷에 있는 RSVP 정보를 무시할 수 있도록 RSVP PATH와 RESV 메시지를 수정하는 것이다. 그리고 패킷이 LAN(2)에 도착하면은 패킷은 원래의 형태로 복구된다. 그리고 PATH와 RESV메시지는 자원을 계속해서 예약한다. 과정은 요약하면 다음과 같다. 패킷이  RSVP를 사용하여 LAN(1)을 통하여 LAN/WAN edge(L/W1)에 도착한다.  그러면 이 라우터는 예약된 자원을 만족할 수 있는 code point를 패킷에 할당한다. 그리고 이것이 LAN/WAN edge(L/W2)에 도달하면 이 라우터는 패킷의 RSVP의 형태로 복구 시키면 이 패킷은 LAN(2)에서 RSVP의 표준에 따라 서비스를 받게 된다.

Status and Future

IETF의 working group에서는 세 개의 표준을 완성시켰다. 그 중 하나는 새로운 DS field에 대한 정의하였다. 그리고 다른 하나는 DiffServ의 구조를 정의하였다. 그리고 마지막으로 아직 정식으로 발표되지는 않았지만, DiffServ가 어떻게 구현되고 사용될 수 있는지에 대해 정의 하였다. 위의 기능이 정의된 다음, ATM, frame relay, Ethernet과 같은 다양한 2계층의 미디어들과 어떻게 이 기능들을 mapping시킬 것인가가 이슈가 될 것이다. Ethernet은 다양한 레벨의 delay를 지원하나 frame relay는 그렇지 않다. ATM과 frame relay는 precedence를 지원하나 Ethernet은 그렇지 않다. 각각의 DiffServ의 기능은 각각의2계층 미디어와 어떻게 mapping이 되는지를 알아야 할 것이다. 게다가, DiffServ는 point-to-point 트래픽만을 고려하였다. DiffServ를 통해 어떻게 multicast를 지원할 것인지는 아직도 working group에서 고려중이다.
 미래에는 DiffServ가 MPLS와 결합하여 WAN상에서 트래픽에 Qos를 지원하는 수단이 될 것이라는 것을 예상할 수 있다. LAN에서는 IntServ와 DiffServ모두가 사용될 것이다. 어플리케이션은 자신의 맞는 서비스 모델을 선택할 것이다.
 Campus Network나 WAN에서의 DiffServ나 IntServ의 도입은 다양한 레벨의 Qos에 접근을 위한 사용자와 서버와 조직을 분류하는 복잡한 메커니즘을 필요로 하게 되었다. 일반적으로 네트워크에 대한 접근이 복잡해지고 동적으로 될수록, policy-enabled 네트워크는 Qos를 각각의 네트워크 장치에 맵핑 시키는데 그 역할이 매우 증대 될 것이다.

출처 : Tong - baboda4u님의 Network 자료통

이번호에는 DiffServ 모델에 대한 개요와 분류자, 미터, 마커에 대해 이론적인 접근과 더불어 실무에서 QoS를 설정할 때 분류자와 미터가 어떤식으로 구현되는지 살펴볼 것이다. 앞으로 DiffServ 모델의 모듈별로 QoS 설정을 추가해 엔드 투 엔드 QoS를 완성해 나가는 방향으로 강좌를 진행할 것이다.

기본적으로 인터넷은 네트워크 트래픽을 하나의 클래스(Class)로 취급해 동일한 정책을 적용하는 베스트 에포트(Best-effort) 방법을 채택하고 있다. 물론, 초기에 인터넷이 구현됐을 때는 네트워크 트래픽을 하나의 클래스로 처리해도 큰 문제가 되지 않았다. 하지만 현재의 인터넷 상황은 새로운 유형의 트래픽(화상전화, 방송, VoIP 등)이 생겨남에 따라 기존의 베스트 에포트 서비스만으로는 QoS(Quality of Service)를 제공하지 못하게 됐다.
이를 보완하기 위한 방법으로 다양한 QoS 프로토콜이나 표준이 만들어졌는데, 대표적인 QoS 관련 프로토콜과 표준에는 IntServ, DiffServ, RSVP, MPLS, IEEE 802.1p/Q 등이 있다. 이들 표준은 그 자체로서 QoS 제공 기능을 갖는 것이 아니며, 다양한 QoS 구현 기술과 이들을 적용하는 방식 혹은 정책들로 이뤄져 있다.
이번호에 소개할 DiffServ(Differentiated Service) 모델은 QoS를 보장하기 위한 방법 중 하나로, 인트서브(IntServ : Integrated Service) 모델이 확장성이 취약한 것을 극복하기 위해 ISP(Internet Service Provider)들에 의해 제안된 모델이다.
기존의 인트서브(IntServ)는 트래픽 흐름(flow)에 대해 미리 필요한 시간에, 필요한 만큼의 대역폭을 할당받는 방식으로, 그 흐름들에 대해 100% 보장된(guaranteed) 서비스와 컨트롤된 로드(controlled load) 서비스를 제공받았다. 이에 비해 DiffServ는 패킷들을 비슷한 성질을 가진 클래스로 구분해서 중요한 클래스에 대해서는 가중치를 둬 서비스를 제공하는 방법이다. DiffServ는 100% 보장된 서비스를 제공하지는 못하지만, 구현이 쉽고 확장성이 뛰어나기 때문에 현재 인터넷에서 가장 많이 채택하는 방식이다. 이제부터 DiffServ 모델에 대해 보다 자세히 알아보자.

중요한 클래스에 가중치 두는 DiffServ
(그림 1)을 보면 DiffServ가 어떤 방법으로 구현되는지 알 수 있다. 먼저 분류자(Classifier)로 들어오는 트래픽을 다양한 기준에 따라 여러 개의 클래스로 구분하는데, 여기서는 도착한 패킷들이 어떤 클래스 큐에 저장이 될지를 결정한다. 좀 더 구체적으로 이야기를 하면, 입력된 트래픽은 다양한 분류기준(extended ACL)에 의해 플로우 단위로 구분되며, 이와 동시에 플로우가 속하게 될 트래픽 클래스가 결정된다.



트래픽 클래스가 결정된다는 것은, 입력된 트래픽이 실제로 저장될 큐와 서비스(스케줄링)되는 방식이 결정된다는 것을 의미한다. 분류자를 통과한 패킷들은 각 트래픽 플로우에 할당된 미터(meter)에 의해 특성을 측정받는다. 측정된 결과는 사전에 약속한 QoS 트래픽 특성과 비교되며, 그 결과에 따라 마커(marker)에 의해 몇 가지 우선순위로 마킹(marking) 된다.
마킹된 패킷들은 컨디셔너(conditioner)를 거치면서 사전에 약속된 트래픽의 대역폭 특성에 맞도록 조절된다. 컨디셔너는 지연(delay)을 이용해 대역폭을 조절하는 세이핑(Shaping)과 드로퍼(deopper)를 이용해 대역폭을 조절하는 폴리싱(policing)으로 구성돼 있다.
트래픽 컨디셔너는 경우에 따라서 흐름제어(flow control)도 처리할 수 있다. 컨디셔너를 통과한 패킷들은 큐잉(queuing)을 거치며 분류자에서 결정된 자신의 클래스에 맞는 큐에 저장된다. 큐에 저장된 패킷들은 스케줄링 과정을 통해 출력 링크로 보내진다.

분류자의 중요한 역할
분류자는 DiffServ 모델의 처음 과정으로, 들어오는 패킷을 일정한 기준에 따라 여러 개의 클래스로 구분하는 기능을 한다. 하지만 여러 종류로 나눠 복잡하게 처리하려는 의도가 아니라, 여러 종류의 패킷을 제한된 몇 개의 클래스로 분류한다는 개념으로 이해해야 한다.
분류자의 목적은 동일하거나 유사한 특성을 갖는 패킷들을 함께 처리함으로써 QoS의 구조를 단순화하자는데 있다. 즉, 다양한 QoS 특성을 갖는 트래픽들을 각각 처리한다면, 수없이 많은 패킷 처리 기준이 있어야 된다. 이것은 현실적으로 불가능하며, 가능하다 하더라도 노드에 커다란 부하를 주는 원인이 된다. 따라서 제한된 클래스로 패킷을 나눠 처리하는 것이다.
실무에서는 적게는 2개에서, 많게는 8개까지의 클래스를 사용하고 있으며, 가장 일반적인 경우가 4개의 클래스를 사용하는 것이다. 큐잉에 관한 연구를 살펴보면, 큐나 클래스의 개수가 1에서 2로 증가할 때 복잡성에 비해 성능 향상 효과가 가장 크다. 2개에서 4개로 증가할 때도 만족할만한 수준이지만, 4개에서 8개 또는 그 이상으로 증가할 때는 복잡성은 배로 증가하지만 성능의 향상효과는 수% 이내로 증가한다. 때문에 클래스의 수를 무작정 늘리는 것이 좋은 것만은 아니다. 따라서 이번 연재에서도 3개 내지 4개의 클래스를 주로 사용할 것이다.
앞에서도 언급했지만 분류자는 DiffServ 모델에서 가장 중요한 부분이다. 그것은 분류자에서 패킷을 구분해주기 때문이다. 뒤에서 여러 QoS 구현 방법들에 대해 설명을 하겠지만, 그런 모든 방법들도 분류자에서 패킷을 클래스로 나눠줘야지 비로소 적용할 수 있다. 실제 업무에서는 분류자를 구현하기 위해서 ACL(Access-Control Lists)을 많이 사용한다.
예를 들어 ACL 101에 해당하는 패킷은 첫번째 큐(Queue)로 보내고, ACL 102에 해당하는 패킷은 두번째 큐로 보내고자 할 때, 큐잉 작업이 이뤄지기 위해서는 분류자 작업이 선행돼야 한다. 트래픽 세이핑이나 폴리싱도 마찬가지이다.
확장된 액세스 리스트를 사용하면 필드값을 하나 또는 그 이상을 조합해서 세부적인 분류도 가능하다. 클래스를 나누는데 쓰이는 또 다른 방법은 PBR(Policy-Based Routing)을 이용하는 것이다. 이 방법은 ACL을 이용하는 것보다 좀 더 유연한 명령으로, 'match'와 'set'을 이용해 분류자 적용 후, 마킹 모듈까지 적용할 수 있는 명령어다. 이는 (그림 2)와 같은 방식으로 구현될 수 있다.

미터와 마커의 이해
미터(Meter)는 장비로 입력돼 분류된 트래픽 플로우를 측정한다. 일반적으로 트래픽 플로우의 입력 속도를 이용해 대역폭을 측정하거나 버스트 정도를 측정하는데, 미터는 미리 약속된 트래픽 프로파일과 입력된 트래픽의 프로파일을 비교함으로써 초과여부를 결정한다. 그 결과에 따라 마커(Marker)는 적절한 마킹(Marking) 작업을 수행한다.
일반적으로 ▲미리 약속된 트래픽 프로파일을 만족하는 경우 ▲일정한 범위 내에서 초과하는 경우 ▲일정한 범위를 넘어서 초과하는 경우의 세가지로 구분한다. DiffServ 모델에서는 그린(Green), 옐로우(Yellow), 레드(Red)로 표시하지만, 시스코는 Conform, exceed, violate이라는 용어를 사용해 나타낸다.



(그림 3)은 DiffServ 모델에서 가장 많이 사용하고 있는 sr-TCM(single-rate Three-Color Marker)에 대한 동작 방식을 설명한 것으로, 듀얼 토큰 바스킷 구조를 사용하고 있다.
토큰이 떨어지는 속도로는 CIR(Committed Information Rate)를 사용하며, (그림 3)에서 입력된 패킷의 크기 P가 토큰 카운터 Tc보다 작으면 그린 패킷으로 마크하고, Tc보다 크지만 Te보다 적은 경우 옐로우 패킷으로 마크한다. Te보다도 큰 경우에는 레드 패킷으로 마크된다. 토큰 바스킷에 대한 추가 설명은 다음 시간에 소개할 트래픽 세이핑과 폴리싱 부분에서 자세하게 설명할 것이다.

마킹에 필요한 IP 우선권과 TOS 필드
그럼 이제부터 실제로 마킹하는데 사용되는 요소들에 대해 알아보자. IP 우선권(precedence)은 DiffServ 모델이 사용되기 이전에 QoS를 보장하기 위해 사용한 필드로, IP 헤더에 ToS(Type of Service) 필드의 상위 3비트를 사용해 표시한다. 숫자가 클수록 우선순위가 높음을 표시한다.
0의 값은 우선순위가 제일 낮은 BE(Best-Effort)를 뜻하며, 6과 7은 인터넷용과 네트워크용으로 예약돼 있어 실제로 우선권의 값 중에서 가장 우선순위가 높은 것은 5(Critical)이다.



(그림 4)는 IP 데이터그램(datagram)을 나타낸 것으로, ToS의 8비트 중에 상위 3비트가 IP 우선권(precedence)으로 표기되는 모습을 잘 나타낸다. 우선권 뒤의 4비트는 ToS 필드이며, 각 해당 비트마다 신뢰성, 처리량, 지연, 코스트 등을 나타낸다. 해당 필드에 마킹(1로 표기)되면 높은 신뢰성, 높은 처리량, 낮은 지연, 적은 코스트를 뜻하며, 해당 패킷의 중요도를 나타내는데 사용된다.

DiffServ 모델의 핵심 'DSCP 필드'
이름에서도 알 수 있듯이 DSCP(Differentiated Service Code Point) 필드는 DiffServ 모델의 핵심이라고 할 수 있다. DiffServ 모델이 제안되기 이전에 사용됐던 우선권을 포함하면서 확장한 개념이다. 이는 기존 IP 체계에 큰 변화없이 헤더값에서 우선권과 ToS 필드가 사용하던 비트를 대체하는 방법으로, 기존의 우선권이 트래픽 플로우에 대해 세부적인 컨트롤을 할 수 없었던 한계를 극복했다.



DiffServ 모델에서는 IP 헤더의 ToS 필드에서 상위 6비트를 이용해 DSCP 필드 값으로 사용, 패킷들을 최대 64개의 클래스로 구분했다. 그러나 64개의 DSCP 필드값 중에서 제일 마지막 6번째 비트값이 1인 필드는 실험용이거나 사설용으로 예약돼 있다. 때문에 실제로는 32개의 표준 PHB(Per-Hop Behavior)가 클래스로 사용될 수 있다
DSCP의 종류는 다음과 같이 4가지로 나눌 수 있다.

·디폴트 PHB(Best-effort)
·CS(Class Selector) PHB (IP Precedence)
·AF(Assured Forwarding) PHB
·EF(Expedited Forwarding) PHB

이중에서 디폴트 PHB(베스트 에포트)는 가장 낮은 우선순위를 뜻하며, CS(Class Selector) PHB는 클래스를 결정하는 상위 3비트만 표시해 기존의 우선권 값과 서로 호환해서 사용할 수 있다.
AF(Assured Forwarding) PHB는 4개의 클래스가 존재하며, 각 클래스에 대해 3개의 서로 다른 드롭 우선권을 갖게 된다. 드롭 우선권(drop precedence)이란 DSCP 코드값 중 클래스를 결정하는 상위 3비트를 제외한 4, 5번째 비트가 드롭될 가능성의 고/저를 표시하는 것으로, 프레임 릴레이의 DE 비트와 성격이 비슷하지만 더 세밀하게 설정할 수 있다.



EF(Expedited Forwarding) PHB는 DSCP 코드값 중에서 우선순위가 가장 높은 클래스라는 의미이다. EF는 2진수 값으로‘101110'으로 표현하며, DSCP 값을 인식못하는 장비(DiffServ 모델에 적용되지 않는 장비)에서도 IP 우선권(precedence) 값으로 인식(5 → Critical)돼 최고의 서비스를 보장받는다.
그 외에 마킹용으로 사용하는 다른 필드에는 ▲내부적으로만 사용하는 QoS 그룹 ▲프레임 릴레이 상에서 마킹해 혼잡이 생겼을 때 우선적으로 드롭되게 설정하는 DE(Discard Eligible) 비트 ▲ATM에서 사용하는 CLP(cell Loss Priority) 비트 ▲IEEE 802.1Q나 ISL 에서 구현하는 CoS 필드 ▲MPLS에서 QoS 마킹용으로 사용하는 실험적인(experimental) 비트 등이 있다.

실전! 분류자와 마킹 따라하기
지금까지 분류자와 마킹에 대해 자세히 알아봤다. 이제부터는 사례를 통해 이들이 실제 상황에서 어떻게 사용되는지 설명하도록 한다.



(그림 7)은 네트워크 상에 VoIP 트래픽과 일반 데이터 트래픽이 혼합돼 흐르고 있는 환경이다. 처음하는 실전 훈련이니 가장 쉽게 VoIP 트래픽과 일반 데이터 트래픽을 클래스로 나누고, DSCP 값을 이용해 마킹하는 실습을 해보자. 연습문제 1은 (그림 7)과 같은 환경에서 수행해야 하는 조건들이다.

☞ 연습문제 1
1. VoIP 트래픽은 DSCP 값을 EF(Experdited Forwarding) PHB로 마킹하라
2. 일반 데이터 트래픽은 DSCP 값을 디폴트(베스트-에포트) PHB로 마킹하라
3. CB(Class-Based) 마킹을 사용해 작성하라
4. 라우터 3에 설정하고, 설정한 내용을 확인하라

☞ 해결
연습문제 1에 대한 CB(Class-Based) 마킹 설정은 다음과 같다.

R3# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#ip cef
R3(config)#class-map voip-rtp → 클래스 맵의 이름을 voip-rtp라고 정의
R3(config-cmap)#match ip rtp 16384 16383 → VoIP 트래픽을 구분하는 과정
R3(config-cmap)#policy-map voip-and-be → 폴리시 맵의 이름을 voip-and-be라고 정의
R3(config-pmap)#class voip-rtp → voip-rtp라는 클래스 맵을 적용
R3(config-pmap-c)#set ip DSCP EF → VoIP 트래픽에 대해 DSCP 값을 EF로 설정
R3(config-pmap-c)#class class-default → 나머지 트래픽들을 표시함
R3(config-pmap-c)#set ip dscp default → 나머지 트래픽들에 대해 DSCP 값을 디폴트로 설정
R3(config-pmap-c)#interface e 0/0
R3(config-if)#service-policy input voip-and-be → 해당 인터페이스에 폴리시 맵을 적용
R3(config-if)#end
R3#

CB(Class-Based) 마킹 설정 확인 내용은 다음과 같다.

R3#show running-config
Building configuretion…
!Portions removed to save space…
ip cef
!
class-map match-all voip-rtp
match ip rtp 16384 16383
!
policy-map voip-and-be
class voip-rtp
set ip dscp 46
class class-default
set ip dscp 0
!
interface Fastethernet0/0
ip address 192.168.3.253 255.255.255.0
service-policy input voip-and-be

생각보다 설정은 그리 어렵지 않다. 결국 QoS라는 것이 생각만큼 그렇게 거창한 것이 아니라는 것을 느꼈을 것이다. 이번에는 동일한 환경이지만 (그림 8)처럼 중급 정도의 설정을 할 것이다. 어렵게 생각하지 말고 차근히 따라하면 분류자와 마킹을 확실하게 익힐 수 있을 것이다.



☞ 연습문제 2
1. VoIP 트래픽은 우선권(precedence) 값을 5로 마킹하라
2. 서버 1에서 클라이언트 1로 가는 넷미팅 비디오와 음성 패킷은 우선권(precedence) 값을 4로 마킹하라
3. 모든 HTTP 패킷들은 우선권(precedence) 값을 2로 마킹하라
2. 일반 데이터 트래픽은 우선권(precedence) 값을 0으로 마킹하라
3. PBR(Policy-Based Routing)를 사용해 작성하라

☞ 해결
연습문제 2에 대한 답으로, PBR(Policy-Based Routing) 설정은 다음과 같다.

ip route-chache policy
!
ip access-list extended VoIP-ACL → Named ACL의 이름을 VoIP-ACL이라 정의
permit udp any range 16384 32768 any range 16384 32768 → VoIP 트래픽을 구분하는 과정
!
ip access-list extended NetMeet-ACL → Named ACL의 이름을 NetMeet-ACL이라 정의
permit udp host 192.168.1.100 range 16384 32768 192.168.3.0 0.0.0.255 range 16384 32768
!
ip access-list extended http-acl → Named ACL의 이름을 http-acl이라 정의
permit tcp any eq www any → 목적지 포트가 TCP 80인 패킷을 구분
permit tcp any any eq www → 소스 포트가 TCP 80인 패킷을 구분
!
interface fastethernet 0/0 → 해당 인터페이스에 폴리시 맵을 적용
ip policy route-map voip-routemap
!
rotue-map voip-routemap permit 10 → 라우트맵을 이용해 10번부터 순차적으로 적용됨
match ip-address NetMeet-ACL → 먼저 넷미팅 패킷을 구분(작은 범위 먼저 적용 원칙)
set ip precedence 4 → 넷미팅 패킷에 대해 precedence 값을 4로 마킹
!
rotue-map voip-routemap permit 20 → 라웃멥 10번을 지난 패킷이 20번에 적용된다
match ip-address VoIP-ACL → VoIP 패킷을 구분
set ip precedence 5 → VoIP 패킷에 대해 precedence 값을 5로 마킹
!
rotue-map voip-routemap permit 30
match ip-address http-acl → HTTP 패킷을 구분
set ip precedence 2 → HTTP 패킷에 대해 precedence 값을 2로 마킹
!
rotue-map voip-routemap permit 40
set ip precedence 0 → 나머지 패킷들에 대해 precedence 값을 0으로 마킹
!
end

PBR(Policy-Based Routing) 설정 확인은 다음과 같다.

R3#show ip policy
Interface Route map
Fastethernet0/0 voip-routemap

R3#show route-map
route-map voip-routemap, permit, sequence 10
Match clauses:
ip address (access-lists): NetMeet-ACL
Set clauses:
ip precedence flash-override
Policy routing matches: 3 packets, 222 bytes
route-map voip-routemap, permit, sequence 20
Match clauses:
ip address (access-lists): VoIP-ACL
Set clauses:
ip precedence Critical
Policy routing matches: 14501 packets, 1080266 bytes
route-map voip-routemap, permit, sequence 30
Match clauses:
ip address (access-lists): http-acl
Set clauses:
ip precedence immediate
Policy routing matches: 834 packets, 1007171 bytes
route-map voip-routemap, permit, sequence 40
Match clauses:
Set clauses:
ip precedence routine
Policy routing matches: 8132 packets, 11263313 bytes

이번 시간에는 DiffServ 모델에 대한 이론과 더불어 실제 환경에서 그것이 어떻게 적용되는지 다각도로 살펴봤다. 다음 시간에서는 네트워크 대역폭 조절에 막대한 영향을 끼치고 있으며, 현재 가장 이슈가 되고 있는 트래픽 세이핑과 폴리싱에 대해 알아보자.

* 참조

PBR ( Policy-Based Routing의 약자)은 어떤 정책을 세우고 이 기준에 맞추어 routing을 하라는 소리라고 생각을 하면 된다. PBR은 위와 같은 경우 처럼 QOS에도 쓰이고 worm전파를 막는데도 쓰인다. 여기서는 미터와 마킹에 대해서 이야기 하고 있는데 우리가 가지고 있는 미터는 access-list이며 이를 마킹 하는데 사용하는 것이 바로 PBR이다.

 예) PBR예

source ip가 1.1.1.1 이면 10.10.10.10으로 보내고

source ip가 2.2.2.2 이면 20.20.20.20으로 보내라는 예제입니다.

access-list 1 permit ip 1.1.1.1
access-list 2 permit ip 2.2.2.2

 

interface ethernet 0
   ip policy route-map s_route // e0를 통하여 들어오는 패킷은 s_route라는 route-map을

                                                   따르라는 명령어

route-map s_route permit 10 // 10은 routemap의 번호
   match ip address 1              // 송신 ip주소가 access-list 1번에 해당하면
   set ip next-hop 10.10.10.10      10.10.10.10으로 보내라

route-map s_route permit 20
   match ip address 2             // 송신ip주소가 access-list2번에 해당하면
   set ip next-hop 20.20.20.20      20.20.20.20으로 보내라

diffserv-ej0320[1].pdf

diffservmchanismfor-ej0320[1].pdf

[출처] DiffServ 모델의 이해와 적용법(3)|작성자 캐슬락

outing : 가는 길을 알려는 것.

forwarding : 경로가 정해져 있고 그길로 보내주는 것.(전화)

* 인터넷은 routing + forwarding

전화는 전송률이 일정하다..

인터넷은 전송률이 일정하지 않고 보장하지 못한다.

* 인터넷 라우터는 패킷 하나하나를 보았을때는 비효율적이지만 전체를 봤을때는 가격비에 효율적이다.

라우터는 자신이 처리할 수 있는 패킷량보다 더 많이 들어오면 버려버린다.

Congestion : 네트웍에 트래픽이 너무 혼잡한 상태..

= Gueueing error

-> Packet loss가 일어나는 경우

1. 라우터의 큐가 넘치는 경우.

2. Checksum 검사를 했을때 데이터 손실이 있다고 판단된 경우 -> Transmission error

3. TTL(time to live)값이 0이 되었을 때(ex, routing loop)

* 위 3가지 문제를 TCP가 해결한다.

TCP가 해야할일 Retransmission(재전송), Reordering(순서정렬), Flow Control(흐름제어)  => Reliable(신뢰성)

IP계층(Network)에서는 패킷이 사라졌는지 확인이 불가능..(IP는 패킷 전송에 최선은 다하지만 보장은 못한다.)

TCP헤더에 Sequence number을 붙여서 패킷이 손실이 되었는지 / 순서되로 받았는지 확인함.

+ Flow control을 함

UDP

TCP가 하는 재전송, 순서정렬, 흐름제어를 해주지 않는다.

- 영상이나 음성 전달시 약간의 Loss는 무시할 수 있다.

- 경로가 하나뿐인경우 패킷순서정렬이 필요없다(LAN)

- 하나의 패킷으로 전송되는 경우에 순서정렬이 필요없다.

TCP는 기본적으로 위에 3가지 기능을 기본적으로 지원하기 때문에 필요가 없다 생각하는 경우 이를 해제 할 수 없다.

그렇기 때문에 UDP를 사용한다.

패킷이 1,2,4,5 순서로 들어왔을때 3번이 손실되었을 확률과 후에 늦게 들어올 확률??

- 뒤에 3개의 패킷이 전송되도록 전송이 안되면 3번 패킷이 에러난걸로 판정하고 재전송 요청..

ACK : 패킷을 정상적으로 받았을 때

NACK : 패킷이 에러가 났을 때..

수신한 패킷마다 ACK를 보낸다면 전송속도가 떨어진다.

* RTT : 패킷을 보냈을때 수신자의 대답이 돌아올때까지 걸리는 총 시간.

* PPS : 초당 처리하는 패킷수.

패킷길이가 길어지면 딜레이가 발생.. -> 패킷을 채울때까지 기달려야 하니깐.

* 음성은 약 10ms단위로 해서 패킷을 만들어 전송한다.

* Window : Ack를 안받고도 한번에 보낼 수 있는 패킷 수 조절..

Flow control 은 네트워크의 상태에 따라 패킷을 많이 보낼지 적게 보낼지 결정..

* dupACK : 1,2까지 전달되고 4,5,6이 전달되면서 3이 손실되었을때 수신자는 3번을 재전송해달라고 요청하는 경우.

* Fast Retransmit

재전송하는 경우

1. Time out : 수신이 완료된 패킷이 적어서 dupAck 조건이 성립안하면...

2 dupAck가 3개이상 뜨는 경우

패킷을 전송할때 첨에는 1부터 시작하여 2제곱승으로 증가한다 (최대 증가값(ssthresh)는 64) : Slow Start

최대값까지 증가후는 1씩 증가하며, 수신측에서 NAck가 왔을때 1/2로 감소한뒤 1씩 증가..

TCP의 속도는 RTT에 반비례한다.

* RTT는 패킷을 전송하고 ACK가 돌아오는데까지 걸리는 시간.

Congestion이 발생했으면 네트워크 상태가 혼잡한 상태..

Congestion이 발생하면 자기 책임이라 생각하고 전송량을 1/2로 줄인다.

-> 따라서 데이터를 전송하는 모든 송신자가 전송량을 1/2로 줄이기 때문에 라우터는 처리할 양이 반으로 줄어들기 때문에 그 사이에

    Congestion 문제를 해결시도하며, 금방 풀 수 있다.

Slow Start parse : 1부터 시작하여 2의 제곱승으로 증가하는 방식

Congestion avoid phase : 전송을 하다가 전송에러 1/2로 감소된 후 다시 1씩 증가하는 방식

TCP의 flow control 방식을 한단어로 AIMD (Additive increase, Muliiplicative Decrease)

- Slow Start 비율이 작기 때문에 보통 AIMD라 부름..

비디오/오디오는 일정한 전송속도 보장이 있는 것이 좋다.

하지만 Tcp에서는 네트워크 상태에 따라서 흐름제어를 하기 때문에 비효율 -> 따라서 버퍼링을 함

TCP에서는 Packet loss가 일어나면 무조건 congestion으로 판단..

-> 그렇다면 패킷 로스가 일어나는 경우는 3가지 경우인데 이를 다 congestion으로 처리를 한다면 TCP의 오동작으로 볼 수 있다.

하지만 통계로 보았을 때 유선에서 실제 Congestion이 일어날 확률이 99%이고 나머지가 1%미만이기 때문에 ...

하지만 무선환경에서는 다르다..오동작률이 20%....

무선에서 패킷전송 속도는 √p 에 반비례한다. (p : average packet loss rate)

유선에 비하여 약 30%정도 떨어진다.