KR19990030145A - 네트워크 자원 예약 제어 방법 및 장치,수신 터미널, 송신 터미널과 중계 장치 - Google Patents

Abstract

VC(Virtual Connections) 등과 같은 자원들이 효과적으로 예약된다. ASP 메시지가 수신 터미널(RECEIVER)로부터 송신 터미널(SENDER)로 송신될 때, ASP에 의해 개별적으로 지정된 소정의 대역폭의 버츄얼 컨넥션들이 수신 터미널로부터 송신 터미널로의 방향 및 송신 터미널로부터 수신 터미널로의 방향으로 ASP 메시지가 통과하는 에지 루터, 백본 루터 및 에지 루터 순으로 독립적으로 확립된다.

Description

네트워크 자원 예약 제어 방법 및 장치, 수신 터미널, 송신 터미널과 중계 장치

본 발명은 일반적으로 네트워크 자원 예약 방법, 네트워크 자원 예약 제어 장치, 수신 터미널, 송신 터미널, 그리고 중계 장치에 관한 것으로서, 더 상세하게는 송신 터미널과 수신 터미널이 모두 독립적으로 소정의 단방향 또는 쌍방향 버티컬 컨넥션을 확립할 수 있도록 구성되는 네트워크 자원 예약 제어 방법, 네트워크 자원 예약 제어 장치, 수신 터미널, 송신 터미널, 및 중계 장치에 관한 것이다.

ATM(Asynchronous Transfer Mode)을 사용하여 IP(Internet Protocol) 네트워크를 구축함에 있어서, ATM의 버츄얼 컨넥션(vertual connection, 이하 VC로 약칭함)에 의해 컨넥션없는 IP 패킷들을 전송하는 방법과 컨넥션-오리엔티드 기술(connection-oriented technology)이 해결되어야 할 문제점으로 제시된다.

종래에는, RSVP(자원 예약 프로토콜, Resource Reservation Protocol) 및 ST-II(Stream Transport Protocol-II)가 버츄얼 컨넥션 등의 네트워크 자원의 예약을 위한 프로토콜로서 이용될 수 있었다. RSVP는 수신측이 컨넥션을 확립할 수 있게 하며, ST-II는 송신측이 컨넥션을 확립할 수 있게 한다.

그러나, RSVP와 ST-II에서는, 컨넥션의 확립이 수신측 또는 송신측 중 하나에 의해서 단지 단방향에서만 이루어질 수 있기 때문에, 때때로 비효율적인 컨넥션 확립의 문제를 일으킨다.

또한 RSVP와 ST-II는 자원의 요구가 송신측으로부터 수신측으로 및 그 역으로 독립적으로 만들어질 수 없다는 또 다른 문제점을 갖는다.

그러므로, 본 발명의 목적은 송신측과 수신측 모두가 다양한 방법으로 효율적인 컨넥션을 확립할 수 있도록 하는 것이다.

본 발명을 실행함에 있어서, 그 특징에 따르면 네트워크 자원 예약 제어 방법은: 자원 예약이 수행되는 방향으로서 자원 예약이 송신 터미널로부터 수신 터미널로의 제1 방향 및 수신 터미널로부터 송신 터미널로의 제2 방향에서의 단방향 통신, 또는 제1 방향 및 제2 방향이 결합된 쌍방향 통신 중 어느 하나를 지정하기 위하여 제1 정보와 제1 방향 및 제2 방향에서 독립적으로 자원을 요구하기 위한 제2 정보로 구성된 메시지를 송신하는 단계; 및 상기 송신 단계에서 송신된 상기 메시지의 제1 정보에 의해서 지정된 방향에서 제2 정보에 의해 요구된 자원을 예약하는 단계를 포함한다.

본 발명을 실행함에 있어서, 또 다른 특징에 따르면 네트워크 자원 예약 제어 장치는: 자원 예약이 수행되는 방향으로서 자원 예약이 송신 터미널로부터 수신 터미널로의 제1 방향 및 수신 터미널로부터 송신 터미널로의 제2 방향에서의 단방향 통신, 또는 제1 방향 및 제2 방향이 결합된 쌍방향 통신 중 어느 하나를 지정하기 위한 제1 정보와 제1 방향 및 제2 방향에서 독립적으로 자원을 요구하기 위한 제2 정보로 구성된 메시지를 송신하기 위한 송신기; 및 상기 송신기에 의해 송신된 상기 메시지의 제1 정보에 의해서 지정된 방향으로 제2 정보에 의해 요구된 자원을 예약하기 위한 자원 예약 시스템을 포함한다.

본 발명을 실행함에 있어서, 또 다른 특징에 따르면 수신 터미널은 송신 터미널로 메시지를 송신하기 위한 송신기를 구비하는데, 여기서 상기 메시지는 자원 예약이 수행되는 방향으로서 송신 터미널로부터 수신 터미널로의 제1 방향 및 수신 터미널로부터 송신 터미널로의 제2 방향으로의 단방향 통신, 또는 제1 방향과 제2 방향이 결합된 쌍방향 통신 중 어느 하나를 지정하기 위한 제1 정보, 및 제1 방향과 제2 방향으로 독립적으로 자원을 요구하기 위한 제2 정보로 구성된다.

본 발명을 실행함에 있어서, 또 다른 특징에 따르면 송신 터미널은 수신 터미널로 메시지를 송신하기 위한 송신기를 구비하는데, 여기서 상기 메시지는 자원 예약이 수행되는 방향으로서 송신 터미널로부터 수신 터미널로의 제1 방향 및 수신 터미널로부터 송신 터미널로의 제2 방향에서의 단방향 통신, 또는 제1 방향과 제2 방향이 결합된 쌍방향 통신 중 어느 하나를 지정하기 위한 제1 정보, 및 제1 방향과 제2 방향에서 독립적으로 자원을 요구하기 위한 제2 정보로 구성된다.

본 발명을 실행함에 있어서, 본 발명의 다른 특징에 따르면 중계 장치는: 자원 예약이 수행되는 방향으로서 자원 예약이 송신 터미널로부터 수신 터미널로의 제1 방향 및 수신 터미널로부터 송신 터미널로의 제2 방향에서의 단방향 통신, 또는 제1 방향 및 제2 방향이 결합된 쌍방향 통신 중 어느 하나를 지정하기 위하여 제1 정보와 제1 방향 및 제2 방향에서 독립적으로 자원을 요구하기 위한 제2 정보로 구성된 메시지를 중계하기 위한 중계; 및 상기 송신기에 의해 송신된 상기 메시지의 제1 정보에 의해서 지정된 방향에서 제2 정보에 의해 요구된 자원을 예약하기 위한 자원 예약 시스템을 포함한다.

네트워크 자원 예약 제어 방법 및 네트워크 자원 예약 제어 장치에서, 메시지는 자원 예약이 수행되는 방향으로서 송신 터미널로부터 수신 터미널로의 제1 방향 및 수신 터미널로부터 송신 터미널로의 제2 방향에서의 단방향 통신, 또는 제1 방향과 제2 방향이 결합된 쌍방향 통신 중 어느 하나를 지정하기 위한 제1 정보, 및 제1 방향과 제2 방향에서 독립적으로 자원을 요구하기 위한 제2 정보로 구성된다. 상기 제2 정보에 의해 요구된 자원은 상기 송신된 메시지의 제1 정보에 의해 지정된 방향에서 예약된다.

수신 터미널에서, 송신기는 자원 예약이 수행되는 방향으로서 송신 터미널로부터 수신 터미널로의 제1 방향 및 수신 터미널로부터 송신 터미널로의 제2 방향에서의 단방향 통신, 또는 제1 방향과 제2 방향이 결합된 쌍방향 통신 중 어느 하나를 지정하기 위한 제1 정보, 및 제1 방향과 제2 방향에서 독립적으로 자원을 요구하기 위한 제2 정보로 구성된 메시지를 송신 터미널로 송신한다.

송신 터미널에서, 송신기는 자원 예약이 수행되는 방향으로서 송신 터미널로부터 수신 터미널로의 제1 방향 및 수신 터미널로부터 송신 터미널로의 제2 방향에서의 단방향 통신, 또는 제1 방향과 제2 방향이 결합된 쌍방향 통신 중 어느 하나를 지정하기 위한 제1 정보, 및 제1 방향과 제2 방향에서 독립적으로 자원을 요구하기 위한 제2 정보로 구성된 메시지를 수신 터미널로 송신한다.

중계 장치에서, 중계는 자원 예약이 수행되는 방향으로서 송신 터미널로부터 수신 터미널로의 제1 방향 및 수신 터미널로부터 송신 터미널로의 제2 방향에서의 단방향 통신, 또는 제1 방향과 제2 방향이 결합된 쌍방향 통신 중 어느 하나를 지정하기 위한 제1 정보, 및 제1 방향과 제2 방향에서 독립적으로 자원을 요구하기 위한 제2 정보로 구성된 메시지를 중계하고; 그리고 자원 예약 시스템은 상기 중계에 의해 중계된 상기 메시지의 제1 정보에 의해 지정된 방향에서 제2 정보에 의해 자원을 예약한다.

도 1은 AMInet 구조의 일예를 도시하는 개략도.

도 2는 AMInet 구조의 시스템 구성의 일예를 도시하는 개략도.

도 3은 수신기가 자원 예약 요구 메시지를 발하는 상태를 도시하는 개략도.

도 4는 ASP의 모범적인 구성의 일예를 도시하는 개략도.

도 5는 ASP의 현재의 실장에서 자원 예약의 확립 및 해제의 성능을 도시하는 그래프.

도 6은 ASP의 헤더의 포멧의 일예를 도시하는 도면.

도 7은 백본 루터(backbone router)의 구성의 일예를 도시하는 도면.

도 8은 에지 루터의 구성의 일예를 도시하는 도면.

도 9는 네트워크의 구성의 일예를 도시하는 개략도.

도 10은 ASP의 내부 테이블을 도시하는 도면.

도 11은 ASP 메시지의 흐름 및 VC 확립이 수행된 절차를 도시하는 도면.

도 12는 또 다른 ASP 메시지의 흐름 및 VC 확립이 수행된 또 다른 절차를 도시하는 도면.

도 13은 또 다른 ASP 메시지의 흐름 및 VC 확립이 수행된 또 다른 절차를 도시하는 도면.

도 14는 또 다른 ASP 메시지의 흐름 및 VC 확립이 수행된 또 다른 절차를 도시하는 도면.

도 15는 또 다른 ASP 메시지의 흐름 및 VC 확립이 수행된 또 다른 절차를 도시하는 도면.

도 16은 또 다른 ASP 메시지의 흐름 및 VC 확립이 수행된 또 다른 절차를 도시하는 도면.

도면의 주요 부분에 대한 부호의 설명

41 : SENDER

42, 46 : 에지 루터

43, 44, 45 : 백본 루터(backbone router)

47 : RECEIVER

본 발명은 첨부된 도면들을 참조하여 실시예에 의해 더욱 상세하게 설명될 것이다. 첫번째는 광역 고속 네트워크 환경을 제공하는 본 출원인 등에 의해 개발된 AMInet 관하여 설명할 것이다.

AMInet는 기존 네트워크 구조에 포함된 문제점들을 해결하기 위한 차세대 네트워크 구조이다. AMInet는 컨넥션 지향의 QoS(connection-oriented Quality of Service), 멀티캐스트 서포트(multicast support), 식별자와 어드레스 사이의 분리, 비엔드들(non-ends)간의 제어, 및 예를 들어 니고시에이션에 바탕을 둔 최적 프로토콜 스택(negotiation-based optimum protocol stack)의 동적 건축(dynamic construction)을 특징으로 한다. AMInet 구조에 기초한 네트워크는 광역 백본뿐만아니라 가정내 네트워크도 대상으로 하는 다가오는 FTTH(Fiber to the Home) 세대를 목적으로 한다.

현재, 통신과 방송의 융합을 목적으로 하는 새로운 네트워크 구조들이 찾아지고 있다. OSI(Open System Interconnection) 참조 모델 및 인터넷 구조가 약 20년 정도 전에 설계되었는데, 동화상 및 음성 등의 연속적인 미디어 통신을 실현시키기 위한 요구, 휴대형 컴퓨팅의 출현에 의해 요구된 이동-투과 통신, 및 ATM(Asynchronous Transfer Mode)으로 대표되는 초고속 통신 기술들의 효과적인 이용에 대처할 수 없게 되었다.

인터넷은 상술한 요구들 및 기술들을 만족하고 구현하기 위하여 확장되어 왔다. 그러나, 인터넷 구조는 상술한 풀리지 않는 문제점을 만드는 하기의 한계를 포함한다:

- 데이터그램(datagram)을 기본으로 하는 IP(Internet Protocol);

- 데이터 링크 특성들을 고려안함;

- 식별자와 어드레스 사이에 분명한 차이가 없음; 및

- 엔드 노드들 사이에서만 트래픽 제어를 함.

인터넷 접속의 현재 상태에서, 대기업들은 전용선을 통해 인터넷에 상시 접속된다. 소기업들 및 가정 사용자들은 다이얼-업에 근거한 간헐적인 접속을 통해 접속된다. 상시 접속의 회선 속도는 대략 1.5 Mbps(megabits/second) 정도이며, 간헐적인 접속의 회선 속도는 대략 128 Kbps(kilobits/second) 정도이다. 접속 형태가 간헐적인 접속에서부터 상시 접속으로 용이하게 변환하는 것은 가정 및 직장에서의 인터넷 이용 형태를 뚜렷하게 변화시킨다. 또한, 회선 속도의 큰 증가는 오늘날의 상상할 수 없는 응용들을 발생시켰다.

FTTH(T.Mike, 1994년 2월 발행된 IEEE Communications Megazine, Vol. 32, No. 2의 Toward the Service-Rich Era) 및 xDSL(G.T. Hawley, 1997년 3월 발행된 IEEE Communications Megazine, Vol. 32, No. 2의 Systems Considerations for the Use of xDSL Technology for Data Access)의 현실화에 의해서 가정과 기업들이 초고속 네트워크에 대칭/준대칭형으로 상시 접속되는 장래에 주목하여, AMInet 구조는 인터넷 구조에 포함된 중요한 문제점들을 해결하기 위하여 의도되었다. 이하에서는 AMInet 구조 및 그 시스템 모델을 설명한다.

장래의 증가하는 많은 응용들은 동화상 및 음성 등의 연속적인 미디어를 처리할 것이다. 기술적으로는, 이용가능한 대역폭, 전송 지연, 전송 지연에서의 저 지터(low jitter), 및 에러율에 대한 서비스의 품질(QoS)이 보증되어야 한다.

다른 한편으로는, 의료용 화상, 신문, 및 영화 필름 전체 등과 같은 대량 데이터의 전송에 대한 요구가 장래에는 증가할 것이다. 이와 같은 응용들은 가능한한 빨리 데이터를 전송할 것이 요구된다. 기술적으로는, 소위 long fat pipe 문제가 해결되어야 하며, 초고속 네트워크의 대역들을 효과적으로 사용하기 위한 기술이 개발되어야 한다.

대부분의 현재의 통신 형태들은 일대일 접속에 기반을 두고 있다. 장래에 요구되는 것도 또한 둘 이상의 목적물로 동일한 데이터를 전송하기 위한 멀티캐스트 통신 및 이동체와의 이동 투과 통신이다. 구조에 있어서는, 식별자와 어드레스 사이의 관계를 처리하는 방법의 문제가 있다. 기술적으로는, 측정할 수 있는 경로 제어 방법(scalable route control method)이 확립되어야 한다. 더우기, QoS 보증과 고속 및 대용량 통신이 요구된다.

컴퓨터 네트워크가 통신 인프라스트럭쳐(infrastructure)를 실제적으로 제공하기 위하여, 강한 안정성이 실현되어야 한다. AMInet는 노드들 간의 비밀, 탬퍼 방지, 인증 및 트래픽 해석 방지를 보증한다. 이용자 인증은 응용 프로그램들에 의해 제어되므로, AMInet의 범주의 밖에 있게 되는 것이 일예이다.

상술한 특징들을 갖는 네트워크를 구축한다 하더라도, 기존 인터넷과의 호환성의 결여는 이용자들을 상기 네트워크로 자연스럽게 인도할 수 없다. 이와 같은 형태의 네트워크가 이용자들에게 분명히 필요한데, 즉 상기 네트워크는 그들이 이용하고 있는 네트워크가 AMInet 네트워크인지 또는 기존의 인터넷인지의 여부에 대한 인식을 사용자들이 하게끔 한다.

인터넷의 결점들과 대비되는 AMInet 구조의 특징들은:

- 최적 프로토콜 스택의 동적 구축;

- 노드들간의 동위 레벨층 사이 및 노드 내의 상하층 사이의 니고시에이션;

- 컨넥션 지향의 QoS 보증;

- 노드 식별자와 어드레스 사이의 분리;

- 비엔드들 사이의 제어; 및

- 통신 매체에 의존하는 구조이다.

OSI 계층 모델이 뒤따른다면, 하나의 층은 그 아래 층의 기능을 추상화하며, 그 하부층을 면밀히 은폐한다. 현실의 광역 네트워크는 다른 특성을 갖는 다양한 링크들로 구성된다. 이동 노드의 경우에는, 데이터 링크 특성들은 통신시에 변경될 수 있다. 상하층간의 니고시에이션은 상층이 하층들의 특성 및 상태를 알게하며, 통신 환경에 동적으로 적응할 수 있게 한다.

프로토콜 스택이 고정되면, 동일한 기능들이 다른 층들간에 중복 실행될 수 있기 때문에, 낭비의 원인이 된다. AMInet에서는, 최적 프로토콜 스택이 동적으로 구축된다. 예를 들어, 엔드 노드들 간의 모든 데이터 링크들이 신뢰성을 보증한다면, 트랜스포트층에서의 신뢰성을 보증하는 기능이 생략될 수 있다. 또한, 무선 LAN에 의해 접속된 노드가 광역 네트워크 내의 다른 노드와 통신하는 경우와 같이 통신 루트에 따른 소정 부분이 다른 부분들과는 다른 데이터 링크를 갖는다면, 데이터 링크 특성 차이들을 일치시키도록, 특정 프로토콜 스택은 다른 데이터 링크의 양측들 상에서만 노드들에 대해 형성될 수 있으므로, 엔드간의 통신 효율을 향상시킬 수 있다.

니고시에이션은 최적 프로토콜 스택을 구축하는데 사용된다. 정상적으로, 니고시에이션은 노드들 사이의 동위 레벨층간에 행해진다. AMInet에서, 니고시에이션은 노드 내의 상하층들 사이에서도 행해진다.

인터텟은 IP 데이터그램 상에 구축되므로, 네트워크 층 내에서 논리 컨넥션을 명확하게 확립하는 것과 QoS를 보증하는 것을 고려하지는 않는다. 이것은 인터넷 층들이 네트워크 장해에 대해 내고장성을 중시하기 때문이다. 반대로, AMInet는 QoS를 중시하며, 이것을 보증하기 위해, 논리 컨넥션을 적극적으로 이용한다.

인터넷에서, IP 어드레스는 노드의 위치를 표시하며, 동시에 노드 식별자를 제공한다. 그러므로, 어떠한 이동 투과 통신도 인터넷 내에서 이동 노드를 가지고 실행될 수 없다. 이것은 또한 안전성을 확보하기 위한 처리를 복잡하게 한다. 차세대 IP인 IPv6에서, 노드 식별자에 대한 논의는 가열되었지만, 그 개념이 사용되지는 않았다. AMInet에서, 노드 식별자와 노드 어드레스 사이의 분명한 차이는 이동 투과 통신(F. Teraoka, K. Uehara, H. Sunahara, 및 J. Murai.VIP: A Protocol Providing Host Mobility, CACM, Vol. 37, No. 8, 1994년 8월)의 현실화를 가능하게 하여, 그 결과 안전성 처리에 대한 부담을 경감시켰다.

또한, 인터넷에서, 플로우 제어, 에러 회복, 및 밀집 제어(congestion control)는 엔드 노드의 트랜스포트층 상에서 행한다. 밀집 제어를 위하여, 밀집된 노드(루터)와 송신 노드 사이에서 더 효과적으로 밀집 회복이 고려된다.

AMInet와 인터넷에 공통적인 것은 데이터 링크에 독립된 구조를 만들기 위해 모든 노드에 공통된 층을 도입하는 것이다. 인터넷과의 호환성을 유지하기 위하여, AMInet는 소위 네트워크층으로 불리우는 IPs (v4 및 v6)를 사실상 사용한다. 그러나, 프로토콜 스택의 동적 구축때문에, IP층은 때때로 데이터 통신에서 바이패스될 수 있다.

이하에서는 프로토콜층에 대하여 설명한다. 상술한 바와 같이, AMInet는 프로토콜 스택을 동적으로 구축한다. 프로토콜 모듈들의 표현을 기능별 계층화가 도 1에 도시된다. 최하위층은 다이렉트 네트워크층이다. 이 층은 단일 전송 매체를 통하여 직접 통신을 할 수 있는 노드간의 통신을 제공한다. 이 층은 OSI 참조 모델의 물리층과 데이터 링크층에 상당한다. 구체적으로, 이 층은 에더넷 및 ATM의 프로토콜에 대응한다.

도 1은 AMInet 구조를 표현하는데, 여기서 다이렉트 네트워크층 상에 버츄얼 네트워크층이 위치한다. 복수의 전송 매체로 구성된 네트워크를 만드는 버츄얼 네트워크층이 하나의 전송 매체를 가상적으로 보이게하여, 이 네트워크에 접속된 노드들 사이의 통신 기능을 제공한다. 프로토콜 스택의 동적 구축은 상기 층 상에서 행해진다. 버츄얼 네트워크층은 OSI 참조 모델의 네트워크층 및 트랜스포토층에 상당한다.

버츄얼 네트워크층 위에 세션층(session layer)이 위치한다. 세션층은 네트워크층에 의해 제공된 통신 기능을 추상화하며, AMInet 구조의 취상위층 상에 위치된 애플리케이션층에 추상화의 결과를 제공한다. 상기 세션층은 OSI 참조 모델의 세션층과는 기능적으로 차이가 있다. 추상화는 QoS 파라미터를 TV 품질 동화상과 같이 수치이외로써 지정 가능하도록 하며, 노드 어드레스나 노드 식별자에 의해서가 아니라 서비스 이름에 의해서 통신의 메이트를 지정 가능하게 하며, 버츄얼 네트워크층에서의 컨넥션이 장해나 노드 이동에 의해 일시적으로 방해받는다면, 컨넥션이 마치 계속되는 것처럼 보이도록 한다. 최상위의 애플리케이션층은 AMInet 프로젝트의 대상이 아니다.

도 1을 참조하면, 수평 화살표 각각은 동위 계층간의 니고시에이션을 표시한다. 각 수직 화살표는 서로 다른 층들 사이의 니고시에이션을 표시한다. 동위 계층 사이의 니고시에이션들은 세션 니고시에이션, 엔드 노드간에 행해지는 플로우 니고시에이션 및 인접한 노드간에 수행되는 홉-바이-홉(hop-by-hop) 니고시에이션을 포함한다.

서로 다른 레벨들의 층들 사이의 니고시에이션은 상위층으로부터 하위층으로 전달된 요구 및 하위층의 상태를 상위층으로 전송되도록 하는 지시를 포함한다. 이 니고시에이션들은 엔드 노드들간의 통신 환경 및 다이렉트 네트워크층의 특성에 관한 정보를 제공하며, 최적 프로토콜 스택의 구축을 지지한다.

다음으로, AMInet 구성에 관하여 설명한다. AMInet는 광역 네트워크 뿐만아니라 가정내 네크워크도 고려한다. AMInet 프로젝트로써 상정된 시스템 구성은 도 2에 도시된다. 도면에 도시된 바와 같이, 전체 네트워크는 백본 네트워크, 홈 네트워크, 및 가입자 네트워크의 3개 부분으로 구성된다.

도 2는 AMInet 시스템 구성의 일예를 도시한다. 백본에 대하여 설명하면, 일본 전역을 커버할 수 있을 만큼 대규모의 것이 상정되는데, ATM의 초고속 통신 기술들을 활용한다. 백본을 제공하는 ATM 네트워크는 ATM 스위치들(및 광섬유)로 구성된다. 상기 ATM 스위치들 중에서, 초고속 시그널링 등의 AMInet 독자의 기능 확장인 것을 백본 루터(backbane router)라고 부른다.

백본 주위에는 에지 루터들이 배치된다. 백본 루터와 같이 ATM 스위치의 AMInet 독자의 기능적 확장이 에지 루터이다. 에지 루터는 가입자 라인들을 집중하고 그것들을 백본에 접속시키도록 배치된다. 에지 루터는 또한 가입자들에게 요금을 청구하고, 홈 네트워크로부터 백본으로의 트래픽을 형성한다. 가입자 라인들은 FTTH에 의해 광섬유일 수도 있으며, 동선을 이용한 ADSL(cooper-wire-based Asymmetric Digital Subscriber Line)과 같은 기술들을 이용하는 것도 가능하다. 다른 경우에, ATM 네트워크는 접속된 가정 각각에 도달하도록 고려된다.

접속된 각 가정에는 홈 루터가 설치된다. 외부 네트워크 인터페이스 등의 ATM 또는 내부 네트워크 인터페이스 등의 IEEE 1394 또는 에더넷(10 Mbps/100 Mbps)을 갖도록 홈 루터는 상정된다. IEEE 1394는 대역 할당과 같은 QoS를 보증할 수 있으므로, QoS 보증 통신이 엔드 노드들 사이에서 수행될 수 있도록 하는 이점이 있다. 장래에는, AV 기기가 IEEE 1394를 갖는 것이 기대되므로, 컴퓨터 뿐만아니라 AV 기기도 네트워크에 접속될 것이다.

다음으로, AMInet 내의 ATM 및 IP의 통합에 기초한 실시간 통신의 실현(AMInet 내의 실시간 통신용 IP를 통한 ATM 제어)에 대하여 설명한다. 이하에서는 AMInet 프로젝트에 의해 전제된 백본 및 가정 사용자들을 접속시키기 위하여 광역 네트워크에 이용하는 자원 예약 셋업 프로토콜 ASP(AMInet Setup Protocol)에 대하여 설명한다. ASP는 IP의 유연성 및 적응성과 회선 지향형 데이터 링크인 ATM에 주목하며, IP와 ATM을 통합하여 초고속이면서도 유연한 자원 예약을 실현한다. ASP는 통상의 ATM 시그널링을 사용하지 않고 IP에 의해 전달된 메시지를 사용하여, ATM VC를 동적으로 확립한다. 다음으로, ASP의 특징, 현재의 프로토타입 실장 및 QoS 루팅의 통합을 설명한다.

FTTH(Fiber To The Home) 및 xDSL(Digital Subscriber Line) 기술의 진보는 다이얼-업이 아닌 상시 접속된 고속 네트워크를 가정에서 사용하는 것을 실현할 것이다. 이와 같은 환경에서, 통합화 서비스(Integrated Service, IS) 및 대용량 파일들의 전송 등의 애플리케이션들은 효율적으로 현실화되어야 한다. 특히, IS의 현실화를 위하여, 자원 예약이 효과적이다. 자원 예약의 도입은 네트워크가 QoS(Quality of Service)를 보증하도록 한다. 그 밖에, 네트워크 자체를 효과적으로 사용하기 위해 TSP 기능이 확장될 수 있다.

다음으로, 광역 고속 네트워크 환경을 제공하는 AMInet 내의 자원 예약에 사용하는 AMInet 셋업 프로토콜에 대하여 설명한다. 자원 예약 기능을 제공하기 위하여, ASP는 ATM VC 기술 및 IC를 효과적으로 통합한다. ASP는 또한 고속 자원 예약 및 동적 QoS 변경을 지지하며, QoS 루팅과의 통합을 고려한다.

다음으로, 자원 예약에 대하여 설명한다. 인터넷에서, IS를 지지하기 위한 자원 예약은 중요시 될 것이다. 자원 예약의 도입은 패킷 교환에 기본적으로 근거한 인터넷으로의 접속의 개념을 도입한다. 그 결과, 데이터 링크로서 ATM의 사용은 완전히 유효하며, ATM에 의한 QoS의 보증을 용이하게 한다.

AMInet는 또한 ATM에 주목하기 때문에, 데이터 링크들 중 하나로서 그것을 취급한다. 본 명세서에서는, ATM의 사용에 의해 주요하게 얻어지는 실현에 관하여 설명한다. 현재, 인터넷 표준화 단체인 IETF(Internet Engineering Task Force)는 자원 예약 프로토콜로서 RSVP(Resourde Reservation Protocol)를 제안된 표준으로 표준화하고 있다. RSVP의 경우에는, 현재 규정된 인터넷 드래프트는 ATM의 SVC(Switched Virtual Channel)를 사용하는 형태를 전제로 한다. 그러므로, VC(Virtual Channel)는 ATM 시스널링의 이용에 의해 확립되어야 한다. 그러나, 현재의 시그널링 처리는 무겁고 시간이 걸리기 때문에, 애플리케이션과 네트워크 모두에 악영향을 끼칠 가능성이 크게 된다. 이 문제점을 해결하기 위하여, 시스널링을 위하여 필요한 처리가 병렬 처리용으로 나누어 지는 몇몇 시스템이 제안되어 왔다.

또한, 동시에 복수의 루트에 따른 자원 예약을 수행함으로써 크랭크백(cranckback)에 기인한 경감하는 연구들이 수행되고 있다. 현재, 상업적으로 이용 가능한 ATM 스위치들에 SVC의 사용은 시그널링 처리 시간을 통상의 IP 데이터 통신에 사용될 수 없게 한다. 이것은 주로 ATM 스위칭이 음성 데이터, 즉 종래 기술에서의 접속 확립 시간을 기준으로하여 설계되기 때문이다. 또한, 현재의 시그널링의 사용은 독자적으로는 QoS를 동적으로 변경할 수 없다.

상술한 문제점들을 해결하기 위하여, AMInet는 유연성이 고도한 IP를 셋업 메시지 전송에 이용하여 ATM VC를 직접 확립하고 QoS를 보증한다.

ASP(AMInet Setup Protocol)는 광역 네트워크, 특히 AMInet 아키텍쳐에 기초한 루터들에 의해 구성된 환경에서 동작하는 자원 예약 프로토콜이다. AMInet는 ATM 스위칭 기능을 갖는 루터들을 갖고, 백본 및 그 경계 상에 배치된 에지 루터들에 의해 구성된다. 예약된 자원들은 ATM VC 또는 패킷 처리에 이용되는 큐(queue)를 포함한다. 특히, ATM과의 통합의 경우에, 통상의 ATM 시그널링이 사용되지는 않지만, ATM 스위치 또는 ATM 기능을 갖는 루터에서 VC를 확립한다. 셋업 메시지는 IP를 사용하여 전송되므로, 고석 자원 예약이 현실화된다. 그러므로, 통상 ATM 스위칭에서 SVC라 불리우는 VC가 전혀 사용되지 않는다. VC는 IP를 사용하는 메시지에 의해 동적으로 확립된다. 이와 같은 VC를 PVC-on-demand로 부른다. ASP의 사용은 통상의 SVC와는 다른 방식으로 VC를 동적으로 확립하거나 절단할 수 있다.

ASP가 사용되면, 데이터는 통상의 IP에 의해 전송되며, IP 패킷은 특정의 예약된 자원 상에 매핑된다. 그러므로, ASP는 장래에 도래할 수 있는 새로운 애플리케이션들과 용이하게 호환될 수 있다. 종래의 애플리케이션들로부터 새로운 애플리케이션들로의 매핑은 소스 및 데스티네이션 IP 어드레스들, 소스 및 데스티네이션 포트 번호들, 그리고 프로토콜 식별자 필드들을 참조함으로써 수행된다. 통상의 IP 트래픽, 즉 베스트 에퍼트(BE, Best Effort) 트래픽은 선정된 디펄트 BE VC를 통하여 전송된다. ASP를 사용함에 의해 예약된 자원들은 BE 트래픽에 의해 영향받지 않는다. 예를 들어, 자원 절약을 고려하여 하나의 VC 내로 묶인 플로우들은 BE 트래픽에 의해 영향받지 않고, 공존할 수 있다.

다음으로, 유연성 있는 셋업 시스템을 설명한다. ASP에서, 유효하게 자원을 이용하거나 애플리케이션 요구들에 따라서 예약하기 위한 다양한 형태들에서 자원들이 예약될 수 있다. 인터넷과 ATM 환경에서는, 다양한 형태의 애플리케이션이 존재한다. 이들은 방송형에서부터, TV 회의, 원격 진단, 비디오 온 디맨드(video on demand), 및 M-bone을 이용한 멀티캐스트 애플리케이션을 포함하는 데이터가 쌍방향으로 전송되는 대화형에 이르는 범위에 있다. 각각의 형(type)에 있어서, QoS 파라미터들은 효과적으로 하층 상에 자원 예약 파라미터들 내로 측정가능한 방식으로 매핑되어야 한다.

예를 들어, VoD의 경우에, VC는 서버와 고객 사이의 쌍방향으로 확립될 필요는 없다. 이것은 데이터가 언제나 서버로부터 고객에게로 흐르기 때문이다. ASP가 사용되면, ASP 고유 메시지들의 교환, 애플리케이션에 필요한 데이터 전송이 아닌 제어의 교환(VoD의 경우에, 보여지는 영화를 변경하는 동안에 고객으로부터의 요구), 및 상층에 필요한 교환(예를 들어, 트랜스포트층)은 전용 VC에 의해 수행될 수 있지만, 디펄트 BE VC만을 사용하여 선택적으로 수행될 수도 있다. ATP 메시지들은 디펄트 BE VC 또는 지정 전용 VC를 통하여 전송된다.

한편으로, 대화형 TV 회의 애플리케이션의 경우에는, 쌍방향 VC가 필요하다. ASP는 일방향과 쌍방향형 모두에 대하여 호환될 수 있다. 쌍방향형의 경우에, 서로 다른 QoS들이 있을 수 있는 비대칭 모델이 상류 및 하류 트래픽으로 설정된다.

RSVP나 ST-2+(Stream Transfort-2+)와 같이, ASP는 자원 예약 요구가 수신측 뿐만아니라 송신측으로부터 발신되는 것을 가능하게 한다. 송신측이 자원 예약에 필요한 QoS 정보를 갖는 것과 수신측이 그 정보를 갖는 두 경우가 존재한다. 어느 경우에나, ASP는 모든 예약들이 하나의 패스에 의해 설정되는 것이 가능하게 한다. 또한, 필요하다면, 각 측은 예약 완료를 표시하는 응답 메시지를 가질 수 있다.

도 3은 일반 자원 예약 요구 메시지가 수신측에 의해 발신되는 예를 도시한다. 이것은 예를 들어, 비디오의 방송형 애플리케이션이 ASP를 사용하는 경우를 나타낸다. 즉, 데이터는 서보(송신측, 1)로부터 고객(수신측, 7)로의 방향에서만 전송된다.

수신측(7)은 우선 QoS 파라미터를 해석한 다음, 이 접속에 의해 사용되는 VPI/VCI를 결정하고, 필요하다면, ATM NIC(Network Interface Card)를 설정한다. 또한, 수신측(7)은 상기 정보를 포함하는 ASP 메시지를 발생하여, 백본에 인접하게 배치된 에지 루터로 발생된 ASP 메시지를 전송한다. 상기 메시지는 IP 호프 마다 처리되는 IP에 의해 전송된다. 도 3의 실시예에서, 메시지가 에지 루터에 도달할 때, 에지 루터는 수신측을 향하여 VPI/VCI 파라미터를 설정한다. VPI/VCI는 각각의 노드에서 독립적으로 제어된다. 이와 같이, ASP 메시지는 송신측(1)을 향하여 상류 방향으로 전송된다. 루터들(2 내지 6)에서, VC들은 상기 메시지의 전송 방향과 반대 방향에서 설정된다. 도면에 도시되지는 않았지만, 메시지가 예약을 사실상 완료하기 위하여 전송될 때, 필요에 따라 응답 메시지가 수신측(7)으로부터 전송된다. 이 때, 최저한의 백본에, VC가 송신측(1)으로부터 수신측(1)로의 방향에서 확립된다. 즉, 에지들을 연결하는 상기 VC의 이용은 데이터 전송시에 IP를 컷 스루(cut through)하고, ATM만에 의한 통신을 가능하게 한다.

도 3은 ASP에서의 유연성있는 셋업의 일 형태 만을 도시한다. 예를 들어, 단지 송신측(1) 만이 QoS 정보를 갖고 예약 요구가 멀티캐스트 애플리케이션에 의해 수신측(7)으로부터 발신된다면, 상술한 실시예에서의 응답이 돌아오는 제2 패스에서 VC 세팅이 실시되도록 메시지가 발생될 수 있다. 또한, 쌍방향의 VC들은 제1 패스에서만 확립될 수 있다.

다음으로, 동적 QoS 변경을 설명한다. ASP에서, ATM VC는 도자 셋업 시스템에 의해 확립된다. 그러므로, 다른 VC들이 이미 예약된 자원의 QoS를 동적으로 변경하기 위하여 사전에 준비될 필요가 없다. 또한, 애플리케이션의 서비스 수준이 간단하게 업그레이드될 수 있다. 예를 들어, BE로부터 IS로의 단순한 시프팅에 있어서, 디펄트 BE VC로부터 도3에 도시된 새로운 VC 내로 데이터 플로우가 용이하게 리매핑될(remapped) 수 있다.

다음으로, QoS와의 통합이 수행된다. ASP에서, VC 셋업 시에 QoS 루팅에 경로 선택 서포트가 고려된다. 구체적으로, 자원을 예약할 때, 종래 IP 레벨에서의 루팅 테이블은 사용되지 않지만, IS가 필요한 플로우를 위한 독자 루팅 테이블을 제어하는 모듈에 의해 경로 정보가 제공된다. 이것은 QoS 요구와 네트워크에서 자원의 이용가능성에 따라서 플로우 마다 다른 경로를 사용할 수 있게 한다.

종래의 자원 예약 프로토콜 및 루팅 시스템은 서로 독립적인 것으로 고려되어 왔다. ASP는 QoS 루팅과의 통합을 목적으로 한다. 이 통합은 QoS 루팅의 모듈로 ASP에 의해 보지된 자원 예약 정보를 피드백함으로써 수행된다. 그러므로, 예약 실패시에 대체 경로의 선택을 용이하게 된다. 또한, 예약된 자원을 네트워크 중에 분산시킬 수 있게되어, 하나의 경로에 자원 예약을 집중함이 없이 전 네트워크의 효율적인 이용을 이끈다.

다음으로, 프로토타입 실장이 수행된다. ASP는 UNIX 데몬 프로세스(aspd)로서 유저 공간에 실장된다. 프로토타입은 Free BSD 2.2.1에서 동작중이며, ATM 스위치를 제어하기 위한 라이브러리(swctl lib)와 ATM NIC를 세팅하기 위한 모듈(afmp)이 통합된다(도 4 참조). 현재, 3가지 형태의 루터들이 서포트된다. 홈 루터는 100 Base-T 에더넷과의 ATM 인터페이스를 갖는다. 에지 루터는 현재 복수의 ATM 인터페이스들을 갖는 루터로서 실현된다. 백본 루터는 ATM 스위치 및 이 ATM 스위치를 제어하기 위한 IP 엔진을 포함하는 PC를 포함한다. 현재의 프로토타입은 Adaptec사와 Efficient Networks사의 PCI 버스용 ATM 인터페이스 카드 및 Fore ASX-2000WG ATM 스위치를 이용한다. ASP 메시지는 raw IP를 사용하여 실장된다.

백본 루터는 갖춰진 스위치에 PVC-on-demand를 설정하기 위해 상술한 스위치 제어 라이브러리를 사용한다. IS가 필요한 IP 플로우는 CBR의 VC 내로 매핑된다. 현재, ASP는 ATM 스위치에 의해 일대다(one-to-many)의 멀티캐스트 VC를 발생시킴으로써 멀티캐스트와의 호환이 가능하다. 또한, ASP는 리프에 의한 조인 및 자원 예약을 서포트한다.

VCI 등의 식별기를 포함하는 ATM 자원들의 스칼라빌러티(scalability)를 고려하면, IP 플로우를 애플리케이션 베이시스 상으로 매핑하는 것은 비효율적이다. ASP의 이용은 VC 내로 동적으로 흐름을 통합하는 것을 용이하게 한다. 그러나, 장래에는 상기 통합을 위한 기준이 검토될 필요가 있다.

마지막으로, QoS 루팅 모듈이 현재 설계중에 있다. 이 모듈의 유효성은 시뮬레이션을 통해 검토되고 있다.

다음으로, 프로토 타입의 성능에 대하여 설명한다. 도 5는 ASP의 현재의 실장에서 자원 예약의 확립 및 해제의 성능을 도시한다. asp_open은 자원 예약 요구의 발신으로부터 그 예약의 정상 종료까지의 시간(예약이 성공하였다는 표시의 응답을 기다리는 시간을 포함한다)을 표시한다. asp_close는 예약의 해제에 필요한 시간을 표시한다. 이와 같은 시간들의 측정은, 단일 송신자와 단일 수신자 사이에 배치된 하나의 루터를 갖는 수신측으로부터의 유니캐스트 통신에 대하여 각각의 요구가 발신된 경우를 표시한다. 송신측과 수신측은 개별적으로 ATM NIC를 구비한다. 도면에서 ASP로서 표시된 시간은 ASP에 필요한 처리를 수행하고 NIC 내로 플로우를 매핑하기 위해 필요한 시간을 표시한다. swctl_lib는 상술한 ATM 스위치 제어 라이브러리에 필요한 처리 시간을 표시한다. switch는 ATM 스위치 제어 라이브러리를 사용하여 ATM 스위치를 세팅하기 위해 필요한 시간을 표시한다.

도 5로부터 도시된 바와 같이, 대부분의 경비는 ATM 스위치를 SNMP에 의해 세팅하기 위한 처리에서 발생한다(switch로 표시함). 이 스위치에 의존하여, 상기 처리에 필요한 시간은 명백히 불안정한데, 40 내지 110 ㎳ 사이에 분산되어 있다. 이 시간이 안정하더라도, 최소한 40 내지 50 ㎳는 필요하다. 이 시간에 사용된 스위치는 이와 같은 불안정한 동작을 목적으로 설계되지는 않았다. 또한, 스위치의 내부 구조에 대한 상세한 설명이 공개되지는 않았으므로, 이들 불안정한 동작들은 검토될 수 없다. 그 결과, 스위치에서의 SNMP처리나 VC 셋업 처리 또는 두 처리 모두 느려질 수 있다. 현재의 성능은 초당 20 내지 25 VCs를 처리할 수 있다. 그러나, 스위치에서 처리의 속도가 증가될 수 있다면, 성능을 뚜렷하게 향상시킬 수 있을 것이다. 현재, ASP와 하드웨어의 통합이 검토되고 있다. 이와 같은 통합이 완료된다면, 수백개의 VCs가 매초당 설정될 수 있다.

지금까지, AMInet에서의 자원 예약 프로토콜 ASP를 설명하였다. ASP는 독자의 셋업 시스템을 도입하였고, IP의 유연성과 ATM VC에 근거한 QoS 보증을 통합하였다. 따라서, 동적 QoS 변경, QoS 루팅과의 통합, 및 유연성 있는 셋업이 제공될 수 있으므로, 프로토타입 실현에 의해 고속 셋업을 실현할 수 있다는 것이 분명하게 되었다. 장래에는, 프로토타입을 독자의 스위치 하드웨어와 통합하고, 플로우 어그리게이션(flow aggregation)과 QoS 루틴을 실장할 수 있을 것이다.

다음으로, AMInet에서의 자원 예약을 위한 프로토콜을 설명한다. 상술한 바와 같이, ASP는 AMInet Setup Protocol을 약칭한 것이다. 여기서, Setup은 수신측, 송신측, 또는 경로 중 경유하는 루터에서 자원 예약 동안의 상태/정보를 세팅하는 것을 의미한다.

IP 네트워크에 흐르는 데이터가 다른 데이터에 의한 영향을 받지 않고 전송되도록, 회선 교환 기능을 갖는 하층 VC 또는 패킷 스케쥴러(packet scheduler)에 으해 제공될 수 있는 큐 할당 클래스(CBQ: Class Based Queueing)를 자원으로서 추상화한다. 구체적으로, 현재 프로토타입 실장의 ASP는 ATM VC 및 UPC 제어를 자원으로서 추상화하여, 이들 자원을 예약하고, VC를 IP의 흐름에 일치하게 한다. 여기서, 플로우는: 어드레스 패밀리(address family); 프로토콜 식별자인 프로토콜(protocol); 데스티네이션 및 소스 IP 어드레스들; 그리고, 데스티네이션 및 소스 포트 어드레스들과 같은 정보를 의미한다.

ASP 셋업, 즉 ASP 프로토콜 메시지의 익스체인지가 IP에 실장된다. 그러므로, ATM VC를 demand에서 발생시킬 때, ATM에 의해 실제로 준비된 시그널링 시스템은 사용될 필요가 없다. 이와 같은 자유가 유연성 및 효과적인 자원 예약을 가능하게 한다.

또한, ASP는 주로 RSVP 및 ST-2와 동등한 기능을 갖는다. ASP는 유연성있게 ATM VC들에 대응하며, 다음과 같은 기능들을 제공하는데, 즉 그 기능들은: 수신측 제어 예약 및 송신측 제어 예약; 고려되는 ATM VC와의 유연성 있는 셋업; 그리고 프로토콜 제어(예약 제어) 전용 대역(자원)의 할당이다.

도 6은 실시예에 의한 ASP 헤더 포멧을 도시한다. 필드 flags는 자원이 예약된 방향이 단방향인지 쌍방향인지를 표시하기 위한 정보를 지정한다. 필드prev-hop는 송신측과 수신측 사이에서 교환되는 메시지들이 동일 경로를 통과하도록 하기 위한 정보를 지정한다. 필드 VPI는 VCI(Virtual Connection(or Channel) Identifier)를 지정한다. 필드 flowinfo는 상술한 플로우 정보를 지정한다.

다음으로는 필드들 s_flowspec 및 r_flowspec이 나온다. 필드 s_flowspec은 송신측에 의해 송신된 데이터에 필요한 QoS를 지정한다. 필드 r_flowspec은 수신측으로부터 송신된 데이터에 필요한 QoS를 지정한다. 현재의 프로토타입에서, 각각의 플로우스펙 필드는 ATM의 CBR(Constant Bit Rate) 서비스를 세팅하기 위한 PCR 만을 포함한다. 상세한 것은 후술한다.

현재, ASP를 실장하기 위한 형태의 루터는 도 7에 도시된 바와 같은 백본 루터, 도 8에 도시된 바와 같은 에지 루터, 및 홈 루터를 포함한다. 또한, 엔드 호스트는 ASP 메시지들의 교환이 필요하다.

백본 루터(11)는 대규모로 네트워크를 구성하기 위한 중간 노드이며, TCP/IP를 이해하기 위한 소프트웨어 엔진(IP 엔진, 12)(중계 수단) 및 스위치부(스위칭 엔진, 13)(자원 예약 수단)(프로토타입에서의 ATM 스위치)로 구성된다. 즉, 각 백본 루터 사이의 접속은 통상의 IP 네트워크를 구성한다. 또한, VC 세팅은 컷-스루를 가능하게 한다.

에지 루터(21)는 복수의 백본 루터에 의해 구성된 네트워크의 포트에 설치된다. 상기 백본의 반대측은 다른 네트워크 또는 다른 루터에 접속될 수 있다. 에지 루터(21)는 통상의 IP 및 하나 이상의 인터페이스들(22 내지 24)을 갖는다.

도 9는 전체 네트워크의 접속예를 도시한다. 이 도면에 도시된 바와 같이, 네트워크를 통하여 대용량의 데이터를 송신하기 위한 서버들(송신 터미널들, 31 및 37)과 복수의 백본들(11)로 구성된 백본(32)을 직접 접속하는 것은 문제점을 야기하지 않는다. 통상의 엔드 노드들(34 내지 36)은 에지 루터(33)를 통해 백본(32)에 접속된다. 루터는 에지 루터(33) 아래에 설치된다. 엔드 노드(수신 터미널, 34)는 ATM 인터페이스(34a, 송신 수단)를 통해 에지 루터(33)에 접속된다. 엔드 노드(수신 터미널, 35)는 ATM 인터페이스(35a, 송신 수단)를 통해 에지 루터(33)에 접속된다. 엔드 노드(수신 터미널, 36)는 ATM 인터페이스(36a, 송신 수단)를 통해 에지 루터(33)에 접속된다.

ASP에 중요한 것은 각 루터에 의해 예약된 자원들 및 그 예약의 방법이다. 백본 루터에서는 스위치에서의 VC 세팅이 필요하다. 데이터가 백본 내로 흐르는 입구에서, 매핑은 소정의 플로우를 새롭게 발생시켰던 VC 상에서 수행되어야 한다. 통상, 이것은 에지 루터에 의해 행해진다. 서버가 백본에 직접 접속된다면, 매핑은 그 노드의 백본에 대응하는 ATM 인터페이스에 의해 수행되어야 한다.

각 노드의 ASP 모듈은 도 10에 도시된 바와 같은 자원 예약 상황을 관리하기 위한 상황 테이블을 유지한다. 이 테이블은 입력 VC에 관한 정보 및 출력 VC에 관한 정보를 관리하여, VC들을 플로우들(flowinfo)에 대응하게 한다. 각 에지 루터는 입력 및 출력 네트워크 인터페이스에 관한 정보가 필요하므로, 그 정보에 대한 필드들이 제공된다. 이 경우에, VC 정보에 대응하는 포트부는 더 이상 사용되지 않는다.

통상의 통신, 예를 들어 IP 통신을 수행하기 위하여, VC 및 ATM은 쌍방향을 발생되어야 한다. 그러나, ASP를 이용하여 VC를 유연하게 확립할 수 있다.

몇몇 애플리케이션에서, 애플리케이션에 의해 구별되는 통신은 단방향 또는 쌍방향 중 어느 하나이다. 예를 들어, VoD(Video on demand)와 관련된 애플리케이션에서, 비디오 데이터는 서보(송신측)로부터 고객(수신측)에게로 단지 단방향으로만 흐른다. 수신측이 화상 데이터에 대한 요구를 할 때, 데이터가 서보로 송신되는 통신은 가능하다. 예를 들어, 자원 예약 메시지들은 ASP를 요구함으로써 전용 VC를 통하여 익스체인지된다. 필요한 다른 익스체인지들은 디펄트 데이터 VC(통상의 IP 경로)를 통하여 흐른다. 그러므로, 이와 같은 경우에, 자원들을 위해 ASP를 요구하는 애플리케이션은 단방향 통신을 특정함으로써 단방향 VC들만 을 설정할 수 있으므로, 식별자들과 대역폭을 절약할 수 있다. 또한, 이와 같은 예약 방식은 방송측 멀티캐스팅에도 충분하다.

그러나, 비디오 회의 등의 대화형 애플리케이션에서, 데이터는 쌍방향으로 흐른다. 이와 같은 쌍방향으로 데이터가 흐르는 것은 통상의 통신과 동일하다. ASP가 사용될 때, 애플리케이션은 서로 다른 QoS들을 각 방향에서 흐르는 데이터에 대하여 세팅할 수 있다. 이 세팅은 ASP 헤더에서 두개의 플로우스펙 필드들의 값(s_flowspec 및 r_flowspec)들에 근거하여 행해진다. NULL 값이 플로우스펙 필드들 중 어느 하나에 포함된다면, 그 방향에서의 VC는 예약되지 않는다.

RECEIVER(수신 터미널; 47, 수신 수단)가 QoS를 안다면, 단방향 VC가 확립되는 절차를 도 11이 도시한다. 즉, RECEIVER(47)는, 예를 들어 VC 확립이 단방향으로 행해진 것을 표시하는 0값을 ASP 헤더의 필드 flags에 설정하고, VC의 대역폭(예를 들어, 5 Mbps(megabits/second))을 나타내는 정보를 ASP 헤더의 필드 s_flowspec에 설정하여, SENDER(송신 터미널, 41)로 최종 메시지를 송신한다. ASP 메시지는 RECEIVER로부터 SENDER로 흐르기 때문에, ASP 메시지가 흐르는 방향과 반대 방향에서의 각 루터에서 VC가 확립된다.

우선, 에지 루터(46, 자원 예약)는 ASP 메시지가 흐르는 방향과 반대 방향에서 VC를 확립한다. 이와 동일하게, ASP 메시지가 흐르는 방향과 반대 방향에서의 VC들은 백본 루터들(45, 44 및 43; 자원 예약 수단) 및 에지 루터(42; 자원 예약 수단)에서 순서대로 확립된다. 이 때, 백본 루터들(43 내지 45)을 구성하는 SW들(스위칭 엔진들)에서, 그 소정의 입력 포트와 그 소정의 출력 포트가 접속되어 상술한 VC를 확립한다.

도 12는 송신측 만이 QoS를 알 때, VC들이 세팅되는 절차를 도시한다. 우선, RECEIVER(47)는 ASP 헤더의 필드 s_flowspec에 NULL을 세팅하는 ASP 메시지를 SENDER(41)로 송신하여, VC 확립을 요구한다. 이 ASP 메시지를 수신하여, SENDER(41)는 상기 메시지를 해석하고, ASP 헤더의 필드 s_flowspec에 소정의 대역폭을 설정하는 것에 대응하는 값을 갖는 ASP 메시지를 RECEIVER(47)로 반송한다. 각 루터에서는, 상기 ASP 메시지가 흐르는 것과 동일 방향으로 VC를 세팅한다.

즉, 에지 루터(42), 백본 루터들(43, 44 및 45), 및 에지 루터(46) 순으로 ASP 메시지가 흐르는 방향과 동일 방향으로 VC들이 세팅된다.

도 13은 SENDER(41)가 예약을 시작할 때 VC들이 세팅되는 절차를 도시한다. 이 경우에도, ASP가 한 방향으로 흐르기 때문에, VC 확립은 각 루터에서 수행된다. 더 구체적으로는, SENDER(41)는 ASP 헤더의 필드 s_flowspec에 세팅된 선정된 대역폭에 대응한 값을 갖는 ASP 메시지를 RECEIVER(47)로 송신한다. 이 ASP 메시지에 기초하여, VC는 ASP 메시지가 흐르는 방향과 동일한 방향에서의 에지 루터에서 확립된다. 이 때, VC들은 백본 루터들(43, 33 및 45)과 에지 루터(46)에서 순서대로 확립된다.

대부분의 경우에, 예약의 종료가 확인되지 않는다면, 송신측은 데이터를 송신할 수 없다. 그러므로, 도시되지는 않았지만, 확인용 ASP 메시지가 RECEIVER(47)로부터 SENDER(41)로 송신된다.

도 14는 송신측과 수신측이 모두 데이터를 전송하기 위해 필요한 QoS를 알 때, 쌍방향 통신이 수행되는 절차를 도시한다. 이 경우, ASP 메시지들(예약 메시지들)이 양 방향에서 흐르며, VC들은 양 방향에서 세팅된다.

더 구체적으로는, SENDER(41)는 ASP 헤더의 필드s_flowspec에 세팅된 하방향 VC들의 대역폭에 대응하는 값을 갖는 ASP 메시지를 RECEIVER(47)로 송신한다. 이것은 ASP 메시지가 흐르는 방향과 동일한 방향에서의 에지 루터(42), 백본 루터들(43, 44 및 45) 및 에지 루터(46)에서 순서대로 하방향 VC들을 확립한다.

한편으로는, RECEIVER(47)는 ASP 헤더의 필드r_flowspec에 세팅된 상방향(RECEIVER(47)로부터 SENDER(41)로)에서의 VC들의 대역폭에 대응하는 값을 갖는 ASP 메시지를 SENDER(41)로 송신한다. 이것은 ASP 메시지가 흐르는 방향과 동일한 방향에서의 에지 루터(46), 백본 루터들(45, 44 및 43) 및 에지 루터(42)에서 순서대로 상방향 VC들을 확립한다.

도 15에 도시된 바와 같이, 송신측과 수신측이 모두 데이터 수신시에 필요한 QoS를 안다면, ASP 메시지들이 도 14에 도시된 것과 반대 방향에서 흐르기 때문에, VC들은 ASP 메시지가 흐르는 방향과 반대 방향에서 세팅된다.

더 구체적으로는, SENDER(41)는 ASP 헤더의 필드r_flowspec에 세팅된 상방향(SENDER(41)로부터 RECEIVER(47)로)에서의 VC들의 대역폭에 대응하는 값을 갖는 ASP 메시지를 RECEIVER(47)로 송신한다. 이것은 ASP 메시지가 흐르는 방향과 반대 방향에서의 에지 루터(42), 백본 루터들(43, 44 및 45) 및 에지 루터(46)에서 순서대로 상방향 VC들을 확립한다.

한편으로는, RECEIVER(47)는 ASP 헤더의 필드s_flowspec에 세팅된 하방향(SENDER(41)로부터 RECEIVER(47)로)에서의 VC들의 대역폭에 대응하는 값을 갖는 ASP 메시지를 SENDER(41)로 송신한다. 이것은 ASP 메시지가 흐르는 방향과 반대 방향에서의 에지 루터(46), 백본 루터들(45, 44 및 43) 및 에지 루터(42)에서 순서대로 하방향 VC들을 확립한다.

도 16은 수신측이 쌍방향 통신을 위해 필요한 QoS를 안다면 VC들이 확립되는 절차를 도시한다. 이 경우에, 쌍방향 VC들은 하나의 예약 메시지에 의해 발생된다.

더 구체적으로는, RECEIVER(47)는 VC 확립이 쌍방향으로 수행되는 것을 표시하는 값, 예를 들어 1을 ASP 헤더의 필드 flag에 세팅한다, 이 때, RECEIVER(47)는 하방향 VC들의 대역폭애 대응하는 값을 ASP 헤더의 필드 s_flowspec 및 상방향 VC들의 대역폭애 대응하는 값을 필드 r_flowspec에 세팅하고, 이 ASP 헤더를 포함하는 ASP 메시지를 SENDER(41)로 송신한다. 그 결과, 필드 r_flowspec에 세팅된 대역폭을 갖는 상방향 VC들 및 필드 s_flowspec에 세팅된 대역폭을 갖는 하방향 VC들이 에지 루터(46)에서 확립된다. 다음으로, 백본 루터들(45, 44 및 43) 및 에지 루터(42)에서 순서대로 필드 r_flowspec에 세팅된 대역폭을 갖는 상방향 VC들 및 필드 s_flowspec에 세팅된 대역폭을 갖는 하방향 VC들이 확립된다.

이와 같이, VC 확립은 다양한 방식으로 수행될 수 있다. 또한, 상층이 이들 방식들 중 어느 하나를 선택하여, 애플리케이션들에 적절한 유효 셋업 시스템을 제공할 수 있도록 구성이 형성될 수 있다.

지금까지, ATM 및 IP가 ATM 시그널링을 이용하지 않고 demand 상에 VC들을 셋업하기 위해 통합되는 것에 대하여 기술하였다. 다음으로, VC(자원)와 플로우 사이의 관계가 ASP 기능들의 사용에 의해 동적으로 변경되는 시스템을 설명한다. 현재, VC용 데이터는 에지 루터로부터 수신측으로 잠기(sink)는데, 즉 데이터는 컷 스루(cut through)된다. 그러므로, 데이터는 복수의 백본 루터들의 스위치들을 경유하여 가며, 수신측의 에지 루터에 이르기까지 ATM VC들을 직접 경유하여 간다.

에지 루터에서의 데이터의 잠김(sinking)에 주목하면, 피드백이 이 점에 공급되어 이미 발생된 VC들에 VC들을 이용하는 기존의 통신을 통신에 영향을 끼지지 않고 이행하도록 ASP 메시지가 발신될 수 있다. 즉, 통신중에, 예를 들어 도중 경로를 동적으로 변경하기 위해, VC들이 입구에서 백본으로 변경될 수 있다.

다음으로, 상술한 시스템을 ASP에 결합함으로써 얻어지는 이점에 대해 설명한다. 이 시스템은 ASP에 한정되지는 않지만, 예를 들어 RSVP와의 연동에 유효하게 이용할 수 있다.

예를 들어, ATM 시그널링의 경우에, VC 셋업의 완료 후, 그 경로를 변경하는 것은 곤란하다. 이것은 VC들이 엔드투엔드(end-to-end)를 다시 세팅하여야 하기 때문이다. 반면에, RSVP는 강하며, 환경에 적응함에 이점이 있는 것으로 간주된다. 그러나, RSVP가 현재의 IP 루팅을 따른다면, 루트 변경이 발생하기 때문에, RSVP는 실시간 통신에 적절하지 않을 수도 있다. 이러한 문제점을 해결하기 위하여, RSVP는 루트 피닝(route pinning)을 도입하여, 명료하게 예약된 경로를 위해 루팅에 의한 변경을 할 수 없게 한다.

본 명세서에서 제시된 방법의 이용은 통신 중에 경로를 용이하게 변경할 수 있다. 또한, 예를 들어 QoS 루팅이 도입될 수 있어서, 허가되지 않았던 경로 변경을 용이하게 한다.

또한, 통신 동안에 예약된 플로우들은 통신 동안에 선정된 VC에 통합될 수 있다. VCI 등의 자원들이 절약될 수 있다. 또한, 조직, 애플리케이션 등의 예약들이 통합될 수 있다.

소정의 데스티네이션에 대한 복수의 통신 경로들이 있고,예를 들어 신규 세션의 통신이 임의의 정도의 자원 용량을 요구한다면, 다른 세션들의 경로들/자원들이 수집될 수 있다.

통신에서 세션의 자원 예약 상태는 동적으로 변경될 수 있다.

본 명세서에서는 특히 에지 루터에 주목하고 있지만, 본 시스템은 백본 루터에서도 실시 가능하다. 실장에 대해서는, 주목하는 플로우를 리매핑하기 위한 VC들이 준비되었을 때, 이 변화가 고속으로 에지 루터에 의해 수행된다. 동등한 동작이 백본 루터에 의해서도 수행될 수 있다. 그러나, 이 동작에 필요한 정보를 수집하는 것이 더 곤란하며, 이와 같은 시스템을 제공함으로써 백본 루터 그 자체의 기능들을 복잡하게 하는 것은 바람직하지 않다.

에지 루터에 대해서는, 말단측에 집약된 터미널들 및 홈 루터들의 개수를 어느 정도 파악하여 적절한 루팅이 따라서 수행될 수 있도록 하는 것은 실행 가능하다. 즉, 백본 루터와 에지 루터들을 비교하여, 정보 수집이 한정되어 간단히 된다.

이와 같은 방법에서, 에지 루터 동작이 흐르는 데이터에 영향을 끼칠 수 있다는 점이 주목되어야 한다. 우선, 송신측 VC들의 전환은 데이터 내의 손실이 송신되도록 한다. 또한, 수신측 상의 에지 루터에서, 데이터는 두개의 VC들로부터 일시적으로 송신되어, 수신측은 중복하여 데이터를 수신할 수 있다. 이와 같은 상황에서 데이터의 정확성을 보증하기 위하여, 고도로 신뢰성 있는 트랜스포트 프로토콜의 이용이 희망된다.

상술한 양호 실시예에서는 VC 예약의 일예가 설명되었는데, 본 발명이 UPC(Usage Parameter Control) 등과 같은 다른 자원들의 예약에도 적용 가능하다는 것이 주목되어야 한다.

상술한 바와 같이, 네트워크 자원 예약 제어 방법 및 네트워크 자원 예약 제어 장치에 따르면, 메시지는 송신 터미널부터 수신 터미널로의 제1 방향, 수신 터미널부터 송신 터미널로의 제2 방향을 포함하는 방향들 중 어느 하나의 방향으로 자원 예약이 수행되는 단방향 통신과 상기 제1 방향 및 상기 제2 방향이 결합된 쌍방향 통신 중에서 어느 하나를 상기 자원 예약이 수행되는 방향으로서 지정하기 위한 제1 정보와 상기 제1 방향 및 상기 제2 방향에서의 자원들을 독립적으로 요구하기 위한 제2 정보로 구성되어 송신된다. 제2 정보에 의해 요구된 자원은 송신된 메시지의 제1 정보에 의해 지정된 방향으로 예약된다. 이와 같은 본 명세서의 신규한 구성은 메시지가 송신되는 방향과 독립적인 유효한 자원 예약을 가능하게 한다.

수신 터미널에 따르면, 수신 터미널은 송신 터미널로 메시지를 송신하며, 이 메시지는 송신 터미널부터 수신 터미널로의 제1 방향, 수신 터미널부터 송신 터미널로의 제2 방향을 포함하는 방향들 중 어느 하나의 방향으로 상기 자원 예약이 수행되는 단방향 통신과 상기 제1 방향 및 상기 제2 방향이 결합된 쌍방향 통신 중에서 어느 하나를 상기 자원 예약이 수행되는 방향으로서 지정하기 위한 제1 정보와 상기 제1 방향 및 상기 제2 방향에서의 자원들을 독립적으로 요구하기 위한 제2 정보로 구성된다. 이와 같은 본 명세서의 신규한 구성은 또한 메시지가 송신되는 방향과 독립적인 유효한 자원 예약을 가능하게 한다.

송신 터미널에 따르면, 송신 터미널은 수신 터미널로 메시지를 송신하며, 이 메시지는 송신 터미널부터 수신 터미널로의 제1 방향, 수신 터미널부터 송신 터미널로의 제2 방향을 포함하는 방향들 중 어느 하나의 방향으로 상기 자원 예약이 수행되는 단방향 통신과 상기 제1 방향 및 상기 제2 방향이 결합된 쌍방향 통신 중에서 어느 하나를 상기 자원 예약이 수행되는 방향으로서 지정하기 위한 제1 정보와 상기 제1 방향 및 상기 제2 방향에서의 자원들을 독립적으로 요구하기 위한 제2 정보로 구성된다. 이와 같은 본 명세서의 신규한 구성은 또한 메시지가 송신되는 방향과 독립적인 유효한 자원 예약을 가능하게 한다.

중계 장치에 따르면, 중계 장치는 송신 터미널부터 수신 터미널로의 제1 방향, 수신 터미널부터 송신 터미널로의 제2 방향을 포함하는 방향들 중 어느 하나의 방향으로 상기 자원 예약이 수행되는 단방향 통신과 상기 제1 방향 및 상기 제2 방향이 결합된 쌍방향 통신 중에서 어느 하나를 상기 자원 예약이 수행되는 방향으로서 지정하기 위한 제1 정보와 상기 제1 방향 및 상기 제2 방향에서의 자원들을 독립적으로 요구하기 위한 제2 정보로 구성되는 메시지를 중계한다. 자원 예약 시스템은 중계 수단에 의해 중계된 메시지의 제1 정보에 의해 지정된 방향으로 제2 정보에 의해 요구된 자원을 예약한다. 이와 같은 본 명세서의 신규한 구성은 또한 메시지가 송신되는 방향과 독립적인 유효한 자원 예약을 가능하게 한다.

본 발명과 분명하게 다른 수 많은 실시예들이 본 발명의 사상과 범위로부터 벗어남이 없이 실시될 수 있으며, 본 발명은 첨부된 청구항들에 의해 한정되는 것 이외에는 특정 실시예들에 의해 제한되지 않는다는 것을 이해하여야 한다.

Claims (11)

1. 네트워크를 통하여 데이터를 송신하는 송신 터미널과 상기 데이터를 수신하는 수신 터미널 사이의 자원 예약을 제어하는 네트워크 자원 예약 제어 방법에 있어서:

   상기 송신 터미널부터 상기 수신 터미널로의 제1 방향, 상기 수신 터미널부터 상기 송신 터미널로의 제2 방향을 포함하는 방향들 중 어느 하나의 방향으로 상기 자원 예약이 수행되는 단방향 통신과 상기 제1 방향 및 상기 제2 방향이 결합된 쌍방향 통신 중에서 어느 하나를 상기 자원 예약이 수행되는 방향으로서 지정하기 위한 제1 정보와 상기 제1 방향 및 상기 제2 방향에서의 자원들을 독립적으로 요구하기 위한 제2 정보로 구성되는 메시지를 송신하는 단계; 및

   상기 송신 단계에서 송신된 상기 메시지의 상기 제1 정보에 의해 지정된 방향으로 상기 제2 정보에 의해 요구된 자원을 예약하는 단계

   를 포함하는 네트워크 자원 예약 제어 방법.
2. 제1항에 있어서, 상기 메시지는 상기 수신 터미널로부터 상기 송신 터미널로의 방향 및 상기 송신 터미널로부터 상기 수신 터미널로의 방향 중 어느 한 방향으로 송신되는 네트워크 자원 예약 제어 방법.
3. 제1항에 있어서, 상기 자원 예약이 수행되는 방향은 상기 메시지가 송신되는 방향과 독립적으로 지정되는 네트워크 자원 예약 제어 방법.
4. 제1항에 있어서, 상기 메시지는 상기 송신 터미널로부터 상기 수신 터미널로 송신되어 상기 메시지에 의해 요구된 자원이 예약되는 네트워크 자원 예약 제어 방법.
5. 제1항에 있어서, 상기 메시지는 상기 수신 터미널로부터 상기 송신 터미널로 송신되어 상기 메시지에 의해 요구된 자원이 예약되는 네트워크 자원 예약 제어 방법.
6. 제1항에 있어서, 상기 네트워크는 ATM(Asynchronous Transfer Mode) 네트워크인 네트워크 자원 예약 제어 방법.
7. 네트워크를 통하여 데이터를 송신하는 송신 터미널과 상기 데이터를 수신하는 수신 터미널 사이의 자원 예약을 제어하는 네트워크 자원 예약 제어 장치에 있어서:

   상기 송신 터미널부터 상기 수신 터미널로의 제1 방향, 상기 수신 터미널부터 상기 송신 터미널로의 제2 방향을 포함하는 방향들 중 어느 하나의 방향으로 상기 자원 예약이 수행되는 단방향 통신과 상기 제1 방향 및 상기 제2 방향이 결합된 쌍방향 통신 중에서 어느 하나를 상기 자원 예약이 수행되는 방향으로서 지정하기 위한 제1 정보와 상기 제1 방향 및 상기 제2 방향에서의 자원들을 독립적으로 요구하기 위한 제2 정보로 구성되는 메시지를 송신하기 위한 송신 수단; 및

   상기 송신 수단에 의해 송신된 상기 메시지의 상기 제1 정보에 의해 지정된 방향으로 상기 제2 정보에 의해 요구된 자원을 예약하기 위한 자원 예약 수단

   를 포함하는 네트워크 자원 예약 제어 장치.
8. 제7항에 있어서, 상기 네트워크는 ATM(Asynchronous Transfer Mode) 네트워크인 네트워크 자원 예약 제어 장치.
9. 네트워크를 통하여 송신 터미널로부터 데이터를 수신하는 수신 터미널에 있어서,

   상기 수신 터미널은 상기 송신 터미널로 메시지를 송신하기 위한 송신 수단을 구비하고, 상기 메시지는 상기 송신 터미널부터 상기 수신 터미널로의 제1 방향, 상기 수신 터미널부터 상기 송신 터미널로의 제2 방향을 포함하는 방향들 중 어느 하나의 방향으로 상기 자원 예약이 수행되는 단방향 통신과 상기 제1 방향 및 상기 제2 방향이 결합된 쌍방향 통신 중에서 어느 하나를 상기 자원 예약이 수행되는 방향으로서 지정하기 위한 제1 정보와 상기 제1 방향 및 상기 제2 방향에서의 자원들을 독립적으로 요구하기 위한 제2 정보로 구성되는

   수신 터미널.
10. 네트워크를 통하여 수신 터미널로 데이터를 송신하는 송신 터미널에 있어서,

    상기 송신 터미널은 상기 수신 터미널로 메시지를 송신하기 위한 송신 수단을 구비하고, 상기 메시지는 상기 송신 터미널부터 상기 수신 터미널로의 제1 방향, 상기 수신 터미널부터 상기 송신 터미널로의 제2 방향을 포함하는 방향들 중 어느 하나의 방향으로 상기 자원 예약이 수행되는 단방향 통신과 상기 제1 방향 및 상기 제2 방향이 결합된 쌍방향 통신 중에서 어느 하나를 상기 자원 예약이 수행되는 방향으로서 지정하기 위한 제1 정보와 상기 제1 방향 및 상기 제2 방향에서의 자원들을 독립적으로 요구하기 위한 제2 정보로 구성되는

    송신 터미널.
11. 네트워크를 통하여 데이터를 송신하는 송신 터미널과 상기 데이터를 수신하는 수신 터미널 사이의 자원 예약을 수행하여 상기 데이터를 중계하는 중계(relay) 장치에 있어서:

    상기 송신 터미널부터 상기 수신 터미널로의 제1 방향, 상기 수신 터미널부터 상기 송신 터미널로의 제2 방향을 포함하는 방향들 중 어느 하나의 방향으로 상기 자원 예약이 수행되는 단방향 통신과 상기 제1 방향 및 상기 제2 방향이 결합된 쌍방향 통신 중에서 어느 하나를 상기 자원 예약이 수행되는 방향으로서 지정하기 위한 제1 정보와 상기 제1 방향 및 상기 제2 방향에서의 자원들을 독립적으로 요구하기 위한 제2 정보로 구성되는 메시지를 중계하기 위한 중계 수단; 및

    상기 중계 수단에 의해 중계된 상기 메시지의 상기 제1 정보에 의해 지정된 방향으로 상기 제2 정보에 의해 요구된 자원을 예약하기 위한 자원 예약 수단

    을 포함하는 중계 장치.