7 장 목차

7-1

7 장 목차

7.1 멀티미디어 네트워킹 응용

7.2 스트리밍 저장 오디오 및 비디오

7.3 최선형 서비스를 최대로 활용하기

7.4 실시간 대화형 응용 프로토콜

7.5 다양한 서비스 클래스 제공

7.6 QoS 보장

7-2

Real-Time Protocol (RTP)

RTP 는 audio 와 video 데이터를 전송하는 패킷의 구조를 정의한다 .

RFC 3550 RTP 패킷에 포함된

정보

페이로드 유형을 명시

패킷의 일련 번호 타임스탬프 (time

stamp)

RTP 는 종단 시스템에서 동작

RTP 패킷은 UDP 데이터그램으로 캡슐화된다 .

상호연동 : 만약 두 인터넷 전화가 RTP 로 동작된다면 두 전화는 서로 통화가 가능해 진다 .

7-3

RTP 프로토콜 스택

RTP 라이브러리는 UDP 를 확장한 수송 계층의 인터페이스를 제공한다 .

• port 번호 , IP 주소• payload 유형 ID• 패킷 일련 번호• 타임스탬프

7-4

RTP 예 RTP 위에서 64 kbps

PCM 으로 인코딩된 voice 를 전송한다고 하자 .

응용 계층은 인코딩된 데이터를 voice chunk(패킷 ) 로 구성한다 . 매 20 msec 마다 160

byte 의 voice 패킷

Voice 패킷 + RTP 헤더 = RTP 패킷

RTP 패킷으로 UDP datagram 으로 캡슐화

RTP 헤더는 각 패킷 마다 인코딩 유형을 표시한다 . 송신자는 통화 중에

인코딩 방법을 변경할 수 있다 .

RTP 헤더는 또한 일련 번호와 타임스탬프를 포함한다 .

7-5

RTP 와 QoS

RTP 는 패킷이 시간 내에 도착할 수 있는 어떤 방법도 제공해 주지 않는다 .(QoS 를 위한 어떤 방법을 제공하지 않는다 .)

RTP 헤더 정보는 오직 종단 시스템 만이 볼 수 있다 .( 망 중간의 라우터는 상관하지 않는다 .)

7-6

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 패킷을 전송할 때 마다 하나씩 증가패킷 손실을 발견하거나 퍀시 손실을 복구할 때 사용

7-7

RTP 헤더 (2)

타임스탬프 (32 bytes long): RTP 패킷의 첫번째 바이트를 샘플링할 때의 시간 오디오의 경우 , 타임스탬프 clock 은 매 샘플링 기간마다 1

씩 증가한다 . ( 예 , 8KHz 샘플링 시계는 매 125 usecs 마다 증가 )

응용 계층에서 160 개의 인코딩 샘플을 발생시키면 매 패킷 마다 160 씩 증가 . 타임스탬프는 송신 소스가 비활성화될 때까지 계속 증가한다 .

SSRC (32 bits long): RTP 스트림의 소스 (source) 를 명시한다 . RTP 세션의 각 스트림은 별도의 SSRC 값을 갖는다 .

7-8

Real-Time Control Protocol (RTCP)

RTP 와 협력하여 동작 RTP 세션의 참여자는

주기적으로 RTCP 제어 패킷을 모든 다른 참여자에게 전송한다 .

RTCP 패킷은 송수신 상태를 보고한다 . 응용 계층에 유용한 통계

정보를 보고 : • 송신한 패킷의 수• 손실된 패킷의 수• 패킷의 도착 시간의 변이 등등

이 정보를 사용하여 성능을 향상시키는데 사용할 수 있다 . 송신자는 피드백 정보에

의거하여 전송율을 조정할 수 있다 .

7-9

RTCP

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

RTP, RTCP 패킷을 다른 포트 번호를 사용하여 구분된다 .

트래픽을 줄이기 위해 , 각 참여자는 상황에 따라서 RTCP 트래픽을 줄일 수 있다 .

7-10

RTCP 패킷들

수신 보고 패킷 : 손실된 패킷의 비율 ,

마지막 패킷의 일련 번호 , 평균 도착 시간 변이

송신 보고 패킷 : RTP 스트림의 SSRC,

현재 시간 , 송신한 패킷의 수 , 송신한 바이트의 수

소스 명시 패킷 : 송신자의 e-mail 주

소 , 송신자 이름 , RTP 스트림과 연관된 SSRC

SSRC 와 사용자 /호스트 이름 사이의 매핑

7-11

스트림들의 동기화

RTCP 는 RTP 세션 내에서 다른 미디어 스트림을 동기화시킬 수 있다 .

화상 회의에서 각 참여자는 video RTP 스트림과 audio RTP 스트림을 전송한다 .

Video, audio RTP 패킷의 타임스탬프는 동일한 샘플링 시계에 의해 만들어짐

각 RTCP 송신 보고 패킷은 RTP 패킷의 타임스탬프 패킷이 생성될 때의 시간

수신자는 audio 와 video를 재생할 때 동기화 시킴

7-12

RTCP 대역 조절

RTCP 트래픽은 세션 대역의 5% 이내로 제한

예 송신자가 2 Mbps 의 video

를 전송한다면 RTCP 트래픽은 100Kbps 로 제한하도록 시도한다 .

RTCP 트래픽은 수신자는 75% 를 송신자는 25% 를 사용한다 .

75 kbps 는 수신자들이 동일하게 분배하여 사용 : R 수신자라면 , 각 수신자는

75/R kbps 로 RTCP 트래픽을 전송

송신자는 25 kbps 속도로 RTCP 트래픽을 전송

참여자는 평균 RTCP 패킷의 크기를 할당된 전송율로 나누어서 얼마나 자주 RTCP 패킷을 전송할 지 결정한다 .

7-13

SIP: Session Initiation Protocol [RFC 3261]

SIP 의 장기적인 목표 :

모든 전화 통화의 호 (call), 화상 회의의 호는 인터넷을 통해 발생한다 .

사람들은 전화 번화가 아니라 이름 혹은 이메일 주소을 자신의 식별자 (identifier) 로 사용한다 .

상대방이 어디에 있든지 , 어떤 IP 주소를 사용하든지 상대방에 접속할 수 있다 .

7-14

SIP 서비스

호 (call) 를 설정할 때 , SIP 이 제공하는 것들 요청자는 자신이 호

(call) 를 설정하기 원한다는 것을 상대방이 알도록 한다 .

그래서 송신자와 수신자가 미디어 형태 , 코딩 방식에 대해 합의를 하도록 한다 .

호를 해제한다 .

상대방의 현재 IP 주소를 결정 상대방 식별 ID 를 현재

IP 주소로 매핑 호 관리 :

통화 중에 새로운 미디어 스트림을 추가

통화 중에 코딩 방식을 변경

또 다른 통화자를 초대 호를 이전 (transfer),

일시 정지

7-15

IP 주소를 이미 알고 있을 때 호 설정

Alice 의 SIP invite message: port 번호 , IP 주소 , 원하는 코딩 방식(PCM ulaw)

Bob 의 200 OK message: port 번호 , IP 주소 , 원하는 코딩 방식 (GSM)

SIP 메시지는 TCP 혹은 UDP 로 전송 ; 여기서는 RTP/UDP 로 전송 디폴트 SIP port 번호는 5060.

time time

Bob'stermina l rings

A lice

167.180.112.24

Bob

193.64.210.89

port 38060

Law audio

G SMport 48753

7-16

호 설정 codec 협상 :

Bob 은 PCM ulaw encoder 가 없다고 하자 .

Bob 은 606 Not Acceptable Reply 로 응답하면서 자신의 encoder 를 알려줌

Alice 는 그 중에서 encoder 를 선택하여 새로운 INVITE 메시지를 보낸다 .

호 거부 Bob 은 호 요청을

거부하면서 다음과 같은 이유를 알려준다 : “busy,” “gone,” “payment required,” “forbidden”

미디어는 RTP 혹은 다른 프로토콜을 사용하여 전달된다 .

7-17

SIP 메시지 예

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP 167.180.112.24

From: sip:[email protected]

To: sip:[email protected]

Call-ID: [email protected]

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 메시지를 보내고 받는다 .

7-18

이름 변환과 상대방 위치 찾기

송신자는 상대방의 이름과 e-mail 주소 만을 갖고 있다면 ,

상대방의 현재 IP 주소를 알아야 한다 : 상대방은 이동 중 DHCP 프로토콜 사용 상대방은 여러 다른 IP

기기를 사용할 수 있다 .(PC, PDA, 차량 부착 기기 )

응답은 요청자가 누구인가에 따라 달라질 수 있다 : time of day (집 , 직장 ) 요청자 ( 친구 , 직장 상사 ) 수신자의 현재 상태 (

요청을 받았을 때 이미 음성 메일을 사용 중 )

SIP 서버 : SIP 등록자 서버 SIP 프록시 서버

7-19

SIP 등록자 (Registrar)

REGISTER sip:domain.com SIP/2.0

Via: SIP/2.0/UDP 193.64.210.89

From: sip:[email protected]

To: sip:[email protected]

Expires: 3600

Bob 이 SIP client 를 시작하면 , client 는 SIP REGISTER 메시지를 to Bob 의 등록자 서버에 보낸다 .

(Instant Messaging 에서와 비슷한 기능 )

등록 메시지 :

7-20

SIP 프록시 (Proxy)

Alice 는 invite 메시지를 자신의 프록시 서버에 보낸다 . 상대방 (Bob) 의 주소를 포함 sip:[email protected]

Proxy 는 경로를 찾아서 수신자에게 SIP 메시지를 전달한다 . 여러 proxy 를 거쳐서 도달할 수 있다 .

수신자는 동일한 경로의 proxy 들을 거쳐서 응답 메시지를 전달한다 .

Proxy 는 SIP 응답 메시지를 Alice 에게 전달한다 . 응답 메시지는 Bob 의 IP 주소를 포함하고 있다 .

Proxy 는 local DNS 서버와 비슷한 기능을 수행한다 .

7-21

예

(6-8) SIP response 를 전달한다 . (9) 미디어는 두 client 사이에서 직접 전달된다 .

또한 이 그림에서는 나타나 있지 않지만 SIP ACK 메시지가 전달된다 .

SIP client217.123.56.89

SIP client197.87.54.21

SIP proxyum ass.edu

SIP registrarupenn.edu

SIPregistrareurecom .fr

1

2

34

5

6

7

8

9

송신자 : [email protected] 수신자 : [email protected]

(1) Jim 은 INVITE 메시지를 umass SIP proxy 에 보낸다 .(2) umass 서버는 이 메시지를 upenn SIP registrar 서버에 전달한다 .(3) Upen 서버는 이 메시지를 반송하면서 [email protected]로 요청하도록 지시한다 .(4) Umass proxy 는 INVITE 메시지를 eurecom registrar에 보낸다 .(5) Eurecom registrar 은 INVITE 메시지를 keith 의 SIP client 가 동작하고 있는 197.87.54.21 로 전달한다 .

7-22

H.323 과 비교

H.323 는 실시간 대화형 통신을 위한 또 다른 신호 프로토콜 (signaling protocol) 이다 .

H.323 은 그 자체가화상 회의를 필요한 모든 것을 규정한 완전한 통합 프로토콜 이다 .

신호 , 등록 , 수락 제어 , 전송 , 코덱 등

SIP 은 프로토콜의 한 요소 만을 규정 .

RTP 와 같이 동작하지만 반드시 RTP 를 사용해야 하는 것은 아니다 .

다른 프로토콜과 같이 결합해서 사용할 수 있다 .

H.323 은 ITU 에서 만듬 (telephony).

SIP 은 IETF 에서 만듬 : 많은 개념은 HTTP 에 기반을 두고 있다 . SIP 은 Web

지향적이고 , H.323 은 전화 지향적이다 .

SIP 은 KISS 원칙을 사용했다 .

Keep it simple stupid.

7-23

7 장 목차






7.6 QoS 보장

7-24

인터넷에서 멀티미디어 서비스를 제공하기 위한 접근 방법

통합 서비스 접근 : 각 응용 서비스에 필요한

대역을 보장해 준다 . 모든 노드들에 근본적인

변화가 요구된다 . Integrated Services

호 수락 제어 (admission control)

RSVP( 신호 프로토콜

자유 방임 (Laissez-faire) 현재 그대로 사용 필요하면 대역을 더 제공 CDN, 응용 계층 멀티캐스트

차별 서비스 접근 : 약간의 변화 필요 Differentiated services

What’s your opinion?

7: Multimedia Networking 7-25

다양한 서비스 클래스의 구분 지금까지 ( 그리고 현재 인터넷에서는 ) 모든 트래픽들은

동일하게 처리되었다 . 즉 서비스 구별이라는 개념이 존재하지 않는다 .

하지만 네트워크에서 서비스 보장을 위해서는 서비스 간에 구별을 할 필요가 있다 . 트래픽을 서비스에 따라서 차별화 : 서비스 클래스

지정

0111

어떤 트래픽 그룹을 하나의 클래스로 정할 것인가 ?

서비스 클래스는 어떻게 결정할 것인가 ?

구별된 클래스는 어떻게 구분해서 처리할 것인가 ?

7: Multimedia Networking 7-26

다양한 서비스 클래스 : 시나리오

R1 R2H1

H2

H3

H41.5 Mbps linkR1 output

interface queue

7-27

시나리오 : FTP 와 audio(1) 예 : IP 전화 (1Mbps) 와 FTP 트래픽 (0.1Mbps) 이 1.5 Mbps

링크를 공유한다고 하자 . FTP 패킷들이 많이 도착할 경우 (burst) 라우터의 버퍼에서 대기해야

하고 , audio 패킷의 손실이 발생할 수 있다 . 따라서 라우터에서 패킷을 처리할 때 FTP 패킷 보다 audio 패킷을

우선적으로 처리할 수 있도록 하고 싶다 .

라우터가 두 트래픽을 구별하기 위해서 패킷에 표시를 할 필요가 있다 . 두 트래픽은 다른 서비스 클래스를 가지며 라우터는 이에 따라 패킷을 처리하는 순서를 결정한다 .

원칙 1

R1 R2

7-28

시나리오 : FTP 와 audio(2)

만약 audio 트래픽이 1Mbps 를 초과할 경우 어떤 일이 발생하겠는가 ? 감시 : 소스는 약속한 대역폭을 지키도록 한다 .

한 클래스는 약속을 이행하지 않는 다른 클래스로부터 보호를 받아야 한다 .

원칙 2

R1 R2

1.5 Mbps link

1 Mbps phone

packet marking and policing

7-29

무엇이 필요한가 ?

라우터에서의 패킷 스케쥴링 서비스 클래스에 따라 패킷 처리 속도가 달라짐

서비스 클래스는 몇 종류로 구분할 것인가? 3가지 , 4가지 , 100가지?

서비스 클래스를 구분하는 기준은? 요금?

서비스 클래스에 따라서 패킷의 표시 (marking)는 어떻게 할 것인가? 트래픽이 원래의 약속을 지키는지 감시(policing)는 어떻게 할 것인가? 패킷의 표시와 감시는 누가 할 것인가?

망 경계 라우터?

7-30

7 장 목차






7.6 QoS 보장

7-31

QOS 보장

서비스가 필요로 하는 대역을 보장할 수 없으면 QoS를 보장할 수 없다 .

호 수락 (Call Admission): - 서비스는 필요 대역을 사전에 요구 - 망이 이 서비스의 요구를 받아들일 수 있으면 수락하고 QoS 를 보장한다 . 아니면 , 거부

Principle 4

R1R2

1.5 Mbps link

1 Mbps phone

1 Mbps phone

7-32

QoS 보장 시나리오

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

QoS-sensitive scheduling

request/reply

7 장 목차

Documents

Transcript of 7 장 목차