KR20050026881A - 페일오버 이벤트를 지원하는 네트워크 상태 객체의 다중오프로드용 방법 및 컴퓨터 프로그램 제품 - Google Patents

페일오버 이벤트를 지원하는 네트워크 상태 객체의 다중오프로드용 방법 및 컴퓨터 프로그램 제품 Download PDF

Info

Publication number
KR20050026881A
KR20050026881A KR1020040072017A KR20040072017A KR20050026881A KR 20050026881 A KR20050026881 A KR 20050026881A KR 1020040072017 A KR1020040072017 A KR 1020040072017A KR 20040072017 A KR20040072017 A KR 20040072017A KR 20050026881 A KR20050026881 A KR 20050026881A
Authority
KR
South Korea
Prior art keywords
state
network
state objects
links
offload
Prior art date
Application number
KR1020040072017A
Other languages
English (en)
Other versions
KR101067394B1 (ko
Inventor
핑커튼제임스티.
캐니야산제이엔.
Original Assignee
마이크로소프트 코포레이션
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US10/666,086 external-priority patent/US7526577B2/en
Application filed by 마이크로소프트 코포레이션 filed Critical 마이크로소프트 코포레이션
Publication of KR20050026881A publication Critical patent/KR20050026881A/ko
Application granted granted Critical
Publication of KR101067394B1 publication Critical patent/KR101067394B1/ko

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4641Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/10Streamlined, light-weight or high-speed protocols, e.g. express transfer protocol [XTP] or byte stream
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/326Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]

Abstract

본 발명은 컴퓨터화된 시스템의 2개의 컴포넌트 장치 간에, 이를테면 호스트 CPU와 NIC 간에, 다수의 네트워크 접속의 프로세서 제어를 전송하기 위한 메커니즘을 제공한다. 본 발명의 일 양태에서, 2 이상의 네트워크 통신이 각각 네트워크 프로토콜 스택의 상위 계층들에서 상이한 상태 객체를 갖고, 상기 네트워크 프로토콜 스택의 하위 계층들(예를 들면, 프레이밍 계층)에서 공통의 상태 객체를 갖는다. 일부분은 하위 소프트웨어 계층 상태들에서의 공통성으로 인해, 본 발명은 장기 및 단기의 접속들을 포함하여 동시에 다수의 네트워크 통신의 프로세서 제어를 오프로드하는 것을 가능케 한다. 게다가, 본 발명은 페일오버 이벤트(failover event)가 발생한 경우에 대체 주변 장치와 교섭하여 네트워크 통신을 그 대체 주변 장치에 오프로드할 수 있고, 하나 이상의 VLAN들에 대해 예정된 착신 데이터에 대한 솔루션을 제공한다.

Description

페일오버 이벤트를 지원하는 네트워크 상태 객체의 다중 오프로드용 방법 및 컴퓨터 프로그램 제품{METHOD AND COMPUTER PROGRAM PRODUCT FOR MULTIPLE OFFLOAD OF NETWORK STATE OBJECTS WITH SUPPORT FOR FAILOVER EVENTS}
본 발명은 컴퓨터 네트워킹 기술에 관한 것으로서, 보다 상세하게는 네트워크 컴퓨팅 작업의 오프로드를 최적화하기 위한 메커니즘에 관한 것이다.
운영 체제, 애플리케이션 소프트웨어, 네트워킹 기술 등의 복잡함과 정교함이 계속해서 크게 증가하여 컴퓨터 기능이 향상되고 있다. 이러한 향상된 기능은 종종 중앙 처리 장치(CPU)가 이 향상된 기능을 구현하기 위하여 수행해야 하는 추가적인 임무로 인해 CPU의 로드(이하, "CPU 오버헤드"로도 지칭됨)를 증가시키게 된다.
CPU 오버헤드의 증가가 명백한 한 영역은 고 대역폭 매체의 성장으로 인하여 네트워크 속도가 증가하고 있는 네트워크 애플리케이션의 영역에 있다. 네트워크 속도는 호스트 컴퓨터에서의 CPU 프로세서 속도와 로컬 메모리에 대한 액세스 속도에 필적할 수도 있다. 이러한 네트워크 애플리케이션은 7 계층 개방형 시스템간 상호접속(seven-layer Open System Interconnect(OSI)) 모델 또는 윈도우 운영 체제에 의해 사용되는 계층화된 모델과 같이 대부분의 운영 체제에 의해 사용되는 계층화된 아키텍처로 인하여 호스트 프로세서에 더 부담을 준다.
잘 알려진 바와 같이, 이러한 모델은 네트워크에 대한 물리적 접속과 최종 사용자 애플리케이션 간의 데이터의 흐름을 기술하는 데에 사용된다. 데이터 비트를 네트워크 케이블에 넣는 것과 같은 가장 기본적인 기능은 하위 계층들에서 수행되며, 반면에 애플리케이션의 디테일(details)에 주의하는 기능은 상위 계층들에서 수행된다. 본질적으로, 각 계층의 목적은 다음 상위 계층에 서비스를 제공하여, 서비스가 실제로 어떻게 구현되는지에 대한 디테일로부터 상위 계층을 보호하는 것이다. 계층들은 각 계층이 다른 컴퓨터 상의 동일 계층과 통신하고 있다고 믿는 방식으로 추상화된다.
계층들 사이에서 처리될 때 데이터 패킷 상에 수행되는 다양한 기능은 소프트웨어 집약적(software intensive)이 될 수 있고, 따라서 종종 상당한 양의 CPU 프로세서 및 메모리 자원을 필요로 한다. 예를 들어, 다양한 계층에서 패킷 상에 수행되는 소정의 기능들은 패킷 체크섬 계산 및 검증(packet checksum calculation and verification), 데이터의 암호화 및 해독(예를 들어 SSL 암호화 및 IP 보안 암호화), 메시지 다이제스트 계산(massage digest calculation), TCP 세그먼트화(segmentation), TCP 재전송 및 수신확인(ACK) 처리, 서비스 공격의 거부로부터 보호하기 위한 패킷 필터링, 및 유저 데이터그램 프로토콜(User Datagram Protocol; UDP) 패킷 단편화(packet fragmentation)와 같이 극히 CPU 집약적이다. 이러한 기능들 각각이 수행될 때 유발되는 CPU에 대한 요구는 전체 컴퓨터 시스템의 처리량과 성능에 크게 영향을 미친다.
CPU 자원에 대한 요구가 증가함에 따라, 네트워크 인터페이스 카드(NIC) 등과 같은 컴퓨터 하드웨어 주변 장치의 성능 및 처리량도 향상되고 있다. 이들 주변 장치는 종종 이들이 행하지 않으면 CPU가 수행해야 할 많은 작업 및 기능을 수행할 수 있는 전용 프로세서 및 메모리를 갖추고 있다.
컴퓨터 산업은 이러한 성능을 인식하고, 이전에 CPU에 의해 수행되었던 CPU 집약적 작업 및 기능을 오프로드하기 위한 방법을 개발하였다. 예를 들어, 본 출원인에게 공히 양도된 Anand 등의 미국 특허 제6,141,705호, 미국 특허 제6,370,599호 및 2000년 11월 29일자로 출원된 "Method and Computer Program Product for Offloading Processing Tasks from Software to Hardware"라는 제목의 미국 특허 출원 09/726,082는 주변 장치들에 질의하여 집약적 작업 및 기능을 수행할 수 있는 주변 장치들로 특정 프로세서 작업을 오프로드하기 위한 솔루션을 제공한다. 일반적으로 오프로드되는 특정 작업은 전송 제어 프로토콜(TCP) 및/또는 인터넷 프로토콜(IP) 체크섬 계산, 대량 전송 오프로드(Large Send Offload; LSO)와 같은 TCP 세그먼트와, 및 보안 인터넷 프로토콜(IPSEC) 암호화 및 해독과 같은 작업을 포함한다.
이러한 오프로드 메커니즘은 네트워크 스택에 대해 최소 수의 변화가 이루어져야 한다는 부수 요건을 갖는다는 점에서 제한된다. 이러한 부수 요건의 결과로서, 오프로드는 긴 코드 경로를 갖게 되는 또 하나의 제한이 있게 되는데, 이는 주변 장치에 도달하기 위하여 디스에이블된 오프로드 작업 및 기능이 전체 네트워크 스택을 트래버스(traverse)하기 때문이다. 네트워크 스택과의 통합의 결여라는 추가적인 제한이 있다. 주변 장치에 질의하거나 파라미터를 설정하기 위한 네트워크 스택에 대한 잘 정의된 인터페이스, 또는 네트워크 스택에 임의의 성능 통지 또는 변경을 알리기 위한 주변 장치에 대한 인터페이스가 존재하지 않는다. 예를 들어, LSO 요구가 처리되고 있을 때 라우트가 변경되는 경우, 폴백 메커니즘(fallback mechanism)이 스택으로 하여금 타임아웃을 기다려 LSO 요구를 재전송하도록 한다.
주변 장치 제조자가 취하려고 하였던 또 하나의 접근법은 코어 스택에서 네트워크 인터페이스 카드(NIC)로 전체 TCP 접속을 오프로드하는 것이었다. 이 접근법은 독점 인터페이스를 사용하여 전체 프로토콜 스택을 바이패스하며, 주변 장치가 TCP 메시지, IP 메시지, 인터넷 제어 메시지 프로토콜(ICMP) 메시지, 도메인 네임 서버(DNS) 메시지, 다이나믹 호스트 구성 프로토콜(DHCP) 메시지, 라우팅 정보 프로토콜(RIP) 메시지 등을 처리할 것을 요구한다. 또한, 이 접근법은 멀티 홈 환경을 어드레스하지 않으며, 호스트 운영 체제 네트워크 관리 유틸리티와 깔끔하게 통합되지 못한다. 주변 장치의 상태가 바뀌는 경우, 오프로드된 접속은 쉽게 실패할 수 있다. 이러한 오프로드 접속 실패의 잠재성은 현재 기술의 다른 단점 중 하나이다.
일반적으로 단일 "접속"은 본 명세서에서 "상태 객체"로서 지칭되는 네트워크 계층들 각각에 대한 상태로 구성된다. 그러나, 네트워크 프로토콜 연산의 오프로딩은 접속 지향 프로토콜에 제한되지 않는다. IPSEC와 같은 다른 프로토콜은 접속 지향이 아닐 수 있지만, 오프로드될 수 있는 상태 객체들 또는 상태 객체들의 그룹들을 포함한다. 원격 DMA(RDMA)는 접속 오프로드에 필요한 상태 객체들에 추가적인 상태 객체들을 추가할 수 있다. 본 발명은 위의 모두에 적용되며, 따라서 "상태 객체"는 상태를 포함하고, 접속 지향이거나 아닐 수 있으며, TCP/IP 네트워킹에 꼭 필요한 것보다 더 많은 상태를 포함하거나 포함하지 않을 수 있는 하나 이상의 네트워크 계층을 지칭한다.
설명을 위해, "네트워크 접속"(종종 "접속"으로 지칭됨)은 TCP 접속, 스트림 제어 전송 프로토콜(SCTP) 접속(또는 스트림), 및 접속 지향 통신을 구현하기 위해 사용될 때의 접속 지향 유저 데이터그램 프로토콜(UDP)과 같은 프로토콜을 이용한 접속인 것으로 이해되지만 이에 제한되지는 않는다. 또한, "네트워크 접속"(또는 "접속")은 일반적으로 7 계층 OSI 네트워크 프로토콜 스택 모델의 전송 계층(즉 계층 4)에서 구현되지만, 접속을 구현하는 애플리케이션 계층 프로토콜, 또는 접속을 구현하는 데이터 링크 계층 프로토콜을 포함하는 다른 계층들에서도 발생할 수 있다.
계속해서, 오프로드 메커니즘의 개발은 특히 처리를 위해 비교적 많은 수의 CPU 싸이클을 필요로 하는 접속의 경우에 한번에 하나의 접속만의 반복적 전송 또는 한번에 하나의 상태 객체들의 논리적 그룹화에 집중되어 왔다. 예를 들어, 단일 오프로드 접속 또는 상태 객체를 처리하는 데에 필요한 총 CPU 싸이클 수는 다음 식으로 표현될 수 있다:
A+[B-C]
여기서, A는 접속 또는 링크를 오프로드하는 데에 필요한 CPU 싸이클의 수이고, B는 접속 또는 링크를 처리하는 데에 필요한 CPU 싸이클의 수이며, C는 접속 또는 링크를 오프로딩함으로써 절약되는 CPU 싸이클의 수이다. 제1 항(즉, "A")이 제2 항(즉, "B-C")보다 상당히 큰 경우, 주어진 접속 또는 링크를 오프로드하는 것은 CPU 오버헤드 측면에서 일반적으로 비용 효과적이지 못하다. 반대로, 제2 항("B-C")이 제1 항(즉, "A")보다 상당히 큰 경우에는, 접속 또는 상태 객체를 오프로딩함으로써 이익을 실현할 수 있게 된다. 따라서, 오프로드 메커니즘은 주로 "B-C" 항이 비교적 큰 경우에 접속 또는 상태 객체를 오프로딩하는 것에 맞추어져 왔다. 이것은 주로 "장기(long-lived)" 접속 또는 큰 파일을 전송하는 데에 사용되는 접속의 경우이다.
장기 접속, 및 대량의 데이터를 전송하기 위한 접속 또는 상태 객체는 호스트 컴퓨터의 가치있는 CPU 자원들의 소모를 요구할 수 있는 유일한 유형의 접속 또는 상태 객체가 아니다. 예를 들어, 인터넷과 같은 광역 네트워크(WAN) 상의 호스트의 경우에는, 웹 페이지들을 호스팅하는 서버가 수천의 단순 웹 페이지 요구와 같은 수십만의 "단기(short-lived)" 접속의 처리와 함께 동일하게 소모될 수 있다.
일반적으로, "단기 접속"은 그 명칭이 내포하고 있듯이 종종 광역 네트워크를 통해 원격 컴퓨터와 서버(또는 호스트) 간의 하나 이상의 짧은 데이터 전송 요구 및 응답이 있을 수 있는 하이퍼텍스트 전송 프로토콜(HTTP) 접속과 같이 수명이 짧은 접속이다. HTTP 버전 1.0은 이 경우를 설명하고 있다. HTTP 1.O을 이용하여 보통의 텍스트 웹 페이지를 요구하기 위하여, 클라이언트는 웹 페이지를 호스팅하는 서버(또는 호스트)와의 양방향 접속을 개시한다. 서버에 대한 클라이언트의 요구는 일반적으로 "get file, file name"(예를 들어, "GET http://10.1.1.1/file_n ame.html")과 같은 짧은 아스키(ASCII) 스트링 시퀀스인 하나의 메시지이며, 이 요구는 종종 총 100 바이트 이하 크기의 데이터를 포함한다. 클라이언트의 요구를 받아들인 후, 클라이언트는 양방향 접속의 제1 방향(클라이언트에서 서버로의 방향)을 닫으며, 서버는 양방향 접속의 제2 방향(서버에서 클라이언트로의 방향)을 통해 텍스트 웹 페이지를 전송함으로써 응답한 다음, 양방향 접속의 제2 방향을 닫는다. 단일 요구를 처리하기보다는 접속을 닫기 전에 적은 수의 요구를 조합하는 몇몇을 포함하여, 이러한 유형의 작업 로드를 갖는 많은 상이한 프로토콜이 있다. 이러한 각각의 프로토콜은 단기 접속으로 지칭한다.
HTTP 웹 페이지 요구는 종종 100 내지 1000 바이트 범위의 크기를 갖는다. HTTP 응답도 마찬가지로 예를 들어 요구된 웹 페이지가 텍스트 기반이고 멀티미디어 정보를 거의 포함하지 않는 경우 아주 작을 수 있다. 따라서, 특히 고속 네트워크의 광범위한 이용가능성을 고려할 때 요구도 응답도 많은 양의 데이터를 갖지 않는다. 더욱이, 점차 빨라지는 프로세서로 인하여 현재의 표준 하에서는 요구도 응답도 많은 양의 CPU 시간을 요구하지 않는다. 따라서, HTTP 요구 및 응답을 처리하는 데에 필요한 접속 시간은 아주 짧을 수 있다. 이 경우, 단일 단기 접속을 오프로드하는 데에 필요한 CPU 싸이클의 수는 CPU로 하여금 단기 접속을 처리하지 않도록 함으로써 유지되는 CPU 싸이클의 수보다 확실히 커질 수 있다. 결과적으로, 한번에 하나의 단기 접속을 반복적으로 오프로드하는 것은 CPU 싸이클의 측면에서 비교적 비싸다.
네트워크 연산을 오프로딩하는 것과 관련된 또 하나의 제한은 하나 이상의 물리적 주변 장치의 상부에 하나 이상의 가상 주변 장치의 생성을 제공하는 사양들과 함께 작업하는 것을 필요로 한다. 이것은 단일 링크를 하나 이상의 가상 링크로 세분하는 것은 물론이고 네트워크 트래픽의 로드 밸런싱 및 네트워크 트래픽의 페일오버를 지원하기 위한 다수 네트워크 링크의 집합을 포함하여 여러가지 이유로 유용한데, 하나 이상의 가상 링크는 일반적으로 가상 LAN(VLAN)이라 지칭되며, 이는 네트워크 관리가 하나의 물리적 네트워크를 다수의 논리적으로 상이한 네트워크로 볼 수 있도록 한다.
링크 집합을 제공하는 기술들의 예에는 IEEE 802.3ad(본 명세서에서 "802.3ad 표준"으로도 지칭됨) 및 다른 벤더 독점 표준들(vendor proprietary standards)이 포함된다. 구체적으로, 802.3ad 표준(아울러 벤더 독점 표준들)은 어떻게 2개 이상의 이더넷 링크들이 다수의 이더넷 링크를 통해 네트워크 트래픽의 로드 밸런싱 또는 네트워크 트래픽의 페일오버를 지원하도록 조합될 수 있는지를 정의하고 있다. 이러한 성능은 a) 호스트의 네트워크 링크 실패에 대한 장애 허용 능력(fault tolerance)을 향상시키기 위하여, 그리고/또는 b) 네트워킹 트래픽이 다수의 이더넷 링크를 통해 로드 밸런싱될 수 있도록 함으로써 서버의 네트워킹 용량을 증가시키기 위하여 사용될 수 있다. 이러한 목적을 달성하기 위하여, 802.3ad 표준은 하나의 가상 주변 장치로 "팀"이 될 수 있는 한 "팀"의 주변 장치를 제공한다. 가상 주변 장치는 (페일오버를 위해) 팀 내의 주변 장치들 중에서 현재 사용할 수 있는 주변 장치를 변경함으로써, 그리고/또는 (로드 밸런싱을 위해) 다수의 물리적 장치 전체에 네트워크 트래픽을 전송함으로써 팀 내의 물리적 주변 장치들을 관리한다. 예를 들어, "팀"이 페일오버를 위해 구성되고, 가상 주변 장치가 물리적 주변 장치가 실패한 것을 검출한 경우, 가상 주변 장치는 실패한 주변 장치를 더 이상 사용하지 않고, 그 대신 주변 장치들의 팀 내의 다른 주변 장치를 이용하여 네트워킹 트래픽을 송수신한다.
가상 LAN 사양들(Virtual LAN specifications)의 예에는 VLAN 태그들에 대한 IEEE 803.1q 사양이 포함된다. 이 사양은 매체 액세스 제어(MAC) 어드레스에 부가되는 태그를 정의하며, 태그 값을 변경함으로써 이더넷 네트워크가 개별 네트워크들로 논리적으로 세분될 수 있게 한다. 이것은 시스템 관리자가 상이한 관리 도메인들에 대해 트래픽을 논리적으로 분리하고(예를 들어 엔지니어링 개발을 위한 네트워크와 페이롤을 위한 네트워크를 분리하고), 양자에 대하여 동일한 물리적 네트워크를 사용할 수 있게 한다. 또한, 블록 저장 네트워크 트래픽을 전통적인 피어 투 피어 트래픽으로부터 논리적으로 격리시키는 것과 같은 보안 관계에 대한 격리를 허용한다.
네트워크 오프로드에 있어서 현재의 기술을 이용하고 이를 가상 주변 장치들을 생성하기 위한 능력과 결합하려고 할 때 여러 한계가 있다. 가상 주변 장치가 로드 밸런싱 또는 장애 허용 능력을 위해 사용되고, 접속 또는 객체 상태가 가상 주변 장치를 통해 물리적 주변 장치로 오프로드되며, 물리적 주변 장치가 실패하는 경우, 일반적으로 오프로드된 접속 또는 상태 객체는 (다른 물리적 주변 장치로 페일오버되는 것을 말할 것도 없고) 복구될 수 없다. 또한, 현재의 기술은 종종 가상 주변 장치가 이종 물리적 장치들을 팀으로 구성할 수 있을 것을 요구한다. 물리적 주변 장치가 접속 또는 상태 객체의 오프로딩을 지원하는 경우, 이것은 팀 내의 물리적 장치들이 상이한 오프로드 성능을 갖는다는 것을 의미한다. 물리적 장치가 실패하고, 팀 내의 새로운 물리적 장치가 가상 장치에 의해 선택되는 경우, 이 새로운 물리 장치는 이전의 장치보다 더 크거나 작은 오프로드 용량 또는 상이한 오프로드 성능을 가질 수 있다. 네트워크 연산의 오프로딩을 위한 현재의 기술은 이러한 수준의 다기능을 가능하게 하지 못한다.
따라서, 본 기술 분야에서 프로세서에서 주변 장치로의 그리고 그 반대로의 다수의 접속의 오프로딩과 관련된 오버헤드를 감소시키는 것이 필요할 뿐아니라, 오프로드 환경에서 장애 허용 능력, 네트워크 용량 및 네트워크 관리를 향상시키기 위하여 하나 이상의 물리적 주변 장치의 상부에 하나 이상의 가상 주변 장치의 생성을 가능하게 하는 기존 사양들과 깔끔하게 통합될 수 있는 오프로드 성능을 확장하는 것이 필요하다. 구체적으로, 다수의 단기 접속을 오프로드하고 동시에 개별 접속들에 대한 특수 처리 요건을 유지하기 위한 솔루션이 필요하다. 또한, 802.3ad 환경에서(특히 주변 장치 페일오버 이벤트에 적용될 때) 집합된 접속을 오프로딩 또는 업로딩하기 위한 솔루션이 필요하고, 가상 LAN에 대한 지원을 가능하게 하는 것이 필요하다.
본 발명은 호스트 프로세서와 주변 장치 프로세서 사이에서 다수의 네트워크 접속 또는 상태 객체를 신뢰성 있게 오프로딩 또는 업로딩하는 방법을 제공함으로써 종래 기술이 가진 전술한 문제들 중 하나 이상을 극복한다. 본 발명은 또한 802.3ad(또는 등가의) 페일오버 이벤트를 제공하여, 다양한 접속들 사이에 객체 상태를 유지하면서, 오프로드된 접속들 또는 상태 객체들이 다른 주변 장치로 전송될 수 있게 하며, 다른 주변 장치들 간의 상이한 자원 성능을 보상한다. 본 발명의 방법은 장기 또는 단기 접속들(또는 양자 모두)을 전송하기 위한 CPU 싸이클의 측면에서 비용 효과적이다.
일 실시예에서, 본 발명은 동시에 다수의 접속의 오프로드를 가능하게 함으로써 전술한 식("A+[B-C]")에서 항 "A"를 줄여, 단기 접속들의 오프로드를 가능하게 하는데, 이전에는 일반적으로 장기 접속들만이 주변 장치로의 오프로딩이 실행가능한 것으로 보여졌었다.
네트워크 스택에서, 2개 이상의 TCP 접속이 하나 이상의 중간 소프트웨어 계층을 통해 동일 경로를 트래버스할 수 있다. 소프트웨어 계층 각각은 일정한(constant) 상태 변수, 캐시된(cached) 상태 변수 및 델리게이트된(delegated) 상태 변수 중 하나 이상을 포함할 수 있는 상태 객체를 갖는다. 임의의 소프트웨어 계층에 대해, 호스트는 처리 제어를 계층의 델리게이트된 상태 변수들에 대한 주변 장치로 오프로드하여 주변 장치가 독립적으로 데이터를 전송할 수 있게 한다. 캐시된 상태 변수들에 대해, 호스트는 캐시된 상태 변수들에 대한 제어를 유지하며, 캐시된 상태 변수가 변경되는 경우 주변 장치를 갱신한다. 일정 상태 변수들의 값은 오프로드 수명 동안 변경되지 않는다. 따라서, 호스트가 상태 객체를 주변 장치로 오프로드할 수 있지만, 이벤트들이 캐시된 또는 델리게이트된 상태 변수들을 변경시키는 경우에도 시스템의 상태는 안정되게 유지된다.
2개의 호스트 사이의 경로 데이터 전송은 경로 상태 객체로 표현된다. 2개의 접속이 동일 경로를 통해 데이터를 전송하는 경우, 이들은 동일한 경로 상태 객체를 공유한다. 따라서, 그 결과, 반전 트리 데이터 구조의 형태를 취하는 상태 객체들의 계층 구조가 생긴다. 호스트는 전체 반전 트리 데이터 구조를 주변 장치로 오프로드할 수 있는데, 이는 호스트가 처리 제어를 다수 접속들의 주변 장치로 한번에 오프로드할 수 있게 한다. 다수의 특정 네트워크 기능을 깔끔하게 오프로드할 수 있는 이러한 능력은 호스트가 원하는 네트워크 기능들, 무결성, 장애 허용 능력 및 보안성과 절충하지 않고도 CPU 싸이클을 유지할 수 있게 하며, 또한 단기 및 장기 접속들을 포함하는 다양한 환경에서 본 발명이 실시될 수 있게 한다.
본 발명은 또한 주변 장치(peripheral) 또는 경로 장애(path faults)의 보다 나은 장애 허용 능력(fault tolerence)을 가능하게 하기 위하여, 그리고 다수의 주변 장치를 통한 네트워킹 트래픽의 로드 밸런싱을 가능하게 하기 위하여, "팀(team)" 또는 추상적으로 "가상 주변 장치(virtual peripheral device)"로 지칭되는 주변 장치들의 그룹화와의 오프로드 기능의 통합(integration)을 포함한다. 본 발명은 페일오버 이벤트가 발생하고 있는 동안 가상 주변 장치가 오프로드 요구를 중지시키고, 모든 오프로드 상태 객체를 선택적으로 업로드하고, 상기 가상 주변 장치의 오프로드 성능을 재협상한 다음, 상태 객체의 오프로딩을 다시 가능하게 할 수 있는 메커니즘을 포함한다.
본 발명의 추가적인 특징 및 이점은 아래에 설명되며, 부분적으로는 그 설명으로부터 명백하게 되거나, 본 발명의 실시예를 통해 알게 될 것이다. 본 발명의 특징 및 이점은 첨부된 청구범위에 구체적으로 지시된 기구 및 조합에 의해 실현되고 얻어질 수 있다. 본 발명에 따른 이러한 특징 및 다른 특징은 아래의 설명과 첨부된 청구범위로부터 보다 완전하게 명백해지거나 이후 설명되는 본 발명의 실시예를 통해 습득될 수 있다.
본 발명의 전술한 이점과 특징 및 다른 이점과 특징이 얻어질 수 있는 방법을 설명하기 위하여 위에서 간단히 설명된 본 발명의 보다 구체적인 설명이 첨부된 도면에 도시된 특정 실시예들을 참조하여 이루어진다. 이들 도면은 단지 본 발명의 일반적인 실시예를 도시하며, 따라서 그 범위를 제한하는 것으로 간주되지 않아야 한다는 것을 이해하면서, 본 발명은 첨부된 도면들의 이용을 통해 구체적이고 상세하게 설명된다.
본 발명은 컴퓨터 네트워킹 기술에 관한 것이다. 보다 상세하게는 본 발명은 일반적으로 호스트 프로세서에 의해 수행되는 네트워크 컴퓨팅 작업의 특정 하드웨어 컴포넌트로의 오프로드를 최적화하고, 제어를 적절히 호스트로 반환하기 위한 메커니즘에 관한 것이다. 본 발명은 또한 가상 주변 장치의 사용을 통해, 오프로드된 네트워크 컴퓨팅 작업의 유연성을 향상시킨다. 이러한 유연성은 호스트 로드가 변경되거나 네트워크 장치 상태가 변경될 때, 오프로드된 네트워크 컴퓨팅 작업의 장애 허용 능력을 향상시키고, 가상 LAN에 대한 지원을 가능하게 할 수 있다.
따라서, 본 발명은 하나의 주변 장치에서 다른 주변 장치로, 또는 주변 장치에서 호스트 프로세서로 네트워크 접속을 전송하면서 다양한 네트워크 접속 사이의 상태 변화를 보상하고, 다른 주변 장치들 간의 상이한 자원 성능을 보상한다. 명세서 및 청구범위를 읽고 나면, "주변 장치"는 설명상으로 네트워크 어댑터를 구비한 범용 CPU, 전용 CPU를 구비한 네트워크 처리 엔진, 오프로드 NIC를 구비한 전통적인 미니포트(miniport), 또는 하드웨어 상태 머신 구현 등과 더불어 네트워크 인터페이스 카드와 같은 컴포넌트들을 포함할 수 있으나, 이에 제한되지 않는다는 것을 알 수 있을 것이다. 따라서, 아래의 설명은 컴포넌트들 간에 장기 또는 단기 접속(또는 양자 모두)을 전송하기 위한 CPU 싸이클의 측면에서 비용 효과적인 발명 방법을 설명한다.
보다 상세히 설명될 바와 같이, 호스트는 주변 장치가 어떠한 자원을 가질 수 있는지를 검출하고, 관련 데이터 구조를 적절히 조정하여 관련 접속의 요건과 오프로드 주변 장치 간에 일관성이 있도록 한다. 오프로드 데이터 구조를 조작하는 능력은 오프로드 또는 업로드 데이터 구조 내에 추가적인 데이터 구조를 적절히 삽입하는 것을 포함하여, 광범위한 네트워크 프로토콜을 이용하여 일관된 업로드 및 오프로드를 허용하는 특정 애플리케이션을 구비한다. 접속이 오프로드될 수 있더라도 호스트가 소정 데이터 구조에 대한 제어를 유지하고, 초기 주변 장치의 페일오버 이벤트에서 호스트가 새로운 주변 장치와 파라미터를 재협상할 수 있기 때문에, 본 발명은 주변 장치의 실패, 및 접속이 장기 접속인지 단기 접속인지에 관계없이 한번에 다수의 TCP 접속을 오프로드 및 업로드하는 새롭고 강인한 방법을 제공한다.
본 발명의 추가적인 특징 및 이점은 아래에 설명되며, 부분적으로는 그 설명으로부터 명백하거나, 본 발명의 실시예를 통해 알게 될 것이다. 본 발명의 특징 및 이점은 첨부된 청구범위에 구체적으로 지시된 기구 및 조합에 의해 실현되고 얻어질 수 있다. 본 발명에 따른 이러한 특징 및 다른 특징은 아래의 설명과 첨부된 청구범위로부터 보다 완전하게 명백해지거나 이후 설명되는 본 발명의 실시예를 통해 알 수 있다.
본 발명에 따른 범위 내의 실시예들은 또한 컴퓨터 실행가능 명령들 또는 데이터 구조를 보유하거나 저장하기 위한 컴퓨터 판독 가능 매체를 포함한다. 이러한 컴퓨터 판독 가능 매체는 범용 또는 특수용도 컴퓨터에 의해 액세스될 수 있는 임의의 이용 가능한 매체일 수 있다. 예를 들어, 이러한 컴퓨터 판독 가능 매체는 RAM, ROM, EEPROM, CD-ROM 또는 다른 광 디스크 저장장치, 마그네틱 디스크 저장장치 또는 다른 마그네틱 저장 장치, 또는 컴퓨터 실행 가능 명령들 또는 데이터 구조들의 형태로 원하는 프로그램 코드 수단을 보유하거나 저장하는 데에 사용될 수 있고 범용 또는 특수용 컴퓨터에 의해 액세스될 수 있는 임의의 다른 매체를 포함할 수 있지만, 이에 제한되는 것은 아니다.
정보가 네트워크 또는 다른 통신 접속(유선, 무선 또는 이들의 조합)을 통해 컴퓨터에 전송되거나 제공될 때, 컴퓨터는 적절하게 그 접속을 컴퓨터 판독 가능 매체로 본다. 따라서, 임의의 이러한 접속은 컴퓨터 판독 가능 매체로 적절히 지칭된다. 위의 조합도 컴퓨터 판독 가능 매체의 범위 내에 포함되어야 한다. 컴퓨터 실행 가능 명령들은 예컨대 범용 컴퓨터, 특수 컴퓨터 또는 특수 처리 장치가 소정의 기능, 또는 기능들의 그룹을 수행할 수 있도록 하는 명령들 및 데이터를 포함한다.
이제 도 1을 참조하면, 이 도면은 본 발명에 따른 네트워킹 모델을 구성하는 일부 컴포넌트들의 상관 관계를 나타내고 있다. 정상 동작 동안, 네트워크 메시지들은 애플리케이션(100)에 의해 네트워크 스택(102)을 통해 주변 장치(104)로 전송되고, 여기서 메시지들은 네트워크 상의 다른 장치들 및 애플리케이션들로 전송된다. 또한, 네트워크 메시지는 주변 장치(104)를 사용하여 네트워크 상의 다른 장치들 및 애플리케이션들로부터 수신될 수 있으며, 주변 장치는 네트워크 메시지를 네트워크 스택(102)을 통해 애플리케이션(100)으로 전송한다. 네트워크 스택(102)은 하나 이상의 중간 소프트웨어 계층(106)을 포함한다. 애플리케이션(100)으로부터 전송되는 데이터는 중간 소프트웨어 계층(106)을 통해 이동하는데, 중간 소프트웨어 계층에서는 데이터에 대해 데이터의 패키징, 신뢰성 있는 데이터 전송, 데이터 암호화 및 메시지 다이제스트의 계산과 같은 특정 동작들이 수행될 수 있다.
스위치(108)는 호스트의 처리 장치로부터 중간 소프트웨어 계층(106)에 대한 네트워크 스택 동작들을 오프로드하는 데에 사용된다. 스위치(108)가 개별적으로 도시되어 있지만, 스위치(108)는 네트워크 스택(102)의 상부 중간 계층에 통합될 수 있다는 것에 유의해야 한다. 네트워크 스택 동작들을 오프로딩한 후, 데이터는 주변 장치(104)가 네트워크 스택 동작들을 수행할 수 있도록 하기 위하여 침니(chimney; 110)를 통해 주변 장치(104)로 전송된다. 이러한 계층구조에서, 중간 소프트웨어 계층들은 호스트 또는 주변 장치 내에 배타적으로 상주할 필요가 없다. 더욱이, 이 계층 구조는 임의의 중간 계층이 완전히 오프로드되거나, 호스트에 남거나, 또는 양자의 조합(예를 들어 하나 이상의 특정 접속을 오프로드하는 것)을 가능하게 한다. 또한, 침니들은 침니들의 상부에 계층화될 수 있다(예를 들어, IPSEC 침니가 TCP 침니의 상부에 계층화될 수 있다).
접속은 신뢰성 있는 데이터 전송 및 신뢰성 없는 데이터 전송의 임의의 조합일 수 있으며, 유니캐스트 또는 멀티캐스트 데이터 전송을 포함할 수 있다. 어느 경우에나, 주어진 접속에 대한 상태 객체가 오프로드될 때, 그리고 상태 객체 내에 캐시된 변수들이 있을 때, 중간 계층은 각각의 상태 객체에 대해 "캐시된" 것으로 표시된 변수가 호스트 내에서 변경되는 경우 변수의 캐시된 사본(copy)이 주변 장치에서 갱신되는 것을 보장한다. 예를 들어, 접속의 오프로딩은 전송 계층에 대한 전송 제어 블록(TCB) 상태 엔트리, 네트워크 계층에 대한 라우트 캐시 엔트리(RCE) 및 프레이밍 계층에 대한 어드레스 레졸루션 프로토콜 엔트리(ARP)를 모두 주변 장치(104)로 오프로딩하는 것을 포함할 수 있다. 스위치(108)는 동일한 RCE를 공유하는 호스트 네트워크 스택(102)을 통해 상이한 TCB에 대해 트래픽을 계속하여 전송하며, 스위치(108)는 침니(110)를 통해 오프로드된 TCB에 대해 트래픽을 전송한다.
스위치(108)는 중간 계층(106)에 오프로드 요구를 전송함으로써 오프로드를 개시한다. 각 중간 계층(106)은 오프로드 요구를 거절하거나 오프로드 요구에 자원 정보를 추가하여 네트워크 스택(102) 내의 인접 소프트웨어 계층으로 전송한다. 오프로드 요구는 주변 장치(104)가 접속을 성공적으로 오프로드할 수 있는지를 결정하는 것을 돕는 (잠재적으로 각 네트워크 계층에 대한) 자원 정보를 포함한다. 주변 장치(104)가 오프로드 요구를 수신할 때, 주변 장치는 접속을 오프로드하는 데에 이용할 수 있는 자원을 갖고 있는지를 계산한다. 주변 장치(104)는 오프로드가 가능하지 않은 경우 오프로드 요구를 거절한다. 가능한 경우에는 주변 장치(104)는 오프로드 요구를 받아들이고 접속에 대한 자원을 할당한다. 주변 장치(104)는 중간 소프트웨어 계층(106)에 파라미터 리스트를 가진 완료 메시지를 전송함으로써 오프로드 요구를 완료한다. 파라미터 리스트는 중간 소프트웨어 계층(106) 및 스위치(108)에 정보를 제공하여, 중간 소프트웨어 계층(106) 및 스위치(108)가 주변 장치와 통신할 수 있게 한다. 각각의 중간 소프트웨어 계층(106)은 완료 메시지를 수신할 때, 파라미터 리스트로부터 그의 계층에 대한 정보를 삭제하고 완료 메시지의 나머지를 다음 중간 계층(106)으로 전송하거나, 추가 중간 계층(106)이 없는 경우에는 스위치(108)로 전송한다.
중간 계층(106)이 오프로딩에 대한 완료 메시지를 수신할 때, 또는 원래의 오프로드 요구 동안, 중간 계층(106)은 그의 상태를 주변 장치(104)로 전송한다. 각 상태는 3가지 변수("상태 변수"로도 지칭됨) 유형, 즉 CONST, CACHED 및 DELEGATED를 가질 수 있다. 임의의 주어진 중간 계층(106)에 대응하는 상태 객체는 3가지 상태 유형 모두, 또는 3가지 상태 유형의 서브세트를 가질 수 있다. CONST 상태 변수는 오프로드된 접속의 수명 동안 절대로 변하지 않는 상수이다.
CONST 상태 변수는 네트워크 스택의 처리 제어를 오프로딩할 때(이하에서는 간단히 "오프로드 동안"으로도 지칭됨) 주변 장치(104)로 제공되지만, 상태 객체가 호스트 프로토콜 스택으로 업로드될 때(이하에서는 간단히 "업로드 동안"으로도 지칭됨) 주변 장치(104)에 의해 적절한 중간 계층(106)으로 반환되지 않는다. 이는 중간 계층(106)이 CONST 상태 변수에 대한 값을 유지하여 업로드 동안 전송되는 데이터 구조가 훨씬 더 작게 하기 때문이다.
호스트 프로세서는 CACHED 상태 변수의 소유권을 유지하고, 호스트 프로세서에서의 CACHED 상태 변수에 대한 임의의 변화가 주변 장치(104)에서 갱신되는 것을 보장한다. CACHED 상태 변수를 변경하는 제어 메시지는 네트워크 스택(102)에 의해 처리된다. 결과적으로, 호스트는 오프로드 동안 CACHED 상태 변수를 주변 장치에 기록하지만, 업로드 동안에는 주변 장치로부터 CACHED 상태 변수를 판독할 필요가 없게 된다. 이것은 업로드와 관련된 오버헤드를 더욱 감소시킨다.
호스트 프로세서는 DELEGATED 상태 변수의 소유권을 주변 장치(104)로 전송한다. DELEGATED 상태 변수는 오프로드 동안 한번 기록되며 업로드 동안 판독된다. DELEGATED 상태 변수의 제어를 단지 역전송함으로써 접속을 호스트로 업로딩하는 것과 관련된 오버헤드가 최소화된다.
따라서, 오프로드 동안, 상태 객체의 제어는 주어진 상태 객체의 상태 변수들의 일부에 대한 제어가 호스트 프로세서에 유지되고, 주어진 상태 객체의 다른 상태 변수들의 제어가 주변 장치(104)로 전송된다는 점에서 호스트 프로세서와 주변 장치(104) 사이에 공유된다. 따라서, 중간 계층과 관련된 상태의 처리에 대한 제어는 호스트 프로세서와 주변 장치 사이에 깔끔하게 분할되어 각각이 배타적인 상태 부분을 소유하게 된다.
호스트 프로세서는 필요할 때 DELEGATED 상태 변수에 대해 주변 장치(104)에 질의할 수 있다. 호스트 프로세서는 또한 진단을 위해 CONST 또는 CACHED 상태 변수에 대해 질의할 수 있다. 상태를 3개의 카테고리(또는 변수)로 나누는 것은 네트워크 스택(102)이 침니(110)와 깔끔하게 공존할 수 있게 한다. 주변 장치에 제공되는 임의의 상태 변수는 (이러한 상태 변수에 대한 제어가 또한 주변 장치로 전송되는 지의 여부에 관계없이) 주변 장치와 호스트 스택 간의 상호작용의 수를 최적화하기 위해 초기 오프로드 요구에 포함될 수 있다. 이것은 상태 객체가 델리게이트된 상태를 포함하지 않거나 호스트 스택이 델리게이트된 상태 변수가 초기 오프로드 요구와 오프로드 요구의 완료 사이에 변경되지 않을 것을 보장할 수 있는 경우에 행해질 수 있다.
업로드는 주변 장치(104) 또는 스위치(108)에 의해 직접 개시될 수 있다. 또한, 업로드는 중간 계층(102)에 의해 간접적으로 개시될 수 있는데, 이는 예컨대 중간 계층(102)이 경로 또는 이웃 엔트리를 무효화하기 때문이다. 업로드가 개시되면, 주변 장치(104)는 모든 미해결 요구를 완료하며, 상태 객체를 호스트 스택으로 도로 전달한다. 스위치(108)는 임의의 추가 전송 요구들을 큐에 넣고, 수신 버퍼들을 주변 장치(104)로 포스트하는 것을 중지한다. 업로드 동안, 호스트 스택의 중간 계층들은 상태 객체의 제어를 다시 얻어 업로드 요구를 종료시킨다. 업로드 요구가 완료된 후, 주변 장치(104)는 업로드로 인해 더 이상 사용되고 있지 않는 자원들을 자유롭게 한다.
어떤 상황하에서는, 특정 접속 또는 상태 객체에 대한 데이터는 다른 주변 장치를 통해 도달할 수 있거나 호스트 프로토콜 스택(예를 들어, TCP 세그먼트가 상이한 네트워크 인터페이스 상에 도달하게 하는 IP 단편들 또는 라우트 플랩들)에 의해 처리되도록 요구될 수 있다. 이것이 발생하는 경우, 중간 계층(106)은 또한 수신 데이터를 주변 장치(104)로 전송하기 위한 전송 인터페이스를 가질 수 있다. 중간 계층(106)은 주변 장치(104)가 관련된 접속 또는 상태 객체를 업로딩하는 중에 데이터를 주변 장치(104)로 전송하려고 시도할 수 있다. 따라서, 주변 장치(104)는 데이터 패킷을 처리하는 데에 필요한 상태 객체에 대한 제어를 더 이상 갖지 않을 수 있다. 이것이 발생하는 경우, 주변 장치(104)는 업로딩 진행 중임을 지시하는 에러 메시지를 중간 계층(106)으로 반환한다. 에러 메시지는 중간 계층(106)에게 착신 데이터의 전송을 중지하고 중간 계층이 상태 객체를 수신할 때까지 추가 데이터를 버퍼링할 것을 알린다. 대안으로, 주변 장치(104) 상의 추가적인 버퍼 메모리의 대가로서, 착신 데이터가 주변 장치(104)로 전송되어 주변 장치(104)가 데이터를 버퍼링하고 상태 객체의 업로딩이 완료된 때 데이터를 제공할 수 있다. (도 7은 업로드 프로세스를 보다 상세히 나타낸다.)
다수의 접속이 중간 소프트웨어 계층(106)에 의해 주변 장치(104)로 오프로드될 수 있다. 기준 카운터(reference counter)는 오프로드에 대한 중간 소프트웨어 계층의 상태 객체를 참조하는 다수의 상위 계층 상태 객체들(즉 중간 소프트웨어 계층(106) 위의 계층들의 상태 객체들)의 중간 소프트웨어 계층(106)에 의해 유지된다. 여기서 사용되는 상태 객체는 특정 계층에 대한 상태 변수들("상태들"로도 지칭됨)의 집합이다. 전술한 바와 같이, 이러한 상태 변수들은 CONST, CACHED 또는 DELEGATED로 분류될 수 있다. 특정 중간 계층의 오프로드 상태 객체에 대한 기준들의 수가 0으로 감소하는 경우(예를 들어 업로드 요구 동안), 중간 계층(106)은 주변 장치(104)에 메시지를 전송하여, 중간 계층(106)에 대한 상태 객체를 업로드하고, 대응하는 델리게이트된 상태 변수들을 중간 계층(106)으로 전송하며, 중간 계층(106)에 대한 상태 객체를 삭제한다. 업로드 요구는 기준 카운트를 0으로 감소시키는 원래의 업로드 요구 동안에, 또는 그 이후에 발생할 수 있다는 점에 유의하자.
도 2는 본 발명에 따른 일 실시예를 나타내는데, 여기서 하드웨어 계층(214)은 예를 들어 네트워크 인터페이스 카드(NIC)일 수 있는 주변 장치를 포함한다. 또한, 도 2는 스위치(206)(즉, 전송 계층 인터페이스(TLI) 스위치(206))를 포함하는 소프트웨어 계층과, 전송 계층(Transport Layer; 201), 네트워크 계층(202) 및 프레이밍 계층(Framing Layer; 203)을 포함하는 네트워크 스택(220)을 나타낸다. 네트워크 계층(202)은 "경로 계층(Path Layer)"으로도 알려져 있으며, 프레이밍 계층(203)은 "이웃 계층(Neighbor Layer)"로도 알려져 있다.
일반적으로, 애플리케이션(200)은 동작 동안 네트워크 메시지를 네트워크 스택(220)을 통해 주변 장치(예를 들어 하드웨어(214))로 전송한다. 애플리케이션(200)으로부터 전송된 데이터는 데이터가 호스트 기반 네트워크 스택(220) 아래로 갈 것인지, 아니면 침니(230) 아래로 갈 것인지를 제어하는 TLI 스위치(206)를 통해 이동한다. TLI 스위치(206)는 네트워크 스택(220)의 정상 계층(top layer) 내에 통합될 수 있다는 점에 유의하자. 네트워크 스택(220) 내의 소프트웨어 계층들은 애플리케이션(200)으로부터 데이터를 수신하고, 이 데이터를 패킷 형태로 패키지하여 얻은 패킷을 NDIS 미니드라이버(210)를 통해 주변 장치 하드웨어(214)로 전송한다. 또한, 소프트웨어 계층은 페이로드(payload)를 애플리케이션에 넘기게 되므로 네트워크 패킷이 수신될 때 역기능을 제공한다. 데이터 패킷이 스택(220)을 통과할 때 네트워크 스택(220)이 수행할 수 있는 다른 작업들에는 데이터 암호화 및 해독, 신뢰성 있는 데이터 전송, 및 메시지 다이제스트의 계산 또는 검사(예를 들어 데이터 패킷에 대한 체크섬 또는 CRC)가 포함된다. 이들 작업 중 많은 작업은 오프로드되지 않거나 프로세서 집약적이라면 호스트 프로세서에 의해 수행된다.
TLI 스위치(206)는 오프로드 접속에 대한 데이터를 침니(230) 및 침니 드라이버(212)를 통해 주변 장치로 전송함으로써 스택 동작들을 CPU에서 주변 장치로 오프로드하는 데에 사용된다. 이 분야의 전문가는 본 명세서 및 청구범위를 읽은 후에 NDIS 드라이버(210) 및 침니 드라이버(212)가 동일한 실제 드라이버일 수 있다는 것을 알 것이다. 또한, 이 분야의 전문가는 NDIS 미니드라이버(210) 및 침니 드라이버(212)의 상위 에지가 마이크로소프트 윈도우즈 운영 체제 내의 NDIS API라는 것을 알 것이다. 본 발명을 설명하기 위하여 전송 제어 프로토콜(TCP) 기반의 프로토콜 스택이 사용된다. 그러나, 이 분야의 전문가는 본 명세서를 읽은 후에 많은 유형의 주변 장치들이 사용될 수 있고 다른 네트워크 스택들이 본 발명에 따른 원리를 이용하여 오프로드될 수 있다는 것을 알 것이다. 예를 들어, 스트림 제어 전송 프로토콜(SCTP) 또는 유저 데이터그램 프로토콜(UDP) 기반 프로토콜 스택, 원격 DMA(RDMA), 또는 IPSEC 암호화/해독이 오프로드될 수 있다. 또한, 본 발명은 인터넷 스몰 컴퓨터 시스템 인터페이스(iSCSI), 네트워크 파일 시스템(NFS), 또는 공통 인터페이스 파일 시스템(CIFS)과 같은 고기능 프로토콜을 오프로드하는 데에 사용될 수도 있다. 오프로드된 프로토콜은 접속 지향(예컨대, TCP)이거나 무접속(예컨대, IPSEC)일 수 있다.
네트워크 접속 오프로드를 행하는 많은 이유가 있다. 예를 들어, 이들 이유 중 몇 가지는 아래에 제공되지만, 이에 제한되지는 않는다. 시스템 관리자가 오프로드할 특정 서비스를 선택할 수 있다. 트래픽(바이트 또는 패킷 수의 측면에서)이 상당한 양의 자원을 소비하는 경우 특정 접속이 오프로드될 수 있다. 또한, IPSEC 서비스와 같은 소정 유형의 서비스가 오프로드될 수 있다. 또한, 관리 정책이 오프로드 처리를 드라이브할 수 있다. 예를 들어, 관리자는 조직 내로부터의 모든 접속을 먼저 오프로드하거나 특정 애플리케이션에 대한 모든 접속을 먼저 오프로드하는 정책을 가질 수 있다. 사용되고 있는 시스템 자원들(예를 들어 CPU 사용, 데이터 캐시 사용, 페이지 테이블 캐시 사용, 메모리 대역폭 등)이 호스트 프로세서가 접속을 오프로드하도록 이끌 수 있다.
도 3은 TCP 접속을 오프로드하기 위해 취해지는 3단계 프로세스를 나타내는데, 여기서 도 2의 애플리케이션 계층(200)은 도시되지 않았지만 TLI 스위치(306)의 왼쪽에 있을 것이다. 또한, 네트워크 어댑터를 구비한 범용 CPU를 포함하여 다른 유형의 주변 장치들이 본 발명에 따른 동일 또는 유사한 기능을 수행할 수 있지만 주변 장치(370)는 도 3에서는 단지 설명의 목적으로 NIC로서 도시되어 있다. 일반적으로 도 3은 프로세스가 TCP 접속을 오프로드하는 데에 필요한 자원을 할당하고, 계층들(300, 302, 304, 306) 각각에 핸들을 제공하고, 계층들(300, 302, 304, 306) 각각에 대한 상태를 주변 장치(370)로 오프로드하는 것을 설명하고 있다. 오프로드 전이 동안, TLI 스위치(306)는 애플리케이션으로부터 전송 받은 모든 메시지를 버퍼링한다. 대안으로, 전송 계층(300)이 데이터를 버퍼링한다. 오프로드가 완료된 때, 버퍼링된 데이터는 주변 장치(370)로 전송된다. 오프로드 전이 동안 착신 패킷들이 수신될 때, 주변 장치(370)는 전송 계층 델리게이트 상태가 주변 장치(370)로 넘겨질 때까지 계층들(300, 302, 304, 306)을 통해 데이터를 계속 끌어올린다. 전송 계층(300)은 오프로드 전이 동안 착신 패킷을 수신한 경우, 데이터를 전송 상태 객체 델리게이트 상태의 일부로서 또는 개별적으로 NIC(370)로 전송한다.
TLI 스위치(306)는 전송 계층(300)에 오프로드 요구(330)를 전송함으로써 오프로드를 개시한다. 오프로드 요구는 그 다음 계층의 로컬 상태에 대한 포인터(예를 들어 전송 계층(300)에 대한 TCB 포인터, 네트워크 계층(302)에 대한 RCE 포인터, 프레이밍 계층(304)에 대한 ARP 엔트리 포인터 또는 NDIS 미니드라이버(210)에 대한 NDIS 미니포트 포인터)를 포함한다. 또한, 오프로드 요구는 오프로드 유형(예를 들어, TLI 스위치(306)에 대한 TCP, 네트워크 계층(302)에 대한 IPv6 등), 및 주변 장치(370)가 TCP 접속을 성공적으로 오프로드할 수 있는지를 결정하는 것을 도와주는 자원 정보를 포함한다. 또한 TLI 스위치(306)는 주변 장치(370)에 오프로드 핸들을 제공할 수 있다. TLI 스위치(306)는 애플리케이션 전송 또는 수신 버퍼들을 전송 계층(300)으로 전송하는 것을 중지하여 이들을 큐에 넣고, 전송 계층(300)이 완료 메시지(320)를 전송하기를 기다린다.
전송 계층(300)은 오프로드 요구를 거절하거나 오프로드 요구(332)를 네트워크 계층(302)으로 전송하며, TCP 자원 정보는 TLI 스위치 자원 정보에 추가된다. 전송 계층(300)은 또한 주변 장치(370)에 오프로드 핸들을 제공할 수 있다. 임의의 미해결 애플리케이션 전송(outstanding application send) 또는 수신 버퍼들이 존재하는 경우, 전송 계층(300)은 버퍼들을 TLI 스위치(306)로 반환한다.
네트워크 계층(302)은 오프로드 요구(332)를 수신하고, 접속을 오프로드하기를 거절하거나 오프로드 요구(334)를 프레이밍 계층(304)으로 전송하며, 네트워크 자원 요건은 TCP 자원 정보 및 TLI 스위치 자원 정보에 추가된다. 네트워크 계층(302)은 주변 장치(370)에 오프로드 핸들을 제공할 수도 있다.
프레이밍 계층(304)은 접속을 오프로드하기를 거절하거나 오프로드 요구(336)를 주변 장치(370)로 전송하며, 프레이밍 자원 요건은 네트워크 자원 요건, TCP 자원 정보 및 TLI 스위치 자원 정보에 추가된다. 또한, 프레이밍 계층(304)은 주변 장치(370)에 오프로드 핸들을 제공할 수 있다.
주변 장치(370)는 오프로드 요구를 수신하고, TCP 접속을 오프로드하는 데에 이용할 수 있는 자원을 갖고 있는지를 계산한다. NIC가 오프로드가 불가능한 것으로 결정한 경우, NIC는 오프로드 요구를 거절한다. NIC가 오프로드가 가능한 것으로 결정한 경우, NIC는 오프로드 요구를 받아들이고 접속에 대한 자원들(예를 들어, TCB, 라우트 캐시 엔트리(RCE), 어드레스 레졸루션 프로토콜(ARP) 테이블 엔트리(ATE))을 할당한다. 주변 장치(370)는 계층들(300, 302, 304, 306)에 전달할 파라미터 및 디스패치 테이블의 링크된 리스트를 생성하고, 링크된 파라미터 리스트를 가진 완료 메시지(308)를 프레이밍 계층(304)으로 전송함으로써 오프로드 요구를 완료한다. 파라미터들은 계층들(300, 302, 304, 306) 각각에 대한 오프로드 핸들 및 디스패치 테이블을 포함한다.
여기서 사용되는 오프로드 핸들은 소프트웨어 계층이 주변 장치와 통신할 수 있도록 하거나 주변 장치가 소프트웨어 계층과 통신할 수 있도록 하는 메커니즘을 의미한다. 예를 들어 오프로드 핸들은 포인터 기반 핸들, 어레이의 탐색(look-up)으로서 사용되는 정수 값, 해쉬 테이블(예를 들어 해싱 함수), 소프트웨어 계층(또는 네트워크 계층)과 주변 장치 간의 통신 채널, 또는 주변 장치가 상태 객체를 탐색하는 데에 사용하는 소프트웨어 계층에 의해 전송되는 파라미터 세트일 수 있지만, 이에 제한되지 않는다.
예를 들어, 중간 소프트웨어 계층들(306, 300, 302, 304)과, 디스패치 테이블로 지칭되는 주변 장치(370) 간에 통신하기 위한 메커니즘은 어레이(array)의 탐색으로서 사용되는 함수 호출 포인터, 해쉬 테이블(예를 들어 해싱 함수), 소프트웨어 계층(또는 네트워크 스택)과 주변 장치 간의 통신 채널, 또는 주변 장치가 상태 객체를 탐색하는 데에 사용하는 소프트웨어 계층에 의해 전송되는 파라미터 세트일 수 있으나, 이에 제한되지 않는다. 디스패치 테이블은 주변 장치 초기화 동안 또는 나중에 교환될 수 있다.
디스패치 테이블은 데이터를 주변 장치(370)로 직접 전송하거나 주변 장치(370)로부터 데이터를 직접 수신하는 데에 사용된다. 디스패치 테이블은 또한 진단을 제공하는 데에 사용될 수 있다. 예를 들어, 소프트웨어 계층은 시스템을 모니터링하고 장애를 인젝트하여 시스템이 적절히 기능하고 있다는 것을 보장하기 위하여 2개의 중간 계층 사이에 또는 최하위 중간 계층과 주변 장치 사이에 삽입된다. 또한, 디스패치 테이블은 필요한 경우 추가적인 기능을 추가할 수 있는 소프트웨어 계층에 의해 패치될 수 있다. 예를 들어, 소프트웨어 계층이 필터 드라이버 또는 가상 주변 장치의 기능을 제공하기 위해 삽입될 수 있다. 일반적으로 패칭은 삽입된 중간 계층에 대한 함수 포인터로 디스패치 테이블을 오버라이팅함으로써 수행된다. 이어서, 삽입된 중간 계층에 대한 함수 포인터가 호출되고, 삽입된 중간 계층이 작업을 완료한 때, 삽입된 중간 계층은 원래의(original) 디스패치 테이블로부터 원래의 함수 포인터를 호출한다.
완료 메시지를 수신할 때 프레이밍 계층(304)은 용이한 갱신(예를 들어, 목적 MAC 어드레스가 변경되거나 암호화 유형이 변경됨)을 위해 프레이밍 계층에 대한 오프로드 핸들 및 디스패치 테이블을 그것의 ARP 테이블 엔트리에 저장한다. 이어서, 프레이밍 계층(304)은 ATE와 관련된 상태로 주변 장치(370)를 갱신한다. 프레이밍 계층(304)은 링크 리스트로부터 그의 상태를 제거하고, 링크 리스트 내의 나머지 정보를 네트워크 계층(302)으로 전송한다(312).
네트워크 계층(302)은 네트워크 계층(302)에 대한 오프로드 핸들 및 디스패치 테이블을 저장한다. 이어서, 네트워크 계층(302)은 RCE와 관련된 상태로 주변 장치(370)를 갱신한다(314). 네트워크 계층(302)은 링크 리스트로부터 네트워크 계층 정보를 제거하고, 파라미터 및 디스패치 테이블의 링크 리스트를 가진 완료 메시지(316)를 전송 계층(300)으로 전송한다(316). 네트워크 계층(302)은 오프로드 동안에 수신한 임의의 버퍼링된 IP 단편들을 처리를 위해 주변 장치(370)로 전송할 수 있거나, 네트워크 계층에서 IP 단편들을 처리하여 이들을 전송 계층(300)으로 전송할 수 있다.
전송 계층(300)은 전송 계층에 대한 오프로드 핸들을 저장하고, 그 상태를 주변 장치(370)로 전송한다(318). 다른 실시예에서, 전송 계층과 TLI 스위치는 동일 계층이다. 이어서, 전송 계층은 완료 메시지를 전송한다(320).
다른 실시예에서, 계층의 상태 객체는 오프로드 요구와 함께 전송된다. 예를 들어, 프레이밍 계층 상태 객체, 네트워크 계층 상태 객체, 및 전송 계층 상태 객체가 오프로드 요구와 함께 전송되며, 캐시 상태가 오프로드 요구와 완료 이벤트 사이에 변하는 경우에만 갱신된다. 전체 계층 상태 객체는 델리게이트 상태가 존재하지 않거나 오프로드 요구와 오프로드 요구의 완료 사이에 변경될 수 없는 경우에만 오프로드 요구와 함께 전송될 수 있다. 오프로드 시퀀스 동안 DELEGATED 상태를 변경하는 메시지가 수신되는 경우, 일반적으로 이 메시지는 처리되지 않고(버퍼링됨), 오프로드가 완료된 때, 이 메시지는 처리를 위해 오프로드 주변 장치로 전송되어야 한다. 그러나, CACHED로 분류되는 상태 변수들은 오프로드 요구와 함께 전송될 수 있으며, 오프로드 요구와 오프로드 요구의 완료 사이에 변경될 수 있다. 이것이 발생하는 경우, CACHED 상태 변경에서의 변경이 기록되어야 하고, 오프로드가 완료된 때 CACHED 상태는 주변 장치에서 갱신되어야 한다.
TLI 스위치(306)가 완료 메시지를 수신하면(320), TLI 스위치(306)는 애플리케이션 송신 및 수신 버퍼들을 주변 장치(370)로 전송한다(322). TLI 스위치(306)는 디스패치 테이블을 사용하여 모든 미해결 및 미래 수신 버퍼들을 포스트하고, 처리를 위해 NIC(370)로 전송한다. 오프로드 요구가 완료되는 데에 걸리는 시간 동안, 각각의 계층(300, 302, 304)은 오프로드된 상태 객체(즉, 계층과 관련된 상태 객체)에 대한 새로운 오프로드 요구를 거절하거나, 오프로드가 완료될 때까지 새로운 오프로드 요구를 대기열에 넣어 둔다(queue). 다른 실시예에서, 애플리케이션 버퍼들은 초기 오프로드 요구에서 전달된다.
전송 계층(300)은 전송 상태 객체가 초기 오프로드 요구(332)에서 주변 장치(370)로 오프로드되지 않은 경우에는 여전히 착신 TCP 데이터를 처리하고 TCP 페이로드를 TLI 스위치(306)로 넘기는 능력을 가질 수 있다. 이후 착신 TCP 데이터가 네트워크 스택(302)을 통해 도달하면, 착신 데이터는 주변 장치(370)로 전송되어 주변 장치에 의해 처리된다.
후속적인 오프로드 요구들에 대해, 네트워크 계층(302) 및 프레이밍 계층(304)은 주변 장치(370)로부터 수신한 오프로드 핸들을 이전 오프로드로부터 주변 장치(370)로 전송한다. 이것은 주변 장치(370)에게 주변 장치(370)가 네트워크 계층(302) 및 프레이밍 계층(304)에 대해 자원을 이미 할당했음을 알리며, 이러한 할당은 주변 장치(370) 자원을 보존하고 오프로드 속도를 증가시킨다.
전술한 바와 같이, 계층들(300, 302, 304)은 그들의 상태를 주변 장치(370)로 전송한다. 각 상태는 3가지 상태 변수 유형, 즉 CONST, CACHED 및 DELEGATED를 갖는다. CONST 상태 변수는 그 명칭이 내포하듯이 오프로드 접속의 수명 동안 결코 변하지 않는 상수이다. 따라서, 호스트는 접속이 종료된 때 CONST 상태 변수를 다시 판독하여 계층들에게 전송할 필요가 없게 된다. 마찬가지로, 호스트 프로세서는 CACHED 상태 변수의 소유권을 유지하고, 호스트 프로세서에서의 CACHED 변수의 임의의 변경이 주변 장치(370)에서 갱신되는 것을 보장한다. 결과적으로, 호스트는 CACHED 상태 변수를 기록하지만, (시스템 진단이 요구하지 않는 한) 그것을 다시 판독하지는 않는다. 따라서, 호스트 CPU는 DELEGATED 상태 변수들의 소유권만을 주변 장치(370)로 전송한다. DELEGATED 상태 변수는 오프로드가 발생할 때 한번 기록되며, 오프로드가 종료된 때 판독된다. 주변 장치(예를 들어 NIC)는 DELEGATED 상태 변수를 역전송(transfer back)하기만 하면 되기 때문에, 호스트로 접속을 역전송하는 오버헤드가 최소화된다. 나아가, 호스트 CPU는 필요할 때만(예를 들어 통계를 위해) DELEGATED 상태 변수에 대해 주변 장치(370)에게 질의한다.
전송 계층(300)에 대한 CONST 상태 변수는 목적 포트, 소스 포트, 전송 계층의 거동을(예를 들어, 윈도우 스케일링이 가능한지 또는 SACK가 가능한지를) 제어하기 위한 하나 이상의 플래그, SEND 및 RECV 윈도우 스케일 팩터, 및 원격 엔드포인트에 의해 광고되는 초기 최대 세그먼트 크기(원격 MSS)를 포함할 수 있다. 전술한 바와 같이, 각각의 TCP CONST 변수의 값은 상수이며, 그 값은 TCP 접속의 수명 동안 변하지 않는다.
전송 계층(300)에 대한 CACHED 상태 변수는 TCP 상태 변수 및 IP 상태 변수일 수 있다. IP 상태 변수는 네트워크 계층 값들이 접속마다 오버라이팅되도록 구현되는 경우 전송 구조에서 필요할 수 있다. 이들 CACHED 상태 변수는 하나 이상의 플래그(예를 들어, "네이글(Nagle)" 알고리즘 또는 "키프-어라이브(Keep-Alives)" 알고리즘이 가능한지), "키프-어라이브" 설정치(즉, 인터벌, 프로브 수 및 델타), 유효 최대 세그먼트 크기(또는 유효 MSS), 초기 디폴트 수신 윈도우(InitialRcvWnd), 주변 장치(370)에 의해 수신 인디케이트에서 복사되는 바이트 수, IPv4에 대한 트래픽 유형에 따라 패킷들을 우선 순위화하는 서비스 유형(TOS), 및 IPv6 패킷들이 네트워크에서 우선 순위화될 수 있게 하는 트래픽 클래스 및 플로우 라벨을 포함할 수 있다.
DELEGATED 상태 변수는 인터넷 엔지니어링 태스크 포스(Internet Engineering Task Force; IETF) RFC 793에서 특정되는 것과 같은 현재 TCP 상태, 하나 이상의 플래그(예를 들어, 원격 피어에 의해 중지되게(abortively) 닫히는 접속임), 그 다음 기대 TCP 수신 세그먼트에 대한 시퀀스 넘버(즉, RCV.NEXT), 수신 윈도우 크기(RCV.WND), 제1 수신 미확인 데이터에 대한 시퀀스 넘버(SND.UNA), 전송될 다음 TCP 세그먼트에 대한 시퀀스 넘버(SND.NEXT), 송신 윈도우 크기(SND.WND), 최종 윈도우 갱신에 대해 사용되는 세그먼트 시퀀스 넘버(SndWL1), 최종 윈도우 갱신에 대해 사용되는 세그먼트 수신 확인 넘버(SndWL2), 전에 전송된 최대 시퀀스 넘버(SND.MAX), 최대 송신 윈도우(Maximum Send Window; MAX_WIN), 및 현재 혼잡 윈도우(Congestion Window; CWnd)를 포함할 수 있다.
DELEGATED 상태 변수는 슬로우 스타트 임계치(SSTHRESH), 평탄화된 라운드 트립 타임(SRTT), 라운드 트립 타임 변화(RttVar), 그 다음 TCP ACK에서 송신될 타임스탬프 값(TsRecent), 가장 최근의 타임스탬프가 얼마나 오래 전에 수신되었는지(TsRecentAge), 동일 시퀀스 넘버에 대해 얼마나 많은 ACK가 받아들여졌는지(DupAckCont), 전송된 키프어라이브 프로브들의 수(KeepAlive ProbeCount), 다음 키프어라이브 타임아웃까지 남은 시간(KeepAlive TimeoutDelta), 전송된 재전송의 수(KeepAlive Count), 다음 재전송 타임아웃까지 남은 시간(Retransmit TimeoutDelta), 및 버퍼링된 수신 데이터에 대한 포인터(BufferedData - 오프로드 또는 업로드가 진해되고 있는 동안 수신된 TCP 데이터)를 더 포함할 수 있다.
네트워크 계층(302)에 대한 CONST 상태 변수는 목적 IP 어드레스(IPv4 또는 IPv6에 대한 어드레스) 및 소스 IP 어드레스(IPv4 또는 IPv6에 대한 어드레스)를 포함할 수 있다. 네트워크 계층(302)에 대한 CACHED 상태 변수는 경로 최대 전송 유닛(PathMTU)을 포함할 수 있다. 네트워크 계층(302)에 대한 DELEGATED 상태 변수는 IP 패킷 ID 시작 값을 포함할 수 있다. 프레이밍 계층(304)에 대한 CACHED 상태 변수는 목적 매체 액세스 제어(MAC) 어드레스, IETF RFC 2461 이웃 발견에 대한 파라미터(호스트 도달 가능성 델타 및 NIC 도달 가능성 델타), 및 헤더의 포맷(예를 들어, 논리 링크 제어/서브 네트워크 액세스 프로토콜(Logical Link Control/Sub-Network Access Protocol; LLC/SNAP) 포맷 또는 DIX(Digital, Intel, Xerox) 포맷)을 지시하는 플래그를 포함할 수 있다.
전송 계층 상태는 네트워크 계층 상태 객체에 대한 핸들을 포함할 수 있으며, 네트워크 계층 상태는 프레이밍 계층 상태 객체에 대한 핸들을 포함할 수 있는데, 이는 네트워크 계층("경로"로도 지칭됨) 상태가 다수의 접속 사이에 공유될 수 있고, 프레이밍 계층("이웃"으로도 지칭됨) 상태가 다수의 경로(예를 들어, 하나의 라우터를 통과하는 모든 트래픽) 사이에 공유될 수 있기 때문이다. 이러한 계층 구조는 여러 이유로 유지된다. 접속은 네트워크 계층에 대한 NIC 핸들을 요구할 수 있는데, 이는 IP ID 네임스페이스가 경로마다 모든 오프로드된 접속을 통해 관리될 수 있기 때문이거나, 경로 MTU의 갱신이 네트워크 계층에서 한번에 수행되어, 각 TCP 접속에 대해 개별적으로 설정하기보다는 모든 TCP 접속을 실행할 수 있기 때문이다. 경로는 프레이밍 계층 상태 객체에 대한 NIC 핸들을 요구하는데, 이는 라우트 갱신이 다음 홉 어드레스를 변경하고, 따라서 새로운 MAC 어드레스를 지시할 수 있기 때문이다. 또한, 계층 구조는 NIC에 의해 유지되는 데에 필요한 상태의 양을 줄인다. 예를 들어, IPv4에 대한 ARP 갱신은 IP 어드레스에서 MAC 어드레스(예를 들어 서버 상에서 페일오버된 인터페이스)로의 맵핑을 변경할 수 있다. 호스트는 MAC 어드레스를 캐시 변수로서 유지하며, 따라서 캐시 상태의 단일 갱신을 행하는 것만이 필요하고, 모든 접속은 새로운 인터페이스로 페일오버된다.
일단 호스트가 TCP 접속을 오프로드하면, 주변 장치(370)는 IPv4를 이용하여 그것이 송신하는 패킷들에 대해 패킷 식별자들(예를 들면, IP ID들)을 할당할 책임이 있다. IP ID는 인터페이스마다(on a per interface basis) 또는 계층 상태 객체마다(on a per layer state object basis) 오프로드된다. 어느 경우든, 주변 장치(370)에는 IP ID 네임스페이스의 일부분이 할당된다. 일 실시예에서, 주변 장치(370)에는 그것이 초기화될 때 전체 IP ID 네임스페이스의 절반이 할당되고, 호스트 프로토콜 스택은 IP_ID 네임스페이스 중 그것의 부분을 주변 장치마다(on a per peripheral device basis) 유지한다. 또 다른 실시예는 호스트 프로토콜 스택이 IP_ID 네임스페이스를 경로마다(on a per path basis) 유지할 수 있게 한다. 주변 장치에는, 네트워크 상태 객체가 그 주변 장치(370)에 전달될 때 사용하기 위한 IP 패킷 ID 시작 값(start value)이 부여된다. 주변 장치(370)는 다음 식을 이용하여 그것이 송신하는 IP 패킷들에 대한 IP ID를 발생시킨다.
Cur_IPID = [(Start_IPID_For_This_Path) + (Counter_For_This_Path)mod32K]mod64K
Counter_For_This_Path = Counter_For_This_Path + 1
오프로드된 접속이 업로드되거나 또는 무효화(invalidate)될 때, 주변 장치(370)는 발생하는 다음 오프로드에 대해 저장하기 위해 그것이 사용할 다음 IPID 값을 네트워크 계층에 전송하고 호스트 처리 유닛(320)은 그것에 할당된 IP ID의 부분을 계속해서 사용한다. 호스트 처리 유닛(320)은 전체 IP ID 네임스페이스를 사용할 수 있지만, 바람직하게는 네트워크 상의 IP 패킷들의 최대 수명이 초과된 이후에만 그것을 사용한다.
주변 장치(370)는 데이터를 그 데이터가 수신된 순으로 수신 버퍼에 넣고 애플리케이션 버퍼들을 오프로드된 접속에 대해 그것들이 포스트되어 있는 순으로 채운다. 많은 애플리케이션들은 수신 버퍼를 포스트하기 전에 수신 지시를 기다린다. 일 실시예에서, 주변 장치(370)는 접속을 위한 데이터가 도착하고 어떠한 애플리케이션 수신 버퍼들도 포스트되지 않은 경우 사용하기 위한 버퍼들의 글로벌 풀(a global pool of buffers)을 갖는다. 버퍼들의 글로벌 풀은 오프로드된 접속들에 대해서 사용되며, 1) 비순차적(out-of-order) TCP 전송들의 핸들링을; 2) IP 데이터그램들의 조각모음(defragmenting)을; 3) 애플리케이션이 제로 카피 알고리즘(zero copy algorithm) 용도로는 너무 작은 버퍼들을 포스팅할 경우 제로 카피 알고리즘보다는 버퍼 카피 알고리즘을; 및 4) 애플리케이션이 버퍼들을 사전 포스트(prepost)하지 않은 경우 애플리케이션에게 데이터를 지시하기 위한 지시 메커니즘(indication mechanism)을 구현하기 위해 사용될 수 있다. 대안적으로, 버퍼 자원들의 능률적인 이용이 관심사가 아니라면 버퍼들의 사전-접속 풀(a pre-connection pool of buffers)이 사용될 수도 있다. 이 경우, 버퍼들의 글로벌 풀은 애플리케이션이 버퍼들을 사전 포스트하지 않았거나 또는 시스템 자원들이 부족한 경우(예를 들면, 애플리케이션 버퍼를 메모리 내에 핀(pin)하기에 자원들이 충분치 않은 경우)에만 사용된다.
이제 도 4a 내지 도 4d를 참조하면, 오프로드를 수신한 전형적인 주변 장치(예를 들면, NIC)가 그 오프로드를 나타내는 반전 트리 데이터 구조(400)를 가질 수 있다. 도면들에서, 점선들은 주변 장치에 의해 할당된 새로운 상태들을 나타낸다. 도 4a에서, 주변 장치는 라우트 캐시 엔트리(route cache entry)(404)에 결합된 ARP 엔트리(402)를 가지며, 상기 라우트 캐시 엔트리(404)는 TCP 엔트리(406)로서의 네트워크 접속에 결합된다. 만일, 예를 들어, 모든 네트워크 접속(예를 들면, TCP) 트래픽이 라우터로 가는 것이면, 다음 홉(hop)은 항상 동일 ARP 엔트리(402)로 향할 것이다. 만일 라우트 캐시 엔트리(404)가 다음 네트워크 접속 오프로드를 위해 사용될 경우에는, 유일한 새 자원은 새로 오프로드된 TCP 상태 객체이다. 따라서 호스트 CPU가 네트워크 프로토콜 스택 아래로 오프로드를 시작할 경우, 이미 그들의 상태를 오프로드한 중간 소프트웨어 계층들(예를 들면, 네트워크 계층(302) 및 프레이밍 계층(304))은 단지 이전의 오프로드 요구 시에 할당된 주변 장치 발생 오프로드 핸들을 삽입할 것이다. 주변 장치(170)는 새 자원들(예를 들면, TCP 엔트리(408))을 할당하고 이 새 자원들에 대한 오프로드 핸들들을 거꾸로 네트워크 프로토콜 스택 위로 송신하기만 하면 된다.
반전 트리(400)는 이제 라우트 캐시 엔트리(404)에 결합된 TCP 엔트리(408)를 갖는다(도 4b 참조). 이 방법은 주변 장치 자원들을 절약하고 오프로드의 속도를 향상시킨다. 게다가, 캐시된 변수 상태가 변하면, 단일 구조만 갱신될 필요가 있다. 만일 침니(chimney) 내의 여러 소프트웨어 계층들에 대한 모든 상태가 단일 엔트리로서 오프로드되면, 최상위 소프트웨어 계층 아래의 임의의 상태 갱신은 다수의 갱신을 필요로 할 것이다.
도 4c는 보다 복잡한 구성을 갖는 반전 트리(400)를 도시한다. 여기에는 ARP 테이블 엔트리(402)를 통과하는 2개의 라우트 캐시 엔트리(404 및 410)가 있다. TCP 네트워크 접속들(406 및 408)은 라우트 캐시 엔트리(404)를 이용한다. TCP 네트워크 접속들(412 및 414)은 라우트 캐시 엔트리(410)를 참조한다. 만일 임의의 ARP 갱신이 발생할 경우(예를 들어, 멀티홈 서버(multi-homed server)의 인터페이스가 무료(gratuitous) ARP 갱신을 이용하여 페일오버(fail over)할 경우), 엔트리(402)만이 갱신되어야 한다. 이것은 잠재적으로 수백 수십만의 접속들이, 해당 주변 장치에 대해 단지 하나의 갱신만이 요구되는 새로운 인터페이스로 페일오버될(failed-over) 수 있게 한다. 도 4d는 라우트 갱신이 발생한 후에 단일 반전 트리(400)로 합병된 2개의 독립적인 반전 트리(엔트리들(402 내지 408) 및 엔트리들(410 내지 416))를 도시한다. 라우트 갱신 전에, 라우트 캐시 엔트리(410)에 대한 다음 홉 ARP 엔트리는 ARP 테이블 엔트리(416)이다. 라우트 갱신 후에, 다음 홉 ARP 테이블 엔트리는 ARP 테이블 엔트리(402)이다. 따라서, 반전 트리를 이용할 경우, 프레이밍 계층, 네트워크 계층, 및 전송 계층에 대한 상태가 단일 엔트리로서 오프로드되었다면, 라우트 갱신들이 수백 수만의 갱신보다는 그 주변 장치에 대한 단일 트랜잭션으로서 처리될 수 있다. 중요한 것은, 이 반전 트리 개념은 동시에 다수의 접속들을 오프로드하는 것까지 확장될 수 있다는 점이다.
도 5a 및 5b는 특히 블록 리스트 핸들(또는 "블록 리스트")을 참조하여 본 발명에 따른 부가적인 특징을 예시한다. 일반적으로, 블록 리스트는 침니 오프로드 또는 침니 종료(Chimney Termination) 중에 오프로드 타깃(예를 들면, 주변 장치)에 부여되는 데이터 구조이다. 따라서, 네트워크 접속을 처리중인 컴포넌트는 "업로드"의 경우에는 블록 리스트를 거꾸로 호스트로 송신하고, "오프로드"의 경우에는 아래로 주변 장치로 송신하므로 최초 기준점은 임의적이다. 이 블록 리스트 데이터 구조는 특정한 다음 계층 상태 객체(종속 블록(Dependent Block)) 또는 동일 계층의 상태 객체들(다음 블록(Next Block))을 가리키는 일련의 포인터들을 포함한다.
보다 구체적으로, 종속 블록 포인터는 계층 구조에서 위로 다음 레벨을 가리키고 오프로드 타깃에게 네트워크 프로토콜 스택 내의 중간 소프트웨어 계층들 간의 임의의 현존하는 의존성을 통지하는 데에 이용된다. 예를 들면, 이웃(Neighbor)(또는 프레이밍 계층) 상태 객체는 경로(Path)(또는 네트워크 계층) 상태 객체에 의존할 것이고, 이 경로(또는 네트워크 계층) 상태 객체는 동일 계층 구조의 TCP 접속에 의존할 수 있다. 그러나, 다음 블록 포인터는 다른 계층 구조 내의 동일 레벨에 있는 데이터 구조를 가리킨다. 예를 들면 제1 TCP 접속 내의 경로(또는 네트워크 계층) 상태 객체는 다른 TCP 접속 내의 경로 상태 객체를 가리킬 수 있다.
도 5a는 도 4a 내지 도 4d에서와 유사하게 도시된 반전 트리 데이터 구조를 예시한다. 도 5a의 반전 트리는 서로 다른 TCP 계층 상태 엔트리들을 갖지만, 공통의 경로(또는 네트워크 계층) 상태 엔트리(505), 및 공통의 이웃 상태 엔트리(500)를 갖는 2개의 TCP 접속들(510 및 515)(즉, TCP 접속 1 및 TCP 접속 2)을 도시한다. 그러나, 다른 네트워크 접속(525)(즉, TCP 접속 3)은 별도의 경로 상태 엔트리(520)를 갖지만, 공통의 이웃 상태 엔트리(500)를 갖는다. 전체 시퀀스 계층 구조(sequence hierarchy)는 각 소프트웨어 사이에서 접속을 다음 소프트웨어 계층에 인도(direct)하는 일련의 경로 핸들들에 의해 정의된다. 예를 들면, 경로 핸들들(507 및 517)은 TCP 상태 엔트리들(510 및 515)을 각각 경로 상태 엔트리(505)에 인도하고, 이 경로 상태 엔트리(505)는 그것을 이웃 상태 엔트리(500)에 인도하는 핸들(502)을 갖는다. 마찬가지로, TCP 상태 엔트리(525)는 경로 상태 엔트리(520)를 가리키는 핸들(527)을 갖고, 경로 상태 엔트리(520)는 핸들(512)에 의하여 공통의 이웃 상태 엔트리(500)에 인도된다. 본 발명에 따르면, 도 5a는 또한 다음 블록 포인터들에 의하여 표현됨으로써, 동시에 다수의 네트워크 접속 침니들을 포함할 수도 있다.
도 5b는 블록 리스트 핸들(각종 다음(Next) 및 종속(Dependent) 블록 포인터들의 집합)이 동시 오프로드를 위해 서로 다른 네트워크 접속들 사이에서 몇몇 네트워크 접속 블록들을 어떻게 관련시키는지를 예시한다. 도 5a에서와 마찬가지로, 도 5b는 각종 소프트웨어 상태 핸들들을 포함하는 소프트웨어 계층 블록들과 관련된 반전 트리를 나타낸다. 공통의 경로 블록(535), 및 공통의 이웃 블록(530)을 갖는 TCP 블록들(540 및 545)이 도시되어 있다. 제3의 TCP 블록(555)은 경로 블록(550) 및 동일 이웃 블록(530)을 갖는다. 블록 리스트 핸들은 이웃 블록(530)이 경로 블록(535)을 가리키는 종속 블록 포인터(537)를 포함한다는 것을 기술할 것이다. 그러나, 도 5a의 이전 반전 트리와는 대조적으로, 이웃 블록(530)은 또한 다음 블록 포인터(532)를 통하여 또 다른 반전 트리 데이터 구조를 지시할 수 있다. 만일 다음 블록 포인터(532)가 누락되어 있으면(예를 들어, 널(NULL) 값이면), 이것은 블록 리스트 내에서 반전 트리의 해당 계층에 다른 반전 트리가 전혀 없다는 것을 나타낼 수 있다. 마찬가지로, 경로 블록(535)은 반전 트리의 전혀 다른 "분기"(branch)인 경로 블록(550)을 가리키는 다음 블록 포인터(560)를 갖는다.
다음 블록(530)의 경우와 마찬가지로, 경로 블록들(535 및 550) 모두는 각각 종속 블록 포인터들(542 및 557)을 각각 갖고, 다음 포인터(560 및 570)를 각각 가지므로, 경로 블록(550)도 또한 전혀 다른 반전 트리(예를 들어, 570)의 다른 접속 경로를 가리킬 수 있다. 게다가, TCP 블록들(540, 545, 및 555) 각각은, 동일 반전 트리(예를 들어, 547) 내의 또 다른 TCP 블록을 가리킬 수 있고, 또는 이 트리(예를 들어, 562 및 572) 내에 더 이상의 블록이 없다는 것을 나타낼 수 있는 다음 블록 포인터들(547, 562, 572)을 갖는다. 그러나, 이들 포인터는 정적(static)인 것이 아니다. 즉, 경로에 대한 라우트가 변하면 다음 이웃을 다른 라우트로 변경할 수 있는 것처럼 링크들은 변할 수 있다. 그 경우에, 예를 들면, 경로 블록(550)은 그것이 사용하는 이웃 상태 엔트리를 이웃 엔트리 1(530)로부터 어떤 다른 이웃(예를 들면, 이웃 엔트리 2(도시되지 않음))으로 변경할 수 있다. 따라서, 블록 리스트를 사용함으로써, 다수의 접속, 경로, 및 이웃 엔트리들이 단일 프로그램 호출에서 오프로드되거나 종료될 수 있다.
한정이 아니라 단지 예로서, 제1 오프로드 요구는 오프로드 타깃(예를 들어, NIC)에게 데이터 구조들(예를 들면, 540, 545, 535, 530 등) 각각에 대한 상태 및 핸들을 할당하고, 그 오프로드 타깃의 핸들을 호스트 네트워크 프로토콜 스택에 돌려줄 것을 요구할 수 있다. 만일 특정 엔트리에서의 오프로드 타깃 할당된 핸들이 무효이면, 상태 객체는 새로운 오프로드 요구이다. 호스트 스택에 의한 후속 오프로드 요구들은 기존의 경로 또는 이웃 상태 엔트리들을 재사용할 수 있다. 블록 리스트는 각각의 계층에 대한 오직 하나의 상태 객체(예를 들면, 단일 이웃 상태 객체, 경로 상태 객체, 및 TCP 상태 객체)를 포함할 수 있고, 또는 그것은 도 5a 내지 도 5b에 정의된 보다 복잡한 구조일 수도 있다. 이 보다 복잡한 구조는, 지적된 대로, 다수의 접속, 경로, 및 이웃 엔트리들이 단일 프로그램 호출에서 오프로드되거나 종료될 수 있게 한다.
일단 호스트가 지시된 대로 접속(들)을 오프로드하면, 하나 이상의 소프트웨어 계층들이 그들 각각의 상태 객체(들)에서의 변화들을 갱신할 필요가 있을 수 있다. 도 6은 본 발명에서의 상태 객체의 캐시된 상태 부분을 갱신하기 위하여 네트워크 프로토콜 스택 내의 중간 소프트웨어 계층들 간에 행해지는 본 발명에 따른 가능한 신호 시퀀스를 예시한다. 이미 지적된 바와 같이, 이것은 소프트웨어 계층이 그 계층의 CACHED 상태 변수의 변화에 의해 주변 장치를 갱신할 때 행해진다. 상태 객체의 CACHED 상태 변수를 갱신함으로써 중간 소프트웨어 계층 및 주변 장치 상태가 일관되게 된다.
따라서, 도 6은 각 소프트웨어 계층이 주변 장치에 의해 그것의 CACHED 상태 변수를 갱신할 때, 각 소프트웨어 계층은 갱신 신호를 네트워크 프로토콜 스택 아래로 그 신호가 미니포트 드라이버(690)에 도달할 때까지 송신한다. 예를 들어, TCP 계층(650)이 주변 장치에 의해 그것의 CACHED 상태 변수를 갱신할 필요가 있을 경우, TCP 계층(650)은 네트워크 계층(경로)(660)에 신호(610)를 송신하고, 네트워크 계층(660)은 프레이밍 계층(이웃)(670)에 갱신 신호(620)를 송신하고, 프레이밍 계층(670)은 네트워크 드라이버 인터페이스 사양(NDIS : Network Driver Interface Specification)(680)에 갱신 신호(630)를 송신하고, NDIS(680)는 미니포트 드라이버(690)에 신호(640)를 송신한다. 일단 CACHED 상태 변수가 주변 장치에 의해 갱신되면, 미니포트 드라이버(690)는 NDIS(680)에 신호(645)를 중계하고, NDIS(680)는 TCP 계층까지 일단의 중계(635, 625, 615)를 계속하고, TCP 계층은 TCP CACHED 상태 변수가 주변 장치에 의해 갱신된 것을 시그널링한다.
본 발명은 블록 리스트 데이터 구조를 이용하므로, 이 일련의 갱신들 및 확인 단계들은 처음에 CACHED 상태 변수를 갱신한 소프트웨어 계층에서만 발생하면 된다. 즉, 예를 들어, 프레이밍 계층(이웃)(670)이 NIC로 그것의 상태 객체의 CACHED 상태 변수 부분을 갱신할 필요가 있으면, 단계들(630, 640, 645, 및 635)만이 일어날 필요가 있을 것이다. 그러므로, 네트워크 프로토콜 스택의 상위 소프트웨어 계층들은 프레이밍 계층의 CACHED 상태를 갱신하기 위한 신호 중계에 관여할 필요가 없을 것이다.
블록 리스트에 의해 다수의 접속 상태 변화들을 갱신할 수 있는 이러한 능력은 또한 오프로드된 네트워크 접속들 각각에 대해 고도의 접속 무결성(connection integrity)을 가능케 할 것이다. 대체 실시예에서, 갱신 통신은 갱신을 수행하는 소프트웨어 계층과 미니포트 드라이버(690) 간에 직접 일어나도록 허용될 수 있다. 그러나, 이것은 미니포트 드라이버(690)에게 다수의 호출 인터페이스를 필요로 하고, 부가적인 네트워크 프로토콜 계층들이 오프로드에 부가되는 것처럼 용이하게 확장될 수 있는 것이 아니다.
만일 호스트 CPU 또는 주변 장치가 오프로드된 접속 또는 상태 객체를 종료할 필요가 있을 경우, 본 발명은 유사한 일련의 시그널링(signaling) 단계들을 제안한다. 예비적으로, 호스트 또는 오프로드 타깃이 오프로드를 종료할 수 있다. 중간 프로토콜 계층이 또한 오프로드된 TCP 접속이 의존한 경로 또는 이웃 상태 객체를 종료함으로써 그 오프로드된 TCP 접속을 간접적으로 종료할 수 있다. 이것은 결국 TCP 접속 타임아웃을 초래하고, TCP 접속 타임아웃은 오프로드 타킷으로 하여금 TCP 접속 오프로드가 종료되도록 요구하게 할 것이다. 접속 오프로드는 다양한 이유로 종료될 수 있다. 일반적으로, 프로토콜 스택에게 특정 접속들을 오프로드하도록 지시하는 관리 메커니즘이 있을 것이다. 만일 오프로드 타깃이 관리자가 오프로드될 것을 지시한 접속에 대해 오프로드 종료를 요구하면, 호스트는 종료를 승인(grant)할 것이고, 관리자에 대한 이벤트가 로깅될 것이다.
대안적으로, 만일 네트워크 인터페이스가 내려가면(go down)(예를 들어, 매체 접속 해제 이벤트), 오프로드 타깃은 오프로드된 상태 객체들의 종료를 요구하지 않아야 한다. 호스트는 통상의 시그널링 이벤트(normal signaling event)를 통하여 그 이벤트에 대해 통지 받을 것이고 가장 양호한 행동 방침을 결정할 것이다. 게다가, 만일 접속이 리셋되면(이것은 TCP RST 세그먼트가 수신될 때 일어난다), 오프로드 타깃은 접속 오프로드가 종료되어야 한다는 것을 호스트에게 지시할 것이다. 만일 다음 홉 어드레스가 변하여, 이웃 상태 객체를 변하게 하면, 호스트 스택은 기존의 상태 객체가 무효화되기 전에 새로운 상태 객체가 확실히 생성되도록 보장할 것이다. 이것은 오프로드 타깃이, 이웃 또는 경로 상태 객체가 더 이상 유효하지 않으면, 그것이 호스트 스택으로부터의 경로 및/또는 이웃 상태 객체 갱신들에서의 일시적인 레이스 조건(temporary race condition) 때문이 아니라는 것을 확신할 수 있게 한다.
도 7은 주변 장치가 오프로드된 TCP 접속의 종료를 요구하는 네트워크 프로토콜 스택 내의 중간 소르트웨어 계층들 간의 본 발명에 따른 가능한 신호 시퀀스를 예시한다. 주변 장치가 오프로드를 종료하기로 결정할 경우, 그 주변 장치는 (호스트 스택에 의해 통지된 바와 같은) "지시(indicate)" 기능을 호출함으로써 호스트 스택에게 오프로드를 종료하도록 요구하고, 그 주변 장치가 그 오프로드를 종료하기를 원하는 이유를 포함시킨다. 이러한 이유는, 주변 장치가 긴급한 데이터를 수신하여 그것을 지원하지 않는 것과 같이, 주변 장치가 특정 네트워크 프로토콜 계층 특징을 지원하지 않는 상황을 포함하여, 다양한 이유일 수 있다. 주변 장치 종료 요구는, 예를 들면, 프로토콜 계층들을 통한 일련의 신호들(702, 704)의 뒤를 따르는데, 이는 미니포트 드라이버(790)로부터 NDIS(780)로의 호출(702)에서 시작되며 이어서 종료 요구 신호(704)가 NDIS(780)에 의해 TCP 계층(750)으로 송신된다. 만일 호스트가 주변 장치의 종료 요구를 승인(grant)한다면, 호스트는 미니포트 드라이버(790)에 신호를 송신함으로써 그 요구를 승인(confirm)한다.
일단 호스트 스택이 오프로드를 종료하기로 결정하면, 호스트 스택이 각각의 중간 소프트웨어 계층들을 통하여 그 중간 계층들에게 종료를 경고하는 신호를 송신하는 것이 도 7에서 도시된다. 예를 들면, TCP(750)는 네트워크 계층(760)에게 종료를 알리는 신호를 송신하고(728), 네트워크 계층은 프레이밍 계층(770)에게 종료를 알리는 신호를 송신하고(726), 계속해서 네트워크 프로토콜 스택을 통해 아래로 신호들(724 및 722)을 송신한다. 중간 소프트웨어 계층의 최상위 계층(예를 들면, TCP)의 경우에, 일단 TCP 전송 계층(750)(즉, 전송 계층(300))이 종료를 요구하면, TCP(또는 전송) 계층은 새로운 애플리케이션 송신 및 수신 버퍼들을 오프로드 타깃에 포스트(post)하는 것을 중단하고, 주변 장치가 네트워크 접속(들)을 성공적으로 갱신할 때까지 임의의 수신된 TCP 세그먼트들을 버퍼링하기 시작할 것이다. 이와 대조적으로, 네트워크 프로토콜 스택 내의 각각의 하위 소프트웨어 계층은 그 각각의 계층이 그들의 상태 객체에 대한 마지막 종속 블록 리스트 데이터 구조인지를 확인하기 위해 체크할 것이다. 만일 각각의 중간 계층이 더 이상의 종속 블록들을 갖지 않으면, 그 각각의 계층도 또한 부가적인 블록 리스트 데이터 구조를 리스트에 부가함으로써 그들의 각각의 상태 객체의 종료를 요구하고, 그 중간 계층의 각각의 상태 객체에 대한 오프로드 타깃 핸들(Offload Target handle)을 포함시킬 것이다. 만일 그것이 부가적인 종속 블록들을 가지면, 그것은 그것의 상태 객체의 업로드를 요구하지 않고 단지 다음 계층에 업로드 요구를 전송(forward)할 것이다. 신호들(724 및 722)을 참조하자.
오프로드 타깃(예를 들면, 주변 장치)이 네트워크 프로토콜 스택을 통하여 요구된 종료를 승인한 경우, 오프로드 타깃은 착신되는(incoming) 네트워크 접속 데이터의 처리를 중지하고, 발신되는(outgoing) 네트워크 접속 데이터의 처리를 일관된 상태(consistent state)로 되게 한다. 계류중인(outstanding) 요구들(즉, 애플리케이션 계층이 오프로드 종료를 승인하기 전에 네트워크 접속 데이터 버퍼들을 포스트한 경우)과 관련하여, 오프로드 타깃은, 네트워크 프로토콜 스택을 통하여 거꾸로 위쪽으로, 접속 "업로드"가 "진행중"(in progress)임을 알리는 상태 신호(732, 734)에 의해 응답한다. 주변 장치가 원격 컴퓨터(즉, WAN 상의 원격 피어(peer) 컴퓨터)에게 이미 수신을 확인한 임의의 수신 네트워크 접속 데이터가 있지만, 호스트의 애플리케이션이 (후속 처리를 위해) 그것을 소비할 버퍼를 아직 포스트하지 않은 경우에는, 주변 장치는 그것이 중간 소프트웨어 계층들에게 반환하는 TCP DELEGATED 상태 변수의 일부로서 이 포스트된 버퍼를 패키징할 것이다.
어느 경우든, 호스트 CPU는 DELEGATED 상태들의 제어를 되찾도록, 주변 장치는 각각의 중간 소프트웨어 레벨에 대해 (예를 들면, NDIS(780)를 통하여) 각각의 DELEGATED 상태 변수의 제어(예를 들면, 신호(744, 746, 748))를 반환한다. 따라서, 오프로드 타깃은 여러 계층들로부터의 요구된 DELEGATED 상태의 일관된 스냅샷(snapshot)을 보장하고, 오프로드 블록 리스트(OffloadBlockList) 구조들과 관련된 상태 구조들 내로 그 상태를 채우고, 오프로드 종료 완료 기능(742)을 호출한다. 역시 마찬가지로, 오프로드된 블록 리스트 데이터 구조 때문에, 접속 종료 호출은 하나 또는 동시에 수 개의 접속들에 대해 행해질 수 있다.
하나 이상의 NIC 드라이버와 같은, 하나 이상의 물리적 주변 장치 드라이버를 관리하는 하나 이상의 가상 장치 드라이버(들)가 제공될 수도 있다. 가상 장치 드라이버는 단일 매체 액세스 제어(MAC : Media Access Control) 어드레스를 호스트 스택에게 노출시키고, 이 호스트 스택과 가상 드라이버가 관리하는 상기 하나 이상의 주변 장치 드라이버들 간의 매핑을 제공할 수 있다. 또는 가상 장치 드라이버는 하나 (또는 그 이상의) 물리적 주변 장치들에게 호스트 스택에 대한 다수의 논리적 인터페이스를 효과적으로 제공할 수 있어, 호스트 스택이 마치 물리적 주변 장치들이 있는 것보다 더 많은 네트워크들이 있는 것처럼 네트워크 트래픽을 관리할 수 있게 한다. 따라서, 주변 장치 드라이버들은, 호스트 스택이 하나 이상의 가상 장치 드라이버(들)를 보도록, 따라서 밑에 있는 하나 이상의 주변 드라이버에 대해 모르도록, 추상화된다. 가상 장치 드라이버는 물리적 장치 드라이버들과 분리될 수도 있고 또는 그들 안에 내장(embed)될 수도 있다.
본 발명에서 가상 주변 장치는, 그것이 모든 호출을 자신을 통해 물리적 장치들에 리다이렉트(redirect)하고, 잠재적으로 시스템 내에 물리적 장치들이 있는 것보다 더 많거나 또는 더 적은 수의 주변 장치들을 호스트 스택에 알릴 수 있도록, 그것이 주변 초기화 처리에 관여하게 함으로써 인에이블된다.
데이터 전송 중에, 주변 장치들의 팀 내에서의 페일오버 지원을 위하여, 가상 주변 장치는 특정 물리적 장치가 장애를 일으켰는지를 검출할 수 있다. 매체 감지가 상실되었는지를 검출하는 것이나, 또는 고정된 간격 동안 신호가 반복되는 형태로 오프로드된 주변 장치로부터 네트워크 스위치로의 일정한 박동(heartbeat)에 의한 것을 포함하여, 이것을 지원하는 다양한 메커니즘이 있다. 만일 주변 장치가 박동이 상실된 것을 검출하면(예를 들어, 더 이상 신호를 검출하지 못하는 것에 의해), 주변 장치 드라이버는 이 이벤트를 가상 주변 장치에게 시그널링한다.
본 발명에 따르면 가상 주변 장치가 오프로드된 상태 객체들을 복구하여 팀 내의 또 다른 주변 장치에 네트워크 트래픽을 이동시키려고 시도할 수 있다. 가상 주변 장치는, 또 다른 물리적 주변 장치로의 페일오버가 일어나는 동안 호스트 네트워크 스택을 이용하여 스택을 관리함으로써, 또는 새로운 프로토콜 오프로드 요구들을 정지시키고 상태 객체들을 새로운 물리적 주변 장치 자체에 이동시킴으로써, 다양한 방법으로 이를 행할 수 있다.
만일 가상 주변 장치가, 호스트 프로토콜 스택이 이행(transition) 중에 오프로드된 상태 객체들 또는 접속들(TCP의 경우에)을 관리하도록 허용하기로 결정하면, 가상 주변 장치는 호스트 프로토콜 스택에게 그 주변 장치에 대한 접속들을 오프로드하는 것을 중지하고 호스트가 그 주변 장치에 대해 이미 오프로드한 기존의 상태 객체들을 업로드하도록 요구한다. 가상 주변 장치가 오프로드를 다시 허용할 때까지, 호스트는 그것의 중간 소프트웨어 계층들에서의 링크들 또는 접속들을 처리한다.
가상 장치 드라이버는 하나 이상의 주변 장치들의 팀 내의 모든 이용 가능한 주변 장치들에 대해서 알고 있다. 일단 하나의 주변 장치가 장애를 일으키면, 가상 장치 드라이버는 접속들 또는 상태 객체들의 오프로드를 수신할 수 있는 새로운 주변 장치를 선택한다. 가상 장치 드라이버는 새로운 주변 장치가 어떤 자원들을 가질 수 있는지를 검출하고, 그 주변 장치에서 요구되는 임의의 상태를 초기화한다. 일단 주변 장치가 초기화되면, 가상 장치는 상태 객체들의 오프로드를 다시 허용한다.
호스트 스택이 특정한 가상 주변 장치에 대해 오프로드하도록 다시 허용되면, 그것은 가상 주변 장치에게 그것의 오프로드 능력들(capabilities)에 대해 다시 문의한다. 호스트는 새로운 능력들의 리스트를 이용하여 어느 상태 객체들 또는 접속들이 오프로드될 수 있는지를 선택할 것이다. 이로 인해, 통지된 새로운 주변 장치 능력들에 따라서, 반전 트리의 제어를 전송함으로써(즉, 델리게이트된, 캐시된, 및 일정한 상태 변수들을 전송함으로써) 그 가상 주변 장치에 대한 (따라서 새로운 주변 장치에 대한) 접속들을 다시 오프로드하는 결과가 초래된다. 대안적으로, 만일 새로운 물리적 주변 장치가 오프로드를 지원하지 않는다면, 호스트는 접속들을 오프로드하려고 시도하기보다는 단지 중간 소프트웨어 계층들을 통하여 접속들 자체를 처리하는 것을 계속할 것이다.
대안적으로, 가상 주변 장치는 주변 장치들 자체 사이에 오프로드된 상태 객체들의 이행을 관리하기로 결정할 수도 있다. 만일 이것이 행해지면 가상 주변 장치는 여전히 상술한 일련의 이벤트들을 이용하여 오프로드 요구들을 스톨(stall)할 수 있고, 그와 동시에 (오프로드된 상태 객체들을 거꾸로 호스트 프로토콜 스택으로 이동시키기보다는) 그 상태를 직접 이동시키고, 페일오버가 완료될 때 능력들의 임의의 변화를 통지할 수 있다.
비록 특정 상태 객체들 또는 접속들이 오프되더라도, 호스트는 오프로드 능력들이 변할 때 일관된 상태를 유지하기 때문에, 그리고 호스트는 최초 주변 장치의 페일오버의 경우에 새로운 주변 장치와 파라미터들을 다시 교섭할 수 있기 때문에, 본 발명은 주변 장치 장애에 상관없이, 동시에 하나 또는 그 이상의 상태 객체들 또는 접속들을 오프로드하고 업로드하는 새로운 확고한 방법을 제공한다.
만일 가상 주변 장치가 하나 이상의 물리적 주변 장치들 상에서 다수의 가상 LAN들을 지원하도록 구성되면, 그 가상 주변 장치는 다시 물리적 장치 초기화를 가로채고, 대신에 하나 이상의 가상 주변 장치들을 호스트 스택에게 통지하고, 특정한 가상 어댑터에 대해 행해지는 모든 호출들이 적당한 가상 LAN 태그 및 물리적 주변 장치에 확실히 매핑되도록 할 것이다. 오프로드 중에 가상 ID는 최초 오프로드 요구 내에서, 프레이밍 계층 상태 객체에 부가함으로써 또는 가상 주변 장치에 대한 새로운 상태 객체를 생성함으로써 전송된다. 구체적으로, 본 발명은 가상 장치가 블록 리스트 내의 프레이밍 계층 구조 바로 아래 블록 리스트 구조 내에 구조를 삽입하거나, 또는 프레이밍 계층 블록 리스트 상태 객체에 VID를 부가할 수 있게 한다. 전자의 방법은 또한 가상 주변 장치가 물리적 주변 장치에게 불투명 데이터(opaque data)(잠재적으로는 벤더 사유 데이터)를 특정할 수 있게 한다. 접속이 업로드될 때, 만일 오프로드 중에 가상 주변 장치에 의해 부가적인 상태 객체가 부가되면, 가상 주변 장치는 그 구조를 제거하고 블록 리스트의 나머지를 호스트 프로토콜 스택에 전달한다.
본 발명은 또한 기능적 단계들, 및/또는 비기능적 동작들을 포함하는 방법들로써 설명될 수 있다. 다음은 본 발명을 실시하는 데에 있어서 수행될 수 있는 동작들 및 단계들에 대한 설명이다. 통상적으로 기능적 단계들은 성취되는 결과로써 발명을 설명하는데 반하여, 비기능적 동작들은 특정 결과를 성취하기 위한 보다 구체적인 동작들을 설명한다. 비록 기능적 단계들 및 비기능적 동작들은 특정한 순서로 기술되거나 또는 청구될 수 있지만, 본 발명은 반드시 동작들 및/또는 단계들의 어떤 특정한 순서 또는 조합에 한정되지는 않는다.
도 8은 하나 이상의 목적 컴포넌트 장치들과 하나 이상의 소스 컴포넌트 장치들 간에 제어를 전송하기 위한 방법을 구현하기 위한 흐름도이다. 상기 제어는 설정된 네트워크 접속들의 무결성을 여전히 유지하면서 소스 컴포넌트의 처리 부담을 덜기 위하여 복수의 네트워크 접속들을 처리하는 데에 필요한 것이다. 도 8은 본 발명을 실시하기 위한 이 방법이, 동시에 2 이상의 네트워크 접속들의 처리 제어를 전송함으로써 2 이상의 네트워크 접속들을 처리하고 있는 컴퓨터화된 시스템의 처리 요구를 줄이는 단계(800)를 포함하는 것을 보여준다. 이상적으로, 이 단계(800)는 상태 변화, 페일오버 이벤트, 및 VLAN 태그들과 관련하여 상기 2 이상의 네트워크 접속들에 대한 무결성을 보존하는 방식으로 수행되어야 한다.
단계(800)는 블록 리스트를 생성하는 특정 동작(810)을 수행함으로써 성취될 수 있다. 동작(810)은 블록 리스트를 생성하는 것을 포함할 수 있고, 이 블록 리스트는 네트워크 프로토콜 스택을 통한 2 이상의 네트워크 접속 데이터 경로들에 대한 순차적인 소프트웨어 계층들에 대응하는 일련의 블록 포인터들을 포함한다. 예를 들면, 동작(810)은 네트워크 프로토콜 스택을 통하여 상이한 접속 데이터 경로 내의 동일 상태 계층을 지시하거나(예를 들면, 2개의 상이한 이웃 계층(530) 상태들 사이의 포인터(532)), 또는 네트워크 프로토콜 스택을 통하여 동일 접속 데이터 경로(예를 들면, 535) 내의 동일 상태 계층을 지시할 수 있는(예를 들면, TCP(540)와 TCP(545) 사이의 포인터(547)) 다음 블록 포인터를 생성함으로써 수행될 수 있다.
단계(800)는 또한 상태 객체의 일부분의 블록 리스트 및 제어를 목적 컴포넌트에 전송하는 특정 동작(830)을 포함한다. 각 소프트웨어 계층의 상태 객체의 상기 부분은 하나 이상의 델리게이트된(DELEGATED), 캐시된(CACHED), 및 일정한(CONST) 상태 변수들을 포함할 수 있다. 이후 호스트 스택은 각 소프트웨어 계층에게 상기 캐시된, 및 일정한 상태 변수들에 대한 그 소프트웨어 계층의 값들을 주변 컴포넌트(예를 들면, 주변 장치)에 송신하도록 지시하고(예를 들면, 제어 신호(330, 332, 334, 336)를 송신함으로써), 그 계층이 그 계층의 델리게이트된 상태 변수의 제어를 상기 주변 컴포넌트에 전송할 필요가 있을 것임을 지시할 수 있다.
이후 소스 컴포넌트는 침니 오프로드 중에 또는 침니 종료(또는 오프로드 종료) 중에 오프로드 타깃(예를 들면, 오프로드 중의 주변 장치, 업로드 중의 CPU)에 블록 리스트를 제공할 수 있다. 게다가, 상기 오프로드는, 소스 컴포넌트가 그것이 오프로드하거나 또는 업로드하고 있는 오프로드된 소프트웨어 계층들에 대한 적어도 상기 델리게이트된 상태 변수의 제어를 제공할 때까지는 완료되지 않을 것이다. 따라서, 상기 오프로드(또는 업로드)는, 블록 리스트 및 각각의 델리게이트된 상태 변수들을 소스 컴포넌트로부터 목적 컴포넌트로 전송하는(그리고 목적 컴포넌트가 이미 그것들을 가지고 있지 않다면 아마도 캐시된 및 일정한 상태 변수들을) 특정 동작 후에 하나 이상의 반전 트리로부터의 다수의 접속들에 대해 완료된다.
도 8의 방법은 또한, (동작들(810, 820, 및 830)에 의하여) 단계(800)를 수행한 후에, 이 방법이 목적 컴포넌트에 의해 상기 2 이상의 접속들을 처리하는 특정 동작(840)을 수행하는 것을 포함하는 것을 예시한다. 이전의 논의로부터 추측되듯이, 동작(840)은 전송 후에 목적 컴포넌트에 의해 상기 2 이상의 접속들을 처리하되, 여기서, 만일 각 상태 객체 데이터 구조 부분의 블록 리스트 및 제어가 소프트웨어 계층에 전송되면, 중간 소프트웨어 계층들을 통하여 중앙 처리 유닛에서 상기 접속들을 처리하고, 만일 각 상태 객체 부분의 블록 리스트 및 제어가 주변 장치에 전송되면, 그 주변 장치에서 상기 접속을 처리하는 것을 포함한다.
예를 들면, 다수의 접속 업로드의 경우에, 주변 장치는 통상의 네트워크 프로토콜 스택을 통하여 처리되도록 중간 소프트웨어 계층들에 대한 네트워크 처리 제어를 거꾸로 CPU에 전송한다. 그러나, 다수의 네트워크 오프로드의 경우에, CPU는 침니를 통하여 처리되도록 중간 소프트웨어 계층들의 각각의 캐시된, 일정한, 및 델리게이트된 상태들 및 블록 리스트를 주변 장치에 전송함으로써 네트워크 제어를 주변 장치에 전송한다. 본 발명은 장기(long-lived) 및 단기의(short-lived) 접속들 모두에 대해 실시될 수 있다. 특히 단기의 TCP 접속들과 같은 단기의 접속들과 관련하여, CPU는 데이터 전송의 "슬로우-스타트"(slow-start) 단계 중에 각각의 단기의 접속을 오프로드할 수 있다.
설명으로서, 예를 들어, 원격 컴퓨터가 서버와 단기의 HTTP 접속을 행할 때, 서버는 통상적으로 동시에 요청된 데이터 모두를 송신함으로써 원격 컴퓨터의 요구에 응답하지 않는다. 대부분의 경우에, 서버는 접속 대역폭을 평가하기 위하여, 그리고 원격 컴퓨터 또는 경로 중의 임의의 다른 장치들 또는 링크들을 오버플로우(overflow)하는 것을 피하기 위하여 처음에는 데이터를 천천히 전송한다. 이 평가를 행하기 위하여, 서버는 요구된 데이터를 데이터 패킷의 수를 증가시키면서 반복적으로 원격 컴퓨터에 송신할 것이다. 예를 들면, 서버는 500 바이트 패킷을 송신하고, 원격 컴퓨터로부터 확인 응답(acknowledgement)을 기다리고, 그런 다음 2개의 500 바이트 패킷(1000 바이트 패킷)을 송신하고, 원격 컴퓨터로부터 확인 응답을 기다리고, 그런 다음 5개의 500 바이트 패킷을 송신하는 식으로, 서버가 원격 컴퓨터에 대해 최대 데이터 전송 속도에 도달할 때까지 계속한다.
따라서, 만일 원격 컴퓨터가 단지 28.8Kbps(초당 킬로비트) 다이얼업(dial-up) 접속을 갖는다면, 서버는 결국 어느 일정한 속도(초당 데이터 패킷 수)로만 데이터를 전송할 수 있고, 반면에 만일 원격 컴퓨터가 1000 Mbps(초당 100만 단위의 비트) 광대역 접속을 갖는다면, 서버는 결국 훨씬 높은 속도로 데이터를 전송할 수 있다. 이 증분적(incremental) 데이터 송신 속도("슬로우 스타트")는 CPU와 주변 장치 간에 단기의 접속의 제어를 전송하는 데에 필요한 시간보다 일반적으로 더 큰 일정한 동작 지연(time lag)을 제공한다. 따라서, 부분적으로 이 방법이 동시에 다수의 접속을 오프로드하는 것을 제공하기 때문에, "슬로우 스타트" 전송 윈도(transfer window)는 본 발명이 특히 장기 및 단기의 네트워크 접속 모두의 처리 제어를 전송하는 데에 적합하게, 특히 오프로드될 다수의 접속들이 있을 때 적합하게 해준다.
도 9는 복수의 오프로드된 집합 네트워크 링크들을 장애를 일으킨 하나 또는 그 이상의 주변 장치들로부터 상기 복수의 오프로드된 접속들을 수신할 수 있는 또 다른 주변 장치로 전송하고, 그와 동시에 설정된 집합 네트워크 링크들 각각의 무결성을 유지하는 방법을 구현하기 위한 흐름도를 예시한다. 도 9는 목적 컴포넌트 페일오버의 경우에 하나 이상의 집합 네트워크 링크들의 무결성을 동적으로 보존하는 기능적 단계(900)를 수행함으로써 본 발명에 따른 이 실시예를 구현하는 것을 예시한다. 지적된 대로, 이 단계는 장애를 일으키지 않은 하나 이상의 목적 컴포넌트들(즉, 대체 목적 컴포넌트들)에서 상기 하나 이상의 집합 네트워크 링크들이 처리될 수 있도록 수행되어야 한다. 게다가, 단계(900)는 하나 이상의 최초 주변 장치들이 장애를 일으킨 것을 검출하는 특정 동작(910)을 포함한다. 동작(910)은 하나 이상의 집합 네트워크 링크들의 처리 제어를 갖는 하나 이상의 최초 주변 장치들이 장애를 일으킨 것을 검출하는 것을 포함한다.
한정이 아니라 단지 예로서, 네트워크 링크들은 "팀을 이룬 NIC"(teamed NIC) 환경(예를 들면, 802.3ad)에서와 같이 "집합"(aggregated)될 수 있다(즉, 수 개의 주변 장치들에 대한 수 개의 링크들이 하나의 네트워크 링크로서 취급될 수 있다). 본 발명에 따른 호스트 CPU는 중간 소프트웨어 계층들로부터 하나 이상의 최초 주변 장치들로 하나 이상의 블록 리스트 및 하나 이상의 델리게이트된 상태들을 송신함으로써 네트워크 처리 태스크들을 처리하는 것을 팀을 이룬 주변 장치들에 오프로드할 수 있다. 이들 집합 링크들은 상당히 크기 때문에, CPU에게는 접속 무결성이 상당히 중요하다. 따라서, 호스트 CPU는 주변 장치들 중 하나 이상이 오프로드된 네트워크 링크들을 더 이상 처리할 수 없을 때를 검출할 필요가 있을 수 있다.
그렇게 하기 위하여, NIC가 주변 장치인 일 실시예에서는, 링크 상의 네트워크 및 오프로드된 주변 장치로부터 고정된 간격들 동안 신호가 반복되는 형태로 일정한 "펄스"가 있을 수 있다. 이 펄스는, 예를 들면, 집합 링크가 여전히 활동중(active)임을 NIC가 알게 해주는 NIC와 네트워크 장치(예를 들면, 네트워크 라우터) 간의 연속적인 전기 신호의 형태일 수 있다. 따라서, 펄스가 멈추거나, 또는 네트워크 장치가 어떤 종류의 에러 메시지의 형태로 펄스를 송신하거나, 또는 호스트 관리자가 컴포넌트들에게 페일오버할 것을 지시할 경우, 호스트는 NIC가 더 이상 오프로드된 태스크들을 수행할 수 없음을 인지한다.
단계(900)는 또한 중앙 처리 유닛에게 처리 제어를 돌려주는 특정 동작(920)을 포함한다. 동작(920)은 최초 주변 장치로부터 중앙 처리 유닛에게 하나 이상의 집합 네트워크 링크들의 처리 제어를 돌려주는 것을 포함한다. 예를 들면, NIC는, 호스트 CPU가, 에러 또는 장애 신호(예를 들면, 신호들(702, 704, 및 708))에 응답하여, 다수의 네트워크 링크들에 대해 이전에 오프로드된, 델리게이트된 상태 변수들 및 블록 리스트들을 업로드하도록 요구할 수 있다. 이후 NIC는 각각의 델리게이트된 상태 변수들의 제어 및 블록 리스트(들)를 네트워크 프로토콜 스택 내의 중간 소프트웨어 계층들을 통하여 호스트 CPU에 전송해야 한다.
단계(900)는 또한 서로 다른 하나 이상의 대체 주변 장치들의 처리 자원을 검출하는 특정 동작(930)을 포함한다. 동작(930)은 집합 링크들을 수신할 수 있는 하나 이상의 대체 주변 장치들의 자원 능력들을 검출하는 것을 포함한다. 예를 들면, 하나 이상의 상이한 NIC들이 페일오버 NIC들보다 훨씬 많거나 또는 훨씬 적은 능력들을 가질 수 있고, 따라서 그들은 서로 다른 데이터 사이즈 처리 능력들, 또는 보다 저속/보다 고속의 프로세서들 등을 가질 수 있다. 게다가, 접속들은, 소수의 접속들만이 상기 상이한 NIC들에 의해 처리될 수 있거나(즉, 하나 이상의 대체 NIC들은 어떤 보안 파라미터들을 지원하지 않는다), 또는 NIC가 동시에 비교적 적은 수의 접속의 처리만을 핸들링할 수 있는 그러한 성질을 가질 수 있다. 따라서, 본 발명은 하나 이상의 상기 블록 리스트(들), 및 상기 각각의 상태 객체(들)를 조작함으로써 새로운 하나 이상의 NIC들과 파라미터들을 교섭하여, 상기 새로운 하나 이상의 NIC들이 오프로드된 접속들을 효과적으로 받을 수 있게 한다. 일 실시예에서, 페일오버 이벤트들의 검출, 및 전송을 핸들링할 수 있는 새로운 주변 장치들의 검출은 여기서 설명되고, 또한 도 10에서 중간 드라이버로서 설명된 가상 장치에 의해 행해진다. 서로 다른 (새로운) 하나 이상의 NIC들과 파라미터들을 교섭할 수 있는 이 능력은 다수의 접속 오프로드들의 무결절 페일오버(seamless failover) 지원을 가능케 한다.
도 9는 또한 기능적 단계(900) 이후에 하나 이상의 대체 주변 장치들에게 네트워크 링크 처리 제어를 전송하는 특정 동작(940)을 행함으로써 본 발명의 방법을 구현하는 것을 예시한다. 동작(940)은 하나 이상의 집합 네트워크 링크들의 처리 제어를 하나 이상의 대체 주변 장치에 전송하는 것을 포함한다. 예를 들면, 호스트가 하나 이상의 새로운 주변 장치들(예를 들면, NIC들)과 파라미터들을 교섭한 후에, 호스트 스택은 적당한 하나 이상의 중간 소프트웨어 계층들에 대한 각각의 델리게이트된 상태들의 제어 및 각각의 블록 리스트들을 전송할 수 있다. 일단 호스트가 블록 리스트들 및 델리게이트된 상태들을 적당한 하나 이상의 대체 NIC들에 전송하면, 하나 이상의 대체 NIC들은 집합 네트워크 링크들을 처리할 수 있고, 그에 의해 호스트에게서 이들 네트워크 처리 의무를 덜어줄 수 있다.
도 10은 본 발명에 따른 일 실시예를 구현하기 위한 흐름도를 예시하는데, 이 실시예에서 본 발명은, 네트워크 접속 오프로드 및/또는 업로드 처리 중에, 가상 구내 정보 통신망(virtual local area network) 및 802.3ad 페일오버 이벤트 중 적어도 하나를 보다 더 용이하게 하기 위하여 오프로드 데이터 구조에 인접하여 (가상 주변 장치 드라이버와 같은) 중간 드라이버를 삽입하는 방법을 수행한다. 구체적으로 이 흐름도를 참조하면, 본 발명의 실시예는 2 이상의 캐시된 상태 데이터 구조를 검출하는 특정 동작(1000)을 포함한다. 동작(1000)은 네트워크 프로토콜 스택 내의 하나 이상의 중간 소프트웨어 계층들의 2 이상의 상태 객체들과 대응하는 2 이상의 캐시된 상태 데이터 구조를 검출하는 것을 포함한다.
예를 들면, 애플리케이션 계층이, 각 계층의 상태 객체의 범위를 결정하고, 이 계층들이 어떤 처리들(만약 있다면)을 업로드할 필요가 있는지를 결정하기 위하여 네트워크 프로토콜 스택 내의 각 네트워크 계층에 인디케이트 신호(예를 들면, 330, 332, 334)를 송신할 수 있다. 호스트가 주변 장치에게 처리 제어를 허여할 유일한 상태 변수는 캐시된 상태 변수이기 때문에, 애플리케이션 계층은 각 계층에 문의하여 어느 계층이 캐시된 상태 변수를 오프로드할 것인지 확인할 필요가 있을 것이다. 다중 접속의 경우에, 네트워크 프로토콜 스택의 동일 중간 소프트웨어에서 적어도 2개의 캐시된 상태 변수가 검출될 것이다.
도 10에 도시된 본 발명의 방법은 또한 2 이상의 캐시된 상태들을 침니 스택으로 편성하는 특정 동작(1010)을 포함한다. 동작(1010)은 상기 2 이상의 캐시된 상태 데이터 구조들을 순차적으로 하나의 침니 스택 데이터 구조로 편성하는 것을 포함하고, 여기서 상기 침니 스택 데이터 구조를 주변 장치로 오프로드함으로써 그 주변 장치에게 상기 2 이상의 캐시된 상태 데이터 구조에 대한 처리 제어가 제공된다. 예를 들면, 소프트웨어 계층들이 그들의 캐시된 상태 변수들을 지시(indicate)한 후에, 호스트 처리는 그 캐시된 상태들을 정확한 처리 순서로 NIC에 읽어들인다. 단일 네트워크 링크의 경우에, 소프트웨어 계층들에 대한 이 일련의 상태들은 여기서 설명된 반전 트리의 단일 분기(single branch)로서 나타날 수 있다(예를 들면, 도 4a 참조). 다중 네트워크 링크들의 경우에, 수 개의 다음 및 종속 블록 포인터들을 편성하는 블록 리스트와 결합된 일련의 캐시된 상태들은 데이터 구조 블록들의 반전 트리로서 나타날 수 있다(예를 들면, 도 5b 참조). 어쨌든, 침니는 NIC에 오프로드되는 단일 데이터 구조를 포함한다. 명칭에 의해 암시되는 바와 같이 침니 데이터 구조는 데이터가 단지 단일 데이터 인터페이스에서 들어가고, 다른 단일 인터페이스에서 나오고, 마치 연기가 물리적 침니를 통해 이동하는 것과 같이, 그것이 처리되는(또는 이동하는) 동안 다른 오퍼레이터들과의 외부 상호 작용을 갖지 않는다는 의미에서 물리적 침니(physical chimney)와 다소 유사하다.
게다가, 도 10에 예시된 방법은 침니 스택을 포함하는 오프로드 데이터 구조를 생성하는 특정 동작(1020)을 더 포함한다. 예를 들면, 침니 데이터 구조(예를 들면, 308)는 부가적으로 침니 드라이버 데이터 구조, 하나 이상의 네트워크 드라이버 인터페이스 사양(NDIS : Network Driver Interface Specification) 데이터 구조, 및 미니포트 드라이버 데이터 구조와 결합될 수 있다. 이 데이터 구조들의 전체 세트는 복합 오프로드 데이터 구조로서 결합될 수 있다.
도 10에 예시된 본 발명의 방법은 또한 오프로드 데이터 구조 내에 중간 드라이버를 삽입하는 특정 동작(1030)을 포함한다. 예를 들면, 다중 또는 집합 링크들 사이에 보다 특정한 요구들을 핸들링하기 위해 오프로드 데이터 구조 내에 중간 드라이버가 삽입될 필요가 있다. 중간 드라이버는 오프로드의 개시 시에 호스트 스택에 의해 생성될 수 있다. 802.3ad 집합 링크들의 경우에, 중간 드라이버(IM 드라이버)는 2 이상의 "팀을 이룬" NIC들 사이에 자원 및 접속들을 조정하기 위해 오프로드 구조 내에 삽입될 수 있다. 대안적으로, 단일 NIC, 또는 범용 CPU와 같은 단일 주변 장치를 나타내기 위해 다수의 중간 드라이버들이 생성된 다음, 오프로드 데이터 구조 내에 삽입될 수도 있다. 가상 구내 정보 통신망들(VLAN들)의 경우에, 하나 이상의 IM 드라이버들이 착신되는 데이터 패킷들에 부가된 VLAN 태그들을 번역할 필요가 있을 수 있다.
설명으로서, 네트워크 관리자는 조직의 특정 그룹들만이 서로의 문서들을 보기를 원할 수 있다(비록 모두가 동일 네트워크 상에 있다고 하더라도). VLAN들은 특정 가상 네트워크들의 멤버들만이 서로의 컴퓨터 데이터에 액세스할 수 있도록 태깅 데이터에 의해 이를 수용하는 것을 돕는다. 즉, 동일 네트워크 상에서, 관리자는 "리서치" VLAN의 멤버들이 "마케팅" VLAN 상의 멤버의 컴퓨터들을 볼 수 없도록 수 개의 VLAN들을 편성할 수 있다. 오프로드 스택이 VLAN 데이터 태그들을 해독할 수 없을 수 있으므로 VLAN들은 다수의 장기 또는 단기의 접속들을 오프로드하는 것에 대해 특별한 복잡한 문제를 야기할 수 있다. 이것은 착신되는 데이터 패킷이 네트워크 접속을 처리하기 전후에 해독되어야 하는 다수의 VLAN 태그들을 포함할 수 있다는 점에 일부 기인할 수 있다.
따라서, 본 발명에 따르면, 2 이상의 VLAN 태그들을 포함하는 데이터 패킷을 역다중화하고, 그 데이터 트래픽을 적절하게 처리할 수 있는 하나 이상의 중간 드라이버들(다수의 주변 장치들에 기초한 단일 중간 드라이버이든, 또는 단일 주변 장치들에 기초한 다수의 중간 드라이버이든)을 오프로드 데이터 구조 내에 삽입하게 된다.
그러나, 당업자라면 본 출원 및 특허청구범위를 고려하여, 상기 하나 이상의 중간 드라이버들은, IPSEC 프로토콜을 통하여 데이터 트래픽을 확보하는 것과 같이, 네트워크 계층에 의해 할당된 기능들을 핸들링할 수도 있다는 것을 알 것이다. 이것은 VLAN 태그들을 할당하는 프레이밍 계층 기능들에 더해질 수 있다. 예를 들면, 중간 드라이버는 데이터 패킷 상에 인증 헤더를 부가하거나, 그 데이터 패킷을 캡슐화(encapsulating)하거나, 또는 양쪽 모두를 행하는 기능들을 수행할 수 있다. 이것은 프레이밍 계층을 통하여 할당된 임의의 부가적인 VLAN 태그 관리에 상관없이 또는 그것에 더하여 행해질 수 있다. 따라서, 본 발명은 안전한 링크를 요구하는 환경을 포함하여, 다양한 환경에서 실시될 수 있는 데이터 구조들 및 드라이버들을 제공한다.
도 11 및 이하의 논의는 본 발명이 구현될 수 있는 적당한 컴퓨팅 환경에 대한 간결하고 일반적인 설명을 제공하기 위한 것이다. 요구 사항은 아니지만, 본 발명은 네트워크 환경에서 컴퓨터들에 의해 실행되는 프로그램 모듈들과 같은 컴퓨터 실행 가능 명령들의 일반적 맥락에서 설명될 것이다. 일반적으로, 프로그램 모듈들은 특정 태스크를 수행하거나 또는 특정 추상 데이터 유형들(abstract data types)을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 데이터 구조 등을 포함한다. 컴퓨터 실행 가능 명령들, 관련 데이터 구조 및 프로그램 모듈들은 여기에 개시된 방법들의 단계들을 실행하기 위한 프로그램 코드 수단의 예들을 나타낸다. 특정 시퀀스의 그러한 실행 가능 명령들 또는 관련 데이터 구조들은 그러한 단계들에서 기술된 기능들을 구현하기 위한 대응 동작들의 예들을 나타낸다.
당업자라면 본 발명이 퍼스널 컴퓨터, 핸드 헬드 장치, 멀티프로세서 시스템, 마이크로프로세서 기반 또는 프로그램 가능한 소비자 전자 기기, 네트워크 PC들, 미니컴퓨터, 메인프레임 컴퓨터 등을 포함하는, 여러 유형의 컴퓨터 시스템 구성들을 갖는 네트워크 컴퓨팅 환경들에서 실시될 수 있다는 것을 알 것이다. 본 발명은 또한 로컬 및 원격 프로세싱 장치들이 태스크를 수행하고 통신 네트워크를 통하여 링크되는{유선(hardwired) 링크나, 무선(wireless) 링크, 또는 유선 또는 무선 링크들의 조합에 의해} 분산 컴퓨팅 환경에서 실시될 수도 있다. 분산 컴퓨팅 환경에서는, 프로그램 모듈들이 로컬 및 원격 메모리 기억 장치들 양쪽 모두에 위치할 수 있다.
도 11을 참조하면, 본 발명을 구현하기 위한 예시적인 시스템은, 프로세싱 유닛(1121), 시스템 메모리(1122), 및 이 시스템 메모리(1122)를 포함한 각종 시스템 컴포넌트들을 프로세싱 유닛(1121)에 결합하는 시스템 버스(1123)를 포함하는 종래의 컴퓨터(1120) 형태의 범용 컴퓨팅 장치를 포함한다. 시스템 버스(1123)는 메모리 버스 또는 메모리 제어기, 주변 버스, 및 각종 버스 아키텍처 중 어느 하나를 이용한 로컬 버스를 포함하는 몇몇 유형의 버스 구조들 중 어느 하나일 수 있다. 시스템 메모리는 판독 전용 메모리(ROM)(1124) 및 랜덤 액세스 메모리(RAM)(1125)를 포함한다. 시동(start-up) 중과 같이, 컴퓨터 내의 소자들 간에 정보를 전송하는 것을 돕는 기본 루틴들을 포함하는 기본 입출력 시스템(BIOS)(1126)이 ROM(1124)에 저장될 수 있다.
컴퓨터(1120)는 또한 자기 하드 디스크(1139)로부터 판독하고 거기에 기록하기 위한 자기 하드 디스크 드라이브(1127), 탈착 가능한 자기 디스크(1129)로부터 판독하거나 거기에 기록하기 위한 자기 디스크 드라이브(1128), 및 CD ROM 또는 다른 광학 매체와 같은 탈착 가능한 광 디스크(1131)로부터 판독하거나 거기에 기록하기 위한 광 디스크 드라이브(1130)를 포함한다. 자기 하드 디스크 드라이브(1127), 자기 디스크 드라이브(1128), 및 광 디스크 드라이브(1130)는 각각 하드 디스크 드라이브 인터페이스(1132), 자기 디스크 드라이브 인터페이스(1133), 및 광학 드라이브 인터페이스(1134)에 의해 시스템 버스(1123)에 접속된다. 이 드라이브들과 그들의 관련 컴퓨터 판독 가능 매체는 컴퓨터 판독 가능 명령, 데이터 구조, 프로그램 모듈 및 컴퓨터(1120)용의 다른 데이터의 불휘발성 기억 장소를 제공한다. 여기서 설명된 예시적 환경은 자기 하드 디스크(1139), 탈착 가능한 자기 디스크(1129), 및 탈착 가능한 광 디스크(1131)를 채용하지만, 자기 카세트, 플래시 메모리 카드, 디지털 비디오 디스크, 베르누이 카트리지, RAM, ROM 등을 포함하여, 데이터를 저장하기 위한 다른 유형의 컴퓨터 판독 매체가 사용될 수 있다.
하드 디스크(1139), 자기 디스크(1129), 광 디스크(1131), ROM(1124) 또는 RAM(1125) 상에는, 오퍼레이팅 시스템(1135), 하나 이상의 애플리케이션 프로그램(1136), 다른 프로그램 모듈들(1137), 및 프로그램 데이터(1138)를 포함하여, 하나 이상의 프로그램 모듈들을 포함하는 프로그램 코드 수단이 저장될 수 있다. 사용자는 키보드(1140), 포인팅 장치(1142), 또는 마이크, 조이스틱, 게임 패드, 위성 접시형 안테나(satellite dish), 스캐너 등과 같은 다른 입력 장치들(도시되지 않음)을 통하여 컴퓨터(1120)에 커맨드 및 정보를 입력할 수 있다. 이들 및 다른 입력 장치들은 흔히 시스템 버스(1123)에 결합된 인터페이스(1146)를 통하여 프로세싱 유닛(1121)에 접속된다. 대안적으로, 이 입력 장치들은 병렬 포트, 게임 포트 또는 유니버설 시리얼 버스(USB)와 같은 다른 인터페이스들에 의해 접속될 수도 있다. 모니터(1147) 또는 또 다른 디스플레이 장치도 비디오 어댑터(1148)와 같은 인터페이스를 통하여 시스템 버스(1123)에 접속된다. 모니터 이외에, 퍼스널 컴퓨터들은 일반적으로 스피커 및 프린터와 같은 다른 주변 출력 장치들(도시되지 않음)을 포함한다.
컴퓨터(1120)는 원격 컴퓨터들(1149a 및 1149b)과 같은 하나 이상의 원격 컴퓨터들에의 논리적 접속을 이용하는 네트워크 환경(networked environment)에서 동작할 수도 있다. 원격 컴퓨터들(1149a 및 1149b)은 각각 또 다른 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 장치(peer device) 또는 다른 공통 네트워크 노드일 수 있고, 도 11에는 단지 메모리 기억 장치들(1150a 및 1150b) 및 그들의 관련 애플리케이션 프로그램들(1136a 및 1136b)만이 예시되어 있지만, 일반적으로 컴퓨터(1120)와 관련하여 상술한 소자들 중의 다수 또는 전부를 포함한다. 도 11에 도시된 논리적 접속은, 여기서 한정이 아니라 예로서 제시되어 있는, 구내 정보 통신망(LAN)(1151) 및 광역 통신망(WAN)(1152)을 포함한다. 그러한 네트워킹 환경들은 사무실 전체적(office-wise), 또는 기업 전체적(enterprise-wise) 컴퓨터 네트워크, 인트라넷 및 인터넷에서 흔한 것이다.
LAN 네트워킹 환경에서 사용될 때, 컴퓨터(1120)는 네트워크 인터페이스 또는 어댑터(1153)를 통하여 구내 정보 통신망(1151)에 접속된다. WAN 네트워킹 환경에서 사용될 때, 컴퓨터(1120)는 모뎀(1154), 무선 링크, 또는 인터넷과 같은 광역 통신망(1152)을 통하여 통신을 설정하기 위한 다른 수단을 포함할 수 있다. 내장형 또는 외장형일 수 있는 모뎀(1154)은 직렬 포트 인터페이스(1146)를 통하여 시스템 버스(1123)에 접속된다. 네트워크 환경에서, 컴퓨터(1120)와 관련하여 도시된 프로그램 모듈들, 또는 그것들의 일부는, 원격 메모리 기억 장치에 저장될 수 있다. 도시된 네트워크 접속들은 예시적인 것이고 광역 네트워크(1152)를 통하여 통신을 설정하는 다른 수단이 사용될 수도 있다.
본 발명은 그 정신 또는 본질적 특징을 벗어나지 않고 다른 특정 형태들로 구현될 수 있다. 설명된 실시예들은 모든 점에서 한정적인 것이 아니라 단지 예시적인 것으로서 간주되어야 할 것이다. 그러므로, 본 발명의 범위는 전술한 설명에 의해서가 아니라 첨부된 특허청구범위에 의해 나타내어진다. 특허청구범위의 균등물의 의미 및 범위 내에 드는 모든 변경들은 본 발명의 범위 내에 포함되어야 한다.
본 발명은 호스트 프로세서와 주변 장치 프로세서 사이에서 다수의 네트워크 접속 또는 상태 객체를 신뢰성 있게 오프로딩 또는 업로딩하는 방법을 제공한다.
도 1은 본 발명에 따른 네트워크 스택 및 교대 경로의 기능 계층들을 나타내는 블록도.
도 2는 본 발명에 따른 NDIS 경로 및 바이패스 경로의 기능 계층들을 나타내는 블록도.
도 3은 본 발명에 따른 오프로드 메커니즘을 나타내는 래더 다이아그램(ladder diagram).
도 4a 내지 도 4d는 중간 소프트웨어 계층 상태 객체들에 관한 본 발명에 따른 반전 트리를 나타내는 객체 다이아그램(object diagrams).
도 5a 내지 도 5b는 블록 포인터들의 집합에 관한 본 발명에 따른 반전 트리를 나타내는 블록도.
도 6은 본 발명에 따른 상태 객체의 캐시된 상태 부분을 갱신하기 위한 네트워크 프로토콜 스택 내의 중간 소프트웨어 계층들 간의 가능한 신호 시퀀스를 나타내는 도면.
도 7은 주변 장치가 오프로드된 TCP 접속의 종료를 요구하는 네트워크 프로토콜 스택 내의 중간 소프트웨어 계층들 간의 본 발명에 따른 가능한 신호 시퀀스를 나타내는 도면.
도 8은 소스 컴포넌트에서 목적 컴포넌트로 다수의 네트워크 접속의 프로세서 제어를 전송하기 위한 흐름도.
도 9는 실패한 주변 장치에서 호스트 스택으로, 그리고 하나 이상의 교대 목적 주변 장치로 다수의 네트워크 접속의 제어를 전송하기 위한 흐름도.
도 10은 오프로드 데이터 구조 내에 중간 드라이버 데이터 구조를 삽입하기 위한 흐름도.
도 11은 본 발명에 따른 특징들을 구현할 수 있는 적절한 컴퓨팅 시스템을 도시한 도면.
<도면의 주요 부분에 대한 부호의 설명>
100, 200 : 애플리케이션
108 : 스위치
106 : 인터페이스 계층
104 : 주변 장치
206 : TLI 스위치
201 : 전송 계층
202 : 네트워크 계층
203 : 프레이밍 계층
210 : NDIS 미니드라이버
212 : 침니 드라이버
214 : 하드웨어

Claims (53)

  1. 스위칭 계층, 및 네트워크 프로토콜 스택의 일련의 하나 이상의 중간 소프트웨어 계층들 - 이 중간 소프트웨어 계층들 각각은 상태 객체를 가짐 - 을 포함하는 컴퓨터화된 시스템에서, 하나 이상의 목적 컴포넌트 장치들과 하나 이상의 소스 컴포넌트 장치들 간에, 설정된 네트워크 통신의 무결성(integrity)을 여전히 유지하면서 복수의 상태 객체들을 처리하기 위해 필요한 제어를 전송하는 방법으로서,
    오프로드 데이터 구조를 생성하는 동작 - 상기 오프로드 데이터 구조는 복수의 상태 객체들의 계층 구조를 포함하고, 상기 복수의 상태 객체들은 하나 이상의 중간 소프트웨어 계층들에 대한 네트워크 프로토콜 상태에 대응함 - 과;
    소스 컴포넌트 장치로부터 목적 컴포넌트 장치로 상기 오프로드 데이터 구조의 동일 중간 소프트웨어 계층 내의 2 이상의 상태 객체들을 전송하는 동작과;
    상기 전송 후에 상기 목적 컴포넌트가 동일 프로토콜 계층에서 상기 2 이상의 상태 객체들을 처리하는 동작
    을 포함하는 방법.
  2. 제1항에 있어서, 상기 목적 컴포넌트 및 소스 컴포넌트 중 하나가 주변 장치인 방법.
  3. 제2항에 있어서, 상기 2 이상의 상태 객체들 중 적어도 하나가 캐시된 상태 변수(cached state variable)인 방법.
  4. 제2항에 있어서, 상기 오프로드 데이터 구조는 적어도 상기 네트워크 프로토콜 스택을 통하여 상이한 접속 경로의 동일 중간 소프트웨어 계층을 가리키는 다음 블록 포인터(next block pointer), 및 상기 네트워크 프로토콜 스택을 통하여 동일 접속 경로의 상이한 계층을 가리키는 종속 블록 포인터(dependent block pointer)를 갖는 블록 리스트를 포함하는 방법.
  5. 제2항에 있어서, 상기 오프로드 데이터 구조 및 각 소프트웨어 계층에 대한 상태 객체의 부분을 전송하는 동작은 TCP 접속의 슬로우-스타트 단계(slow-start phase) 중에 수행되는 방법.
  6. 제2항에 있어서, 상기 오프로드 데이터 구조 내에 중간 드라이버 데이터 구조를 삽입하는 동작을 더 포함하고, 상기 중간 드라이버는 착신 및 발신(incoming and outgoing) 데이터 패킷들을 적절하게 해독(deciphering) 및 캡슐화(encapsulating)할 수 있고, 상기 발신 데이터 패킷들은 하나 이상의 가상 구내 정보 통신망 식별자들(virtual local area network identifiers)과 함께 패키징되고, 착신 패킷들로부터 하나 이상의 가상 구내 정보 통신망 식별자들이 제거되는 방법.
  7. 제6항에 있어서, 상기 중간 드라이버는 데이터 패킷에 대해 인증 헤더를 부가 및 제거하는 것과, 상기 데이터 패킷을 적절하게 암호화 및 해독하는 것 중 하나 이상을 수행함으로써 IPSEC 프로토콜을 이용하여 하나 이상의 네트워크 링크들 상의 네트워크 트래픽을 확보할 수 있는 방법.
  8. 제2항에 있어서,
    상기 주변 장치가 하나 이상의 중간 소프트웨어 계층에 대한 하나 이상의 핸들들을 생성하는 동작 - 상기 주변 장치는 상기 하나 이상의 핸들들을 하나 이상의 대응하는 호스트 프로토콜 스택 계층들에 전송함 - 과;
    상기 중간 소프트웨어 계층들 중 적어도 하나가 캐시된 상태(cached state)를 변경할 경우, 상기 중간 소프트웨어 계층들 중 상기 적어도 하나가 상기 주변 장치의 상기 캐시된 상태를 갱신하는 동작
    을 더 포함하는 방법.
  9. 제2항에 있어서, 페일오버 이벤트가 발생하고,
    하나 이상의 대응하는 주변 장치들에서 처리되고 있는 하나 이상의 링크들이 장애를 일으킨 것을 검출하는 동작 - 상기 하나 이상의 장애를 일으킨 주변 장치들에는 하나 이상의 오프로드 데이터 구조 및 하나 이상의 상태 객체의 프로세서 제어가 부여되어 있음 - 과;
    상기 하나 이상의 오프로드 데이터 구조 및 상기 하나 이상의 상태 객체의 제어를 수신함으로써 상기 하나 이상의 링크들의 처리 제어를 핸들링할 수 있는 상이한 하나 이상의 주변 장치들을 검출하는 동작
    을 더 포함하는 방법.
  10. 제9항에 있어서, 상기 하나 이상의 장애를 일으킨 주변 장치들로부터 상기 하나 이상의 오프로드 데이터 구조 및 상기 하나 이상의 상태 객체의 처리 제어를 상기 소스 컴포넌트에 전송함으로써, 상기 하나 이상의 링크들의 처리 제어를 상기 하나 이상의 장애를 일으킨 주변 장치들로부터 상기 소스 컴포넌트로 업로드하는 동작을 더 포함하는 방법.
  11. 제10항에 있어서, 상기 상이한 하나 이상의 주변 장치들의 처리 자원을 검출하는 동작과; 상기 하나 이상의 링크들이 상기 장애를 일으킨 하나 이상의 주변 장치들이 아닌 상기 상이한 하나 이상의 주변 장치들에서 처리될 수 있도록, 상기 하나 이상의 장애를 일으킨 주변 장치들로부터 업로드된 상기 하나 이상의 상태 객체들을 상기 상이한 하나 이상의 주변 장치들의 상기 검출된 자원과 일치하도록 조정하는 동작을 더 포함하는 방법.
  12. 제11항에 있어서, 상기 하나 이상의 링크들은 집합(aggregated) 802.3ad 링크들인 방법.
  13. 제9항에 있어서,
    상기 상이한 하나 이상의 주변 장치들의 처리 자원을 검출하는 동작과;
    상기 검출된 처리 자원에 기초하여 상기 하나 이상의 오프로드된 상태 객체들 중 하나가 상기 상이한 하나 이상의 주변 장치들에 의해 처리될 수 있는 경우, 상기 하나 이상의 오프로드된 상태 객체들 중 상기 하나의 처리 제어를 상기 상이한 하나 이상의 주변 장치들에 전송하는 동작과;
    상기 검출된 처리 자원에 기초하여 상기 하나 이상의 오프로드된 상태 객체들이 상기 상이한 하나 이상의 주변 장치들에 의해 처리될 수 없는 경우, 상기 하나 이상의 오프로드된 상태 객체들 중 하나의 처리 제어를 상기 호스트 프로토콜 스택에 전송하는 동작
    을 더 포함하는 방법.
  14. 제13항에 있어서, 상기 하나 이상의 링크들은 집합 802.3ad 링크들인 방법.
  15. 스위칭 계층, 및 네트워크 프로토콜 스택의 일련의 하나 이상의 중간 소프트웨어 계층들 - 이 중간 소프트웨어 계층들 각각은 상태 객체를 가짐 - 을 포함하는 컴퓨터화된 시스템에서, 하나 이상의 목적 컴포넌트 장치들과 하나 이상의 소스 컴포넌트 장치들 간에, 설정된 네트워크 통신의 무결성을 여전히 유지하면서 복수의 상태 객체들을 처리하기 위해 필요한 제어를 전송하는 방법으로서,
    동일 중간 소프트웨어 계층에 대응하는 2 이상의 상태 객체들을 처리하는 컴퓨터화된 시스템의 처리 수요(processing demands)를, 상태 변화, 페일오버 이벤트, 및 VLAN 태그와 관련하여 네트워크 통신의 무결성을 보존하는 방법으로 상기 2 이상의 상태 객체들의 처리 제어를 전송함으로써, 감소시키는 단계와;
    상기 전송 후에 상기 목적 컴포넌트가 동일 프로토콜 계층에서 상기 2 이상의 상태 객체들을 처리하는 동작
    을 포함하는 방법.
  16. 제15항에 있어서, 상기 전송하는 단계는,
    오프로드 데이터 구조를 생성하는 동작 - 상기 오프로드 데이터 구조는 복수의 상태 객체들의 계층 구조를 포함하고, 상기 복수의 상태 객체들은 하나 이상의 중간 소프트웨어 계층들에 대한 네트워크 프로토콜 상태에 대응함 - 과;
    소스 컴포넌트 장치로부터 목적 컴포넌트 장치로 상기 오프로드 데이터 구조의 동일 중간 소프트웨어 계층 내의 2 이상의 상태 객체들을 전송하는 동작을 포함하는 방법.
  17. 제16항에 있어서, 상기 목적 컴포넌트가 상기 2 이상의 상태 객체들을 네트워크 통신 무결성을 잃지 않으면서 의도한 대로 여전히 처리할 수 있도록, 상기 상태 객체가 변경되는 경우에 또는 상기 오프로드 데이터 구조가 변경되는 경우에 상기 목적 컴포넌트를 갱신하는 단계를 더 포함하는 방법.
  18. 제17항에 있어서, 상기 목적 컴포넌트를 갱신하는 단계는,
    상기 주변 장치가 하나 이상의 중간 소프트웨어 계층에 대한 하나 이상의 핸들들을 생성하는 동작 - 상기 주변 장치는 상기 하나 이상의 핸들들을 하나 이상의 대응하는 호스트 프로토콜 스택 계층들에 전송함 - 과;
    상기 중간 소프트웨어 계층들 중 적어도 하나가 캐시된 상태를 변경할 경우, 상기 중간 소프트웨어 계층들 중 상기 적어도 하나가 상기 주변 장치의 상기 캐시된 상태를 갱신하는 동작을 포함하는 방법.
  19. 제15항에 있어서, 상기 하나 이상의 집합 네트워크 링크들이 상이한 하나 이상의 주변 장치들에서 적절하게 처리될 수 있도록, 페일오버 이벤트가 발생하는 경우에 네트워크 통신의 무결성을 동적으로 보존하는 단계를 더 포함하는 방법.
  20. 제19항에 있어서, 상기 2 이상의 네트워크 링크들의 무결성을 동적으로 보존하는 단계는,
    하나 이상의 대응하는 주변 장치들에서 처리되고 있는 하나 이상의 링크들이 장애를 일으킨 것을 검출하는 동작 - 상기 하나 이상의 장애를 일으킨 주변 장치들에는 하나 이상의 오프로드 데이터 구조 및 하나 이상의 상태 객체의 프로세서 제어가 부여되어 있음 - 과;
    상기 하나 이상의 오프로드 데이터 구조 및 상기 하나 이상의 상태 객체의 제어를 수신함으로써 상기 하나 이상의 링크들의 처리 제어를 핸들링할 수 있는 상이한 하나 이상의 주변 장치들을 검출하는 동작과;
    상기 상이한 하나 이상의 주변 장치들의 처리 자원을 검출하는 동작과;
    상기 검출된 처리 자원에 기초하여 상기 하나 이상의 오프로드된 상태 객체들 중 하나가 상기 상이한 하나 이상의 주변 장치들에 의해 처리될 수 있는 경우, 상기 하나 이상의 오프로드된 상태 객체들 중 상기 하나의 처리 제어를 상기 상이한 하나 이상의 주변 장치들에 전송하는 동작과;
    상기 검출된 처리 자원에 기초하여 상기 하나 이상의 오프로드된 상태 객체들이 상기 상이한 하나 이상의 주변 장치들에 의해 처리될 수 없는 경우, 상기 하나 이상의 오프로드된 상태 객체들 중 하나의 처리 제어를 상기 호스트 프로토콜 스택에 전송하는 동작
    을 포함하는 방법.
  21. 스위칭 계층, 및 네트워크 프로토콜 스택의 일련의 하나 이상의 중간 소프트웨어 계층들 - 이 중간 소프트웨어 계층들 각각은 상태 객체를 가짐 - 을 포함하는 컴퓨터화된 시스템에서, 하나 이상의 목적 컴포넌트 장치들과 하나 이상의 소스 컴포넌트 장치들 간에, 설정된 네트워크 통신의 무결성을 여전히 유지하면서 복수의 상태 객체들을 처리하기 위해 필요한 제어를 전송하는 방법으로서,
    오프로드 데이터 구조를 생성하는 동작 - 상기 오프로드 데이터 구조는 복수의 단기의(short-lived) 네트워크 접속을 포함함 - 과;
    소스 컴포넌트 장치로부터 목적 컴포넌트 장치로 상기 오프로드 데이터 구조의 동일 중간 소프트웨어 계층 내의 2 이상의 단기의 네트워크 접속들을 전송하는 동작과;
    상기 전송 후에 상기 목적 컴포넌트가 상기 2 이상의 단기의 네트워크 접속들을 처리하는 동작
    을 포함하는 방법.
  22. 제21항에 있어서, 상기 목적 컴포넌트 및 소스 컴포넌트 중 하나가 주변 장치인 방법.
  23. 제22항에 있어서, 상태 객체는 캐시된(cached) 상태 변수, 및 하나 이상의 일정한(constant) 상태 변수, 및 델리게이트된(delegated) 상태 변수를 포함하는 방법.
  24. 제22항에 있어서, 상기 오프로드 데이터 구조는 적어도 상기 네트워크 프로토콜 스택을 통하여 상이한 접속 경로의 동일 중간 소프트웨어 계층을 가리키는 다음 블록 포인터, 및 상기 네트워크 프로토콜 스택을 통하여 동일 접속 경로의 상이한 계층을 가리키는 종속 블록 포인터를 갖는 블록 리스트를 포함하는 방법.
  25. 제22항에 있어서, 상기 2 이상의 단기의 접속들을 전송하는 동작은 TCP 접속의 슬로우-스타트 단계 중에 수행되는 방법.
  26. 제22항에 있어서, 상기 오프로드 데이터 구조 내에 중간 드라이버 데이터 구조를 삽입하는 동작을 더 포함하고, 상기 중간 드라이버는 착신 및 발신 데이터 패킷들을 적절하게 해독 및 캡슐화할 수 있고, 상기 발신 데이터 패킷들은 하나 이상의 가상 구내 정보 통신망 식별자들과 함께 패키징되고, 착신 패킷들로부터 하나 이상의 가상 구내 정보 통신망 식별자들이 제거되는 방법.
  27. 제26항에 있어서, 상기 중간 드라이버는 데이터 패킷에 대해 인증 헤더를 부가 및 제거하는 것과, 상기 데이터 패킷을 적절하게 암호화 및 해독하는 것 중 하나 이상을 수행함으로써 IPSEC 프로토콜을 이용하여 하나 이상의 네트워크 링크들 상의 네트워크 트래픽을 확보할 수 있는 방법.
  28. 제22항에 있어서,
    상기 중간 소프트웨어 계층들의 각 계층에 대한 핸들을 생성하는 동작 - 상기 주변 장치는 각 중간 소프트웨어 계층에 대한 상기 핸들을 각 중간 소프트웨어 계층에 전송함 - 과;
    상기 중간 소프트웨어 계층들 중 적어도 하나가 캐시된 상태를 변경할 경우, 상기 중간 소프트웨어 계층들 중 상기 적어도 하나가 상기 주변 장치의 상기 캐시된 상태를 갱신하는 동작
    을 더 포함하는 방법.
  29. 제22항에 있어서,
    하나 이상의 대응하는 주변 장치들에서 처리되고 있는 하나 이상의 링크들이 장애를 일으킨 것을 검출하는 동작 - 상기 하나 이상의 장애를 일으킨 주변 장치들에는 상기 2 이상의 단기의 네트워크 접속들의 프로세서 제어가 부여되어 있음 - 과;
    상기 2 이상의 단기의 네트워크 접속들을 수신함으로써 상기 하나 이상의 링크들의 처리 제어를 핸들링할 수 있는 상이한 하나 이상의 주변 장치들을 검출하는 동작
    을 더 포함하는 방법.
  30. 제29항에 있어서, 상기 하나 이상의 장애를 일으킨 주변 장치들로부터 상기 하나 이상의 오프로드 데이터 구조 및 상기 하나 이상의 상태 객체의 처리 제어를 상기 소스 컴포넌트에 전송함으로써, 상기 하나 이상의 링크들의 처리 제어를 상기 하나 이상의 장애를 일으킨 주변 장치들로부터 상기 소스 컴포넌트로 업로드하는 동작을 더 포함하는 방법.
  31. 제30항에 있어서, 상기 상이한 하나 이상의 주변 장치들의 처리 자원을 검출하고; 상기 하나 이상의 링크들이 상기 장애를 일으킨 하나 이상의 주변 장치들이 아닌 상기 상이한 하나 이상의 주변 장치들에서 처리될 수 있도록, 상기 하나 이상의 장애를 일으킨 주변 장치들로부터 업로드된 상기 하나 이상의 상태 객체들을 상기 상이한 하나 이상의 주변 장치들의 상기 검출된 자원과 일치하도록 조정하는 동작을 더 포함하는 방법.
  32. 제31항에 있어서, 상기 하나 이상의 링크들은 집합 802.3ad 링크들인 방법.
  33. 제29항에 있어서,
    상기 상이한 하나 이상의 주변 장치들의 처리 자원을 검출하는 동작과;
    상기 검출된 처리 자원에 기초하여 상기 하나 이상의 오프로드된 상태 객체들 중 하나가 상기 상이한 하나 이상의 주변 장치들에 의해 처리될 수 있는 경우, 상기 하나 이상의 오프로드된 상태 객체들 중 상기 하나의 처리 제어를 상기 상이한 하나 이상의 주변 장치들에 전송하는 동작과;
    상기 검출된 처리 자원에 기초하여 상기 하나 이상의 오프로드된 상태 객체들이 상기 상이한 하나 이상의 주변 장치들에 의해 처리될 수 없는 경우, 상기 하나 이상의 오프로드된 상태 객체들 중 하나의 처리 제어를 상기 호스트 프로토콜 스택에 전송하는 동작
    을 더 포함하는 방법.
  34. 제33항에 있어서, 상기 하나 이상의 링크들은 집합 802.3ad 링크들인 방법.
  35. 중앙 처리 유닛, 복수의 주변 장치들, 스위칭 계층, 및 일련의 하나 이상의 중간 소프트웨어 계층들을 포함하는 컴퓨터화된 시스템에서, 복수의 오프로드된 집합 상태 객체들을, 상기 주변 장치들 중 장애를 일으킨 하나 이상의 주변 장치로부터 상기 복수의 오프로드된 상태 객체들 중의 하나 이상의 상태 객체들을 수신할 수 있는 또 다른 주변 장치로 전송하면서, 각각의 설정된 네트워크 통신의 무결성을 여전히 유지하는 방법으로서,
    하나 이상의 주변 장치들에서 처리되고 있는 하나 이상의 링크들이 장애를 일으킨 것을 검출하는 동작 - 상기 하나 이상의 장애를 일으킨 주변 장치들에는 하나 이상의 상태 객체의 처리 제어가 부여되어 있음 - 과;
    상기 하나 이상의 링크들만의 처리 제어를 핸들링할 수 있는 상이한 하나 이상의 주변 장치들을 검출하는 동작과;
    상기 하나 이상의 링크들 및 하나 이상의 상태 객체들의 처리 제어를 수신할 수 있는 상이한 하나 이상의 주변 장치들을 검출하는 동작과;
    상기 검출된 하나 이상의 주변 장치들 중 임의의 것의 처리 자원을 검출하는 동작
    을 포함하는 방법.
  36. 제35항에 있어서,
    상기 검출된 처리 자원에 기초하여 상기 상이한 하나 이상의 주변 장치들이 상기 하나 이상의 링크들만의 처리 제어를 핸들링할 수 있는 경우, 상기 하나 이상의 링크들만의 처리 제어를 상기 상이한 하나 이상의 주변 장치들에 전송하는 동작과;
    상기 검출된 처리 자원에 기초하여 상기 상이한 하나 이상의 주변 장치들이 상기 하나 이상의 링크들 및 하나 이상의 상태 객체들의 처리 제어를 핸들링할 수 있는 경우, 상기 하나 이상의 링크들 및 하나 이상의 오프로드된 상태 객체들의 처리 제어를 상기 상이한 하나 이상의 주변 장치에 전송하는 동작과;
    상기 하나 이상의 링크들 중 남아 있는 임의의 것과 상기 하나 이상의 오프로드된 상태 객체들 중 남아 있는 임의의 것의 처리 제어를 상기 호스트 프로토콜 스택에 전송하는 동작
    을 더 포함하는 방법.
  37. 제36항에 있어서, 상기 오프로드된 상태 객체들 중 하나 이상은 적어도 캐시된 상태 변수를 포함하는 방법.
  38. 제36항에 있어서, 상기 하나 이상의 링크들은 집합 802.3ad 링크들인 방법.
  39. 제36항에 있어서, 상기 하나 이상의 링크들 및 상기 하나 이상의 오프로드된 상태 객체들의 처리 제어를 전송하는 동작에 앞서, 상기 오프로드된 상태 객체들을 포함하는 데이터 구조에 인접하여 중간 드라이버를 삽입하는 동작을 더 포함하고, 상기 중간 드라이버는, 하나 이상의 VLAN 태그들을 다중화(multiplex)하는 것과, 하나 이상의 VLAN 태그들을 역다중화(de-multiplex)하는 것과, 하나 이상의 주변 장치들을 통하여 네트워크 상태 객체 트래픽을 인도(direct)하는 것과, IPSEC 프로토콜을 이용하여 네트워크 데이터 패킷들을 확보하는 것 중 적어도 하나를 수행할 수 있는 방법.
  40. 호스트 처리 유닛, 하나 이상의 주변 장치들, 스위칭 계층, 및 일련의 하나 이상의 중간 소프트웨어 계층들 - 이들 중 적어도 일부는 상태 객체를 가짐 - 을 포함하는 컴퓨터화된 시스템에서, 네트워크 접속 오프로드 및/또는 업로드 처리 중에, 가상 구내 정보 통신망을 보다 더 용이하게 하기 위하여 오프로드 데이터 구조에 인접하여 중간 드라이버를 삽입하는 방법으로서,
    오프로드 데이터 구조를 생성하는 동작 - 이 오프로드 데이터 구조는 복수의 상태 객체들의 계층 구조를 포함하고, 상기 복수의 상태 객체들은 하나 이상의 중간 소프트웨어 계층들에 대한 네트워크 프로토콜 상태에 대응함 - 과;
    상기 오프로드 데이터 구조 내에 하나 이상의 중간 드라이버 데이터 구조들을 삽입하는 동작과;
    소스 컴포넌트 장치로부터 하나 이상의 주변 장치들로 상기 오프로드 데이터 구조의 대응하는 중간 소프트웨어 계층의 하나 이상의 상태 객체들을 전송하는 동작
    을 포함하는 방법.
  41. 제40항에 있어서, 페일오버 이벤트가 발생하고, 상기 하나 이상의 중간 드라이버 데이터 구조들 중 적어도 하나와 대응하는 중간 드라이버가,
    상기 하나 이상의 링크들만의 처리 제어를 핸들링할 수 있는 상이한 하나 이상의 주변 장치들을 검출하는 동작과;
    상기 하나 이상의 링크들 및 하나 이상의 상태 객체들의 처리 제어를 수신할 수 있는 상이한 하나 이상의 주변 장치들을 검출하는 동작과;
    상기 검출된 하나 이상의 주변 장치들 중 임의의 것의 처리 자원을 검출하는 동작
    을 포함하는 방법을 수행하는 방법.
  42. 제40항에 있어서, 상기 하나 이상의 중간 드라이버 데이터 구조들은, 상기 오프로드 데이터 구조의 처리 제어를 상기 하나 이상의 주변 장치들에 오프로드하기에 앞서, 상기 오프로드 데이터 구조 내에 삽입되는 방법.
  43. 제40항에 있어서, 상기 하나 이상의 중간 드라이버 데이터 구조들은, 상기 하나 이상의 주변 장치들에 대한 상기 오프로드 데이터 구조의 오프로드 요구를 개시하는 시점에 삽입되는 방법.
  44. 제43항에 있어서, 상기 하나 이상의 중간 드라이버들 중 적어도 하나는, 서브데이터 패킷(sub-data packet)과 관련된 가상 LAN 태그에 기초한 VLAN 어드레스에 상기 서브데이터 패킷을 인도하는 동작을 수행하는 명령들을 포함하고, 상기 명령들은,
    다중화된 데이터 패킷을 수신하는 동작과;
    상기 데이터 패킷을 하나 이상의 서브데이터 패킷들로 역다중화하는 동작과;
    데이터 패킷을 다중화하는 동작과;
    다중화된 데이터 패킷을 송신하는 동작
    중 적어도 하나를 더 포함하는 방법.
  45. 제40항에 있어서, 상기 오프로드 데이터 구조는 동일 중간 소프트웨어 계층에 대응하는 2 이상의 상태 객체들과 대응하고, 상기 2 이상의 상태 객체들은 네트워크 프로토콜 스택의 하위 소프트웨어 계층에 있는 단일 상태 객체를 가리키고, 상기 오프로드 데이터 구조는 반전 트리(inverted tree)의 외관을 갖는 방법.
  46. 제45항에 있어서, 전체 반전 트리 오프로드 데이터 구조의 처리 제어를 상기 하나 이상의 주변 장치들 중의 하나 이상에 전송하는 동작을 더 포함하는 방법.
  47. 제46항에 있어서, 상기 반전 트리 오프로드 데이터 구조의 상태 객체들 중 하나 이상의 처리 제어를 상기 하나 이상의 주변 장치들 중 적어도 하나로부터 호스트 프로토콜 스택으로 전송하는 동작을 더 포함하는 방법.
  48. 제47항에 있어서, 소스 컴포넌트 장치로부터 하나 이상의 주변 장치들로 하나 이상의 상태 객체들을 전송하는 동작은, 상기 하나 이상의 주변 장치들 중 상기 적어도 하나가 장애를 일으킨 것을 검출하는 동작에 응답하여 발생하는 방법.
  49. 제48항에 있어서, 상기 하나 이상의 중간 드라이버 데이터 구조들 중 적어도 하나와 대응하는 중간 드라이버가,
    상기 하나 이상의 링크들만의 처리 제어를 핸들링할 수 있는 상이한 하나 이상의 주변 장치들을 검출하는 동작과;
    상기 하나 이상의 링크들 및 하나 이상의 상태 객체들의 처리 제어를 수신할 수 있는 상이한 하나 이상의 주변 장치들을 검출하는 동작과;
    상기 검출된 하나 이상의 주변 장치들 중 임의의 것의 처리 자원을 검출하는 동작과;
    상기 검출된 처리 자원에 기초하여 상기 상이한 하나 이상의 주변 장치들이 상기 하나 이상의 링크들만의 처리 제어를 핸들링할 수 있는 경우, 상기 하나 이상의 링크들만의 처리 제어를 상기 상이한 하나 이상의 주변 장치들에 전송하는 동작과;
    상기 검출된 처리 자원에 기초하여 상기 상이한 하나 이상의 주변 장치들이 상기 하나 이상의 링크들 및 하나 이상의 상태 객체들의 처리 제어를 핸들링할 수 있는 경우, 상기 하나 이상의 링크들 및 상기 하나 이상의 오프로드된 상태 객체들의 처리 제어를 상기 상이한 하나 이상의 주변 장치에 전송하는 동작과;
    상기 하나 이상의 링크들 중 남아 있는 임의의 것과 상기 하나 이상의 오프로드된 상태 객체들 중 남아 있는 임의의 것의 처리 제어를 상기 호스트 프로토콜 스택에 전송하는 동작을 포함하는 방법을 수행하는 방법.
  50. 스위칭 계층, 및 네트워크 프로토콜 스택의 일련의 하나 이상의 중간 소프트웨어 계층들 - 이 중간 소프트웨어 계층들 각각은 상태 객체를 가짐 - 을 포함하는 컴퓨터화된 시스템에서 사용하기 위한 컴퓨터 프로그램 제품으로서, 하나 이상의 목적 컴포넌트 장치들과 하나 이상의 소스 컴포넌트 장치들 간에, 설정된 네트워크 통신의 무결성을 여전히 유지하면서 복수의 상태 객체들을 처리하기 위해 필요한 제어를 전송하는 방법을 구현하기 위한 것이고, 호스트 컴퓨팅 시스템에서 하나 이상의 프로세서에 의해 실행될 때, 상기 호스팅 컴퓨터로 하여금 상기 방법을 수행하게 하는 컴퓨터 실행 가능 명령들이 저장되어 있는 하나 이상의 컴퓨터 판독 가능 매체를 포함하는 컴퓨터 프로그램 제품에 있어서,
    상기 방법은,
    오프로드 데이터 구조를 생성하는 동작 - 상기 오프로드 데이터 구조는 복수의 상태 객체들의 계층 구조를 포함하고, 상기 복수의 상태 객체들은 하나 이상의 중간 소프트웨어 계층들에 대한 네트워크 프로토콜 상태에 대응함 - 과;
    소스 컴포넌트 장치로부터 목적 컴포넌트 장치로 상기 오프로드 데이터 구조의 동일 중간 소프트웨어 계층 내의 2 이상의 상태 객체들을 전송하는 동작과;
    상기 전송 후에 상기 목적 컴포넌트가 동일 프로토콜 계층에서 상기 2 이상의 상태 객체들을 처리하는 동작을 포함하는 컴퓨터 프로그램 제품.
  51. 제50항에 있어서, 상기 컴퓨터 실행 가능 명령들은 상기 하나 이상의 프로세서들에 의해 실행될 때 컴퓨터화된 시스템으로 하여금,
    상기 중간 소프트웨어 계층들의 각 계층에 대한 핸들을 생성하는 동작 - 상기 목적 컴포넌트는 NIC이고, 이 NIC는 각 중간 소프트웨어 계층에 대한 상기 핸들을 각 중간 소프트웨어 계층에 전송함 - 과;
    상기 중간 소프트웨어 계층들 중 적어도 하나가 캐시된 상태를 변경할 경우, 상기 중간 소프트웨어 계층들 중 상기 적어도 하나가 상기 NIC의 상기 캐시된 상태를 갱신하는 동작을 더 수행하게 하는 컴퓨터 프로그램 제품.
  52. 제50항에 있어서, 상기 컴퓨터 실행 가능 명령들은, 상기 하나 이상의 프로세서들에 의해 실행될 때, 컴퓨터화된 시스템으로 하여금,
    하나 이상의 대응하는 주변 장치들에서 처리되고 있는 하나 이상의 링크들이 장애를 일으킨 것을 검출하는 동작 - 상기 하나 이상의 장애를 일으킨 주변 장치들에는 하나 이상의 오프로드 데이터 구조 및 하나 이상의 상태 객체의 프로세서 제어가 부여되어 있음 - 과;
    상기 하나 이상의 오프로드 데이터 구조 및 상기 하나 이상의 상태 객체의 제어를 수신함으로써 상기 하나 이상의 링크들의 처리 제어를 핸들링할 수 있는 상이한 하나 이상의 주변 장치들을 검출하는 동작을 더 수행하게 하는 컴퓨터 프로그램 제품.
  53. 제52항에 있어서, 상기 컴퓨터 실행 가능 명령들은, 상기 하나 이상의 프로세서들에 의해 실행될 때, 상기 컴퓨터화된 시스템으로 하여금,
    상기 상이한 하나 이상의 주변 장치들의 처리 자원을 검출하는 동작과;
    상기 검출된 처리 자원에 기초하여 상기 하나 이상의 오프로드된 상태 객체들 중 하나가 상기 상이한 하나 이상의 주변 장치들에 의해 처리될 수 있는 경우, 상기 하나 이상의 오프로드된 상태 객체들 중 상기 하나의 처리 제어를 상기 상이한 하나 이상의 주변 장치들에 전송하는 동작과;
    상기 검출된 처리 자원에 기초하여 상기 하나 이상의 오프로드된 상태 객체들이 상기 상이한 하나 이상의 주변 장치들에 의해 처리될 수 없는 경우, 상기 하나 이상의 오프로드된 상태 객체들 중 하나의 처리 제어를 상기 호스트 프로토콜 스택에 전송하는 동작을 더 수행하게 하는 컴퓨터 프로그램 제품.
KR1020040072017A 2003-09-10 2004-09-09 페일오버 이벤트를 지원하는 네트워크 상태 객체의 다중오프로드용 방법 및 컴퓨터 프로그램 제품 KR101067394B1 (ko)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US50215603P 2003-09-10 2003-09-10
US60/502,156 2003-09-10
US10/666,086 US7526577B2 (en) 2003-09-19 2003-09-19 Multiple offload of network state objects with support for failover events
US10/666,086 2003-09-19

Publications (2)

Publication Number Publication Date
KR20050026881A true KR20050026881A (ko) 2005-03-16
KR101067394B1 KR101067394B1 (ko) 2011-09-27

Family

ID=34139069

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020040072017A KR101067394B1 (ko) 2003-09-10 2004-09-09 페일오버 이벤트를 지원하는 네트워크 상태 객체의 다중오프로드용 방법 및 컴퓨터 프로그램 제품

Country Status (5)

Country Link
EP (1) EP1515511B1 (ko)
JP (1) JP4658546B2 (ko)
KR (1) KR101067394B1 (ko)
CN (1) CN1595935B (ko)
AT (1) ATE528897T1 (ko)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7783880B2 (en) * 2004-11-12 2010-08-24 Microsoft Corporation Method and apparatus for secure internet protocol (IPSEC) offloading with integrated host protocol stack management
US20060165084A1 (en) * 2005-01-21 2006-07-27 International Business Machines Corporation RNIC-BASED OFFLOAD OF iSCSI DATA MOVEMENT FUNCTION BY TARGET
US7693044B2 (en) 2005-12-15 2010-04-06 Nvidia Corporation Single logical network interface for advanced load balancing and fail-over functionality
US8572288B2 (en) 2005-12-15 2013-10-29 Nvidia Corporation Single logical network interface for advanced load balancing and fail-over functionality
US7983150B2 (en) * 2006-01-18 2011-07-19 Corrigent Systems Ltd. VPLS failure protection in ring networks
JP4872412B2 (ja) * 2006-03-31 2012-02-08 日本電気株式会社 情報検知処理方法及び装置
US7715321B2 (en) * 2007-01-30 2010-05-11 International Business Machines Corporation Network interface card transmission control protocol acceleration offload failure detection and recovery mechanism
US8432788B2 (en) * 2007-05-18 2013-04-30 Nvidia Corporation Intelligent failback in a load-balanced networking environment
JP4964683B2 (ja) * 2007-06-18 2012-07-04 株式会社リコー 通信装置およびプログラム
US8774213B2 (en) 2011-03-30 2014-07-08 Amazon Technologies, Inc. Frameworks and interfaces for offload device-based packet processing
CN104054067B (zh) * 2011-03-30 2017-09-08 亚马逊技术公司 基于减负装置的数据包处理的框架和接口
US9678791B2 (en) 2012-02-14 2017-06-13 International Business Machines Corporation Shared resources in a docked mobile environment
CA2912941C (en) * 2013-06-13 2022-06-21 Tsx Inc. Apparatus and method for failover of device interconnect using remote memory access with segmented queue
CN106572147B (zh) * 2016-09-29 2020-02-14 深圳市科创思科技有限公司 一种通过连接表远程维护设备的方法及系统
CN110830283B (zh) * 2018-08-10 2021-10-15 华为技术有限公司 故障检测方法、装置、设备和系统

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5802258A (en) * 1996-05-03 1998-09-01 International Business Machines Corporation Loosely coupled system environment designed to handle a non-disruptive host connection switch after detection of an error condition or during a host outage or failure
US6687758B2 (en) * 2001-03-07 2004-02-03 Alacritech, Inc. Port aggregation for network connections that are offloaded to network interface devices
US6389479B1 (en) * 1997-10-14 2002-05-14 Alacritech, Inc. Intelligent network interface device and system for accelerated communication
US6427171B1 (en) * 1997-10-14 2002-07-30 Alacritech, Inc. Protocol processing stack for use with intelligent network interface device
US6904519B2 (en) * 1998-06-12 2005-06-07 Microsoft Corporation Method and computer program product for offloading processing tasks from software to hardware
US6141705A (en) * 1998-06-12 2000-10-31 Microsoft Corporation System for querying a peripheral device to determine its processing capabilities and then offloading specific processing tasks from a host to the peripheral device when needed
JP2000312244A (ja) * 1999-04-27 2000-11-07 Nippon Telegr & Teleph Corp <Ntt> ネットワークインタフェース切替方法およびその装置、その記録媒体
CN1173269C (zh) * 2001-02-01 2004-10-27 英业达股份有限公司 用于卸载的监控方法
CN1197018C (zh) * 2001-03-01 2005-04-13 中兴通讯股份有限公司 一种实现双系统槽的装置和方法
JP2005503699A (ja) * 2001-08-31 2005-02-03 アダプテック・インコーポレイテッド コンピュータネットワークでホストベースのセキュリティを行うシステムおよび方法
US20030046330A1 (en) 2001-09-04 2003-03-06 Hayes John W. Selective offloading of protocol processing
US20030105977A1 (en) * 2001-12-05 2003-06-05 International Business Machines Corporation Offload processing for secure data transfer
US7007103B2 (en) * 2002-04-30 2006-02-28 Microsoft Corporation Method to offload a network stack

Also Published As

Publication number Publication date
JP4658546B2 (ja) 2011-03-23
ATE528897T1 (de) 2011-10-15
KR101067394B1 (ko) 2011-09-27
CN1595935A (zh) 2005-03-16
EP1515511A3 (en) 2005-04-27
EP1515511A2 (en) 2005-03-16
EP1515511B1 (en) 2011-10-12
CN1595935B (zh) 2012-04-25
JP2005085284A (ja) 2005-03-31

Similar Documents

Publication Publication Date Title
US7526577B2 (en) Multiple offload of network state objects with support for failover events
JP5025941B2 (ja) 統合ホストプロトコルスタック管理を使用するセキュアなインターネットプロトコル(ipsec)オフロードのための方法および装置
Maltz et al. TCP Splice for application layer proxy performance
KR100938519B1 (ko) 네트워크 스택으로 오프로딩된 네트워크 스택 연결을 동기화 및 업로딩하는 방법, 공유 방법, 제어 방법, 및 컴퓨터 판독가능 매체
JP5442755B2 (ja) リモートデスクトッププロトコルのためのハードウェアアクセラレーション
Spatscheck et al. Optimizing TCP forwarder performance
US7007103B2 (en) Method to offload a network stack
US6687758B2 (en) Port aggregation for network connections that are offloaded to network interface devices
KR101067394B1 (ko) 페일오버 이벤트를 지원하는 네트워크 상태 객체의 다중오프로드용 방법 및 컴퓨터 프로그램 제품
AU2007320794B2 (en) Selective session interception method
Dakhane et al. UDP-Based Multi-Stream Communication Protocol

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
LAPS Lapse due to unpaid annual fee