Multimedia Networking

상위 문서: 컴퓨터 네트워크

개요

현재 전 세계의 대부분의 사람들은 인터넷을 이용하여 여러 멀티 미디어 건텐츠에 접근할 뿐만 아니라, 동영상과 오디오등을 인터넷에 업로드하기도 한다. 이렇듯, 멀티미디어 컨텐츠는 인터넷의 중요한 구성 요소가 되어가고 있다. 해당 문서에서는 이러한 멀티미디어 서비스를 제공하는 멀티미디어 애플리케이션의 분류 체계와, 기존 애플리케이션과의 차이점에 대해 다룬다. 또한 이를 구현하기 위한 여러 기술 들과 기법에 대해 다룬다.

Multimedia Networking Applications

멀티미디어 네트워크 애플리케이션이란 오디오나 비디오를 사용하는 모든 네트워크 애플리케이션을 의미한다.

Properties of Video

비디오란 이미지들의 연속이며, 여러 이미지들이 동일한 속도로 표시되는 것이다. 예를 들어 24 images/sec(24fps)란 초당 24장의 정지 이미지로 전송되는 비디오 품질을 의미한다. 또한 디지털 이미지란 픽셀 배열이며, 각각의 픽셀은 비트로 표시된다. 예를 들어 RGB 픽셀은 24비트로 표현 가능하다.

비디오의 가장 큰 특징은 높은 비트 전송률(bit rate)를 요규한다는 것이다. 화상 회의는 적어도 100kbps의 전송률을 요구하며, 고화질 영상 스트리밍 서비스는 3Mbps 이상의 전송률을 요구한다. 비디오의 또다른 특징은 압축이 가능하다는 것이며, 이를 통해 영상 품질과 비트 전송률 사이의 절충(trade-off)를 택할 수 있다. 이렇게 멀티미디어의 데이터를 압축하고 디지털 형식으로 변환하는 과정을 인코딩(encoding)이라고 한다.

압축을 할 때 중요한 것은 중복(redundancy)를 활용하는 것으로 이는 공간적 중복(spatial redundancy)와 시간적 중복(temporal redundancy)로 구분된다. 공간적 중복은 이미지 내부에서 반복되는 색상, 패턴들을 의미하며, 시간적 중복은 연속된 프레임에서 중복되는 프레임을 의미한다. 보라색 픽셀이 하나의 프레임 내에서 중복된다고 할 때, 각 픽셀의 색 정보를 N번 전송하는 대신 공간적 중복을 활용하여 보라색 + 반복 횟수: N만을 전송하면 된다. 또한 시간적 중복을 활용한다면 연속된 프레임(frame i와 frame i+1) 사이의 차이만 전송하여, 전체 프레임을 다 보내지 않고, 변화된 부분만 보내는 방식이다.

동영상의 비트레이트는 CBR(Constant Bit Rate)와 VBR(Variable Bit Rate)로 나뉜다. CBR은 고정 전송률로 비디오를 전송하는 방식이다. 즉, 매 초마다 동일한 양의 데이터를 사용해서 비디오를 압축하는 방식이다. 인코딩 속도가 일정하여 비교적 예측가능하며, 이에 따라 일정한 네트워크 대역폭을 요구한다는 장점이 있다. 하지만 모든 프레임에 동일한 비트 수를 사용하므로, 동적인 화면과 같이 압축이 어려운 프레임에 대해서는 영상의 품질이 떨어질 수 있다는 단점이 있다.
VBR이란 가변 전송률로 비디오를 전송하는 방식이다. 즉, 프레임 간의 변화나 복잡도에 따라 인코딩 속도가 달라지는 방식이다. 이에 따라 장면의 복잡도에 따라 적절한 전송률을 사용하여 비디오 서비스의 품질을 일정하게 유지할 수 있다는 장점이 있다. 하지만 요구되는 네트워크 대역폭의 요구량이 일정하지 않다는 단점이 있다.

Properties of Audio

Figure 1. Multimedia: audio

실제의 소리는 연속적인 파동 형태의 아날로그 신호이다. 따라서 디지털 전송을 위해서는 이를 아래와 같은 과정을 통해 디지털 신호로 변환하여야 한다:

1. 아날로그 오디오 신호는 일정한 속도로 샘플링(sampling)된다.
   • 샘플링이란, 일정 시간 마다 소리의 세기를 측정하는 것이다.
   • 예를 들어, 전화는 초당 8000번의 샘플링을, CD에 저장된 음악은 초당 44100번의 샘플링을 요구한다.
2. 샘플링하여 측정된 소리의 세기는 어떤 유한한 값 중 하나로 반올림(quantized)되며, 이 과정을 양자화(quantization)이라고 한다.
   • 예를 들어 8비트 사용시, 가능한 양자화 값은 256개이다.
   • 이 과정에서 원래의 값과 차이가 생기는데, 이를 양자화 오차(quantization error)라고 한다.
3. 모든 샘플의 비트 표현은 이에 해당하는 디지털 신호가 된다.

이러한 과정은 figure 1을 통해서 더욱 잘 이해할 수 있다. 또한 이를 통해서 오디어의 전송률을 계산할 수 있는데, 예를 들어 초당 8000번의 샘플링이 진행되고, 256개의 양자화 값이 존재할 때, 해당 오디오의 전송률은 log2256bits/sample x 8000samples/sec = 64000bps(64kbps)가 된다. 오디오 스피커를 통해 이를 다시 재생하기 위해서는 수신자가 해당 디지털 신호를 다시 아날로그 신호로 변환해야 한다. 하지만 이것은 원래 신호의 근사치일 뿐이며, 원래의 아날로그 신호에 더 가까워지기 위해서는 샘플링 속도 혹은 양자화 값의 수를 늘려야 한다. 즉, 비디오와 마찬가지로 QoS와 비트 전송률 간의 절충(trade off) 관계가 있다.

Types of Multimedia Network Application

인터넷은 여러 가지 유형의 멀티미디어 애플리케이션을 지원하며, 이는 크게 세 가지 범주로 나뉜다:

• 저장된 오디오/비디오 스트리밍(Streaming Stored Audio and Video)
• IP 기반의 음성/영상 통화(Conversational Voice- and Video-over-IP)
• 실시간 오디오/비디오 스트리밍(Streaming Live Audio and Video)

먼저, 저장된 오디오/비디오 스트리밍에 대해 논의하자. 이때 해당 문서에서는 저장된 비디오 스트리밍 애플리케이션에 대해서 집중하여 서술한다. 저장된 오디오 스트리밍(예: Spotify의 음악 스트리밍 서비스)은 저장된 비디오 스트리밍과 매우 유사하지만, 일반적으로 비트 전송률이 훨씬 낮을 뿐이다. 이 범주의 애플리케이션에서, 전송하는 매체는 미리 녹화되어 서버에 저장되어 있는 비디오이다. 이때 저장된 비디오 스트리밍 애플리케이션에는 다음과 같은 세 가지 특징이 있다:

1. 스트리밍(Streaming): 저장된 비디오 스트리밍 애플리케이션에서는 클라이언트가 서버로부터 비디오를 받고 몇 초 내에 재생을 시작한다. 즉, 클라이언트는 비디오의 한 지점을 재생하는 동시에, 서버로부터 이후의 부분을 받는다. 이 기법을 스트리밍이라고 하며, 이는 전체의 비디오 파일을 먼저 다운로드하고 재생하는 방식보다 더욱 빠른 재생을 가능하게 한다.
2. 상호작용성(Interactivity): 미디어는 사전에 녹화된 것이며, 이에 따라 사용자는 비디오를 일시 정지하거나, 앞으로 또는 뒤로 이동하거나, 빨리 감기 등을 할 수 있어야 한다. 또한 해당 동작을 클라리언트가 요구했을 때, 그 반응 시간은 매우 짧아야 한다.
3. 연속 재생(Continuous playout): 생이 시작되면, 비디오는 원래 녹화된 타이밍에 맞춰 계속 재생되어야 한다. 따라서 데이터는 클라이언트가 재생하기 전에 적시에 서버로부터 도착해야 하며, 그렇지 않으면 QoS는 프레임 정지/건너뜀 등의 현상으로 악화된다.

이러한 스트리밍 서비스에서 가장 중요한 성능 지표는 처리량(throughput)이다. 이는 연속적인 재생을 보장하기 위해서는 네트워크가 해당 비디오의 비트 전송률보다 높은 처리량을 제공해야 하기 때문이다.

그리고, IP 기반 음성/영상 통화에 대해서 논의하자. IP 기반의 음성 통화는 사용자의 관점에서 전통적인 circuit-switching 전화 서비스와 유사하여 종종 인터넷 전화라고도 불린다. 또한 VoIP(Voice-over-IP)로도 알려져 있다. 영상 통화는 음성에 더하여 참여자의 영상도 포함된다는 점에서만 구분된다. 이때 VoIP에서 중요한 특성 두가지는 아래와 같다:

• timing consideration: 약간의 지연만 생겨도 사용자는 불편을 느끼므로 음성/영상 애플리케이션은 지연에 매우 민감하다. 이는 delay tolerance가 매우 낮다는 말로 표현되기도 한다.
• loss-tolerant: 데이터 손실에 비교적 관대하여, 데이터의 완전성과 무결성이 상대적으로 중요하지 않다는 의미이다.

마지막으로 실시간 오디오/비디오 스트리밍에 대해 논의하자. 실시간 오디오/비디오 스트리밍 서비스는 전통적인 라디오/TV 방송과 유사하지만, 전송이 인터넷을 통해서 이루어진다는 점에서 차이가 있다. 이들 애플리케이션은 사용자의 위치에 상관없이 생방송을 시청할 수 있게 한다. 해당 애플리케이션은 보통 동일한 프로그램을 동시에 여러 사용자에게 전송한다. 오늘날 인터넷에서는 보통 CDN을 이용해 이를 수행한다. 저장된 오디오/비디오 스티리밍과 마찬가지로, 네트워크는 실시간 멀티미디어 흐름마다 비디오 소비 속도보다 높은 평균 처리량을 제공해야 한다.

Streaming Stored Video

자세한 내용은 Streaming Stored Video 문서를 참조해주십시오.

VoIP

자세한 내용은 VoIP 문서를 참조하십시오.

Network Support for Multimedia

지금의 인터넷은 멀티미디어 애플리케이션에 대해 "best-effort" 방식만을 제공하며, 이에 따라 멀티미디어 애플리케이션은 클라이언트 버퍼링, 품질 조정, 패킷 손실 보정과 같은 application layer에서의 기법을 통해 성능을 높인다. 실제로 이 방식만으로도 괜찮은 수준의 QoS를 제공할 수 있다. 하지만 현재, 네트워크 수준에서의 멀티미디어 애플리케이션을 지원하기 위한 시도가 계속되고 있다. 아래는 네트워크에서 지원 가능한 서비스들이다:

• Making the best of best-effort service: 위에서 다룬 application layer 수준의 메커니즘과 인프라는 패킷 손실이나 과도한 종단 간 지연이 거의 발생하지 않는 잘 차원화된(well-dimensioned) 네트워크에서는 성공적으로 작동한다. 이를 위해서 수요 증가가 예측될 경우, ISP들은 만족스러운 지연 및 패킷 손실 성능을 계속 보장하기 위해 추가적인 대역폭 및 스위칭 용량을 배치한다.
• Differentiated Service: 인터넷은 보통 모두에게 동일한 서비스를 제공하는 "best-effort" 방식이다. 하지만 각 패킷의 용도에 따라 차등 서비스(Differentiated Service)를 제공함으로서, 더 나은 서비스를 제공할 수 있다. 예를 들어, VoIP 애플리케이션은 지연에 대해 더욱 민감하므로, 다른 패킷에 대해 우선 순위를 받아 라우터에서 처리될 수 있다.
• Per-connection QoS Guarantees: 해당 서비스를 통해서 각 애플리케이션 인스턴스가 명시적으로 end system 사이의 대역폭을 예약하고, 이를 통해 end system 사이에 보장된 성능을 확보한다. 예를 들어, 사용자가 호스트 A에서 호스트 B로 VoIP 전화를 하고 싶다면, VoIP 응용 프로그램은 두 호스트 간 경로상의 각 링크마다 대역폭을 명시적으로 예약하는 것이다.

아래는 이에 대해 정리한 것이다:

Approach	Granularity	Guarantee	Mechanisms	Complexity	Deployment to date
Making the best of best- effort service	all traffic treated equally	none, or soft	application-layer support, CDNs, overlays, network- level resource provisioning	minimal	everywhere
Differentiated service	different classes of traffic treated differently	none, or soft	packet marking, policing, scheduling	medium	some
Per- connection QoS Guarantees	each source- destination flows treated differently	soft or hard, once flow is admitted	packet marking, policing, scheduling; call admission and signaling	light	little

Dimensioning Best-Effort Networks

네트워크 수준에서 멀티미디어 애플리케이션은 지원하는데에 있어 어려운 점은 이러한 응용 프로그램들이 매우 엄격한 성능 요구사항(즉, 낮은 종단 간 패킷 지연, jitter, 패킷 손실 등)을 갖고 있고, 네트워크가 혼잡 상태에 빠질 때마다 이러한 지연, 지터, 손실이 발생한다는 점에서 비롯된다.

이에 따라 멀티미디어 애플리케이션의 품질을 향상시키기 위한 가장 간단한 해결책은 돈으로 해결하는 것이다. 즉, 자원 경쟁이 일어나지 않도록 네트워크 전반에 걸쳐 충분한 링크 용량을 제공함으로써, 네트워크 혼잡과 그에 따른 지연 및 손실이 전혀 발생하지 않도록 하는 것이다. 충분한 링크 용량이 있다면, 패킷들은 대기 지연 없이, 손실 없이 오늘날의 인터넷을 빠르게 통과할 수 있다. 이는 이상적인 해결책으로, 멀티미디어 응용은 완벽하게 동작하고, 사용자들도 만족하며, 인터넷의 best-effort 구조를 변경하지 않고도 달성 가능하기 때문이다. 이때 중요한 질문은 아래와 같다:

• 이러한 이상적인 상태를 달성하기 위해 얼마나 대역폭이 요구되는가?
• 그리고 그만한 대역폭을 제공하는 것이 ISP의 사업적 관점에서 실현 가능한가?

이때 특정 수준의 성능을 달성하기 위해서, 주어진 토폴로지에서 네트워크 링크에 얼마나 많은 용량을 제공할 것인가에 대한 질문은 대역폭 할당(bandwidth provisioning) 문제라 불린다. 이를 좀더 고차원적으로 확장한 문제는 라우터를 어디에 배치하고, 어떤 링크로 연결하고, 링크에 어떤 용량을 부여할 것인가를 설계하여 원하는 end system 사이의 성능을 달성하는 것으로, 이는 네트워크 차원화(network dimensioning) 문제라고 불린다. 이 문제를 해결하기 위해서는 아래와 같은 요소에 대해 파악해야 한다:

• 네트워크 end system 사이의 트래픽 수요 모델을 만들어 두 end system 사이에 얼마나 많은 데이터가 오가는지를 수학적·통계적으로 예측해야 한다.
  • call-level 모델: 사용자들이 얼마나 자주 세션을 시작하는지에 대해 모델링
  • packet-level 모델: 세션이 시작된 이후 실제로 패킷이 얼마나 자주, 어떤 패턴으로 생성되는가를 모델링한다.
  • 트래픽 부하는 시간에 따라 변화할 수 있다는 점도 고려해야 한다.
• 정의된 성능 요구 사항
  • 예를 들어, 지연에 민감한 트래픽(예: VoIP 애플리케이션)을 지원하기 위한 요구사항은 "패킷의 종단 간 지연이 허용 가능한 최대 지연을 초과할 확률이 일정 값보다 작아야 한다"와 같이 정의될 수 있다.
• 주어진 트래픽 모델에 대한 end system 성능을 예측하는 모델과, 이에 대해 최소 비용의 대역폭 할당을 위한 최적화 기법

Providing Multiple Classes of Service

자세한 내용은 Providing Multiple Classes of Service 문서를 참조하십시오.

Diffserv

인터넷에서 여러 종류의 트래픽을 각각 질적으로(qualitative) 다르게 처리하고자 할 때, 이를 실현하는 데에는 확장성(scalability)이 매우 중요하다. 이는 인터넷 백본 라우터에는 동시에 수백만 개의 통신 흐름(source-destination flows)이 존재할 수 있기 때문이며, 각각에 대해 상태(state)를 추적하고 유지하는 것은 굉장히 비효율적이기 때문이다. 이를 위해서 네트워크 코어는 단순한 기능만을 수행하며, 속도와 효율을 우선시한다. 이에 따라 복잡한 제어는 엣지 라우터 또는 호스트에서 수행한다. 따라서, 서비스 클래스를 구성할 수 있는 특정 기능을 수행하는 소프트웨어/하드웨어 모듈 또는 절차 제공한다.

DiffServ 아키텍쳐는 네트워크를 구성하기 위해 라우터를 엣지 라우터와 코어 라우터로 구분한다. 엣지 라우터는 트래픽을 네트워크 내부로 들이기 전에 세부 분석과 제어를 수행한다. 엣지 라우터의 주요 기능은 아래와 같다:

1. Per-flow 트래픽 관리
   • 각 트래픽별로 전송률과 burst size 등의 트래픽 특성들을 추적한다.
   • 이 정보를 기준으로 해당 플로우가 정해진 profile을 따르는지 검사한다.
2. 마킹(Marking)
   • 엣지 라우터는 트래픽을 검사한 후, 패킷에 아래와 같이 마킹한다.
   • In-profile: 사전에 약속한 전송률/버스트 크기 내의 패킷이며, 기준을 만족하는 패킷이므로 Out-of-profile 패킷에 비해 먼저 처리된다.
   • Out-of-profile: 기준을 초과한 패킷이며, 초과분이므로 처리시 우선 순위가 낮다.

코어 라우터는 네트워크 내부(백본)에서 고속으로 데이터 패킷을 전송하는 역할을 한다. 따라서 처리 속도가 매우 중요하며, 복잡한 연산은 하지 않는다. 아래는 코어 라우터의 주요 기능이다:

1. Per-class 트래픽 관리: 각 트래픽 별로 처리하는 것이 아니라, 트래픽 클래스 전체를 대상으로 처리한다.
2. 마킹 기반 스케줄링: 엣지 라우터에서 부여된 마킹(DSCP, in/out-profile 등)을 기반으로 패킷 처리 우선순위를 결정한다.
   • In-profile 패킷은 빠르게 전송한다.
   • Out-of-profile 패킷은 큐가 비어 있으면 처리되지만, 혼잡할 경우 지연되거나 삭제(drop) 될 수 있음.

Figure 2. Edge-router packet marking

Profile은 사용자와 미리 협상한 속도 r과 버스트 한계량 b를 의미한다. 이를 만족하는 트래픽은 정상(in-profile) 이고, 초과하면 비정상(out-of-profile) 으로 간주되어 마킹된다. Figure 2는 Token Bucket 알고리즘을 시각화한 것이다. 토큰(초록색 동그라미)은 일정 속도 r로 생성되며, 토큰은 버킷(크기 b)에 저장되며, b개 이상으로 쌓인 토큰은 버려진다. 패킷이 도착할 때마다 토큰이 충분한 경우에는 토큰을 소모하고 in-profile로 마킹한다. 반면 토큰이 부족하면, out-of-profile로 마킹한다.

이때 위와 같이 트래픽이 약속된 profile을 지키는지 여부에 따라 패킷을 다르게 마킹하는 방식을 intra-class marking이라고 한다. 또한 class-based marking이라고 하는 방식도 존재한다. 이는 네트워크 트래픽을 클래스 단위로 나누고, 클래스별로 고정된 DSCP 값을 할당해 마킹하는 방식으로 이를 통해 각 클래스에게 서로 다른 QoS 처리를 제공한다. 이는 IPv4 기준으로는 ToS 필드에, IPv6 기준으로는 Traffic Class 필드에 저장된다. 이때 DSCP(Differentiated Services Code Point)는 ToS 또는 Traffic Class 필드에서 상위 6비트를 차지한다. 이 6비트는 PHB(Per-Hop Behavior)을 결정한다. 예를 들어, 101110과 같은 DSCP는 EF(Expedited Forwarding)과 같은 QoS 처리를 VoIP 등에 제공한다. 이때 전체 8비트 중에서 6비트만 사용되며, 뒤의 2비트는 현재 사용되지 않는다.

Figure 3. Classification, conditioning

Diffserv 아키텍쳐는 어떤 클래스의 트래픽 유입률을 제한하고 싶을 수 있다. 예를 들어, VoIP 트래픽은 1Mbps만 허용하고, HTTP 트래픽은 5Mbps까지만 허용하고자 할 수 있다. 이를 위해서 사용자는 profile(트래픽 특성)을 미리 약속하며 burst size나 average rate를 설정한다. 이 profile은 엣지 라우터가 기준으로 삼아 이후 마킹/제어할 때 사용된다.
Figure 3는 트래픽 측정(traffic metered)을 시각화한 것이다. 들어오는 패킷의 흐름을 측정기(meter)가 감시하며, 이는 사용자와 사전에 협상된 트래픽 profile을 기준으로 작동한다. 이때 주로 Token Bucket 또는 Leaky Bucket 같은 알고리즘을 통해, 해당 패킷이 profile을 벗어나는지의 여부를 판단한다. 이때 만약 profile을 벗어난다면, 비순응 트래픽(non-conforming traffic)으로 간주하고 이를 아래와 같이 처리한다:

1. Shaping: 초과 트래픽을 즉시 버리지 않고, 큐에 저장해서 나중에 전송한다.
   • 결과적으로 실제 네트워크로 나가는 속도를 조절하는 방식이다.
   • 예를 들어 허용되는 전송률이 2 Mbps인데 실제 3 Mbps로 들어오면, 1 Mbps는 큐에 저장하고 나머지는 시간이 지나고 천천히 전송할 수 있다.
2. Dropping: profile을 초과하는 트래픽을 바로 버린다.
   • 예를 들어, 허용된 2 Mbps 이상 트래픽은 측정 후 즉시 drop된다.

Per-connection QoS guarantees

Figure 4. Two competing audio applications overloading the R1-to-R2 link

위에서 다룬 메커니즘 만으로는 고우선순위 트래픽 클래스에 대한 QoS가 보장되는 것은 아니다. Figure 4와 같이 두 개의 1 Mbps VoIP 애플리케이션이 1.5 Mbps 링크를 통해 패킷을 전송하고 있다고 하자. 두 트래픽의 합산 데이터 전송률은 2 Mbps로, 링크 용량(1.5 Mbps)을 초과한다. 해당 시나리오에서 두 애플리케이션이 대역폭을 동등하게 나누어 사용하면, 각 애플리케이션은 전송한 패킷의 25%를 손실하게 되며, 이는 사실상 두 애플리케이션 모두 실패한 것을 의미한다. 따라서 두 애플리케이션을 모두 허용하는 것은 결국 사용자에게 아무 쓸모도 없는 흐름에 네트워크 자원을 낭비하는 것을 의미하며, 두 애플리케이션 트래픽 중 하나는 차단(즉, 네트워크 접근을 거부)하고, 다른 하나는 해당 애플리케이션이 필요로 하는 1 Mbps 전체를 온전히 사용할 수 있도록 허용해야 한다. 트래픽의 자원 요구량과 이미 수락된 트래픽들의 자원 점유 상태를 기반으로 흐름을 명시적으로 수락하거나 차단하는 과정을 Call Admission이라고 한다. 이를 통해 네트워크는 수락된 흐름이 요구한 QoS를 보장할 수 있으며, 이를 위해 각 트래픽은 자신의 QoS 요구사항을 선언해야 한다. 이와 같은 논의에서 아래와 같은 결론이 도출된다:

만약 네트워크 자원이 항상 충분하지 않으며, QoS를 보장하고자 한다 가정하자.
이 경우 트래픽이 QoS 요구사항을 선언하고, 네트워크가 그 흐름을 수락하거나 차단하는 call admission이 필요하다.

어떤 VoIP 애플리케이션이 자신의 원하는 QoS를 충족시키는 데 필요한 자원(링크 대역폭, 버퍼 등)을 보장받으려면, 그 자원을 명시적으로 해당 애프리케이션에 할당 해야 한다. 이를 네트워크 용어로 자원 예약(resource reservation) 이라고 한다. 일단 해당 애플리케이션에 대해 자원이 예약되면, 해당 애플리케이션은 지속 시간 동안 언제든지 그 자원에 접근할 수 있으며, 손실과 지연이 없는 성능을 보장받는다.

Figure 5. QoS guarantee scenario

Figure 5는 실제로 QoS 보장을 위해 네트워크가 어떻게 작동하는지를 보여주는 시나리오이다:

1. resource reservation: 트래픽을 실제로 전송하기 전에 아래와 같은 작업들이 선행된다:
   • Call setup: 트래픽 생성 시 연결을 요청한다.
   • Signaling (RSVP): 네트워크 노드들에게 자원 요청을 전달한다.
   • QoS declaration: "나는 1 Mbps 필요해요"와 같은 방식으로 요구사항을 명시한다.
   • Admission control: 네트워크 노드들이 이에 대해 "수용 가능한가?"를 판단한다.
2. QoS-sensitive scheduling: 실제 전송 시, 스케줄링 알고리즘이 패킷을 처리한다.(WFQ 등)