7장 목차 7.1 멀티미디어 네트워킹 응용 7.5 다양한 서비스 클래스 제공 7.2 스트리밍 저장 오디오 및 비디오 7.3 최선형 서비스를 최대로 활용하기 7.4 실시간 대화형 응용 프로토콜 7.5 다양한 서비스 클래스 제공 7.6 QoS 보장

Real-Time Protocol (RTP) RTP는 audio와 video 데이터를 전송하는 패킷의 구조를 정의한다. RFC 3550 RTP 패킷에 포함된 정보 페이로드 유형을 명시 패킷의 일련 번호 타임스탬프(time stamp) RTP는 종단 시스템에서 동작 RTP 패킷은 UDP 데이터그램으로 캡슐화된다. 상호연동: 만약 두 인터넷 전화가 RTP로 동작된다면 두 전화는 서로 통화가 가능해 진다.

RTP 프로토콜 스택 RTP 라이브러리는 UDP를 확장한 수송 계층의 인터페이스를 제공한다. port 번호, IP 주소 payload 유형 ID 패킷 일련 번호 타임스탬프

RTP 예 RTP 위에서 64 kbps PCM으로 인코딩된 voice를 전송한다고 하자. 응용 계층은 인코딩된 데이터를 voice chunk(패킷)로 구성한다. 매 20 msec 마다 160 byte의 voice 패킷 Voice 패킷+ RTP 헤더 = RTP 패킷 RTP 패킷으로 UDP datagram으로 캡슐화 RTP 헤더는 각 패킷 마다 인코딩 유형을 표시한다. 송신자는 통화 중에 인코딩 방법을 변경할 수 있다. RTP 헤더는 또한 일련 번호와 타임스탬프를 포함한다.

RTP와 QoS RTP는 패킷이 시간 내에 도착할 수 있는 어떤 방법도 제공해 주지 않는다.(QoS를 위한 어떤 방법을 제공하지 않는다.) RTP 헤더 정보는 오직 종단 시스템 만이 볼 수 있다.(망 중간의 라우터는 상관하지 않는다.)

RTP 헤더(1) 페이로드 유형 (7 bits): 현재 패킷에서 사용된 인코딩 유형을 표시 송신자는 통화 중 인코딩 방법을 변경하였으면 이 필드로 수신자에게 알려줌 Payload type 0: PCM mu-law, 64 kbps Payload type 3, GSM, 13 kbps Payload type 7, LPC, 2.4 kbps Payload type 26, Motion JPEG Payload type 31. H.261 Payload type 33, MPEG2 video 일련 번호 (16 bits): RTP 패킷을 전송할 때 마다 하나씩 증가 패킷 손실을 발견하거나 퍀시 손실을 복구할 때 사용

RTP 헤더 (2) 타임스탬프(32 bytes long): RTP 패킷의 첫번째 바이트를 샘플링할 때의 시간 오디오의 경우, 타임스탬프 clock은 매 샘플링 기간마다 1씩 증가한다. (예, 8KHz 샘플링 시계는 매 125 usecs 마다 증가) 응용 계층에서 160개의 인코딩 샘플을 발생시키면 매 패킷 마다 160씩 증가. 타임스탬프는 송신 소스가 비활성화될 때까지 계속 증가한다. SSRC (32 bits long): RTP 스트림의 소스(source)를 명시한다. RTP 세션의 각 스트림은 별도의 SSRC 값을 갖는다.

Real-Time Control Protocol (RTCP) RTP와 협력하여 동작 RTP 세션의 참여자는 주기적으로 RTCP 제어 패킷을 모든 다른 참여자에게 전송한다. RTCP 패킷은 송수신 상태를 보고한다. 응용 계층에 유용한 통계 정보를 보고: 송신한 패킷의 수 손실된 패킷의 수 패킷의 도착 시간의 변이 등등 이 정보를 사용하여 성능을 향상시키는데 사용할 수 있다. 송신자는 피드백 정보에 의거하여 전송율을 조정할 수 있다.

RTCP 각 RTP 세션마다: 보통 하나의 멀티캐스트 주소를 갖음 모든 RTP /RTCP 패킷은 동일 멀티캐스트 주소를 사용

RTCP 패킷들 소스 명시 패킷: 수신 보고 패킷: 송신자의 e-mail 주소, 송신자 이름, RTP 스트림과 연관된 SSRC 손실된 패킷의 비율, 마지막 패킷의 일련 번호, 평균 도착 시간 변이 송신 보고 패킷: RTP 스트림의 SSRC, 현재 시간, 송신한 패킷의 수, 송신한 바이트의 수 소스 명시 패킷: 송신자의 e-mail 주소, 송신자 이름, RTP 스트림과 연관된 SSRC SSRC와 사용자/호스트 이름 사이의 매핑

스트림들의 동기화 RTCP는 RTP 세션 내에서 다른 미디어 스트림을 동기화시킬 수 있다. 화상 회의에서 각 참여자는 video RTP 스트림과 audio RTP 스트림을 전송한다. Video, audio RTP 패킷의 타임스탬프는 동일한 샘플링 시계에 의해 만들어짐 각 RTCP 송신 보고 패킷은 RTP 패킷의 타임스탬프 패킷이 생성될 때의 시간 수신자는 audio와 video를 재생할 때 동기화 시킴

RTCP 대역 조절 RTCP 트래픽은 세션 대역의 5% 이내로 제한 75 kbps는 수신자들이 동일하게 분배하여 사용: 예 송신자가 2 Mbps의 video를 전송한다면 RTCP 트래픽은 100Kbps로 제한하도록 시도한다. RTCP 트래픽은 수신자는 75%를 송신자는 25%를 사용한다. 75 kbps는 수신자들이 동일하게 분배하여 사용: R 수신자라면, 각 수신자는 75/R kbps로 RTCP 트래픽을 전송 송신자는 25 kbps 속도로 RTCP 트래픽을 전송 참여자는 평균 RTCP 패킷의 크기를 할당된 전송율로 나누어서 얼마나 자주 RTCP 패킷을 전송할 지 결정한다.

SIP: Session Initiation Protocol [RFC 3261] 모든 전화 통화의 호(call), 화상 회의의 호는 인터넷을 통해 발생한다. 사람들은 전화 번화가 아니라 이름 혹은 이메일 주소을 자신의 식별자(identifier)로 사용한다. 상대방이 어디에 있든지, 어떤 IP 주소를 사용하든지 상대방에 접속할 수 있다.

SIP 서비스 호(call)를 설정할 때, SIP이 제공하는 것들 그래서 송신자와 수신자가 미디어 형태, 코딩 방식에 대해 합의를 하도록 한다. 호를 해제한다. 상대방의 현재 IP 주소를 결정 상대방 식별 ID를 현재 IP 주소로 매핑 호 관리: 통화 중에 새로운 미디어 스트림을 추가 통화 중에 코딩 방식을 변경 또 다른 통화자를 초대 호를 이전(transfer), 일시 정지

IP 주소를 이미 알고 있을 때 호 설정 Alice의 SIP invite message: port 번호, IP 주소, 원하는 코딩 방식(PCM ulaw) Bob의 200 OK message: port 번호, IP 주소, 원하는 코딩 방식 (GSM) SIP 메시지는 TCP 혹은 UDP로 전송; 여기서는 RTP/UDP로 전송 디폴트 SIP port 번호는 5060.

호 설정 codec 협상: Bob은 PCM ulaw encoder가 없다고 하자. Bob은 606 Not Acceptable Reply로 응답하면서 자신의 encoder를 알려줌 Alice는 그 중에서 encoder를 선택하여 새로운 INVITE 메시지를 보낸다. 호 거부 Bob은 호 요청을 거부하면서 다음과 같은 이유를 알려준다: “busy,” “gone,” “payment required,” “forbidden” 미디어는 RTP 혹은 다른 프로토콜을 사용하여 전달된다.

SIP 메시지 예 INVITE sip:bob@domain.com SIP/2.0 Via: SIP/2.0/UDP 167.180.112.24 From: sip:alice@hereway.com To: sip:bob@domain.com Call-ID: a2e3a@pigeon.hereway.com Content-Type: application/sdp Content-Length: 885 c=IN IP4 167.180.112.24 m=audio 38060 RTP/AVP 0 Notes: HTTP 메시지와 동일한 문법(syntax) sdp = session description protocol Call-ID는 호를 식별하는 유일한 값 Bob의 IP 주소를 모른다면 중간에 SIP 서버가 필요하다. SIP 포트 번호 5060을 사용하여 SIP 메시지를 보내고 받는다.

이름 변환과 상대방 위치 찾기 송신자는 상대방의 이름과 e-mail 주소 만을 갖고 있다면, 상대방의 현재 IP 주소를 알아야 한다: 상대방은 이동 중 DHCP 프로토콜 사용 상대방은 여러 다른 IP 기기를 사용할 수 있다.(PC, PDA, 차량 부착 기기) 응답은 요청자가 누구인가에 따라 달라질 수 있다: time of day (집, 직장) 요청자 (친구, 직장 상사) 수신자의 현재 상태(요청을 받았을 때 이미 음성 메일을 사용 중) SIP 서버: SIP 등록자 서버 SIP 프록시 서버

SIP 등록자(Registrar) Bob이 SIP client를 시작하면, client는 SIP REGISTER 메시지를 to Bob의 등록자 서버에 보낸다. (Instant Messaging에서와 비슷한 기능) 등록 메시지: REGISTER sip:domain.com SIP/2.0 Via: SIP/2.0/UDP 193.64.210.89 From: sip:bob@domain.com To: sip:bob@domain.com Expires: 3600

SIP 프록시(Proxy) Alice는 invite 메시지를 자신의 프록시 서버에 보낸다. 상대방(Bob)의 주소를 포함 sip:bob@domain.com Proxy는 경로를 찾아서 수신자에게 SIP 메시지를 전달한다. 여러 proxy를 거쳐서 도달할 수 있다. 수신자는 동일한 경로의 proxy들을 거쳐서 응답 메시지를 전달한다. Proxy는 SIP 응답 메시지를 Alice에게 전달한다. 응답 메시지는 Bob의 IP 주소를 포함하고 있다. Proxy는 local DNS 서버와 비슷한 기능을 수행한다.

예 (6-8) SIP response를 전달한다. (9) 미디어는 두 client 사이에서 직접 전달된다. 송신자: jim@umass.edu 수신자: keith@upenn.edu (1) Jim은 INVITE 메시지를 umass SIP proxy에 보낸다. (2) umass 서버는 이 메시지를 upenn SIP registrar 서버에 전달한다. (3) Upen 서버는 이 메시지를 반송하면서 keith@eurecom.fr로 요청하도록 지시한다. (4) Umass proxy는 INVITE 메시지를 eurecom registrar에 보낸다. (5) Eurecom registrar은 INVITE 메시지를 keith의 SIP client가 동작하고 있는 197.87.54.21로 전달한다. (6-8) SIP response를 전달한다. (9) 미디어는 두 client 사이에서 직접 전달된다. 또한 이 그림에서는 나타나 있지 않지만 SIP ACK 메시지가 전달된다.

H.323과 비교 H.323는 실시간 대화형 통신을 위한 또 다른 신호 프로토콜(signaling protocol)이다. 신호, 등록, 수락 제어, 전송, 코덱 등 SIP은 프로토콜의 한 요소 만을 규정. RTP와 같이 동작하지만 반드시 RTP를 사용해야 하는 것은 아니다. 다른 프로토콜과 같이 결합해서 사용할 수 있다. H.323은 ITU에서 만듬 (telephony). SIP은 IETF에서 만듬: 많은 개념은 HTTP에 기반을 두고 있다. SIP은 Web 지향적이고, H.323은 전화 지향적이다. SIP은 KISS 원칙을 사용했다. Keep it simple stupid.

7장 목차 7.1 멀티미디어 네트워킹 응용 7.5 다양한 서비스 클래스 제공 7.2 스트리밍 저장 오디오 및 비디오 7.3 최선형 서비스를 최대로 활용하기 7.4 실시간 대화형 응용 프로토콜 7.5 다양한 서비스 클래스 제공 7.6 QoS 보장

인터넷에서 멀티미디어 서비스를 제공하기 위한 접근 방법 통합 서비스 접근: 각 응용 서비스에 필요한 대역을 보장해 준다. 모든 노드들에 근본적인 변화가 요구된다. Integrated Services 호 수락 제어(admission control) RSVP(신호 프로토콜 자유 방임(Laissez-faire) 현재 그대로 사용 필요하면 대역을 더 제공 CDN, 응용 계층 멀티캐스트 차별 서비스 접근: 약간의 변화 필요 Differentiated services What’s your opinion?

다양한 서비스 클래스의 구분 지금까지(그리고 현재 인터넷에서는) 모든 트래픽들은 동일하게 처리되었다. 즉 서비스 구별이라는 개념이 존재하지 않는다. 하지만 네트워크에서 서비스 보장을 위해서는 서비스 간에 구별을 할 필요가 있다. 트래픽을 서비스에 따라서 차별화: 서비스 클래스 지정 어떤 트래픽 그룹을 하나의 클래스로 정할 것인가? 서비스 클래스는 어떻게 결정할 것인가? 구별된 클래스는 어떻게 구분해서 처리할 것인가? 0111 7: Multimedia Networking

다양한 서비스 클래스: 시나리오 H3 H1 R1 R2 H4 R1 output 1.5 Mbps link H2 interface queue 1.5 Mbps link 7: Multimedia Networking

시나리오: FTP와 audio(1) 예: IP 전화(1Mbps)와 FTP 트래픽(0.1Mbps)이 1.5 Mbps 링크를 공유한다고 하자. FTP 패킷들이 많이 도착할 경우(burst) 라우터의 버퍼에서 대기해야 하고, audio 패킷의 손실이 발생할 수 있다. 따라서 라우터에서 패킷을 처리할 때 FTP 패킷 보다 audio 패킷을 우선적으로 처리할 수 있도록 하고 싶다. R1 R2 원칙 1 라우터가 두 트래픽을 구별하기 위해서 패킷에 표시를 할 필요가 있다. 두 트래픽은 다른 서비스 클래스를 가지며 라우터는 이에 따라 패킷을 처리하는 순서를 결정한다.

시나리오: FTP와 audio(2) 만약 audio 트래픽이 1Mbps를 초과할 경우 어떤 일이 발생하겠는가? 감시: 소스는 약속한 대역폭을 지키도록 한다. 1 Mbps phone R1 R2 1.5 Mbps link packet marking and policing 원칙 2 한 클래스는 약속을 이행하지 않는 다른 클래스로부터 보호를 받아야 한다.

무엇이 필요한가? 라우터에서의 패킷 스케쥴링 서비스 클래스는 몇 종류로 구분할 것인가? 서비스 클래스를 구분하는 기준은? 서비스 클래스에 따라 패킷 처리 속도가 달라짐 서비스 클래스는 몇 종류로 구분할 것인가? 3가지, 4가지, 100가지? 서비스 클래스를 구분하는 기준은? 요금? 서비스 클래스에 따라서 패킷의 표시(marking)는 어떻게 할 것인가? 트래픽이 원래의 약속을 지키는지 감시(policing)는 어떻게 할 것인가? 패킷의 표시와 감시는 누가 할 것인가? 망 경계 라우터?

7장 목차 7.1 멀티미디어 네트워킹 응용 7.5 다양한 서비스 클래스 제공 7.2 스트리밍 저장 오디오 및 비디오 7.3 최선형 서비스를 최대로 활용하기 7.4 실시간 대화형 응용 프로토콜 7.5 다양한 서비스 클래스 제공 7.6 QoS 보장

QOS 보장 서비스가 필요로 하는 대역을 보장할 수 없으면 QoS를 보장할 수 없다. Principle 4 1 Mbps phone R1 R2 1.5 Mbps link 1 Mbps phone Principle 4 호 수락(Call Admission): -서비스는 필요 대역을 사전에 요구 - 망이 이 서비스의 요구를 받아들일 수 있으면 수락하고 QoS를 보장한다. 아니면, 거부

QoS-sensitive scheduling 대역 예약(Resource reservation) 호 설정, 자원 예약 (RSVP) 트래픽과 요구하는 대역을 명시 서비스 당 수락 제어 request/ reply QoS-sensitive scheduling