회선 교환과 패킷 교환
네 트워크 코어의 구성방식에는 회선 교환(circuit switching)과 패킷 교환(packet switching)이라는 두 가지 기본 방식이 있다. 회선 교환 네트워크에서, 종단 시스템 간에 통신을 제공하기 위해 경로상에 필요한 자원(버퍼, 링크 전송률)은 통신 세션(session) 동안에 예약된다. 패킷 교환 네트워크에서는 이들 자원을 예약하지 않는다.
세 션의 메시지는 그 자원을 요청하여, 즉 온디멘드(on-demand) 방식을 사용하고 그 결과, 통신 링크에 대한 접속을 위해 기다릴(즉, 큐에서 대기) 수도 있다. 간단한 비유로 두개의 레스토랑을 생각해보자. 예약을 요구하는 레스토랑과 예약이 필요없는(받지도 않는) 레스토랑이 있다. 예약을 요구하는 레스토랑과 예약이 필요 없는(받지도 않는) 레스토랑이다. 예약을 요구하는 레스토랑은 집을 떠나기 전에 전화로 예약해야 한다. 레스토랑에 도착하면 웨이터에게 말하고 식사를 주문한다. 예약을 받지 않는 레스토랑은 테이블을 예약하는 준비 작업이 필요 없다. 그러나 레스토랑에 갔을 때, 테이블을 할당받기 위해 기다려야만 한다.
먼 저 회선 교환 네트워크의 예로 전화망이 있다. 어떤 사람이 전화망을 통해 다른 사람에게 정보(음성이나 팩시밀리)를 보내려고 할 때 어떤 일이 일어나는지 생각해보자. 송신자가 정보를 보내기 전에 네트워크는 송신자와 수신자 간의 연결을 설정해야 한다. TCP 연결과 비교해서, 이것은 송신자와 수신자 간의 경로에 있는 스위치들이 해당 연결 상태를 유지해야 하는 연결이다. 전기통신 용어로 이 연결을 회선(circuit)이라고 한다. 네트워크가 회선을 설정할 때, 그 연결이 이루어지는 동안 네트워크 링크에 일정한 전송률을 예약한다. 대역폭(bandwidth)이 송신자-수신자 연결을 위해 예약되므로, 송신자는 수신자에게 보장된 일정 전송률로 데이터를 보낼 수 있다.
다 음으로, 오늘날의 인터넷을 패킷 교환 네트워크의 전형적인 예로 꼽을 수 있다. 이번에는 어떤 호스트가 인터넷을 통해 다른 호스트로 패킷을 보내려고 할 때 어떤 일이 일어나는지 생각해 보자. 회선 교환과 마찬가지로 패킷은 일련의 통신 링크를 통해서 전송된다. 그러나 패킷 교환에서는 어떠한 대역폭도 예약하지 않고서 네트워크로 패킷을 보낸다. 링크 중 어느 하나가 다른 패킷을 동시에 그 링크를 통해 전송하게 되는 혼잡 상태일 때, 나중에 온 패킷은 전송 라인의 송신 쪽 버퍼에 대기해야 하고 지연 상태가 된다. 인터넷은 데이터를 시간에 맞게 전달하려는 최선의 노력(best effort)을 하지만, 보장하지는 않는다.
모 든 전기 동신 네트워크를 순수한 회선 교환 네트워크와 패킷 교환 네트워크로 분명하게 구분할 수 있는 것은 아니다. 그렇지만, 패킷 교환 네트워크와 회선 교환 네트워크의 기본 분류는 전기 통신 네트워크 기술을 이해하는 좋은 출발점이다.
회선교환
회 선 교환 네트워크는 네 개의 회선 스위치가 네 개의 링크에 연결되어 있다. 이들 각 링크는 n개의 회선을 가지면, 따라서 각 링크는 n개의 동시 연결을 지원할 수 있다. 호스트들(예: PC와 워크스테이션)은 스위치 중 하나에 직접 연결된다. 두 호스트가 통신하고 싶을 때, 네트워크는 두 호스트 사이에 지정된 조단 간 연결(end-to-end connection)을 설정한다(둘 이상의 장비 간 회의 통화도 물론 가능하다. 그러나 여기서는 각 연결에 두 호스트만 있다고 가정하자). 그러므로 호스트 A가 호스트 B에게 메시지를 보내기 위해, 네트워크는 먼저 두 개의 링크 각각에 한 회선을 예약한다. 각 링크는 n개의 회선을 가지므로, 종단 간 연결이 사용하는 각 링크에 대해, 그 연결은 연결이 지속되는 동안 그 링크 대역폭의 1/n을 얻는다.
회선 교환 네트워크에서의 다중화
링 크 내 한 회선은 주파수분할 다중화(FDM: Frequency-Division Multiplexing) 혹은 시분할 다중화(TDM: Time-Division Multiplexing)로 구현된다. FDM에서, 링크를 통해 설정된 연결들은 그 링크의 주파수 스펙트럼을 공유한다. 특히 그 링크는 연결되는 동안 각 연결에 대해 주파수 대역을 고정 제공한다. 전화망에서의 이 주파수 대역은 일반적으로 4kHz(4,000헤르츠 혹인 초당 4,000사이클) 폭을 갖는다. 이런 대역의 폭을 대역폭(bandwidth)이라고 부른다. FM 라디오 방송도 88MHz와 108MHz 사이의 주파수 스펙트럼을 공유하는데 FDM을 사용한다.
TDM 링크의 경우는 시간을 일정 주기의 프레임으로 구분하고 각 프레임으로 고정된 수의 시간 슬롯으로 나뉜다. 네트워크가 링크를 통해 하나의 연결을 설정할 때, 그 네트워크는 모든 프레임에서 시간 슬롯 한 개를 그 연결에 할당한다. 이들 슬롯은 그 연결을 위해 사용되도록 할당되고, 그 연결의 데이터를 전송하기 위해 모든 프레임에 하나의 시간 슬롯을 갖게 된다.
패 킷 교환 옹호자는 회선 교환의 경우에 할당된 회선이 쉬는 사간(silent period)에는 놀게 되므로 낭비라고 계속 주장했다. 예를 들어, 전화통화를 할 때 사람이 이야기를 중단하더라도, 이 사용되지 않는 네트워크 자원(연결 경로상의 링크 주파수 대역이나 슬롯)은 다른 진행 중인 연결이 대신해서 사용할 수 없다는 것이다. 이들 자원이 얼마나 이용률이 떨어지는지에 대한 다른 예로서, 원격으로 엑스레이 필름에 접속하기 위해 회선 교환 네트워크를 사용하는 방사능 과학자를 생각해보자. 이 학자는 연결을 설정하고, 이미지를 요청하고, 그 이미지를 관찰하고, 다음 이미지를 요청한다. 이 학자가 이미지를 관찰하는 동안에도 자원을 점유하고 있으므로 네트워크 자원이 낭비된다. 또한 패킷 교환 옹호자는 회선 교환에서 종단 간 회선을 설정하고 대역폭을 보존하는 것이 복잡하고 경로에 있는 스위치들 사이의 운영을 조절하는 복잡한 신호 소프트웨어가 필요하다고 지적한다.
패킷 교환
메 시지에는 프로토콜 설계자들이 원하는 어떤 것이라도 포함도리 수 있다. 메시지는 제어기능(예: 핸드셰이킹 예에서 “안녕” 메시지)이나 전자메일 메시지, JPEG 이미지 또는 MP3오디오 파일 같은 데이터를 포함할 수 있다. 현대 컴퓨터 네트워크에서, 근원지(source: 송신자)는 긴 메시지를 패킷이라는 작은 데이터 덩어리로 분할한다. 근원지와 목적지(destination: 수신자) 사이에서 각 패킷은 통신 링크와 패킷 스위치(주로 라우터와 링크 계층 스위치)들을 각각 횡단하고 통과한다. 패킷들은 그 링크의 최대 전송률 속도로 각 통신 링크를 통해 전송된다. 대부분의 패킷 스위치는 저장 후 전달 전송(store-andforward transmission) 방식을 이용한다. 저장 후 전달은 스위치가 출력 링크로 패킷의 첫 비트를 전송하기 전에 전체 피킷을 받아야 함을 의미한다. 따라서 저장후 전달 방식은 패킷 경로에서 각 링크의 입력에 따라 저장한 후 전달하는 데 필요한 지연이 발생하낟. 이 지연은 패킷의 비트 길이에 비례한다. 만약 패킷이 L비트로 구성되고 패킷이 R bps 속도로 출력 링크에 전달된다면, 스위치에서의 자장 후 전달 지연은 다음과 같다.
저장 후 전달 지연 = L/R 초
각 라우터는 자신에 연결된 여러 링크를 가진다. 각 연결 링크의 패킷 스위치에 대해, 라우터는 출력 버퍼(output buffer, 혹은 출력 큐(output queue))를 갖고 있으며, 출력 버퍼는 라우터가 그 링크로 보내려는 패킷을 저장한다. 출력 버퍼는 패킷 교환 네트워크에서 중요한 역할을 한다. 만약 도착하는 패킷이 어떤 링크를 통해 전달되어야 하는데 그 링크가 다른 패킷을 전송하고 있다면, 도착하는 패킷은 출력 버퍼에서 대기해야 한다. 따라서 저장 후 전달 지연 뿐 아니라, 패킷은 출력 버퍼 큐잉 지연(queuing delays: 규 대기 지연)을 겪는다. 이들 지연은 변할 수 있으며 네트워크 혼잡에도 영향을 받는다. 버퍼(큐: 임시 저장 공간) 크기가 유한하므로, 새로 도착한 패킷은 전송을 기다리는 다른 패킷으로 꽉 채워진 버퍼를 발견하게 될 수도 있다. 이 경우에는 패킷 손실(packet loss)이 발생한다. 새로 도착한 패킷이나 큐에 남아 있던 패킷 하나가 폐기될 것이다. 레스토랑에서 큐잉 지연은 테이블이 빌 때까지 레스토랑 대기실에서 여러분이 기다리는 시간과 비슷하다. 패킷 손실은 웨이터가 레스토랑에 새로 도착한 손님에게 이미 대기하는 손님이 많으니 돌아가라고 말하는 것과 유사한다.
패 킷 교호나 네트워크를 통해 L비트의 패킷을 한 호스트에서 다른 호스트로 보내는 데 걸리는 시간을 생각해 보자. 두 호스트 사이에 Q개의 링크들이 있고, 이들은 각각 R bps의 속도를 갖는다고 하자. 큐잉 지연과 종단 간의 전파지연은 무시하며 연결 설정 시간은 없다고 가정하자 패킷은 호스트 A로부터 나가는 첫 번째 링크에 전송되어야 한다. 즉, L/R초가 걸린다. 다음에는 나머지 Q-1개의 링크들에게 전송되어야 한다. 즉, Q-1번의 저장 후 전송이 있어야 한다. 따라서 전체 지연은 다음과 같다.
전체 지연 = QL/R초
패킷 교환 대 회선 교환: 통계적 다중화
앞 에서 설명한 회선 교환과 패킷 교환을 비교해보자. 패킷 교환을 반대하는 사람은 가변적이고 예측할 수 없는 종단 간의 지연(주로 불규칙적이고 예축할 수 없는 규잉 지연에서 발생) 때문에 패킷 교환이 실시간 서비스(예: 전화통화와 비디오 회의 통화)에는 적당하지 않다고 주장했다. 반면 패킷 교환 옹호자는 다음과 같은 것을 주장한다. (1) 패킷 교환이 회선 교환보다 대역폭 공유에서 더 효율적이다. (2) 패킷 교환이 더 간단하고, 효율적이며, 회선 교환보다 구현 비용이 적다.
사 용자가 1Mbps 링크를 공유한다고 가정하자. 또한 각 사용자는 활동시간(100Mbps의 일정 속도로 데이터를 생산할 때)과 비 활동시간(데이터를 생산하지 않을 때)을 반복한다고 하자. 그리고 사용자는 전체 시간에서 10%만 활동한다고 하자(나머지 90% 시간에는 커피를 마신다). 회선 교환의 경우 100kbps가 항상 각각의 사용자에게 예약되어야 한다. 예를 들어, 회선 교환 TDM에서 1초 프레임이 100ms마다 10개의 시간 슬롯으로 나뉜다면, 각 사용자는 한 프레임에 한 번의 시간 슬롯이 할당된다.
따 라서 링크는 동시에 10명(1Mbps/100kbps)만 지원할 수 있다. 패킷 교환의 경우, 한 특정 사용자가 활동하고 있을 확률은 0.1(10%)이다. 만약 35명의 사용자가 있다면, 11명 이상의 사용자가 동시에 활동할 확률은 약 0.0004이다. 만약에 10명 이하의 동시 사용자가 있다면(확률 0.9996), 데이터의 통합 도착률은 1Mbps(링크의 출력률)보다 작거나 같다. 따라서 10명 이하의 동시 사용자가 있을 때, 사용자의 패킷은 회선 교환의 경우와 마찬가지로 지연 없이 링크를 통과한다. 10명 이상의 동시 사용자가 있다면 패킷의 통합 도착률이 링크의 출력 용량을 초과하므로 출력 큐가 커지기 시작한다(이 큐는 통합 입력률이 1Mbps 이하로 떨어질 때까지 커질 것이고, 이후에는 큐 길이가 줄어들기 시작한다). 10명 이상의 동시 사용자가 있을 확률은 매우 작으므로 패킷 교환은 거의 항상 회선 교환과 대등한 지연 성능을 가지면서도 사용자 수에 있어서 거의 3배 이상을 허용한다.
링 크 전송률을 공유하는 두 방식의 가장 큰 차이점은 회선 교환 요구에 관계없이 미리 전송 링크의 사용을 할당하는 반면에 패킷 교환은 요구할 때만 링크의 사용을 할당한다는 것이다. 회선 교환 방식처럼 사용하지 않는 링크 시간에는 링크 사용을 할당할 필요는 없다. 패킷 교환 방식에서 링크 전송 능력은 링크에 전송할 패킷을 가진 사용자만이 패킷마다 공유할 것이다. 이렇게 요구가 있을 때마다(미리 저장되지 않음) 자원을 공유하는 것을 자원의 통계적 다중화라고 한다.
패 킷 교환과회선 교환이 현재 전기 통신 네트워크에서 널리 이용되지만, 그 추세는 패킷 교환으로 바뀌고 있다. 오늘날의 많은 회선 교환 전화망이 패킷 교환으로 전환되고 있다. 특히, 전화망은 비싼 해외 통화부분을 패킷 교환 방식으로 이용한다.
'Computer > Network' 카테고리의 다른 글
ARP(Address Resolution Protocol) (0) | 2009.06.19 |
---|---|
MAC 주소 (0) | 2009.06.19 |
CSMA/CD 프로토콜 (0) | 2009.06.19 |
LAN 의 거리의 한계를 극복하기 위한 방법 (0) | 2009.06.19 |
PPP(Point-to-Point Protocol) & TCP/IP (0) | 2009.06.19 |