jaeilyou's Tistory Blog

Qos - Quality of service

 Qos를 하는 이유?

 1. 서비스의 차별화 : isp 업체에서 사용자의 등급에 맞추어 차별화된 서비스를 제공하기 위함

(돈을 더 내면 더 높은 대역폭을 할당하여 차별화)

 2. 확장 비용을 줄이기 위해서 : 예전에는 데이터의 양이 많이 않아 갖추어진 네트워크에 아무런 문제없이 통신이 이루어 졌지만 데이터의 양과 사용자가 많아짐에 따라 회선의 대역폭을 정리하여 원활하게 통신하기 위함.  돈이 많다면 회선을 더 설치하면 되지만 비용상 갖추어진 네트워크의 회선을 정리하여 쓰는것이 효율적.

(도로가 네트워크이고 차가 데이터라면 차의 대수가 작은경우 도로에는 혼잡이 발생하지 않지만 현재 차가 많아져 혼잡이 발생하므로 신호등으로 교통정리를 한다. 이 경우 도로를 넓히면 되지만 역시 비용이 문제 10부제등과 같은 정책으로 혼잡을 방지한다.)

 Qos 에서 사용하는 지연은 'End-to-End' 종단간 지연이며, 각 구간의 지연시간을 합하여 계산한다. 지연은 크게 장비 구간에서의 지연과 전송 구간에서의 지연으로 구분된다. 여기에는 연속지연, 전달지연, 큐잉지연, 포워딩 지연, 쉐이핑 지연, 네트워크 지연으로 세분화 된다.

 1> DELAY

 1. Serialization Delay (연속지연)

  ->패킷을 라우터에서 링크로 보내는데 소요되는 시간, 패킷의 크기와 비례적으로 증가하며

    대역폭과 반비례로 감소한다.

2. Propagation Dealy (전달지연)

  ->특정 구간 링크를 통해 한 비트를 전달하는데 소요되는 시간, 패킷의 크기와는 무관하며

    링크간 거리와 비례한다.

3. Forwarding Delay (포워딩지연)

  ->패킷이 라우팅 및 스위칭 프로세서에 의해 경로가 결정된 이후, 출력 인터페이스의 나가

    는 큐에 대기하는 시간.

4. Shaping Delay (버퍼링 지연)

  ->초과된 패킷에 대해(exceed) 일정 버퍼링을 실시하여 소요되는 시간.

5. Queuing Dealy (큐잉지연)

  ->패킷이 전송되기 전에 라우터 큐에 패킷이 대기하는데 소요되는 시간, 큐의 크기는 크게

    하면 오히려 문제점을 발생시킴.

6. Network Dealy (네트워크지연)

  ->ISP구간에서 소요되는 시간.

7. Jitter

  ->네트워크를 통해 신호가 전달되면서 발생되는 왜곡된 정보를 나타내는데 사용되는값,

    즉 지연의 편차 라고 한다.

8. Packet loss (패킷손실)

  ->패킷의 전달과정에 있어서 패킷이 손실되는 손실율을 말한다.

 * 패킷손실이 일어나는 경우?

 - 혼잡현상(congestion) :서비스를 할 수 있는 적정수준 이상으로 큐에 패킷이 쌓인 상태

 - RED(Random Early Detect) : 랜돔으로 패킷을 드롭하는 RED에 의해 패킷 손실

 - TCP 처럼 흐름 제어를 하는 트래픽 소스가 전송 속도를 증가 시키는 경우

 - 라우팅 알고리즘 때문에 많은 트래픽이 증가 되는 경우

 - 라우팅 패스에 오류가 발생되어 다시 라우팅 되는 경우

 - 공격자로부터의 공격으로 인한 트래픽 증가 현상 경우

 2> Interserv model Qos

  - 'End-to-End' 적용으로 트래픽의 흐름을 근거로 Qos 를 실시한다.

 - RSVP (Reservation Setup Protocol) 프로토콜로 일정의 대역폭을 예약한다.

 - 종단간에 RSVP 프로토콜을 지원해야 한다.

 - 'RSVP path', 'RSVP resv' 메세지를 이용하여 종단간 대역폭 예약을 실시한다.

 - 만약, 종단 사이에 RSVP 에 참여하지 않으면 'RSVP error'메세지를 전송하여 예약을 거부 및 종료한다.

 - 확장된 네트워크 환경 보다는 일정 소규모 구간에 사용 적합하다(기업대기업 본사대지사)

 Ex)

   본사 사장 전화기 ----A----B----C----D---- 지사 부장 전화기

                     [ 음성 트래픽 전용 20kbps 예약!!]

 - 예약된 대역폭은 다른 트래픽이 사용할 수 없다는 단점을 가지고 있다.

- RSVP는 WFQ 큐잉 기반하에 동작이 실시되며, 최대 32개의 프로우를 가진다.

- Router(config-if)#fair-queue 64 256 32 <- 최대 32개의 플로우 예약

  Router(config-if)#ip rsvp bandwidth 1000 500 <- 최대 1000kbps 중 플로우당 500kbps 예약 실시.

*Cisco Router serial interface : 기본 WFQ 동작

*Cisco Router ethernet interface : 기본 FIFO 동작

 3> Diffserv 간단 정리

  - 트래픽 종류를 근거로 차별화된 Qos 를 실시한다.

 - Qos 처리과정

   1. 트래픽 입력

  2. Classification(분류) -Classifier(분류자)로 들어오는 트래픽을 다양한 기준에 따라 여러개의 class로 구분한다.

  3. Meter 로 하여금 트래픽 측정 실시 - 분류자를 통과한 패킷은 각 플로우에 할당된 meter에 의해 특성을 측정받고 , 측정된 결과는 사전에 약속된 Qos 트래픽 특성과 비교되며, 그결과에 의해서 Maker에 의해 우선 순위별로 마킹된다.

  4. Marking

      - Layer 2 Frame (ISL,Dot1q) : Cos(3bit) 0,1,2,3,4,5,6,7

      - Layer 3 Packet : IP Precedence(3bit) 0,1,2,3,4,5,6,7

                             DSCP(6bit) 0,1,,,, 63

  5. Conditioner

   - Policing : 임계값 초과시 드랍 실시, 지연 없음

   - Shaping : 임계값 초과시 버퍼링 사용 후 전송 실시, 지연발생

   - 마킹된 패킷들은 컨디셔널을 지나면서 사전에 약속한 트래픽 대역폭 특성에 맞도록 조정되며, 컨디셔널은 Delay(지연)을 이용해 대역폭을 조정하는 Shaping,polishing을 실시한다.

  6. Congestion Avoidance (혼잡 회피)

   - Tail Drop : 디포르 동작, 큐에 트래픽이 다 차면, 그 이후 트래픽들은 드랍

   - TCP Slow Start : 윈도우 사이즈를 1씩 증가

   - RED : Random 하게 패킷을 드롭

   - WRED : 중요한 패킷에 가중치를 두어 중요하지 않은 패킷을 드롭시키게 하는방법

  7. Queue 할당 및 스케쥴링 실시(소프트웨어 큐 사용)

   - Queuing 스케쥴러를 할당 받아 스케쥴링 실시

   - FIFO Queuing :먼저 들어온 것부터 먼저 내보냄 first in first out

   - Priority Queuing : 클래스 별로 우선순위 할당, High, Medium, Normal, Low 구분

   - Custom Queuing : 16 개 클래스로 구분, 동등한 대역폭을 할당, Round-Robin 방식

   - WFQ Queuing : 꼬리가 먼저 들어온놈 먼저 내보냄 , 자동동작한다.

   - CBWFQ (Class-Based Weight Fair Queue) 큐잉 : 관리자가 참여하여 실시,
      Bandwidth command

   - LLQ (Low Latency Queue) : CBWFQ + PQ , cisco 권장

   - IP RTP Prioritization : LLQ 가 나오기 이전음성트래픽에서 사용했던 스케쥴러

  8. 시리얼리제이션 실시 (하드웨어 큐 사용)

   - 패킷은 링크로 전송하기 위해 하드웨어 큐인 TX 큐(FIFO)로 전송

  9. 트래픽 출력

  TCP Header (헤더) Window (윈도우) 필드 

 네 간단히 말해드리면 송신 해서 답장이 오면 윈도우크기를 지수승 만큼 늘리죠 첨엔 1이였다가 답장이오면
2로 늘리고 그리고 2개를 보내고 다시 2개의 답장이오면 4로 늘리고 이렇게요 하지만 임계값이 넘어가면
윈도우창의 크기를 1씩 증가시 키고 혼잡이 생기면 임계값의 크기를 반으로 줄이고 다시 윈도우 크기를 1로
시작해서 지수승씩하다가 임계값을 넘어가면 다시 윈도우의 크기를 1씩 증가 시킵니다.

 윈도우 사이즈는 수신측에서 정하는것외에 네트워크 혼잡값에 의해서도 결정됩니다..
둘중 작은값으로 결정이 되구요 수신측이 버퍼가 넉넉치 않아서 못받을 상황이 되면 사이즈를 0으로 해서 보내면 송신측은 수신측에서 다시 0이아닌 윈도우 사이즈를 보낼때까지 전송을 하지 않습니다.

윈도우 필드를 쓰는 이유는 윈도우 사이즈만큼은 수신측에서 확인응답을 받지 않고도 보낼수 있다는 것이죠 효율적인 전송이 가능함.

  지터(jitter)는 대기시간에서의 변동을 뜻한다. 두 개의 노드가 같은 스위치에 있지 않으면 대기시간은 패킷마다 크게 달라질 수 있다. 네트워크 대역폭이 포화 상태가 되면 지터는 늘어난다. 파일 다운로드나 웹 브라우징과 같은 애플리케이션의 경우는 이것이 늘 큰 문제가 되는 것은 아니다. 하지만 스트리밍 비디오와 VoIP는 높은 지터로 인해 크게 고통을 받는다. QoS는 스트리밍 트래픽에 보다 높은 대역폭 우선순위를 제공함으로써 지터를 줄이는 데 도움이 될 수 있다. 또 한 가지 해결책으로 버퍼 크기를 늘리는 방법이 있다.

MPLS란 무엇인가?

MPLS는 '멀티프로토콜 라벨 스위칭(Multiprotocol Label Switching)'을 말한다. MPLS 네트워크에서 유입되는 패킷은 '라벨 에지 라우터(LER)'에 의해 '라벨'로 할당된다. 패킷은 '라벨 스위치 경로(LSP)'를 따라 포워드되는데, LSP에서 각 '라벨 스위치 라우터(LSR)'는 전적으로 라벨의 컨텐츠를 토대로 포워드에 대한 판단을 내린다. 각 홉(hop)에서, LSR은 기존 라벨을 제거하고 패킷 포워드 방법에 대한 다음 단계를 설명해주는 새로운 라벨을 적용시킨다.

라벨 스위치 경로(LSP)는 몇 가지 이유로 네트워크 운영자에 의해 구성되는데, 특정 성능 수준을 보장하기 위해서, 그리고 네트워크 병목을 피해 경로를 설정하기 위해, 마지막으로 네트워크 기반의 가상 사설망을 위한 IP 터널을 생성하기 위함이 그 이유이다. 많은 경우에 있어서, LSP는 특정한 레이어 2 기술에 의존하지 않는 경우를 제외하고는 ATM이나 프레임 릴레이 네트워크에서의 서킷 스위치 경로와 차이가 없다.

LSP는 ATM, 프레임 릴레이 또는 이더넷과 같이 다양한 레이어 2 전송에 대해 구성될 수 있다. 따라서, MPLS가 제공하는 이점 중의 하나는 네트워크 이중 설치나 레이어 2 전용 제어 매커니즘에 대한 필요성을 없애주며 어떠한 전송 매체를 통해서도 특정 성능을 갖고 종단간(end-to-end) 서킷을 생성할 수 있다는 것이다.

MPLS가 제공하는 이점

라벨 기반 스위칭의 처음 목적은 레이어 3에 대한 레이어 2 스위칭의 속도를 향상시키는데 있었다. 라벨 기반 스위칭 방법을 통해 라우터는 IP 어드레스 목적지를 토대로 한 복잡한 경로 배정이 아닌 단순한 라벨의 컨텐츠를 토대로 포워드에 대한 판단을 실행할 수 있다. MPLS와 같은 기술에 대한 이러한 초기 '명분'은 더 이상 주요 이점으로 인식되고 있지 않은데, 레이어 3 스위치(ASIC 기반 라우터)가 대부분의 인터페이스 유형을 지원할 정도로 충분한 속도에서 경로 검색을 실행할 수 있기 때문이다.

하지만, MPLS는 IP 기반 네트워크에 대해 다른 많은 이점을 제공하고 있으며 대표적인 것으로는 다음과 같은 사항이 포함된다:

트래픽 엔지니어링 - 경로 트래픽이 네트워크를 통해 흐르도록 설정할 수 있는 기능과 트래픽 계층에 따라 성능을 설정할 수 있는 기능
VPN - MPLS를 사용할 경우, 서비스 사업자들은 암호화나 최종 사용자의 애플리케이션이 없이도 네트워크를 통해 IP 터널을 창출할 수 있다.
레이어 2 전송 - IRTF의 PWE3과 PPVPN 네트워킹 그룹에 의해 규정되고 있는 새로운 표준을 통해 서비스 사업자들은 이더넷, 프레임 릴레이와 ATM over IP/MPLS 코어 등의 레이어 2 서비스를 제공할 수 있다.
멀티플 레이어의 제거 - 일반적으로, 대부분의 사업자 네트워크는 SONET/SDH가 레이어 1에서 구성되며 ATM이 레이어 2에서 사용되고 IP가 레이어 3에서 이용되는, 오버레이(overlay) 구조로 이루어져 있다. MPLS를 사용함으로써, 사업자들은 SONET/SDH와 ATM 컨트롤 플레인의 많은 기능을 레이어 3로 이전시킬 수 있어 네트워크 관리와 네트워크 복잡성을 단순화시킬 수 있다. 그 결과, 사업자 네트워크는 SONET/SDH와 ATM 모두를 이전시킬 수 있게 됨으로써 IP 트래픽 전송에 있어서의 ATM 고유의 '셀 택스(cell-tax)' 문제를 해결할 수 있게 된다.

MPLS를 통한 VPN 구현 방법

MPLS가 '가상 서킷'이나 터널을 IP 네트워크 전체에 걸쳐 창출할 수 있기 때문에 서비스 사업자들이 MPLS를 VPN 서비스를 프로비저닝하는데 도입하고 있다. 일부 표준안이 제안되어 서비스 사업자들은 IP 네트워크에 대한 고객의 트래픽을 분리하고 고객 사이트에 대한 안전한 종단간(end-to-end) 접속을 제공하기 위한 VPN 서비스의 프로비저닝으로 MPLS를 사용할 수 있게 되었다.

VPN을 위해 MPLS를 사용함으로써 ATM이나 프레임 릴레이 서비스보다 더욱 향상된 트래픽 분리의 단순화를 이끌 수 있다는 것은 중요한 이점이다. 현재 MPLS는 패킷 암호화에 대한 어떠한 매커니즘도 없기 때문에, 고객 요구 사항에 암호화가 포함된다거나 IPsec과 같은 다른 방법을 요구할 경우 이를 충족시켜주어야 한다. MPLS VPN을 바라보는 최선의 시각은 프레임 릴레이나 ATM 가상 서킷과 동등한 기능을 제공하는 것에 두어야 할 것이다.

VPNs over MPLS를 구축하는데 있어서의 대안

IP 기반 VPN을 프로비저닝하기 위해 MPLS를 사용하는데 있어서 다양한 방법이 있다. MPLS/BGP VPNs는 BGP(Border Gateway Protocol)로의 확장을 통해 MPLS-VPN 을 구현할 수 있게 해준다. 이러한 방법에서, BGP는 확장된 어드레스를 처리하기 위해 BGP 멀티프로토콜 확장(MP-BGP)을 사용해 VPN-IPv4 정보를 전달하는데, 에지 라벨 스위치 라우터(프로바이더 에지 라우터) 사이에서 도달 가능한 정보(VPN-IPv4 어드레스)를 전달한다. 주어진 VPN에 대해 도달 가능한 정보는 VPN의 다른 구성원에 의해서만 보급된다. BGP 멀티프로토콜 확장은 VPN 라우팅 정보에 대한 유효한 수신자를 규명한다. VPN의 모든 구성 요인은 다른 요인에 대한 경로를 파악하고 있다.

MPLS를 사용하여 IP-VPN을 생성하는 또 다른 방법은 Network Based IP-VPN Architecture Using Virtual Routers 로, 다양한 가상 사설망에 대한 개별 라우팅 테이블을 유지하는 것에 토대를 투고 있으며 BGP를 사용하지 않는다.

MPLS VPN의 안정성

많은 사람들이 VPN을 공중 네트워크에 대해 '암호화된' 터널로 간주한다. MPLS-VPN은 암호화를 필요로 하지 않기 때문에, 많은 네트워크 엔지니어들은 공중 IP 네트워크로의 非 암호화 트래픽을 터널링 하는데 MPLS를 사용하는 것에 우려의 목소리를 제기하고 있다. MPLS VPN에 제기되고 있는 보안 부족이라는 우려를 없애기 위해서는 두 가지 요인이 고려되어야 한다:

ATM과 프레임 릴레이 PVC가 공중 ATM/프레임 릴레이 네트워크에서 격리되고 있는 것과 같은 방법으로 MPLS VPN 트래픽은 태그를 사용해 격리되어야 한다. 이는 MPLS VPN이 프레임 릴레이나 ATM 공중 네트워크 서비스와 동일한 보안 기능을 갖고 있다는 의미이다. 이러한 세 가지 유형의 트래픽 중 어떠한 것에 대한 가로채기(interception)도 서비스 사업자 네트워크에 대한 액세스를 가능하게 할 것이다.
MPLS VPN은 보안을 불가능하게 하지 않는다. 보안이 문제라면, 트래픽은 IPSec이나 SSL과 같은 프로토콜을 사용해, MPLS로 캡슐화되기 전에 암호화될 수 있다.

MPLS 보안에 대한 논쟁은 고객들에 대한 요구 사항에서는 실제로 그다지 중요하지 않을 수도 있다. 자사의 트래픽을 공중 ATM이나 프레임 릴레이 서비스를 통해 전송하는데 익숙한 고객들은 MPLS VPN 서비스에서도 동일한 수준의 만족도를 얻을 수 있다. 보안을 추가로 요구하는 고객들은 MPLS에 암호화 기능을 추가해 구축하면 된다.

음성신호를 얹어 송신할 수 있는 VoIP 기술이 발달함에 따라 제2의 전화혁명이 진행되고 있다. 기존의 전화망이 아닌 데이터망을 이용함으로써 회선의 단일화와 비용의 절감이라는 측면에서 수요가 급속히 증가하고 있어 기존의 아날로그 전화사업에 커다란 위협을 주고 있다.  특히 VoIP 기술 중 가장 핵심기술이라고 할 수 있는 호 처리 기술은 활발한 기술개발과 경쟁이 이루어지고 있어 음성통신기술의 변화를 주도하고 있다. 그 중 Gateway의 부담을 줄이고 간단함을 유지하는 MGCP(Media Gateway Control Protocol)에 대해 기술하고자 한다.

VoIP 기술은 그림 1에서 보는 바와 같이 주로 2가지 핵심기술로 나누어 질 수 있는데 호 처리 기술과 media data 처리 기술이다.

그 중 표준화 과정과 개발이 활발하게 진행되고 있는 부분이 호 처리 기술이라고 할 수 있는데, 전통적인 H.323과 SIP(Session Initiation Protocol), MGCP/MEGACO 등이 가장 주된 호 처리 기술이라고 할 수 있다.

H.323은 ITU 표준이며, 초기 LAN상에서의 IP-based 통신에 초점을 맞추어져 있었으나, 버전 2에서는 광대역과 일반적인 IP망에서 수용될 수 있도록 확장되었다. 현존하는 H.323은 몇몇의 작은 프로토콜들(H.255(call signaling channel), H.245(call control channel)...)을 수용하는 포괄적인 프로토콜이다. 또한 H.323은 네트웍 기반의 통신시스템을 구성하는 4가지의 구성요소를 관장하는데, 각 구성요소는 TE(Terminal Endpoint), GW(Gateway), GK(Gatekeeper), MCU(Multipoint Control Unit)이다. GK는 PSTN과의 상호연결 협약을 담당하고, MCU는 오디오/비디오 컨퍼런스에 대한 다수 접속을 가능하게 한다. GW는 표준전화를 멀티미디어 컴퓨터 대신 인터넷을 이용할 수 있도록 하고, 어드레스 문제를 해결하는 기능을 한다.

SIP은 하나 이상의 참관자를 가지는 세션을 생성/종단하고 변형하는 기능을 하는 어플리케이션 층 제어 프로토콜이다. IETF 표준이며, “request-response"모델을 사용하고, 중계자 없이 두 클라이언트 사이에서 시작되고 종단된다. 호 경로 배정을 목적으로 Redirect Server나 Proxy Server에 의해 중계될 수 있다.

MGCP는 MG(Media Gateway)와 MGC(Media Gateway Controller) 사이의 통신을 정의한 프로토콜이다. 이 프로토콜은 집중화된 네트웍 인프라구조 수준에서 복잡한 H.323의 명백한 단점을 부분적으로 보완해 준다. MGCP의 목표는 단순함을 유지하는 것이다. 오디오 신호와 데이터 패킷을 변환시켜주는 다중 서비스 패킷 네트워크에서 MG의 역할을 줄이고, Call Agent나 MGC(Media Gateway Controller)에서 호 처리와 제어를 지능적으로 처리하도록 구현된 프로토콜이다.

본 고에서는 단순함을 유지하면서 신뢰성 있는 호 처리를 구현하는 MGCP에 대한 구성과 동작방법 및 형식에 대한 기술하고자 한다.

MGCP 특징

MGCP는 외부 망의 호 처리 장비(Call Agent나 MGC 등)에 의해 MG가 제어될 수 있도록 설계되어 있는 프로토콜이다. 이전의 SGCP(Simple Gateway Control Protocol)과 IPDC(Internet Protocol Device Control)의 조합으로 구성된 프로토콜이라고 할 수 있다. 또한 전달 방식은 UDP-based로 통신하므로 TCP를 사용한 경우보다 연결 관리에 따른 추가적인 복잡성을 회피한다. 또한 최소한의 명령 집합으로 구성되어 단순함을 유지한다.

MGCP는  “stateless” 프로토콜이고, 이것이 핵심적인 특징이다. “stateless”의 뜻은 두개의 호 처리 유닛 간의 진행 순서인 “state machine”이 필요하지 않고 MGC와 MG 간의 이전 과정을 저장할 여분의 메모리도 필요 없다는 결과를 초래한다. 이것은 “call state”와 혼돈 되어서는 안 된다. “call state”는 MGC에서 유지하고 있도록 한다.

VoiP 란?

시간과 공간의 제약을 받지 않는 전화 통화방식
기존의 전화방식은 항상 고정된 장소에서 이미 지정된 전화 번호를 가지고 상호 통화를 하는 방식이었다. 그러나 VoIP 기술이 도입되면서 등장한 IP 텔레포니(Telephony) 방식은 사용자가 시간이나 공간에 상관없이 어디서나 자신의 번호를 가지고 통화가 가능하다. 즉, IP주소와 사용자의 정보가 DB화 되어 이를 통하여 상호 연결되므로 가능하게 된 것이다.

다양한 부가 서비스(어플리케이션) 개발

음성망과 데이터통신망을 연결함으로써 또한 데이터통신망을 통해 음성을 전달함으로써 새로운 많은 서비스를 개발할 수 있다. 각 망에 고유하게 존재하는 서비스들을 이용하거나 두 망의 특징을 이용해 새로운 서비스를 개발해낼 수 있다. 음성메일이나 콜센타 애플리케이션, 스크린팝, IVR(Interactive Voice Response;대화식 음성 응답) 시스템이 예라 할 수 있다.

VoIP 시스템

시스템을 구축하기 위해서는 기본적으로 다음과 같은 구성요소(기능)를 갖추어야 한다.

Media Gateway

각 네트워크(PSTN, IP)에서 데이터가 전달되기 위해서는 각 네트워크에서 전달될 수 있는 데이터로 우선 변경한 후에 가능하다. Media Gateway는 멀티미디어 데이터간의 교환작업을 수행하고, 변경한 데이터를 해당 네트워크에 전달하는 기능을 수행한다. 음성, 디지털 데이터간의 교환작업은 여러 가지 음성압축방법(G.711 PCM, G.726 ADPCM, G.728 LD-CELP 등)을 사용하여 이를 수행할 수 있고, IP망에서의 멀티미디어 데이터 전송은 RTP(Real-time Transport Protocol)/RTCP(RTP Control Protocol)와 같은 프로토콜을 통해서 할 수 있다. Media Gateway의 제어는 MGCP(Media Gateway Control Protocol)/ MEGACO(Media Gateway Control)을 통해서 할 수 있다.

아래 그림은 미디어 게이트웨이의 동작과정을 보여준다.

Signaling Gateway

PSTN에서 콜 시그널링은 매우 중요한 기술이다.

기존 PSTN에서 사용되는 콜 시그널링은 CAS(Channel Associated Signaling)와 CCS(Common Chnnel Signal)로 나뉘는데, CCS에는 ISDN이나 SS7(Signaling System 7)등이, CAS는 MFC-22(E1), 윈크스타트(WinkStart : T1) 등이 해당된다. 그리고 IP네트워크에서는 H.323, SIP, MGCP, MEGACO 등과 같은 프로토콜을 사용하여 콜 시그널링을 수행한다. 시그널링 게이트웨이는 이러한 PSTN와 IP 네트워크에서의 시그널들을 서로 사용할 수 있도록 변환하는 기능을 수행한다.

SS7은 전화망에서 효율적인 트래픽 처리와 진보된 서비스를 제공하기 위해 교환기간 또는 교환기와 부가서비스 장비간의 필요한 정보를 전달하기 위한 프로토콜이다. 현재의 전화망은 보다 다양하고 유용한 서비스를 고객에게 제공하기 위하여 SS7을 기초로 한 지능망(Intelligent Network), 공통선망으로 진화되고 있다.

VoIP에 있어서 IP 네트워크의 일반 사용자가 PSTN의 서비스를 이용하기 위해서는 SS7을 다시 IP로 변환하여야 하는데 이는 대단히 중요한 VoIP 프로토콜 기술 중의 하나이다. 아직까지 표준이 제시된 상태는 아니고 각 업체마다 독자적인 방식으로 프로토콜을 적용하고 있다.

아래는 SS7의 프로토콜구조와 지능망 서비스에 대한 것을 보여준다.

Addressing/Naming & Routing
PSTN에서는 E.164 주소체계를 사용하고, 일반 IP 네트워크에서는 IPv4, IPv6 등의 주소 쳬계를 사용한다. 네트워크 요소를 고유하게 구별할 수 방법이 요구된다. 콜 설정을 하기 위해서 시그널이 해당 목적지로 도달하도록 하는 라우팅 기술도 필요하다. H.323에서는 Gatekeeper에서 이를 수행하고, IETF에서는 ENUM, TRIP과 같은 프로토콜을 제시하고 있다.

QoS(Quality of Service) 보장

IP Telephony에서 중요하게 다루어야 하는 기술중의 하나가 QoS 를 보장하는 방법이다. 아직까지 인터넷 텔레포니가 기존 전화를 대체하지 못하는 중요한 이유중의 하나가 통화 품질이 좋지 않다는 것이다. PSTN의 경우 설정된 콜 연결이 자원을 할당 받은 후에 이루어지지만, IP 기반의 인터넷의 경우는 Best Effort 데이터 전송 방식을 제공하기 때문에 서비스의 고품질을 보장하지 못하는 것이다.

QoS 보장은 일반적으로 다음 두 가지로 구분될 수 있다. 첫째는 응용의 QoS 요구에 따라 인터넷 망에서 양단간의 경로에 자원을 예약하는 방법이 있다. 둘째는 IP 데이터그램의 우선순위를 이용하는 것이다. 일반 인터넷 망에서 이러한 작업은 힘들지만 ATM과 같은 경우은 대역폭 관리 정책에 따라 망 트래픽을 분류하고 분배할 수 있다.

RSVP(ReSource reserVation Protocol)는 IETF 시그널링 프로토콜의 하나로 Flow는 End-to-End(양단간)까지 시그널링에 의해 정적 대역폭을 할당받는다. 기본적으로 Queue 공간을 예약하는 방법을 사용한다.

아래 그림은 RSVP의 동작과정을 보여준다.

<RSVP Operation>

다음은 IP datagram의 TOS 필드를 이용한 우선순위 방법이다. 아래 그림은 IP 네트워크에서 사용되는 Layer 2, Layer 3 의 메시지 형식이다.

그림에서 볼 수 있듯이 Layer 3의 데이터그램 메시지는 TOS(Type Of Service)라는 필드를 가지고 있다. 서비스 타입을 정의하는 역할을 수행하는 필드이지만 실제 인터넷 망에서는 이 필드를 사용하지 않고, 만약 특정 관리 네트워크(예, ATM)에서 트래픽 관리 정책에 이 필드를 사용한다면 QoS를 보장할 수 있다. 하지만 트래픽이 특정 도메인이나 carrier boundary 안에서만 존재해야 하며, 방법 또한 복잡하고 비용이 비싸다는 단점이 있다.

QoS를 보장하기 위해 한가지 더 고려해야 할 점이 Fragmentation 이다.

IP 네트워크에서 사용되는 일반적인 응용들의 패킷은 음성 패킷보다 상대적으로 큰 바이트수를 가진다. (FTP의 경우 1000 바이트이상이지만, 음성의 경우 20 바이트이다.) 즉, Burst한 LAN 트래픽 발생시 음성 패킷의 지연을 초래하게 된다. Congestion 예상 지역에 Fragmentation을 적용하여 지연을 줄여 QoS를 보장할 수 있다.

VoIP 시스템 구현

VoIP 관련 표준화 기구는 ITU, IETF, ETSI가 있다.

ITU(Internet Telecommunication Union)의 SG(Study Group) 16에서는 멀티미디어 단말과 보안에 관하여 연구하고 있으며, H.323 프로토콜을 이용한 VoIP 시스템 구현 방법을 제시하고 있다.

IETF(Internet Engineering Task Force)에서는 웹 서비스와 PSTN/ISDN의 상호 연동에 관해서 연구하고, VoIP 관련 WG(Working Group)으로는 SIP(Session Initiation Protcol;SIP-시그널링 프로토콜), MMUSIC, IPTEL(IPTelephony), PINT(PSTN-Internet service), IMPP(Instant Messaging and Presence Protocol), SIGTRAN(Telephony signaling transport), ENUM(Telephone Number Resolution)등이 있다. 그리고 IETF는 SIP을 이용한 VoIP 시스템 구현에 힘쓰고 있다.

ETSI(European Te lecomm. Standards Institute)는 TIPHON(Telephony and IP Harmonization Over Networks)과 SPS5(UNI/NNI signaling aspects)를 제시하고 있다.

H.323

H.323은 하나의 단순한 프로토콜이 아니다. H.323은 ITU의 여러 프로토콜을 이용하여 VoIP 시스템을 구성하는 방법에 대해 기술한 것이다. 실제 시그널링 변환, 미디어 전송, 콜 설정 등의 작업은 ITU의 여러 프로토콜에 의해서 이루어진다. 콜 설정에 대한 작업을 수행하기 위해서는 H.225.0, capability/media 제어를 위해서는 H.245, 음성, 화상 미디어 전송을 위해서는 RTP/RTCP을 사용하고, 데이터 전송에는 T.12X를 사용한다.

각각의 미디어에 대해서도 세분화된 프로토콜을 사용하는데, Audio의 경우는 ITU에서 이미 제시한 G.711, G.729등과 같은 G.7xx 프로토콜 등과 또 다른 표준(예, GSM)과 기타 코더를 사용하며, 비디오 스트림에 대해서는 H.261, H.263과 같은 G.26x 프로토콜을 사용한다. 그리고 일반 데이터의 경우는 T.12x 프로토콜을 사용하며, Fax의 경우는 T.38 프로토콜을 사용한다.

아래 그림은 H.323 시스템을 간단히 보여준다.

다음 그램은 H.323 의 프로토콜 스택을 나타낸 것이다.

<H.323 Protocol Stack>

H.323 시스템은 크게 Terminal, Gatekeeper, Gateway, MCU로 구분해 볼 수 있다.

Terminal

실제 사용자에 의해서 사용되는 장치로서 일반 전화, 팩스, 멀티미디어 장비(마이크로폰, 스피커, 카메라 등)를 갖춘 PC가 이에 해당한다.

SIP(Session Initiation Protocol)

SIP는 종단간(end-to-end)의 멀티미디어 세션을 생성, 수정, 해제하는 응용 계층의 제어(시그널링) 프로토콜로, 여기서 멀티미디어 세션은 multimedia conference, internet telephone call, multimedia application 등이 될 수 있다. 한가지 중요하게 알아두어야 할 것은 SIP은 H.323과 같이 여러 프로토콜들의 조합으로 VoIP 서비스를 한꺼번에 수행하는 프로토콜이 아니라 단순하게 세션 설정만을 다루는 프로토콜이라는 점이다. 이는 SIP이 간단하면서도 여러 다른 프로토콜들과 함께 사용될 수 있는 확장성을 가지고 있다는 것을 말해준다.

- 구성요소/기능

SIP 요소

SIP을 이루는 구성요소는 크게 user agent 와 network server 로 나뉜다.

User agent 는 다시 user agent client(UAC: calling user agent)와 user agent server(UAS: called user agent) 로 나뉘는데, 전자는 세션에 참여 시키고자 하는 상대방에게 request를 보내는 역할을 하고, 후자는 SIP request에 대한 적절한 response를 반환하는 역할을 한다. Network server는 proxy server와 redirect server 로 나뉘는데, 전자는 caller와 callee 사이의 SIP Message들을 forwarding하고, 후자는 caller의 INVITE request (세션설정(참여)를 요청하는 SIP 메시지)를 받고 callee에 대한 정보를 다시 caller에게 전달하는 역할을 한다. 이외에도 사용자의 위치(location) 정보를 저장하고 있는 location server가 있다.

주소지정 방식/라우팅
SIP에서는 각 사용자마다 고유한 SIP URI(주소)를 부여한다. 형식은 간단히 sip:user@host으로 표현할 수 있다. “sip:”은 이 주소가 sip 프로토콜에서 사용하는 주소임을 알려주고, user는 사용자의 이름, host 는 해당 터미널의 주소를 표현할 수 있는데 여기에는 PC, 네트워크 서버 등의 IP주소나 도메인명, 전화번호, 팩스번호 등을 사용할 수 있다. SIP은 IP 프로토콜이기 때문에 PSTN의 전화, 팩스와 같은 장치를 구별하거나 라우팅하는 방법이 필요한다. IETF는 이를 위해 ENUM(Telephone Number Resolution)과 TRIP(Telephony Routing over IP)을 제안하고 있다.

ENUM은 IETF ENUM WG에서 연구가 진행중이고, E.164 전화 번호를 인터넷 DNS에서 구별지을 수 있도록 변환하는 역할을 수행한다. 예를 들어 전화번호 1-212-691-8215를 DNS entry 5.1.2.8.1.9.6.2.1.2.1.e164.foo와 같은 방식으로 변환할 수 있다.

TRIP은 IPTEL WG(IP Telephony Working Group)에서 연구가 진행중이고, BGP(Border Gateway Protocol)기반의 전화번호를 통한 라우팅을 가능하게 하는 역할을 수행한다.

메시지 1 – Request
SIP의 메시지 전달과정이나 형식은 HTTP의 메시지 형식을 응용하였다.
SIP이 확장되어 오면서 몇 가지 request 메소드들이 추가되었지만, 기본적인 메소드는 다음 6가지이다.
INVITE : call 설정 요청을 한다.
ACK : INVITE 요청에 대해서 서버로부터 final response를 받았을 때 이에 대한 Acknowledge(ACK)를 한다.
BYE : call을 Release한다.
CANCEL : pending request(아래에서 기술될 SIP 네트워크 구성요소 중 proxy server는 해당 INVITE 요청을 가능한 여러 목적지로 request 를 fork하여 forwarding한다. 이때 이러한 request 들을 pending request 라 한다.)를 Cancel 한다. BYE와 구별되어야 하는 점은 CANCEL은 단순히 request 를 cancel하는 것이고 BYE는 세션 자체를 종료하는 것이다.
OPTIONS : capability에 대한 정보를 요구한다.
REGISTER : SIP location server에 사용자 자신의 위치(location) 정보를 알려준다.
이외에도 INFO, COMET, PRACK, SUBSCRIBE, NOTIFY등의 메시지가 있다.

메시지 2 – Response
Response 는 HTTP에서와 같이 클래스에 특정 의미를 지니고 있는 다음 6가지 class를 가지고 있다. 그리고 각 클래스는 Provisional과 Final의 두 가지 상태로 구분될 수 있는데, Provisional Response는 세션 설정을 하는 동안 필요한 정보를 전달하기 위한 response 이고 Final Response는 세션 설정의 제일 마지막에 성공/실패 등을 알려주기 위한 response이다.

<SIP Response>

메시지 전송 프로토콜
SIP 자체가 응용계층 프로토콜이기 때문에 메시지를 전송하기 위해 TCP와 UDP, 그리고 SCTP(Stream Control Transmission Protocol)을 사용할 수 있다. 그렇지만 일반적으로 SIP 메시지들은 대부분 UDP를 사용하여 전달하고 SIP의 REGISTER 메소드와 같이 전송할 데이터의 양이 많은 경우에는 TCP를 사용할 수도 있다.

SDP(Session Description Protocol) 사용
SDP는 세션을 기술하는 프로토콜이다. SDP는 기본적으로 세션 이름과 목적, 세션이 active되어 있는 시간, 세션에 사용될 미디어정보, 미디어를 전송하기 위해 필요한 정보(주소, 포트, 포맷등)을 포함하고, 추가적으로 conference에 의해 사용될 bandwidth에 대한 정보를 포함한다. 앞서 언급했듯이 SIP은 단순한 세션 설정 프로토콜일 뿐, 세션 자체에 대한 어떠한 동작도 하지 않는다. SIP은 세션 설정 후에 양쪽 endpoint에서 실제 데이터를 주고받는 방법을 명시하기 위해 SDP를 사용한다.

아래 그림은 SDP의 예를 보여준다.

위 SDP 예에서는 audio와 video에 대한 세션 정보를 기술하고 있다. 예에서는 음성, 비디오 압축 기술에 PCUM, G723, H.263등의 프로토콜을 사용하고 미디어 데이터 전송에는 RTP를 사용하고 있음을 볼 수 있다. 이외에도 양단간의 터미널의 종류와 기능에 따라 다른 여러 가지 압축 기술과 미디어 전송프로토콜들(RTSP, RTP, RTCP)을 사용할 수 있다.

- 동작

Registration
Registration은 사용자가 자신의 위치(location) 정보를 location server에게 알려주는 작업이다. REGISTER 메소드에 자신의 정보를 포함시켜 location 서버로 보냄으로써 이를 수행할 수 있다.

아래 그림은 사무실에 있는 전화, PC 집에 있는 PC를 Location Server에 등록하는 과정이다. 각 장치들은 Location server의 DB에 저장되고 proxy, redirect 시에 DB에 저장된 사용자의 정보를 이용함으로써 올바른 세션 설정을 할 수 있다.

<Registration Operation>

Proxy

SIP 네트워크 서버에서는 UAC로부터 INVITE 메시지(세션 연결 요청)를 받고 call processing 정책에 따라 이를 proxy할 것인지 redirect할 것인지를 결정한다. Proxy server로써의 역할을 수행할 경우는 해당 request 를 가능한 사용자의 장치들(UAS)에게 forwarding하고 UAS로부터의 응답을 대신 UAC로 전달해주는,즉 대리자,의 역할을 수행한다. 아래 그림은 proxy 동작과정을 보여준다.

<Proxy Operation>

Redirect
Redirect server로써의 역할을 수행할 경우, callee(요청받은 사용자)에 대한 적절한 정보(예, 주소)를 caller(요청한 사용자, UAC)에게 전달해주어 caller가 다시 INVITE 요청(세션 요청)을 수행하도록 하게 한다.

<Proxy Operation>

- SIP을 이용한 VoIP 시스템 구현

SIP은 단지 시그널링 프로토콜이기 때문에 VoIP 나타내 보면 아래 그림과 같이 나타낼 수 있다.

세션 설정을 위해서는 SIP 프로토콜을 사용하고 세션 설정이 이루어진 후에는 RTP/RTCP 등과 같은 미디어 전송프로토콜을 사용하여 통신을 할 수 있다.

- SIP 확장

SIP은 시그널링 프로토콜이면서 또한 확장성을 갖추고 있어서 기본적인 세션설정서비스 이외에도 다른 서비스들을 위해 확장되어 사용되고 있다. IETF의 IMPP WG에서는 Presence & Instant Messaging 시스템을 구축하는데 SIP을 확장하여 사용하고, IETF의 PINT에서도 SIP을 시그널링 프로토콜로서 사용하는 방법을 제시하고 있다. 더욱이 근래에는 Mobile 네트워크 환경에서 terminal, service mobility를 지원하기 위해 SIP을 사용하는 방법들이 제시되고 있다.

H.323과 SIP

네가지 관점에서 H.323과 SIP을 비교해보자.

첫째, 복잡성(Complexity)
H.323은 여러 프로토콜들간의 상호 동작을 통해 만들어졌기 때문에 많은 헤더를 가지고 있으며 디버깅과 개발이 어렵다. 반면 SIP은 단순한 시그널링 프로토콜로써 단지 몇 가지 헤더만을 포함하는 텍스트 기반의 메시지를 주고 받기 때문에 디버깅이 쉽다.

RTSP(Real-Time Streming Protocol)

>> RFC 2326

☛ 개요 

   많은 인터넷 멀티미디어 사용자는 재생 중지 이전이나 이후 시점으로 재생 재위치, 급전진 재생, 되감기 재생 등을 이용하여 연속적인 미디어의 재생을 제어하려고 한다. 이런 기능은 DVD 비디오를 볼 때 DVD 플레이어를 조작하거나, 음악 CD를 들을 때 CD 플레이어를 조작하는 것과 비슷하다. 사용자가 재생을 제어할 수 있도록 하려면 미디어 플레이어와 서버는 재생 제어정보를 교환하는 프로토콜이 필요한데 RTSP가 바로 그것이다.

☛ RTSP가 하지 않는 것

- 오디오와 비디오를 압축하는 기법에 대해서는 정의 하지 않는다.

-  네트워크 상으로 전송하기 위해서 오디오와 비디오를 어떻게 패킷으로 캡슐화 하는지에 대해서는 정의하지 않는다.

스트리밍 미디어를 캡슐화하는 것은 RTP 또는 임의의 사적 프로토콜에 의해서 제공될 수 있다. 예를 들어, 리얼네트웍스사의 오디오/비디오 서버와 플레이어는 서로에게 제어정보를 전송하기 위해 RTSP를 사용한다. 그러나 미디어 스트림 자체는 RTP 패킷들이나 EH는 다른 사설 데이터 타입으로 캡슐화 할 수 있다.

- 스트림된 미디어의 전송 방식에 대해서는 제약하지 않는다.

 RTSP는 UDP나 TCP상으로 전송될 수 있다.

- 미디어 플레이어의 오디오/비디오 버퍼링 방식을 제약하지 않는다.

 오디오/비디오는 클라이언트에 도착하는 즉시 재생될 수도 있고, 또는 몇 초의 지연 후에 재생 될 수도 있으며, 재생하기 전에 모두 다운로드할 수도 있다.

   그림을 보면 먼저 웹 브라우저는 웹 서버에게 프리젠테이션 기술 파일을 요청한다. 프리젠테이션 기술 파일은 연속 미디어 파일의 동기화에 대해서 지시할 뿐만 아니라 연속 미디어 파이들을 참조할 수 있다. 각각의 연속 미디어 파일에 대한참조는 URL 기법인 rtsp://로 시작된다. 다음에 파일을 제시한 후 이 프레젠테이션에서 오디오와 비디오 스트림은 병렬로( 같은그룹의 일부로) 립 싱크해서 재생된다. 오디오 스트림에 대해 미디어 플레이어는 두 종류의 오디오 기록, 즉 저품질 기록과 고품질 기록 중에서 선택(스위치)할 수 있다.

   웹 서버는 프레젠테이션 기술 파일을 HTTP 응답 메시지에 캡슐화해서 브라우저에게 전송한다. 브라우저는 HTTP 응답 메시지를 수신하면 그 메시지의 content-type 필드에 맞게 미디어 플레이어를 가동한다. 프레테이션 기술 파일은 앞 예에서 본 것처럼 URL 기법인 rtsp://를 사용하는 미디어 스트림에 대한 참조를 포함한다. 그 뒤에 플레이어와 서버는 그림처럼 서로에게 일련의 RTSP 메시지를 전송한다. 플레이어는 RTSP SETUP 요청을 보내고, 서버는 RTSP OK 메시지로 응답한다. 플레이어는 저품질 오디오에 대한 RTSP　PLAY 요청을 보내며, 서버는 RTSP OK 메시지로 응답한다. 이 시점에서 스트리밍 서버는 저품질 오디오를 자신의 대역내 채널로 내보낸다. 나중에 미디어 플레이어는 RTSP PAUSE 요청을 보내고, 서버는 RTSP OK 메시지로 응답한다.사용자가 실행을 끝내면, 미디어 플레이어는 RTSP TEARDOWN 요청을 보내며, 서버는 RTSP OK 메시지로 응답한다.

☛ HTTP와 RTSP의 유사점 & 차이점

- 유사점 : 모든 요청과 응답 메시지는 ASCII 텍스트로 되어 있으며, 클라이언트는 표준화된(setup, play등) 방법을 사용하고, 서버는 표준 응답코드로 답한다.

- 차이점 : RSTP 서버는 진행 중인 각 RTSP 세션의 클라이언트 상태를 계속 감시한다는 것이다. 예를 들어 서버는 클라이언트가 초기상태, 재생상태, 정지상태에 있는지 그 여부를 계속 검사한다. RTS 요청과 응답에 포함되어 있는 세션번호 및 순서번호는 서버가 세션 상태를 감시할 수 있도록 한다. 세션번호는 전체 세션에서 그대로 유지된다. 서버는 세션번호와 현재 순서번호를 돌려준다.

☛ SETUP

- 클라이언트는 스트리밍할 파일의 URL과 RTSP 버전이 포함된 SETUP 요청해서 세션을 초기화 한다. SETUP메시지는 미디어가 전송되어야 할 클라이언트의 포트번호도 포함한다. 또한 패킷화를 수행하는 프로토콜인 RTP를 사용해서 UDP상으로 미디어를 전송하도록 지시한다.

RSVP(Resource Reservation Protocol)

 >> RFC 2205

☛ 개요

   네트워크가 QoS를 보장을 하기 위해서는 호스트에서 실행되고 있는 애플리케이션들로 하여금 인터넷에서 자원을 예약할 수 있도록 하는 시그널링 프로토콜이 있어야만 하는데 RSVP는 인터넷을 위한 그런 시그널링 프로토콜이다.

   RSVP 프로토콜은 애플리케이션들로 하여금 자신의 데이터 흐름을 위해 대역폭을 예약할 수 있도록 한다. 이 프로토콜은 애플리케이션 데이터 흐름을 대신해서 호스트가 네트워크로부터 특정 양의 대역폭을 요청하기 위해 사용된다. 또한 RSVP는 라우터가 대역폭 예약 요청을 전달하기 위해서 사용된다. 또한 RSVP는 라우터가 대역폭 예약 요청을 전달하기 위해서 사용된다. RSVP를 구현하려면 수신자, 송신자, 라우터에 RSVP 소프트웨어가 있어야만 한다.

1. 멀티캐스트 트리에서 대역폭 예약을 할 수 있게 한다.

2. 수신자지향(receiver-oriented), 즉 데이터 흐름의 수신자가 그 흐름을 위한 자원예약을 시작하고 유지한다.

   옆의 그림은 트리의 맨 위로부터 트리의 맨 아래에 있는 호스트들로 데이터 흐름이 있는 멀티캐스트 트리를 보여준다. 비록 데이터는 송신자가 보내지만, 예약 메시지는 수신자가 보낸다. 라우터는 예약 메시지를 송신하는 쪽인 상향으로 전달할 때 이 예약 메시지를 하향에서 오는 다른 예약 메시지들과 합칠 수 있다.

☛ RSVP가 하지 않는 것

1. 네트워크가 데이터 흐름에게 예약된 대역폭을 제공하는 방식에 대해서 명시하지 않났다.

    RSVP는 단지 애플리케이션으로 하여금 필요한 링크 대역폭을 예약할 수 있도록 해주는 프로토콜일 뿐이다. 일단 예약이 되면, 데이터 흐름에게 예약된 대역폭을 실제로 제공하는 것은 인터넷의 라우터에게 달려 있다. 이러한 일들은 스케줄링기법을 사용하면 가능하다.

2. 라우팅 프로토콜이 아니다.

   RSVP는 예약을 해야 하는 링크들을 결정하지 않는다. 대신에 흐름을 위한 경로를 결정하기 위해 하부의 라우팅 프로토콜에 의존한다. 일단 경로가 결정되면 RSVP는 이 경로상의 링크들의 대역폭을 예약할 수 있다. (경로가 바뀌면 RSVP가 자원을 재예약하는 것을 볼 수 있다.)일단 예약이 되면, 라우터의 패킷 스케줄러는 데이터 흐름에게 예약된 대역폭을 실제로 제공해야 한다. 따라서 RSVP는 QoS를 보장하는 요소들 중 한 가지 일 qNs이다.

   RSVP는 시그널링 프로토콜(signaling protocol)이라고 한다. 이것은 RSVP가 호스트로 하여금 데이터 흐름을 위한 얘약을 설정하고 해제할 수 있게 하는 프로토콜이라는 것을 뜻한다.

* 이질적인특성을 가진 수신자들의 문제를 해결하기 위해 비디오와 오디오를 계층적으로 인코딩하도록 제안하고자 하낟. 예를 들어, 비디오는 두 계층으로 인코딩할 수 있다. 즉, 기본계층과 향상된 계층이다. 기본 계층은 20kbps의 전송률을 갖는 반면에 향상된 계층은 100kbps의 전송률을 가질 수 있다. 이런 식으로 28.8kbps의 접근을 갖는 수신자는 저품질의 기본 계층 이미지를 수신할 수 있고 128kbps의 수신자는 고품질의 이미지를 구성할 수 있도록 두 계층 모두 수신할 수 있다.

송신자는 모든 수신자들의 수신율을 알고 있을 필요가 없으며, 단지 수신자들의 수신율 중 최고 수신율만 알면 된다. 송신자는 비디오나 오디오를 여러 계층으로 인코딩해서 최고율까지의 모든 RP층을 멀티캐스트 트리로 전송한다. 수신자는 자신의 수신율에 맞는 계층만을 받아들인다. 네트워크 링크 대역폭을 너무 많이 낭비하지 않기 위해서, 이질적인 수신자들은 자신이 처리할 수 있는 수신유은 네트워크에게 알려야 한다. RSVP는 이질적인 수신자들에게 자원을 예약해주는 문제에 가장 관심을 기울인다.

☛ 콜 수락(Call Admission)

   레스토랑의 매니저가 레슽랑의 테이블 수보다 더 많은 예약을 받아들일 수 없는 것처럼, 라우터가 예약하는 링크의 대역폭 양은 링크의 용량을 초과해서는 안 된다. 따라서 라우터는 새로운 예약 메시지를 수신할 EO마다 멀티캐스트 트리상의 하향 링크들이 예약을 수용할 수 있는지에 대해서 먼저 결정해야 한다. 이와 같은 수락 시험은 라우터가 예약 메시지를 수신할 때마다 수행된다. 만일 수락 시험이 실패하면, 라우터는 예약을 수락하지 않고 오류 메시지를 적절한 수신자에게 보낸다.

☛ 동작

1. 전송근원지는 멀티캐스트 트리를 통해 RSVP path 메시지를 보내서 자신의 콘텐츠를 광고하는데 이를 통해 콘텐츠에 필요한 대역폭과 소프트 상태 타임아웃 간격, 그리고 송신자로의 업스트림 경로에 대한 정보를 나타낸다. 각 수신자는 RSVP 예약 메시지를 멀티 캐스트 트리의 상향으로 전송한다 예약 메시지는 수신자가 송신지로부터 데이터를 수신하고자 하는 비율을 명시한다. 예약 메시지가 라우터에 도착하면, 라우터는 이 예약을 수용할 수 있도록 자신의 패킷 스케줄러를 조절한다. 라우터에게 예약받는 상향대역폭의 양은 하향예약된 대역폭에 의존한다.

   그림을 보면 우리는 RSVP가 수신자 지향이라는 것을 알 수 있다. 즉, 데이터 흐름의 수신자는 이 흐름에서 사용하는 자원예약을 초기화 하고 유지한다. 각 라우터는 멀티 캐스트 트리의 하향 링크들로부터 예약 메시지를 수신하며 상향 링크로 단 하나의 예약 메시지를 전송한다.

RTP (Real Time Protocol)

>> RFC 3550

☛ 개요

   RTP는 오디오, 비디오 및 시뮬레이션 데이터와 같은 실시간 데이터를 멀티캐스트 또는 유니캐스트 네트웍을 이용해서 전송하는 응용 서비스에 알맞은 단말-대-단말 네트웍 전송 기능을 제공한다.  RTP는 자원 예약을 수행하지 않으며, 따라서 적시 전달, 순차 전달과 같은 서비스 품질도 보장하지 않는다. RTP 데이터 전송 기능은 제어 프로토콜에 의해 확장되는데, RTCP라 불리우는 이 제어 프로토콜은 데이터의 전달 상황을 감시하며, 최소한의 제어 기능과 매체 식별 기능을 제공한다. RTP와 RTCP는 하위의 전송 및 네트웍 계층에 무관하게 설계되었다.

   RTP는 별개의 독립 계층으로 구현되기 보다는 특정 응용에서 요구되는 정보를 제공하여 프로토콜의 처리가 응용의 처리 과정으로 통합될 수 있도록 설계되었다. 따라서 기존의 프로토콜들과는 달리 RTP는 응용의 필요에 따라 헤더를 변경하거나 추가하여 응용에 맞는 프로토콜이 될 수 있도록 하는 일종의 맞춤형 프로토콜이다. 이 문서에서는 RTP를 이용할 수 있을 것으로 추정되는 모든 응용들이 공통적으로 필요로 할 기능들 만을 명시하고 있다. 따라서, 특정 응용 서비스에 필요한 RTP를 구현하기 위해서는 이 문서 이외에 RTP 페이로드의 종류와 형식을 정의하는 프로파일 문서(Profile Specification)와 페이로드의 전송 방법을 정의한 페이로드 형식 문서(Payload Format Specification)가 필요하다. 

☛ 특징

- UDP상에서 실행

  UDP는 TCP에 비해 신뢰성이 낮은 반면, 더 빠르게 데이터를 전달함. 이러한 UDP의 특성을 이용하여 RTP가 등장하였다. 그래서, RTP는 그 자체로 QoS 보장이나 신뢰성을 제공하지 못한다.(RTCP를 통해 QoS를 보장)

- 송신자는 데이터 단위를 RTP 패킷으로 캡슐화한 후 그 패킷을 UDP 세그먼트로 캡슐화해서 IP에게 넘겨준다.

- RTP 세션 다중화

  효과적인 프로토콜 처리를 위해서 다중화 점의 수는 최소화되어져야 한다. RTP의 경우에 다중화는 목적지 전송 주소에 의해 수행된다.. 예를 들어 오디오와 비디오로 이루어지는 회의에서 각 매체는 자신만의 목적지 전송 주소를 가지는 독자의 RTP 세션으로 전송되어야 한다.  

- 수신자는 UDP 세그먼트로부터 RTP 패킷을 추출한 후에 RTP 패킷으로부터 데이터 단위를 추출해서 디코딩 및 렌더링을 위해 미디어 플레이어에게 전달한다.

- RTP는 다른 3계층, 4계층 프로토콜과도 같이 사용이 가능하며,

  하위 프로토콜에 별로 의존하지 않음.

☛ RTP 패킷헤더 필드

  그림 RTP header field

-부하타입, 순서번호, 타임스탬프, 근원지식별자 필드가 있다.

1. 페이로드타입필드의 길이는 7비트이다. 오디오 스트림의 경우, 사용되는 오디오 인코딩타입을 타나내기 위해 사용한다. 만일 송신자가 세션 중간에 인코딩을 변경하면, 송신자는 수신자에게 페이로드 타입 필드를 사용해서 이 변경사항을 알려준다. 예컨대, 송신자는 오디오 품질을 향상시키거나 RTP스트림 비트율을 감소시키기 위해 인코딩을 변경하고자 할 수도 있다.

   비디오 스트림의 경우에 페이로드 타입은 비디오 인코딩 타입을 나타내기 위해 사용된다. 이 때도 송신자    는 세션 중에 비디오 인코딩을 변경할 수 있다.

2. 순서번호필드의 길이는 16비트이다. 순서번호는 전송되는 RTP 패킷마다 하나씩 증가하며, 패킷 손실을 감지하고 패킷 순서를 회복하기 위해 수신자가 사용할 수 있다. 예를 들어, 만일 애플리케이션의 수신자가 순서번호 86과 89사이에 공백이 있는 RTP패킷 스트림을 수신하면, 수신자는 패킷 87과 88을 잃어버렸음을 알게 된다. 그러면 수신자는 손실된 데이터를 막기l 위해 시도할 수 있다.

3. 타임스탬프 필드의 길이는 32비트 이다. 이 필드는 RTP 데이터 패킷의 첫 번째 바이트의 샘플링 시점을 나타낸다. 수신자는 네트워크에 의해 만들어진 패킷 지터를 제거하고 수신자가 동기적인 재생을 가능하도록 타임스탬프를 사용할 수도 있다. 타임스탬프는 송신자 샘플링 클록으로부터 생성된다. 예를 들어, 오디오의 경우에는 타임스탬프의 클록은 각 샘플링 주기마다 하나 증가한다. 만일 오디오 애플리케이션이 160개의 인코딩된 샘플로 구성된 chunk를 생성한다면, 근원지가 활성일 때 타임스탬프는 각 RTP 세션마다 160씩 증가한다. 타임스탬프 클록은 근원지가 비활성일 때 조차도 일정 비율로 계속 증가한다.

그림 RTP layer

☛ RTP로 소프트웨어 애플리케이션 개발방법

1. 애플리케이션 개발자가 RTP 캡슐화를 수행하는 송신자의 코드와 RTP 패킷을 풀어보는 수신자의 코드를 직접 작성해서 RTP를 추가하는 것.

2. 캡슐화 및 역캡슐화를 수해앟는 기존 RTP 라이브러리와 자바 클래스들을 애플리케이션 개발자가 사용하는 것이다.

   예를들어, 음성을 전달하기 위해 RTP를 사용하는 것에 대해 생각해보자. 음성 데이터는 64kpbs의 PCM으로 인코딩된다고 가정하자. 또한 애플리케이션이 인코딩된 데이터를 20밀리초의 데이터 단위(즉, 한 데이터 단위에 160바이트)로 모은다고 가정하자. 송신자는 오디오 데이터의 각 데이터 단위 앞에 오디오 인코딩 종류, 순서번호, 타임스탬프 등을 가진 RTP 헤더를 덧붙인다. RTP 헤더는 보통 12바이트이다. 오디오 데이터 단위에 RTP 헤더를 덧붙여서 RTP 패킷을 구성한 후, UDP 소켓 인터페이스로 전송한다. 수신자의 애플리케이션은 소켓 인터페이스에서 RTP 패킷을 수신한 후, RTP 패킷에서 오디오 데이터 단위를 추출하고, 추출된 RTP 패킷의 헤더 필드를 살핀 후에 오디오 데이터 단위를 적절히 디코드 및 재생한다.

   페이로드 타입이나 순서번호, 타임스탬프를 제공하는 개인 기법 대신에, 애플리케이션이 RTP를 사용하면 훨씬 쉽게 다른 네트워킹 멀티미디어 애플리케이션을 통합할 수 있다. 예를 들어. 만일 두 회사에서 인터넷 폰 애플리케이션을 개발할 때 RTP를 사용한다면, 한 회사의 인터넷 폰 제품을 사용하는 사용자가 다른 회사의 인터넷 폰 제품을 사용하는 사용자와 통신 가능할 거라고 기대할 수 있다.

   RTP 자체가 시간에 맞춘 데이터 전달을 보장하거나 다른 서비스 품질 보장을 제공하는 기법을 지원하지 않는다는 것이다. 즉, RTP는 패킷 전달을 보장하거나 패킷 전달 순서를 보장하지 않는다. 실제로 RTP 캡슐화는 종단 시스템에서만 된다. 라우터는 RTP 패킷을 전달하는 IP 데이터그램과 RTP 패킷을 전달하지 않는 IP 데이터 그램을 구분하지 않는다.

   RTP는 각각의 근원지(예:마이크로폰, 카메라)에게 자신만의 RTP 패킷 스트림을 생성할 수 있도록 허용한다. 예를 들어, 두명의 참여자가 있는 화상회의의 경우, 두 개의 오디오 송신용 스트림(각 방향으로 하나의 스트림)과 두 개의 비디오 송신용 스트림(각 방향으로 하나의 스트림)등 총 네 개의 RTP 스트림이 만들어질 수 있다. 그러나 MPEG1이나 MPEG2 같은 대다수 많이 사용되는 인코딩 기법은 인코딩 과정에서 오디오와 비디오를 하나의 단일 스트림으로 합친다. 인코더에서 오디오와 비디오를 합치면 각 방향으로 하나의 스트림만 생성된다.

   RTP 패킷은 유니캐스트 애플리케이션에 한정되지 않는다. RTP 패킷은 일대다 EH는 다대다 멀티캐스트 트리로 전송될 수도 있다. 다대다 멀티캐스트 세션에 대해, 세션의 모든 송신자와 근원지는 RTP 스트림을 전송하는 데 있어서 일반적으로 동일한 멀티캐스트 그룹을 사용한다. 화상회의 애플리케이션에서 다수의 송신자들에 의해 전송되는 오디오, 비디오 스트림과 같이 함께 포함된 RTP 멀티캐스트 스트림들은 하나의 RTP 세션에 속하게 된다.

ALOHA, APMBS, ARPA, ATM, B-ISDN, CCITT, DCE, DSU, DTE, FEP, ISDN, ISO, ITU-T. LAN, MODEM, MULTICS, NC, OSI, POS, SMDS, SNA

1. ALOHA:

알로하는 하와이 대학에서 개발되었으며 시분할 다중접속 기술을 사용해, 위성과 지구 사이의 무선전송을 하는 프로토콜이다. 원래의 알로하에서, 사용자는 언제든지 전송할 수 있지만, 다른 사용자들의 메시지와 충돌할 위험이 있다. 패킷이 준비되면 브로드캐스트 되며, 만약 충돌이 일어나면 일정시간 후에 재전송된다. "Slotted Aloha"는 채널을 시간대별로 나누어서 충돌위험을 줄이는 것으로, 각 사용자는 시간대의 시작에서만 전송할 수 있다.

2. APMBS:
APM (advanced power management)
APM은 인텔과 마이크로소프트에 의해 개발된 일종의 API로서 개발자들이 BIOS 내에 전력 관리 기능을 포함시킬 수 있게 해준다. APM을 이용하면 배터리로 동작하는 노트북컴퓨터 등에서, 일정 기간동안 컴퓨터가 사용되지 않으면 전력을 절약하기 위해 컴퓨터 디스플레이 모니터가 저절로 꺼지거나, 시스템 자체를 절전모드로 들어가게 하는 등의 일을 할 수 있다. APM은 프로그래머가 상세한 하드웨어 내용을 알지 않아도 되도록 하드웨어와 운영체계 간에 하나의 계층을 정의한다. APM은 점차적으로 ACPI로 대체될 것으로 예상된다.

3. ARPA:
ARP (Address Resolution Protocol) ; 주소결정 프로토콜
ARP는 IP 네트웍 상에서 IP 주소를 물리적 네트웍 주소로 대응시키기 위해 사용되는 프로토콜이다. 여기서 물리적 네트웍 주소라 함은 이더넷 또는 토큰링의 48 bits 네트웍 카드 주소를 의미한다.
예를 들어, IP 호스트 A가 IP 호스트 B에게 IP 패킷을 전송고자 할 때 IP 호스트 B의 물리적 네트웍 주소를 모르는 경우, ARP 프로토콜을 사용하여 목적지 IP 주소 B와 브로드캐스팅 물리적 네트웍 주소 FFFFFFFFFFFF를 가지는 ARP 패킷을 네트웍 상에 전송한다. IP호스트 B는 자신의 IP 주소가 목적지에 있는 ARP 패킷을 수신하면 자신의 물리적 네트웍 주소를 A에게 응답한다.
이와 같은 방식으로 수집된 IP 주소와 이에 해당하는 물리적 네트웍 주소 정보는 각 IP 호스트의 ARP 캐시라 불리는 메모리에 테이블 형태로 저장된 후 다음 패킷 전송시에 다시 사용된다. ARP와는 역으로, IP 호스트가 자신의 물리 네트웍 주소는 알지만 IP 주소를 모르는 경우, 서버로부터 IP주소를 요청하기 위해서는 RARP를 사용한다.

4. ATM:
ATM (asynchronous transfer mode) ; 비동기 전송 모드
[주] ATM은 automated teller machine의 약자로 고객이 은행창구에 가지 않고서도 업무를 처리 할 수 있는 '현금자동지급기'라는 일반적인 의미로 널리 쓰이기도 한다. 하지만 asynchronous transfer mode의 ATM과 automated teller machine의 ATM은 약어만 같을 뿐 전혀 다른 의미이다.
ATM은 디지털 데이터를 53 바이트의 셀 또는 패킷으로 나누어, 디지털 신호 기술을 사용한 매체를 통하여 전송하는 전용접속(dedicated-connection) 스위칭 기술이다. 하나의 셀은 개별적으로 다른 셀 들과 관련하여 비동기적으로 처리되고 회선공유를 위한 멀티플렉싱을 하기 위해 큐(queue)에 들어가게 된다.
ATM은 소프트웨어보다는 하드웨어로 더 쉽게 구현되도록 설계되었기 때문에 처리 속도를 빠르게 하는 것이 가능하다. 현재 얘기되고 있는 ATM망의 전송속도는 155.520 Mbps 또는 622.080 Mbps 정도이지만, IEEE 스펙트럼에서는 이러한 속도가 곧 10 Gbps에까지 이를 것으로 예측된다고 보고했다. SONET 그리고 몇 개의 다른 기술과 함께 ATM은 광대역 종합정보통신망(BISDN)의 핵심 기술이다.

5. B-ISDN:
BISDN (Broadband Integrated Services Digital Network) ; 광대역 종합정보통신망
BISDN[비 아이에스디엔]은 광섬유나 무선매체 등의 광대역 네트웍에서 디지털 전송서비스를 통합하기 위한 개념, 일련의 서비스 및 표준의 개발 등을 모두 포괄하는 용어이다. BISDN은 고속 데이터를 위한 프레임 릴레이 서비스와, FDDI, 그리고 SONET 등을 모두 포함하게 될 것이다. BISDN은 2 Mbps의 속도에서부터 그 이상을 빠른 속도를 지원하게 될 것이지만, 구체적인 속도는 아직 결정되지 않았다.
BISDN은 협대역 가입자회선 상의 구리 전화회선을 이용해 디지털 데이터 전송을 제공하는 ISDN의 광대역 판이다.

6. CCITT:
CCITT (Comite Consultatif Internationale de Telegraphique et Telephonique
or Consultative Committee on International Telephone and Telegraphy)
CCITT[씨씨 아이티티]는 통신장비 및 시스템의 협동조합 표준을 육성하기 위한 최초의 세계기구이며, 지금은 이름이 ITU-T로 바뀌었다. 스위스의 제네바에 본부를 두고 있다.

7. DCE:
DCE (Distributed Computing Environment; or Data Communication Equipment)
네트웍 컴퓨팅에서, DCE[디씨이](Distributed Computing Environment ; 분산 컴퓨팅 환경)는 분산 컴퓨터들의 시스템 내에서 컴퓨팅 및 데이터 교환을 설정하고 관리하는데 필요한 산업표준 소프트웨어 기술이다. 일반적으로 DCE는 여러 가지 다른 크기의 서버들이 지리적으로 퍼져있는 대형 컴퓨터 시스템의 네트웍 내에서 사용된다. DCE는 클라이언트/서버 모델을 사용한다. DCE를 사용하면, 사용자는 원격지의 서버에 있는 응용프로그램과 데이터를 쓸 수 있다. 프로그래머들은 그들의 프로그램이 어느 곳에서 실행되는지 또는 데이터가 어디에 위치해 있는지 등에 대해 전혀 신경을 쓸 필요가 없다.
DCE 설정시에는 대부분, 필요할 때 DCE 응용프로그램과 관련 데이터들을 찾을 수 있도록 분산 디렉토리를 준비하는 것이 필요하다. DCE는 보안지원을 포함하며, 몇몇 제품들은 IBM의 CICS, IMS 및 DB2 데이터베이스들과 같은 보편적인 데이터베이스에 접근하기 위한 지원을 제공한다.
DCE는 몇몇 회원사들이 기여한 소프트웨어 기술을 사용하여, OSF (Open Software Foundation)에 의해 개발되었다.
컴퓨터 통신에서의 DCE (Data Communication Equipment ; 데이터 통신 기기)는 모뎀이나 다른 직렬장치들이 컴퓨터와 데이터를 주고받기 위해 사용하는 RS-232C 인터페이스를 의미한다. DCE 인터페이스와 DTE 인터페이스간의 관계에 대해 좀더 자세한 정보를 알기 원하면 RS-232C를 찾아 보라.

8. DSU:

DSU는 근거리통신망에 사용되는 통신기술로부터 나온 디지털 데이터 프레임들을 광역통신망에 보낼 수 있도록 적절한 프레임으로 변환하는 외장형 모뎀 크기의 하드웨어 장치이다. 예를 들어, 만약 자신의 집에서 웹 관련 비즈니스를 하려면 T-1 정도의 디지털 전용회선을 전화회사로부터 빌려야하는데, 이때 자신의 집과 전화회사에 각각 1개씩의 CSU/DSU를 설치해야한다.
CSU는 광역통신망으로부터 신호를 받거나 전송하며, 장치 양측으로부터의 전기적인 간섭을 막는 장벽을 제공한다. CSU는 또한 전화회사에서 테스트 목적으로 보내는 신호에 대해 루프백 반향을 할 수 있다. DSU는 회선제어를 관리하고, RS-232C, RS-449 또는 근거리통신망으로부터의 V.35 프레임들과 T-1 회선상의 TDM DSX 프레임 사이의 입출력을 변환한다. DSU는 타이밍 에러와 신호재생을 관리한다. DSU는 DTE로서 컴퓨터와 CSU 사이에서 모뎀과 같은 인터페이스를 제공한다.
CSU/DSU는 별개의 제품으로 만들어지지만, 때로는 라우터와 함께 통합되기도 한다. CSU/DSU의 DTE 인터페이스는 보통 V.35나 RS-232C 또는 이와 비슷한 직렬 인터페이스와 호환성이 있다. CSU/DSU 제작자로는 시스코, 메모텍 및 Adtran 등이 있다.
시스코는 DSU/CSU라는 용어를 더 선호한다. CSU라는 용어는 AT&T가 자신들의 비교환 디지털 데이터시스템의 인터페이스를 부르는 데에서 유래되었다. DSU는 표준 인터페이스를 사용한 DTE의 인터페이스를 제공하며, 또한 시험 기능도 제공한다.

9. DTE:
DTE (Data Terminal Equipment) ; 데이터 단말 장치
컴퓨터 데이터 통신에서, DTE[디티이]는 컴퓨터가 모뎀이나 기타 다른 직렬장치를 이용하여 데이터를 교환하기 위한 RS-232C 인터페이스이다. DTE 인터페이스와 DCE 인터페이스에 관한 좀더 자세한 정보는, RS-232C를 참조할 것.

10. FEP:
FEP (Front End Processor) : 전단 처리기
FEP는 메인프레임의 통신제어를 위해 설계된 전용 컴퓨터이다. 대개 FEP의 한쪽은 통신회선에 그리고 다른 한쪽은 메인프레임에 연결되어, 메시지의 전송이나 수신, 패킷의 조립 및 해체, 에러의 감지 및 교정 등의 역무를 수행한다. 그러므로, FEP가 때로 통신제어기라는 말과 동의어로 사용되는 경우도 있지만, 통신제어기라는 용어가 다소 유연성이 떨어지는 용어이다.
또한, FEP는 클라이언트/서버 구조에서는 백엔드, 즉 서버에 서비스를 요청하기 위한 하나의 노드 또는 소프트웨어 프로그램을 의미하기도 한다. FEP는 일반적으로, 입력되는 데이터를 어느 정도까지 사전에 처리함으로써, 주 소프트웨어가 일을 좀 더 쉽고 빠르게 처리할 수 있도록 하는 프로그램을 가리키는 경우도 있다.

11. ISDN:
ISDN (Integrated Services Digital Network) ; 종합정보통신망
ISDN[아이에스 디엔]은 다른 매체는 물론, 평범한 구리전화선 위에서도 디지털 전송을 할 수 있게 하기 위한 일련의 CCITT/ITU 표준들이다. 모뎀 대신에 ISDN 어댑터를 설치한 가정이나 회사의 사용자들은 최고 128 Kbps 까지의 빠른 속도로 제공되는 웹 페이지를 볼 수 있다. ISDN은 전송 양단에 어댑터가 필요하므로, 서비스제공자 역시 ISDN 어댑터가 필요하다. ISDN은 일반적으로 미국이나 유럽의 대부분 도시지역의 전화회사가 서비스를 공급하며, 우리나라에서도 한국통신에서 1993년부터 ISDN 서비스를 시작하였다.
ISDN에는 두 종류의 서비스가 있는데, 가정이나 소규모회사에는 BRI가, 많은 사용자를 위해서는 PRI 서비스가 적합하다. 두 종류 모두 여러 개의 B 채널과 한 개의 D 채널을 포함한다. B 채널에는 데이터, 음성 및 기타 다른 서비스를 전송할 수 있으며, D 채널은 제어 및 신호정보를 전송한다.
BRI는 64 Kbps 속도를 내는 2개의 B 채널과, 16 Kbps 속도를 내는 1개의 D 채널로 구성된다. 그러므로, BRI 사용자는 최고 속도 128 Kbps까지의 서비스를 받을 수 있다. PRI는 미국의 경우에는 23개의 B 채널과 64 Kbps 속도를 내는 한 개의 D 채널로 구성되어 있으며, 유럽의 경우에는 30개의 B 채널과 1 개의 D 채널로 구성된다.
ISDN의 개념은 음성 등의 아날로그 데이터와, 디지털 데이터를 같은 네트웍을 통해 함께 통합하여 전송하는 것이다. 비록 ISDN이 아날로그 전송을 위해 설계된 매체 상에 이러한 것들을 통합해서 전송할 수 있지만, 광대역 ISDN(BISDN)은 종단회로를 포함한 처음부터 끝까지를 광케이블과 무선 매체 등을 사용하여 이 두 가지 서비스의 통합을 확대할 수 있을 것이다. 광대역 ISDN은 많은 량의 데이터를 고속으로 송신하기 위한 프레임릴레이 서비스와 FDDI 그리고 SONET 등을 포함하게 될 것이다. 광대역 ISDN은 2 Mbps 이상의 빠른 속도로 전송할 수 있게될 전망이지만, 정확한 최고 속도는 아직 정의되지 않았다.

12. ISO:
ISO (International Organization for Standardization) ; 국제표준화기구
ISO[아이에스오], 즉 국제표준화기구는 1947년에 설립되었으며, 100 여개 나라에서 온 대표자들로 구성된 국가표준화기구의 세계적인 연합체이다. ISO가 육성하는 표준들 가운데 하나인 OSI는 통신 프로토콜의 보편적인 참조 모델이다. 많은 나라들이 ANSI 등과 같은 국가표준화기구를 가지고 있으며, 이들은 ISO의 표준안 작성에 참여하고 기여한다.
"ISO"는 약어가 아니다. 이 용어는 그리스어의 isos에 근원을 두고 파생된 말로서, "같다"는 의미인 "equal"의 뜻을 가지고 있는데, "iso-"라는 접두어에서 그 예를 찾아볼 수 있다 ("isometric"은 동일한 치수를 의미하며, "isonomy"는 모든 사람들은 권리가 같다는 것을 의미한다). ISO라는 이름은 "International Organization for Standardization"을 각 나라에서 이 기구의 이름을 나름대로 번역하면서 생길지도 모르는 여러 가지의 약어들의 과잉을 막기 위해, 전세계적으로 사용된다 (이를테면, 영어권에서는 약어를 IOS라고 쓰고, 프랑스에서는 Organisation internationale de normalisation의 약어로서 OIN 등으로 쓰는 것을 방지하기 위함이다). 그러므로, 어느 나라에서든 이 기구를 의미하는 약어는 항상 ISO로 쓰인다.

13. ITU-T:
ITU-T (International Telecommunications Union - Telecommunication Standardization Sector)
ITU-T[아이티유 티]는 통신장비 및 시스템의 조합표준을 육성하기 위한 제일의 세계적인 조직체이다. 전에는 CCITT로 알려져 있었으며, 스위스 제네바에 본부를 두고 있다.

14. LAN:
LAN (Local Area Network) ; 근거리 통신망
LAN[랜]이란 300m 이하의 통신회선으로 연결된 PC, 메인프레임, 워크스테이션 들의 집합을 말한다. LAN은 컴퓨터 사이의 전류나 전파신호가 정확히 전달될 수 있는 거리, 즉 한 기관의 빌딩 내에 설치된 컴퓨터 장비들을 직원들이 가장 효과적으로 공동 사용할 수 있도록 연결된 고속의 통신망이다.
1970년대 말에서 1980년초 제록스사의 한 연구소에서 LAN에 관한 중요한 업적이 이루어졌다. 이 연구소에서 이더넷(Ethernet ; 공기가 없는 진공상태의 공간에 전파가 흘러갈 수 있는 물질이 존재한다고 가정하여 지은 독일어 단어 "에테르"에서 따온 말)이라고 이름을 붙인 컴퓨터 연결방법이 처음으로 실용화되었다.
[근거리 통신망의 구성요소]
네트웍 운영체계 : 네트웍에 연결된 컴퓨터에 서버기능이나 클라이언트 기능을 할 수 있도록 해주며, 서버는 등록된 클라이언트의 이름과 부여된 권리를 검사한 뒤, 클라이언트의 요구사항을 처리하여 그 결과를 클라이언트에게 전송하는 프로그램의 집합체이다. 주요 네트웍 운영체계로는 노벨의 네트웨어, 마이크로소프트의 윈도우NT, 알리소프트의 LANtastic 등이 있다.
LAN 카드 : 컴퓨터 내부의 확장 슬롯에 끼울 수 있는 LAN 카드는 컴퓨터와 전송선을 이어주는 장치이다. LAN 카드는 전압이 낮은 컴퓨터의 2진 병렬 전류신호가 회선을 타고 멀리갈 수 있도록 전압이 높은 직렬신호로 변환시켜주는 일종의 프로세서가 내장된 작은 플라스틱 카드 회로판이다. LAN 카드는 통신망과의 접속장치이기 때문에 네트웍 접속카드라고도

15. MODEM:
modem (modulator/demodulator) ; 모뎀 또는 변복조기
모뎀은 컴퓨터에서 나가는 디지털 신호를 전화회선을 통해 보낼 수 있도록 아날로그 신호로 바꾸고(변조), 들어오는 아날로그 신호를 디지털 신호로 바꾸어주는(복조) 장치를 말한다.
우리가 사용하는 전화회선이나 전용회선은 음성급으로 구성되어서 디지털 신호가 통과하면 많은 감쇠가 일어나므로, 50 피트 이상 떨어져 있는 장비 사이에 데이터를 전송하려면 모뎀이 필요하게 된다. 모뎀은 크게 송신부와 수신부로 나눌 수 있다. 송신부는 디지털 신호가 인코더에 입력되어 "1" 이나 "0" 이 더이상 나오지 않도록 스크램블 된 후 변조기로 들어간다. 여기서 약 1700~1800 Hz 정도의 반송 주파수로 변조된 후 아날로그 형태로 변형된 다음, 대역제한 여파기를 거쳐 송신선로로 나가게 된다.
수신부는 통신선로로부터 들어오는 아날로그 신호가 대역제한 여파기를 거쳐 원하는 부분의 주파수 대역을 할당받은 후, 자동 이득조절기(AGC ; automatic gain control)로 들어가서 적절한 크기로 분할된다. 아날로그 신호는 복조기를 통해 복조된 후 디지털신호로 변환되고, 다시 데이터 디코더를 거쳐 본래의 데이터로 환원된다.
모뎀은 미국을 중심으로 하는 Bell 표준과 유럽을 중심으로 한 CCITT 표준의 두가지 표준이 있다. 이 두 개의 표준은 유사한 경우도 있으나, 전혀 다른 경우도 있어 서로 호환성을 갖지 않는다. 전화망을 이용한 데이터 전송용 모뎀에 관한 권고는 V 시리즈로서 그 내용은 다음 표와 같다. CCITT 규격 Bell 규격 전송속도(bps) 회선 동기형태 전송형태 변조방식
V.21 103A 300 PSTN 비동기 FDX FSK
V.22 212A 300/1200 PSK
V.23 202A 600/1200 HDX FSK
V.26 201B 2400 전용회선 동기 FDX QPSK
V.27 208A 4800 8-PSK
V.29 209A 9600 QAM
최근 몇년 사이의 빠른 기술변화로 2,400 bps 속도의 모뎀은 퇴역하여 더이상 사용하지 않게 되었으며, 14,400 bps 나 28,800 bps 모뎀조차 좀더 빠른 전송속도로 가기 위한 중간단계였다. 1998년 초반부터 출시되는 PC들에는 56 Kbps 모뎀이 장착되고 있으며, 동일한 전화회선에 모뎀 대신 디지털 ISDN 어댑터를 장착하면 전송속도를 128 Kbps까지 높일 수 있고, DSL 기술을 채용하면 전송속도를 수 Mbps 범위까지 향상 시킬 수 있게 되었다.
모뎀은 컴퓨터와 직렬 포트나 USB 포트를 통해 연결해 사용할 수 있는 외장형 모뎀과, PC의 확장 슬롯 등에 꽂아쓸 수 있는 확장카드 형태의 내장형 모뎀(왼쪽 그림 참조), 그리고 노트북 컴퓨터 등에서 사용하는 PCMCIA 카드형 모뎀 등이 있으며, 최근에는 데이터의 송수신 뿐 아니라, 음성이나 팩스 송수신 기능까지도 함께 제공되는 경우가 많다.

16. MULTICS:
Multics (multiplexed information and computing service) ; 멀틱스
멀틱스는 미국의 MIT와 GE 그리고 벨연구소의 공동작업으로 1963-1969년 사이에 개발된 메인프레임용 시분할 운영체계였다. 멀틱스는 페이지 세그먼트형 저장 방식을 사용했던 최초의 운영체계 중 하나이다. 이 운영체계는 PL/I으로 작성되었으며, GE의 하드웨어에서 운영되었다. 1970년에 벨연구소는 이 사업에서 발을 빼었고, GE의 컴퓨터 부문을 인수한 하니웰이 하드웨어 제공자로서의 역할을 지속해 나갔다. 미국의 고등연구사업국이 지원이 이 사업을 계속 유지하는데 도움이 되었다.
1973년에 하니웰은 6180이라는 상용시스템을 발표하였는데, 이 시스템은 각 1 MIPS의 처리속도를 가지고 있는 두 개의 프로세서에 768 KB의 메모리, 8 MB의 벌크 스토리지, 1.6 GB의 하드디스크, 8개의 테이프 드라이브 그리고 두 개의 통신 제어장치를 장착하고 있었다. 이 시스템의 가격은 대략 미화 7백만 달러 정도였다. 후에, NSS (new storage system)라고 불리는 다중 디스크 시스템이 추가되었다. 1977년에 하니웰은 최초의 상용 관계형 데이터베이스인 MRDS, 즉 Multics Relational Data Store를 발표하였다.
그동안 멀틱스 고객에는 제너럴 모터스, 포드, 그리고 Industrial Nucleonics 등이 포함되었다. 1980년대 말까지 멀틱스를 인텔과 같은 보다 전략적인 프로세서 기반으로 이주시키려는 노력은 실패로 돌아가고, 하니웰은 멀틱스의 유지보수를 마지막 고객사 중 하나인 캘거리 대학으로 이양하였으며, 캘거리 대학은 지역회사인 CGI 그룹으로 그 권리를 넘겼다. 1998년 9월 현재, CGI 그룹은 단 하나 남은 멀틱스 시스템의 운영을 계속하고 있다.

17. NC:
NC (network computer) ; 네트웍 컴퓨터
네트웍 컴퓨터는 오라클과 썬 마이크로시스템즈의 두 회사로부터 나온 개념인데, Net PC 처럼 네트웍 전용의 값싼 개인용 컴퓨터를 의미한다. 이 컴퓨터는 CD-ROM 드라이브, 디스크 드라이브, 확장 슬롯 등이 전혀 없는 채, 오직 필수적인 장치만을 장착하며, 나머지 것들은 모두 중앙에서 유지관리하는 개념이다.
Net PC와는 달리, 네트웍 컴퓨터는 인텔제품이 아닌 다른 회사의 마이크로프로세서를 기반으로 할 수 있으며, 윈도우 대신 자바 기반의 운영체계를 포함할 수 있다. 네트웍 컴퓨터는 Net PC와 함께 씬 클라이언트로 일컬어지기도 한다.

18. OSI:
OSI (Open Systems Interconnection) ; 개방형 시스템간 상호 접속
[주] 그림으로 나타낸 OSI 참조 모델을 참고할 것
OSI[오에스아이]는 통신 네트웍으로 구성된 컴퓨터가 어떻게 데이터를 전송할 것인가에 대한 표준규약 또는 참조 모델이다. 이것의 목적은 통신 제품을 만들 때 다른 제품과 모순됨이 없이 통신하도록 유도하는 것이다. 이 참조 모델은 통신의 종단에서 이루어지는 기능을 7 계층으로 정의했다. OSI가 잘 정의된 계층마다 관련된 기능을 따르도록 강하게 고수하지 않아도, 대부분의 제품들은 OSI 모델에 관련된 정의들을 따르기 위해 노력한다. OSI 모델은 또한 모든 사람이 동일한 관점에서 통신에 대해 교육하고, 논의하는 유일한 참조 모델로서 중요한 가치가 있다.
주요 컴퓨터와 통신 회사 대표자들에 의해 1983년부터 개발이 시작된 OSI는 본래 인터페이스 사이의 상세 규정을 시도했다. 그러나 위원회는 다른 것들 간에 상세 인터페이스 규정을 개발할 수 있는 공통의 참조 모델을 확립하기로 결정하였으며, 그것은 표준이 될 수 있었다. OSI는 ISO에 의해서 국제 표준으로 채택되었다. 현재, 이것은 ITU의 권고 X.200 이다.
OSI의 주된 개념은 통신 네트웍으로 구성된 두개의 종단 이용자 사이에서, 통신 처리를 각 계층이 가지고 있는 특별한 기능을 가지고 계층별로 나눌 수 있도록 하는 것이다. 각 통신 이용자는 7 계층의 기능을 갖는 컴퓨터를 이용한다. 이용자들 사이에 메시지가 주어지면, 컴퓨터에서 한 계층씩 아래로 각 층을 통과하여 데이터가 흐르게되고, 다른 쪽에서는 메시지가 도착할 때 메시지를 받는 컴퓨터는 한 계층씩 위로 통과하여 이용자에게 전달 될 것이다. 실제로 이러한 7 계층의 기능을 제공하는 프로그램이나 장치는 컴퓨터 운영체계, 웹 브라우저와 같은 응용프로그램, TCP/IP 또는 다른 트랜스포트 네트웍 프로토콜과 이용자의 컴퓨터에 구성된 회선을 사용할 수 있는 소프트웨어 및 하드웨어가 함께 결합된다.
OSI는 7 계층으로 통신을 나누는데, 이 계층들은 다시 2개의 그룹으로 나뉜다. 상위 4 계층은 이용자가 메시지를 주고받는데 사용된다. 네트웍 계층까지의 아래의 3 계층은 메시지가 호스트를 통과 할 수 있도록 한다. 컴퓨터에 보내진 데이터는 위 계층으로 전달된다. 다른 컴퓨터에 보내진 메시지는 위 계층으로 전달되지 않고 다른 호스트로 전달된다.
7 계층을 하나하나 살펴보면 다음과 같다.
7 계층 : 응용계층 ... 이 계층에서는 통신상대, 서비스 품질, 사용자 인증과 비밀을 고려하고, 데이터 구문의 제약을 정한다 (이 계층은 응용 프로그램이 응용 계층의 기능을 수행하지만 응용프로그램 자체는 아니다).
6 계층 : 표현 계층 ... 이 계층은 운영체계의 한 부분으로 입력 또는 출력되는 데이터를 하나의 표현 형태에서 다른 표현 형태로 변환하는 것이다 (예를 들면 텍스트로 도착한 데이터를 팝업 윈도우 형태로 변환하는 것이다). 표현 계층을 문법 계층이라고 하기도 한다.
5 계층 : 셰션 계층 ... 이 계층에서는 종단 호스트 프로그램 사이에서 메시지를 주고받기 위한 설정을 하고, 데이터를 받는 동기를 제어하는 역할을 한다. 이 계층은 통신 세션을 구성하는 역할을 한다.
4 계층 : 트랜스포트 계층 ... 이 계층은 종단간 제어와 에러를 관리한다. 즉, 신뢰성 있는 데이터 전송을 보장한다.
3 계층 : 네트웍 계층 ... 이 계층은 데이터 경로를 제어한다 (패킷이 정확한 수신자에게 보내지도록 올바른 경로는 제어하여 수신 쪽에서 받을 수 있게 한다). 네트웍 계층은 경로를 설정하고 다른 쪽으로 전송한다.
2 계층 : 데이터링크 계층 ... 이 계층은 물리적 레벨의 에러 제어와 동기를 제공하고, 5를 초과하는 1의 스트링으로 비트화한다. 이 계층은 전송 확인과 관리를 담당한다.
1 계층 : 물리 계층 ... 이 계층은 전기 기계적으로 체계를 갖춘 네트웍을 통하여 비트열을 나른다. 이 계층은 전송 매체를 통해 데이터를 주고받는 하드웨어 수단을 제공한다.

19. POS:
POS (point of sale) ; 판매시점관리
POS[포스]란 판매와 관련된 데이터를 물품이 판매되는 그 시간과 장소에서 즉시 취득하는 것이다. POS 시스템은 상품에 붙어있는 바코드를 읽어들이는 바로 그 시점에 재고량이 조정되고, 신용조회 등 판매와 관련되어 필요한 일련의 조치가 한번에 모두 이루어지는 시스템이다. 이를 위하여 POS 시스템은 바코드리더, 광학스캐너 카드리더 등이 계산대와 결합되어 있는 PC나 또는 특별한 단말기를 사용한다. POS 시스템은 신용조회나 재고량 조정 등을 위해 중앙컴퓨터와 온라인으로 연결되거나, 또는 일괄처리를 위해 주전산기에 전송되기 전까지 일일거래를 저장하기 위해 독립된 컴퓨터를 사용할 수도 있다.

20. SMDS:
SMDS (Switched Multimegabit Data Service)
SMDS는 광역통신망을 통해 다른 회사들과 지속적이지는 않지만 돌발적으로 많은 량의 데이터를 주고받아야 할 필요가 있는 기업체들을 겨냥해서 나온 공중 패킷 교환방식의 서비스이다. SMDS는 이러한 종류의 데이터 교환을 위한 구조와 일련의 서비스를 제공한다. 일반적으로, SMDS는 넓은 지역에 걸쳐 있는 회사의 근거리통신망을 필요시마다 연결함으로써 성능과 효율을 확장시켜준다.
SMDS는 데이터를 보내기 전에 네트웍의 접속을 확립할 필요가 없는 "커넥션리스"이다. 이것은 주로 근거리통신망에서 볼 수 있는 돌발적 데이터 송신 요구에 따른 대역폭을 제공한다.
SMDS 패킷은 최고 7,168 바이트의 데이터를 포함하며, 이것은 가장 보편적인 랜 패킷을 받아들이기에 충분하리 만치 큰 것이다. 각 패킷은 발신지 주소와 수신지 주소를 포함하며, 다른 패킷들과는 별도로 보내진다.
SMDS를 사용하는 각 기업은 필요에 따라 한개에서 16개까지 고유한 SMDS 주소가 할당되는데, 하나의 주소는 마치 평범한 전화번호처럼 보이는 10자리의 숫자로 되어 있다.
SMDS는 또한 여러 개의 SMDS 주소지에 한번에 보낼 수 있는 브로드캐스팅 패킷도 제공한다. 각 SMDS 회사는 수신그룹을 정의하는데 사용될 수 있는 하나 이상의 그룹주소가 배당된다. 그룹주소는 LAN의 멀티캐스팅과 비슷한 것이다. 그것은 TCP/IP와 같은 라우팅 프로토콜이 동적으로 주소를 찾고 라우팅 정보를 갱신하게 한다.
SMDS는 공중서비스이기 때문에 어떤 SMDS 이용자라도 다른 이용자와 데이터를 주고받을 수 있다. SMDS 동아리 그룹, 서비스제공자 연합, 장비제작자, 그리고 사용자들이 함께 기술규격을 개발하고, SMDS에 관한 관심을 고취시키며, 새로운 활용분야를 발굴하고, 그리고 전세계적으로 서비스에 대한 상호운용 가능성을 보증하고 국제적으로 제휴관계를 맺으며 함께 일하고 있다. 그들의 홈페이지에 SMDS 서비스를 제공하는 회사들의 목록이 제공된다.

21. SNA:
SNA (Systems Network Architecture)
SNA[에센에이]는 기업 내의 네트웍 컴퓨팅을 구현하기 위해 1974년에 소개된 IBM의 메인프레임 네트웍 표준이다. 원래는 많은 수의 단말기를 제어하는 호스트 컴퓨터용 중앙집중식 아키텍처였으나, APPN이나 APPC와 같은 기능향상이 이루어짐으로써, 현재는 peer-to-peer 통신과 분산 컴퓨팅 환경에 알맞게 변화되었다. 이것은 IBM의 SAA (Systems Application Architecture) 이전부터 있었다가 SAA의 일부가 되었고, 현재는 IBM의 Open Blueprint의 일부이다. 여러 기업이 함께 네트웍 컴퓨팅을 하게되는 인터넷과, 사실상의 개방형 네트웍 아키텍처인 TCP/IP의 탄생과 함께, IBM은 대형 네트웍상의 업무를 위해 TCP/IP를 사용하는 기업 내에 자사의 SNA를 결합시키는 방법을 찾고 있었다.
SNA 그 자체는 여러 가지 기능적 계층들을 포함하고 있으며, VTAM이라고 불리는 응용프로그램 인터페이스와, 제어정보와 데이터 그리고 데이터링크 계층의 교환을 위한 통신 프로토콜인 SDLC를 포함한다. SNA는 어느 정도의 셋업기능을 제공하는 물리적인 유니트와, 특정한 네트웍 트랜잭션과 관련되는 논리적 유니트를 모두 담고 있는 노드의 개념들을 포함한다.