대학원부터 시작한 첫번째 블로그

1.    <!--[endif]-->when the MAC layer of the AP receives the marked packet, it updates the credits counter for increasing its access weight; and when enough credits are accumulated, its cw is multiplicatively decreased.

      수업이 몇학점 짜리냐고 물어볼때 쓰는말이 credits이라고 한다.

      한국말로 굳이 적용하자면.. 마일리지??? ㅎㅎㅎ

TCP의 greedy closed loop 성질은

burst 성질과 같은 것으로, ACK를 받아야 전송하는 closed loop의 성질에 입각해,

보낼 수 있는 양을 나눠서 적당하게 조절해서 보내는 것이 아니라, 보낼 수 있는 최대 양대로

전송하는 성질을 말하며

어플리케이션 수요(Needs)의 다양성을 만족시키기 위하여 다수의 QoS 프로토콜들이 만들어져 왔다. 우리는 이 프로토콜들을 각각 설명할 것이며, 그런 다음 그것들이 어떻게 end-to-end principle 의 다양한 아키텍쳐 내에서 서로 적합할 것인가를 기술하고자 한다. 이러한 IP QoS 기술에 대한 도전은 개별적인 흐름(individual flow) 또는 프로세스 내에서 망을 분할 하지 않는 집단화(aggregate without breaking the Net) 에 대하여 Differentiated Delivery Service를 제공하게 되었다. 망에 ‘smarts’를 추가하고, “best effort”서비스를 향상시키는 것은 근본적인 변화를 표현하게 되었으며, 그것은 인터넷을 성공하게 만들었다. 이러한 잠재적으로 과감한 변화는 많은 인터넷의 구조(Internet’s architect)를 매우 nervous(신경과민의, 古간결한, 굳센)하게 만들었다.

이러한 잠재적인 문제점을 회피하기위한 QoS 프로토콜과 같은 것은 망에 적용되며, end-to-end 원칙은 아직까지도 QoS구조의 가장 주된 초점이다. 그 결과로 근본적인 원칙 “Leave complexity at the ‘edges’ and keep the network ‘core’ simple” 은 QoS 아키텍쳐 설계의 중심 개념이 되었다. 이것은 개별적인 QoS프로토콜 의 초점일 뿐만 아니라, end-to-end QoS사이에서 어떻게 함께 이용되어 질 수 있는가에 대한 것이기도 하다. 우리는 이러한 아키텍쳐들을 이 논문의 다음에서 찾아보고, 그 후에 QoS프로토콜들의 각각의 핵심을 간략히 소개하고자 한다.
 
The QoS Protocols
Quality Of Service는 한가지 이상의 방법으로 특징지어 질 수 있다. 일반적으로 QoS는 일관된 네트워크 data delivery 를 적정(어떤) 수준의 보증을 제공하는 네트워크 구성요소(e.g. an application, a host or a router)의 능력을 말한다. 어떤 어플리케이션들은 그들의 QoS에 대한 요구가 다른 것들에 비해 더욱 엄중하다. 이러한 이유로 우리는 QoS에 대하여 두 개의 기본형태를 가진다.

●       Resource Reservation (integrated services): 네트워크 자원들이 어플리케이션의 QoS요청에 따라 배분되며, 대역폭 관리정책(Bandwidth management policy)이 중심이 된다

●       Prioritization(differentiated service): 네트워크 트래픽들을 분류(classify)하며, 네트워크 자원들은 대역폭관리정책의 고려사항에 따라 분배된다. QoS를 가능케 하기 위하여, 네트워크 구성 요소들은 더 많은 요구를 받아들이기 위하여 이미 규정된 분류(classification)에 의하여 우선권이 주어진다.
이러한 형태의 QoS는 개별적인 어플리케이션 ‘flow’나 플로우의 집합에 제공되며, 따라서 QoS의 형태를 특징 짓는 또 다른 두 방법이 있게 된다.

●       Per Flow: 하나의 ‘Flow’는 개별적인(individual), 단 방향의(uni-directional), 두 어플리케이션간의 데이터 스트림(sender 또는 receiver), 5-Tuple(transport protocol, source address, source port number, destination address, and destination port number) 에 의해 단일하게 규정되어지는 것으로 정의 된다.

●       Per Aggregate: 하나의 aggregate는 간단히 두 개이상의 Flow를 말한다. 전통적으로 flow는 어떤 공통점을 가지게 된다. (e.g. 하나 이상의 어떤 5-tuple의 파라미터, 레이블이나 프라이오리티 번호, 또는 아마도 어떤 인증정보 등)
 
어플리케이션들, 네트워크 위상(topology)과 정책(policy)은 어떤 형태의 QoS가 각각의 개별적인 FLOW나 aggregate에 대하여 가장 적당한 것인지를 말하고 있다. 이러한 서로 다른 형태의 QoS에 대한 요구사항을 만족시키기 위하여, 많은 서로 다른 프로토콜과 알고리즘이 있다.

●       ReSerVation Protocol (RSVP): 네트워크 자원을 예약하도록 하는 시그널링을 제공한다( 달리 Integrated Service로 알려져 있다). 전통적으로 per-flow 기반으로 사용되었지만, RSVP는 또한 aggregates에 대한 자원예약에도 사용된다.

●       Differential Services(DiffServ): 네트워크 트래픽(flow) aggregates들에 대해 범위를 분류하며, 우선순위를 매기는 [조잡(coarse)하며]간단(simple)한 방법을 제공한다

●       Multi Protocol Labeling Switching (MPLS): 패킷 헤더의 레이블(capsule)에 따른 네트워크 라우팅 제어(control) 를 통해aggregates에 대한 대역폭 관리(bandwidth management) 기능을 제공한다.

●       Subnet Bandwidth Management(SBM): shared 또는 switched 된 IEEE 802 네트워크들에서 Layer 2(data link layer on OSI model)에 대한 범위분류(categorization)와 우선순위화(prioritization) 기능을 제공한다.

Table 1. Shows the different bandwidth management algorithm and protocols, their relative QoS levels, and whether they are activated by network elements (Net) or applications (App), or both.
 
표 1은 어플리케이션 (App) 또는 네트워크에서 QoS레벨과 그것들이 제공하는 구현된 서비스들에 대하여 QoS 프로토콜을 비교한 것이다. 이 표는 또한 Fair Queuing(FQ), Random Early Drop(RED)와 같은 라우터의 큐 경영 알고리즘(Queue management Algorithm)을 참조하고 있는 사실에 주목하여야 한다. 큐의 경영(queue management) – 큐의 개수와 그들의 depth 뿐만 아니라 그것들을 관리하는 알고리즘 까지를 모두 포함은 QoS 구현(implementation)에 있어 매우 중요한 것이다. 우리는 여기서 단지 그것들을 QoS 의 기능(능력)에 대한 전체적인 스펙트럼을 묘사할 뿐이다, 그러나 그것들은 어플리케이션에 대하여 매우 투명한 것이며 QoS 알고리즘에 명시적이지는 않으므로 우리는 그것들을 다시 다루지는 않을 것이다. 더 이상의 정보는 [Queuing]을 보라.
 
이 논문에서 우리가 초점을 두는 QoS 프로토콜은 매우 다양한 것이지만 그것들은 서로 상호 배타적인 것은 아니다. 다른 말로 하면 서로 훌륭히 상호 보완적이다. 이러한 프로토콜들이 상호 복수개의 서비스 제공자들을 통해 end-to-end QoS를 제공하기위해 다양한 아키텍쳐를 가진다. 우리는 이제 이러한 각각의 프로토콜들을 좀더 자세히 설명하고자 하며. – 그것들의 본질적인 구성과 기능들 -  뒤이어 그것들이 서로 end-to-end QoS를 제공하기 위해 사용되는 다양한 아키텍쳐에 대해 설명하고자 한다.
 
RSVP – Resource reservation
RSVP 프로토콜은 (자원)예약을 셋업하고 Integrated Service(IntServ)를 가능하게 제어하는 시그널링 프로토콜(signaling protocol)이다. 그것은 IP 네트워크 상에서 서킷-에뮬레이션 기능을 제공할 수 있도록 고려된 것 이다.  RSVP는 모든 QoS기술들 중 가장 복잡한 것이며, 어플리케이션들 (hosts), 네트워크 구성요소(network element : routers and switches)들에 적용된다.
그러한 결과로 “best-effort” IP 서비스에 있어 가장 큰 부분으로 표현되며, 서비스를 개런티함에 있어 가장 높은 레벨의 QoS를 제공하여 주고, 자원의 할당을 세분화 시켜주고(granuallity) 어플리케이션과 유저에게 상세화 된 QoS 프로토콜을 제공하여 준다.
여기 어떻게 프로토콜이 작동되는 지에 대한 간략화 된 개략설명을 제공한다. 이것은 그림 1에 나타나 있다.

 

< 그림 2 > 

그림 2에 묘사된 대로 PHBs들은 사전 정의된 정책 결정요소에 따라 트래픽의 소통을 위하여 네트워크 진입점(network ingress point : network board entry)에서 적용된다. 트래픽은 이 점에 서 마크 되어지며 그 마킹에 따라 라우트된다. 그런 다음 네트워크 출구(egress : noetwork board exit) 에서 Unmark 되어진다. 호스트로부터 시작되어지는 것 또한 DiffServ 마킹이 적용되어 질 수 있으며, 그렇게 함으로써 많은 장점을 취할 수 있게 된다.
 
DiffServ 는 하나의 보더를 공유하는 네트워크 사이에 SLA(Service Level Agreement)로 존재하는 것으로 가정한다. SLA는 정책결정요소를 수립하며 트래픽 프로파일(traffic profile)을 정의한다. 그것은 네트워크 진출점(egress point)에서 SLA에 따라 조절되어지고(Policed) 유연해 지기(smoothed)를 기대하는 것이며, 진입점(ingress)에서 “out of profile”한 어떤 트래픽(i.e. SLA에 정해진 대역폭의 상위 범위를 초과하는 트래픽 따위)들도 guarantee를 가지지 못하도록 하는 것이다. 사용되는 정책결정요소(Policy criteria)에는 time of day, 송신측, 수신측 주소, 트랜스포트, 그리고/또한 포트번호 등이 포함될 수 있다. 기본적으로 어떤 context나 traffic 의 내용(헤더나 데이터에 포함되어진)이 정책을 적용하는데 이용될 수 있다.
 

이것을 적용할 때 서비스에서 사용되는 프로토콜 메커니즘은 “DS-byte”에 있는 비트-패턴(bit pattern)이며, IPv4에서는 TOS(Type Of Service)옥텟이며 IPv6에서는 Traffic Class Octet이 된다.
그림 3에 묘사 된 대로 DS 필드가 , IPv4 TOS바이트를 사용한다 하더라도 RFC 791에 규정된 대로[IP], RFC1349[TOS]에서 정한 원래의 IPv4 TOS 비트 값을 보존하지 않는다. 그러나 IP 우선순위 비트(precedence bits : 0-2)들은 보존된다. 이러한 영역의codepoint에 어떠한 PHB를 assign 하는 것이 가능하다 할 지라도,  묵시적으로 필요한 PHB들은 RFC1812[RouterReqs]에서 기술된 것 처럼 IP Precedence service description 과 동등한 것이다.
트래픽을 순서화하는 DiffServ의 간결성(simplicity)은 그것의 유연성(flexibility)과 성능(power)에 있어 나타난다.

DiffServ가 RSVP의 파라미터를 사용하거나 CBR(Constant-Bit-Rate)을 규정하고 분류하기 위하여 특정한 어플리케이션의 형태를 사용하는 경우 고정된 대역폭 통로(fixed bandwidth pipe)로 보내기 위하여(direct) 잘-정의된 aggregate flow를 설정하는 것이 가능해 진다. 그 결과 자원을 효율적으로 공유할 수 있으며, 보증된 서비스를 지속적으로 제공할 수 있게 된다.  우리는 이러한 형태의 활용을 나중에 다룰 것이며, 가능한 형태의 다양한 QoS 아키텍쳐를 설명하고자 한다.

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

기존의 인터넷은 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)|작성자 캐슬락