인터넷의 발전에 따라 사용자가 서비스에 대한 요구가 다양해지는 동시 서비스의 품질에 대한 요구가 높아지고 있다. 특히 멀티미디어 서비스의 도입에 따라 화상 전송과 같은 넓은 대역폭을 요구하는 서비스, 더 나아가 영상, 방송과 같은 높은 대역폭과 실시간 전송을 요구하는 서비스가 많이 도입된다. 많은 사용자가 요구하는 멀티미디어 서비스를 지원하기 위하여 망을 확장하는 동시에 기존 망을 효율적으로 최대 활용하는 방안에 대한 연구가 활발히 진행하고 있다.
기존의 인터넷은 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 과 같다
그림 1: RSVP Signaling
발신자가 연결을 설정 시 요구된 트래픽 특성 정보를 포함하는 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를 훨씬 더 잘 구별할 수 있기 때문이다.
그림 Multiple Domain
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로 제명 할 것이다
A DiffServ field(byte)
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 가 제공될 수 있을까?
그림 WAN에서의 RSVP와 RESV message
만약 호스트가 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를 각각의 네트워크 장치에 맵핑 시키는데 그 역할이 매우 증대 될 것이다.
(원제: Qos with Differentiated Service 저자: Walter Weiss 출처: Bell Labs Technical journal October-December 1998)
