KR101201187B1 - 통합된 호스트 프로토콜 관리를 이용한 보안 인터넷 프로토콜 (ｉｐｓｅｃ) 오프로드를 위한 방법 및 시스템 - Google Patents

Abstract

본 발명은, 호스트 CPU 및 NIC 내의 프로세서와 같은, 컴퓨터화된 시스템의 타겟 프로세싱 장치와 호스트 간의 안전한 IPSec SA 함수(secure Internet Protocol security association function)의 프로세서 제어를 전송하기 위한 메커니즘을 제공한다. 본 발명의 일 양상에서, 호스트가 SA 함수들이 오프로드, 업로드, 무효화 및 리키(re-key)될 때의 제어를 유지하는 동안, 인증 및/또는 암호화에 관련된 연산이 오프로드된다. 장치는 SA 만료에 대한 관대한 및 엄격한 제한 모두에 대한 지원을 포함하는 SA에 대한 메트릭을 유지하도록 조정된다. 타이머 요건은 타겟을 위해 최소화된다. 오프로드된 SA 함수는 네트워크 스택의 중간 소프트웨어 계층의 다른 오프로드된 상태 객체 내에 임베딩될 수 있다.

리키, 인증, 암호화, 타겟, 스택

Description

통합된 호스트 프로토콜 관리를 이용한 보안 인터넷 프로토콜 (ＩＰＳＥＣ) 오프로드를 위한 방법 및 시스템{METHOD AND APPARATUS FOR SECURE INTERNET PROTOCOL (IPSEC) OFFLOADING WITH INTEGRATED HOST PROTOCOL STACK MANAGEMENT}

도 1은 본 발명에 따른 특징들을 구현할 수 있는 적절한 컴퓨팅 시스템.

도 2a는 본 발명에 따른 IP 보안 교대 경로(IP security alternate path) 및 네트워크 스택의 기능 계층들을 설명하는 블록도.

도 2b는 본 발명에 따른 다른 오프로드 침니(offload chimney)에 내장되는 IP 보안 교대 경로를 갖는 네트워크 스택의 기능 계층들을 설명하는 블록도.

도 3a는 본 발명에 따른 IP 보안 바이패스 경로(IP security bypass path) 및 네트워크 스택의 기능 계층들을 설명하는 블록도.

도 3b는 본 발명에 따른 또 다른 오프로드 침니에 내장되는 IP 보안 바이패스 경로를 갖는 NDIS 경로의 기능 계층들을 설명하는 블록도.

도 4는 본 발명의 교시에 따른 오프로드 메커니즘을 설명하는 사다리 다이어그램(ladder diagram).

도 5a 내지 5d는 중간 소프트웨어 계층 상태 객체들(intermediate software layer state objects)에 대하여 역 트리(inverted tree)를 설명하는 객체 다이어그램.

도 6a 내지 6b는 블록 포인터들의 집합(collection of block pointers)에 대하여 본 발명에 따른 역 트리를 설명하는 블록도.

도 7은 본 발명의 교시에 따라 상태 객체의 캐시된 상태 부분을 갱신하기 위하여 네트워크 프로토콜 스택의 중간 소프트웨어 계층들 간의 가능한 신호 시퀀스를 도시하는 도면.

도 8은 네트워크 프로토콜 스택의 중간 소프트웨어 계층들 간의 가능한 신호 시퀀스를 나타내는 도면 - 여기서 주변 장치는 오프로드된 TCP 접속의 종료(termination)를 요청함 - .

도 9는 본 발명에 따른 IP 보안 경로 및 다른 바이패스 경로들과 네트워크 스택의 기능 계층들을 설명하는 블록도.

도 10은 도 9의 IP 보안 경로의 데이터 전송 모드들(data transfer modes)을 설명하는 블록도.

도 11은 블록 포인터들의 집합에 대하여 본 발명에 따른 IP 보안 연관들(IP security associations)을 갖는 역 트리를 설명하는 블록도.

도 12는 블록 포인터들의 집합에 대하여 본 발명에 따른 IP 보안 연관들을 갖는 역 트리를 설명하는 블록도.

도 13은 본 발명의 교시에 따른 IP 보안 블록 오프로드 메커니즘을 설명하는 사다리 다이어그램.

도 14a 내지 14b는 네트워크 프로토콜 스택의 중간 소프트웨어 계층들 간의 가능한 신호 시퀀스를 설명하는 다이어그램 - 여기서, 주변 장치는 오프로드된 IP 보안 연관들의 종료를 요청함 - .

도 15는 오프로드 IP 보안 구조 내의 보안 연관들을 리키(re-keying)하기 위한 이벤트들의 시퀀스를 설명하는 사다리 다이어그램.

도 16은 IP 보안 오프로드의 보안 위협 모델(security threat model)을 설명하는 블록도.

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

110 컴퓨터

120 프로세싱 유닛

121 시스템 버스

130 시스템 메모리

140,150 인터페이스

[문헌 1] 미국 특허 가출원 제60/627,395호 (2004년 11월 12일)

본 발명은 일반적으로 컴퓨터 네트워킹 기술에 관한 것이다. 보다 구체적으로는, 본 발명은 일반적으로 네트워크 컴퓨팅 작업(tasks)의 오프로드(offload)를 최적화하기 위한 메커니즘에 관한 것이다.

운영 시스템(operating systems), 애플리케이션 소프트웨어, 네트워킹 기술 등의 복잡화 및 정교화가 엄청난 속도로 계속되고 있고, 이로써 컴퓨터 기능이 증가하게 되었다. 증가된 기능은 종종 CPU(Central Processor Unit)의 로드의 증가(이하, "CPU 오버헤드"(CPU overhead"라 함)를 초래하였는데, 이는 증가된 기능을 구현하기 위하여 CPU에 의하여 수행되어야 하는 의무(duites)가 증가하기 때문이다.

CPU 오버헤드의 증가가 이미 명백한 분야 중 하나는, 고대역폭 매체(high bandwidth media)의 증가로 인해 네트워크 속도가 증가하고 있는 네트워크된 애플리케이션(networked applications) 분야이다. 네트워크 속도는 CPU 프로세서 및 호스트 컴퓨터에서의 로컬 메모리에의 액세스 속도에도 필적할 수 있다. 이러한 네트워크된 애플리케이션은 7-계층 Open System Interconnect(OSI) 모델 또는 윈도우 운영 시스템에 의해 사용되는 계층화된 모델(layered model) 등의 대부분의 운영 시스템에 의해 사용되는 계층화된 아키텍쳐로 인해 호스트 프로세서에 부담을 더 가중시킨다.

널리 알려진 바와 같이, 이러한 모델은 네트워크로의 물리적 접속과 최종 사용자(end-user) 애플리케이션 사이의 데이터의 흐름을 나타내기 위하여 사용된다. 데이터 비트를 네트워크 케이블에 부가하는 것과 같은 가장 기본적인 기능은 하부 계층(bottom layers)에서 수행되는 반면, 애플리케이션의 디테일(details)을 취급하는 기능은 상부 계층(top layers)에서 수행된다. 근본적으로, 각 계층의 목적은, 상위 계층을 서비스가 실제로 어떻게 구현되는지에 관한 디테일로부터 실드(shield)하면서, 다음의 상위 계층에 서비스를 제공하는 것이다. 각 계층이 다른 컴퓨터의 동일한 계층와 통신하고 있다고 믿도록 하는 방식으로 계층은 추출(abstract)된다.

데이터 패킷으로 수행되는 다양한 기능은 계층들 사이에서 진행되면 소프트웨어 집약적(software intensive)이므로, 따라서 종종 상당한 양의 CPU 프로세서 및 메모리 자원을 요구한다. 예를 들어, 다양한 계층에서 패킷으로 수행되는 패킷 체크섬 계산 및 검증, 메시지 다이제스트(digest) 계산, 서비스 공격의 거부를 보호하기 위한 패킷 필터링, 및 UDP(User Datagram Protocol) 패킷 프레그먼트화(fragmentation)와 같은 기능은 지나치게 CPU 집약적이다. 이러한 기능들 각각이 수행되면 결과적인 CPU의 요구는 전체 컴퓨터 시스템의 처리량(throughput) 및 성능에 크게 영향을 미칠 수 있다.

온라인 판매(on-line sales) 및 재택근무 이용이 증가함에 따라, 데이터 전송의 보안이 더욱 중요해지고 있다. 이는 데이터 패킷으로 수행되기 위한 추가적인 보안 기능을 요구한다. 이러한 보안 기능은 다른 통신 네트워크를 거쳐 데이터를 전송하는 동안 데이터의 프라이버시를 보증하고, 데이터 패킷이 인증된 최종 호스트(end host), 애플리케이션, 또는 사용자로부터 오고 있는지 보증하고, 다른 통신 네트워크를 거치는 동안 데이터가 수정되지 않았음을 보증하는 것을 포함한다. 이 애플리케이션을 위해, 하나 이상의 프라이버시, 인증 또는 데이터 무결정(integrity)의 임의의 조합이 엔드-투-엔드(end-to-end)로 가정될 수 있는 안전한 데이터 전송이 정의된다. 데이터 네트워크를 통한 안전한 데이터 전송을 용이하게 하기 위하여 몇몇 표준이 개발되었다. 이러한 표준은, 원격 시스템(remote system)에 있어서 메시지 교환 및 계산을 통해 안전한 세션(session)을 설정하기 위한 방법을 제공하며, 이로써 다른 통신 네트워크를 통해 전송되는 민감한 데이터가 안전하고 간섭으로부터 자유롭도록(tamper free 또는 untampered) 유지되게 한다. 예를 들어, IPSec(Internet security protocol)은, 안전한 호스트-투-호스트 파이프(host-to-host pipes), 사용자 레벨 보안, 애플리케이션 레벨 보안, 접속 레벨 보안 및 인터넷을 통한 가상 프라이빗 네트워크를 설정하기 위하여 사용될 수 있다. IPSec은 암호의 부호화(encryption) 및 인증(authentication)을 위한 사양의 세트를 정의한다. IPSec은 또한 애플리케이션 간에 설정되는 안전한 세션을 위한 키를 설정하기 위한 Internet Key Exchange("IKE")를 포함하는 키 교환(key exchange)을 위한 여러 알고리즘을 지원한다. 데이터의 부호화 및 복호화(예를 들어, SSL 부호화 및 IP Security 암호화)는 CPU 집약적이다. 예를 들어, TCP 전송 프로세싱을 위해서는 전송되는 데이터의 바이트 당 대략 2 사이클이 소요되는 것으로 현재는 추정된다. IPSec 인증을 위하여, CPU 오버헤드는 가변적이지만, 상당한 수로서 바이트 당 대략 15 사이클이다. 암호화를 위해서는, CPU 오버헤드는 바이트 당 약 25 사이클에서 약 145 사이클 사이에 달한다.

상술한 수로부터 안전한 세션을 설정하기 위한 작업을 수행하는 것이 CPU 집약적임을 알 수 있다. 이러한 모든 작업을 수행하는 호스트 프로세서는 이러한 작업을 위하여 자원이 소비되기 때문에 시스템 성능에 있어서 문제를 초래할 수 있다. 시스템 성능의 저하는, 네트워크 엘리먼트(예를 들어, 라우팅, 스위칭, 서빙, 네트워크된 스토리지의 관리 등)의 기능에 따라 다양한 방식으로 네트워크 및 사용 자에게 영향을 끼친다.

CPU 자원에 대한 요구가 커짐에 따라 네트워크 인터페이스 카드(NICs) 등의 컴퓨터 하드웨어 주변기기의 성능 및 처리량도 증가한다. 이러한 주변기기는 종종 CPU에 의하여 수행되는 많은 작업 및 기능을 수행할 수 있는 전용 프로세서 및 메모리를 구비한다.

코프로세서(coprocessors)는 호스트 컴퓨터로부터의 일부 작업을 오프로드(offload)하기 위하여 개발되었다. 어떤 코프로세서는 호스트 프로세서를 위한 특정 기본 작업을 수행하기 위하여 개발되었다. 그러나, 작업이 특정된 코프로세서의 추가는 안전한 세선 설정을 위한 작업의 많은 양을 호스트 프로세서로부터 오프로드하지는 않는다. 다른 대안은 시스템에 복수의 코프로세서를 추가하고, 각 프로세서가 서로 다른 작업을 수행하게 하는 것이다. 이러한 대안은 물리적 제약(예를 들어, 컴퓨터에서 카드가 접속되는 슬롯의 수)에 의하여 제한되고, 호스트 프로세서와 복수의 코프로세서 간의 다중 통신이라는 문제를 야기한다.

안전한 세션을 설정하기 위하여 요구되는 하나 이상의 작업을 수행하기 위한 다른 프로세서가 개발되었다. 이러한 예로서, 프로세서가 암호화 동작(즉, 부호화 및 복호화), 키 생성 동작, 해시(hash) 동작을 수행할 수 있다고 가정한다. 안전한 세션을 설정하기 위한 요청을 서버가 수신하면, 서버는 프로세서로 하여금 클라이언트로부터 수신한 프리-마스터(pre-master) 시크리트(secret)를 복호화하도록 명령한다. 마시터 시크리트 및 키 자료(material)를 생성하기 위하여, 호스트 프로세서는 프로세서로 대략 20회의 호출(calls)을 생성하여야 한다(각 해쉬 동작마 다 한 번). 이 예에서 설명한 바와 같이, 복수의 작업을 수행할 수 있는 프로세서는 호스트 프로세서와 코프로세서 간의 다중 통신에 의한 자원 소비 문제를 해결하지 못한다.

따라서, 본 기술분야에 있어서, 프로세서로부터 주변 장치와 같은 프로세서로 IPSec 기능의 오프로드과 관련된 오버헤드를 감소시킬 필요성이 있다. 특히, 개개의 접속에 대한 프로세싱 요구를 동시에 유지하는 동안 IPSec 기능을 오프로드하는 해결책이 요구된다.

본 발명은, IPSec 인증 및/또는 복호화와 관련하여 패킷 생성을 포함한 연산(computation)을 신뢰성 있게 오프로드 및 업로드하는 방법을 제공함으로써, 본 기술분야의 종래기술에 있어서의 상술한 하나 이상의 문제점을 해결한다.

본 발명의 전술한 이점들 및 다른 이점들과 특징들이 얻어질 수 있는 방식을 설명하기 위해서, 간략하게 전술한 본 발명의 더 특정한 설명이, 첨부된 도면에서 설명되는 특정 실시예를 참고하여 주어진다. 이들 도면은 단지 본 발명의 전형적인 실시예만을 설명하는 것이지 본 발명의 범위를 제한하는 것으로 간주되지 않아야 한다는 것을 이해하면서, 본 발명은 첨부된 도면을 사용하여 추가적인 간략성 및 상세정보로 개시되고 설명될 것이다.

네트워크 스택(stack)에 있어서, 2 이상의 IPSec 보안 연관(association)은 하나 이상의 동일한 중간 소프트웨어 계층을 통하여 전송될 수 있다. 각 소트프웨 어 계층은 상태 객체(state object)를 구비하는데, 이는 하나 이상의 일정 상태 변수(constant state variable), 캐시된(cached) 상태 변수, 및 위임(delegated) 상태 변수를 포함할 수 있다. 임의의 소프트웨어 계층에 있어서, 호스트는 계층의 위임 상태 변수에 대한 주변 장치의 프로세싱 제어를 오프로드하여, 주변 장치가 독립적으로 데이터를 전송할 수 있게 한다. 캐시된 상태 변수에 대해서는, 호스트는 캐시된 상태 변수의 제어를 유지하고, 캐시된 상태 변수가 변경되면 주변 장치를 갱신 한다. 일정 상태 변수에 대해서는, 이들의 값은 오프로드의 지속시간 동안 변경되지 않는다. 따라서, 호스트는 주변 장치로의 상태 객체를 오프로드할 수 있지만, 이벤트가 캐시된 상태 변수 또는 위임 상태 변수를 변경시키더라도 시스템의 상태는 일정하게 유지된다.

2개의 호스트 간에 데이터를 전송하는 경로는 경로 상태 객체로 표현된다. 2개의 접속이 동일한 경로를 통하여 데이터를 전송한다면, 동일한 경로 상태 객체를 공유한다. 따라서, 일반적으로 역 트리 데이터 구조의 형태를 갖는 상태 객체의 계층이 결과적으로 존재한다. 호스트는 전체 역 트리 데이터 구조를 주변 장치로 오프로드할 수 있으며, 이로써 호스트가 한 번에 다중 접속을 갖는 주변 장치로의 프로세싱 제어를 오프로드할 수 있다. 보안 연관(security association; SA) 기능이 오프로드, 업로드, 무효화 및 리키(re-keyed)되는 동안 인증 및/또는 부호화와 연관된 연산과 같은 복수의 특정 네트워크 기능을 깨긋하게 오프로드하는 이 능력은, 호스트가 원하는 네트워크 기능, 네트워크 관리, 보전, 결함 허용(fault tolerance) 및 보안을 손상시키지 않고 CPU 사이클을 유지할 수 있게 하고, 또한 본 발명이 광범위한 다양한 환경에서 실행될 수 있도록 한다. 이 장치는 SA 파기에 관한 관대한 및 엄격한 양자의 제한의 지원을 포함하여 SA를 위한 메트릭스를 유지하도록 조정한다. 타이머 요구는 타겟에 대하여 최소화된다. 오프로드된 SA 기능은 네트워크 스택의 중간 소프트웨어 계층의 다른 오프로드된 상태 객체에 내장될 수 있다.

본 발명의 추가적인 특징 및 장점은 이하의 상세한 설명에 의하여 밝혀질 것이며, 일부는 상세한 설명으로부터 명백하거나, 또는 본 발명의 실시에 의하여 습득될 것이다. 본 발명의 특징 및 장점은 첨부된 청구범위에 특별히 지적된 기구 및 조합에 의하여 밝혀지고 얻어질 것이다. 본 발명에 따른 이러한 특징 및 다른 특징은 이하의 상세한 설명 및 첨부된 청구범위로부터 더욱 명확해질 것이며, 본 발명의 실시에 의하여 습득될 것이다.

본 발명은 일반적으로 컴퓨터 네트워킹 토폴로지에 관한 것이다. 특히, 본 발명은, 프로세싱 모듈에 호스트 프로세서에 의하여 전형적으로 수행되는 IPSec 인증(authentication) 및/또는 부호화(encryption)("IPSec 동작들(IPSec operations)"이라고 함)와 연관되는 컴퓨팅 작업들의 오프로드를 최적하기 위한, 그리고 적절한 대로 호스트 프로세서에 제어를 반환하기 위한 메커니즘에 관한 것이다. 프로세싱 모듈은 소프트웨어로, 하드웨어로, 또는 하드웨어 및 소프트웨어의 혼합으로 아래에서 설명되는 바와 같은 오프로드된 IPSec 동작들을 처리한다. 프로세싱 모듈은 마더보드의 부분인 별도의 인터페이스 카드에, 다중 프로세서 유니트의 또 다른 프로세서인 내부 또는 외부 카드 등에 있을 수 있다. 또 다른 방 법은 소프트웨어로, 하드웨어로, 또는 소프트웨어 및 하드웨어의 혼합으로 아래에서 설명하는 바와 같은 오프로드된 네트워크 스택 동작들을 처리하는, 예컨대 네트워크 인터페이스와 같은 주변 장치의 모듈에 프로세싱 모듈의 기능을 내장하는 것이다. 주변 장치는 하나 이상의 프로세서를 가질 수 있다.

제한이 아닌 설명의 목적으로, 명세서 및 청구범위를 읽은 후에, "주변 장치"가 네트워크 어댑터를 갖는 범용 CPU, 지정된 CPU(dedicated CPU)를 갖는 네트워크 엔진, 오프로드 NIC를 갖는 전통적인 미니포트, 또는 하드웨어 상태 머신 구현 등 뿐만 아니라 네트워크 인터페이스 카드와 같은 콤포넌트를 포함할 수 있다는 것을 알 것이다. 그러므로, 다음의 설명은 CPU 사이클의 견지에서 비용 효율적인 발명의 방법을 설명한다.

본 발명의 추가적인 특징 및 이점은 후속하는 설명에서 개시되며, 부분적으로 명세서로부터 자명할 것이고, 또는 본 발명의 실시에 의하여 배워질 수 있다. 본 발명의 특징 및 이점은 첨부된 청구범위에서 특히 지적되는 도구들 및 조합들에 의하여 실현되고 획득될 수 있다. 본 발명에 따른 이들 및 다른 특징들은 다음의 설명 및 첨부된 청구범위로부터 완전히 명백해 질 것이고, 또는 다음에 제시하는 바와 같은 본 발명의 실시예 의해 배워질 수 있다.

또한, 본 발명에 따른 범위 내의 실시예는 컴퓨터 실행가능 명령어들 또는 안에 저장된 데이터 구조체들을 운반 또는 갖기 위한 컴퓨터 판독 가능 매체를 포함한다. 이러한 컴퓨터 판독 가능 매체는 범용 또는 특정 목적 컴퓨터에 의해 접속될 수 있는 임의의 이용가능한 매체일 수 있다. 제한이 아닌 예로서, 이러한 컴 퓨터 판독 가능 매체는 RAM, ROM, EEPROM 또는 다른 광 디스크 저장 매체, 자기 디스크 저장 장치 또는 다른 자기 저장 장치, 또는 컴퓨터 실행가능 명령어들 또는 데이터 구조체들의 형태로 소망하는 프로그램 코드 수단을 운반 또는 저장하기 위하여 사용될 수 있고 범용 또는 특정 목적 컴퓨터에 의하여 접속될 수 있는 임의의 다른 매체를 포함할 수 있다.

정보가 네트워크 또는 다른 통신 접속(유선, 무선 또는 유선 또는 무선의 조합) 상으로 컴퓨터에 전송 또는 제공되면, 그 컴퓨터는 그 접속을 컴퓨터 판독가능 매체로서 적절히 본다. 그러므로, 임의의 이러한 접속은 컴퓨터 판독 가능 매체로서 적절히 이름지어질 수 있다. 상기의 조합들도 컴퓨터 판독가능 매체의 범위 내에서 포함될 수 있다. 예컨대, 컴퓨터 실행가능 명령어들은 범용 컴퓨터, 특정 목적 컴퓨터, 또는 특정 목적 프로세싱 장치가 특정 기능 또는 기능들의 그룹을 수행하도록 하는 명령어들 및 데이터를 포함한다.

동일한 도면부호가 동일한 엘리먼트를 나타내는 도면을 참조하면, 본 발명은 적절한 컴퓨팅 환경에서 구현될 수 있는 것으로서 설명되고 있다. 요구되지는 않지만, 본 발명은 퍼스널 컴퓨터에 의해 실행되고 있는 프로그램 모듈과 같은 컴퓨터 실행가능 명령어들의 일반적인 콘텍스트에서 설명될 것이다. 일반적으로, 프로그램 모듈은 특정 작업을 수행하거나 특정 추상 데이터 유형을 구현하는 루틴, 프로그램, 객체, 콤포넌트, 데이터 구조체 등을 포함한다. 더욱이, 당업자는 본 발명이, 핸드-헬드 장치, 멀티-프로세서 시스템, 마이크로프로세서 기반 또는 프로그래머블 소비자 장치, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 네트워크된 주 변장치(예컨대, 네트워크된 프린터) 등을 포함하여 다른 컴퓨터 시스템 구성으로 구현될 수 있다. 또한, 본 발명은, 통신 네트워크를 통하여 링크되는 원격 프로세싱 장치들에 의하여 작업들이 수행되는 분산 컴퓨팅 환경에서 실시될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 로컬 및 원격 메모리 저장 장치 모두에 위치될 수 있다.

도 1을 참조하면, 본 발명이 구현될 수 있는 적절한 컴퓨팅 환경의 간략하고 일반적인 설명이 설명될 것이다. 도 1은 본 발명이 구현될 수 있는 적절한 컴퓨팅 시스템 환경(100)의 예를 설명한다. 컴퓨팅 시스템 환경(100)은 적절한 컴퓨팅 환경의 단지 한 예이고, 본 발명의 기능 또는 사용의 범위를 제한하기 위한 어떠한 제한을 제안하는 것으로 의도되지 않는다. 컴퓨팅 환경(100)은 예시적인 운영 환경(100)에서 설명되는 콤포넌트들의 임의의 하나 또는 조합에 관계되는 임의의 의존 또는 요건을 갖는 것으로 해석되어서는 안된다.

본 발명은 다수의 다른 범용 또는 특정 목적 컴퓨팅 시스템 환경 또는 구성으로 동작가능하다. 본 발명에서 사용하기에 적절할 수 있는 잘 알려진 컴퓨팅 시스템, 환경 및/또는 구성의 예는 퍼스널 컴퓨터, 서버 컴퓨터, 핸드-헬드 또는 랩탑 장치, 멀티프로세서 시스템, 마이크로프로세서 기반 시스템, 셋탑 박스, 프로그래머블 소비자 전자장치, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 네트워크된 주변장치(예컨대, 네트워크된 프린터), 상기 시스템 또는 장치 중의 임의의 것들을 포함하는 분산 컴퓨팅 환경을 포함하지만, 이들에 한정되지는 않는다.

본 발명은 컴퓨터에 의해 실행되고 있는 프로그램 모듈과 같은 컴퓨터 실행 가능 명령어들의 일반적인 콘텍스트로 설명될 수 있다. 일반적으로, 프로그램 모듈은 특정 작업을 수행하거나 특정 추상 데이터 유형을 구현하는 루틴, 프로그램, 객체, 콤포넌트, 데이터 구조체 등을 포함한다. 또한 본 발명은, 통신 네트워크를 통하여 링크되는 원격 프로세싱 장치에 의해 작업들이 수행되는 분산 컴퓨팅 환경에서 실시될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 메모리 저장 장치를 포함하는 로컬 및 원격 컴퓨터 저장 매체 모두에 위치될 수 있다.

도 1을 참조하면, 본 발명을 구현하기 위한 예시 시스템은 컴퓨터(110)의 형태를 한 범용 컴퓨팅 장치를 포함한다. 컴퓨터(110)의 컴포넌트들은 프로세싱 유닛(120), 시스템 메모리(130) 및 시스템 메모리를 포함하는 다양한 시스템 컴포넌트들을 프로세싱 유닛(120)에 연결시키는 시스템 버스(121)를 포함하지만, 이에 한정되는 것은 아니다. 프로세싱 유닛(120)은 단일 프로세서 또는 복수의 프로세서들을 가질 수 있다. 시스템 버스(121)는 임의의 다양한 버스 아키텍처를 이용하는 메모리 버스 또는 메모리 제어기, 주변 버스, 크로스바(cross-bar), 스위칭되는 버스 조직(switched bus fabric) 및 로컬 버스를 포함하는 여러 유형의 버스 구조들 중 임의의 것일 수 있다. 시스템 버스(121)는 또한 버스들의 계층일 수 있다. 예컨대, 이러한 아키텍처는 ISA(Industry Standard Architecture) 버스, MCA(Micro Channel Architecture) 버스, EISA(Enhanced ISA) 버스, VESA(Video Electronics Standards Associate) 로컬 버스, NC-NUMA(No Cache Non-Uniform Memory Access) 아키텍처 버스, CC-NUMA(Cache-Coherent Non-Uniform Memory Access) 아키텍처 버스, GIGARING 네트워크 버스, FIFCON 버스 및 PCI(Peripheral Component Interconnect) 버스(Mezzanine 버스로도 알려짐)를 포함하지만, 이에 한정되는 것은 아니다.

컴퓨터(110)는 통상적으로 다양한 컴퓨터 판독 가능 매체를 포함한다. 컴퓨터 판독 가능 매체는 컴퓨터(110)에 의해 액세스될 수 있는 임의의 매체일 수 있으며, 휘발성 및 비휘발성, 이동형 및 고정형 매체를 포함한다. 예컨대, 컴퓨터 판독 가능 매체는 컴퓨터 저장 매체 및 통신 매체를 포함할 수 있지만, 이에 한정되는 것은 아니다. 컴퓨터 저장 매체는 컴퓨터 판독 가능 명령어, 데이터 구조, 프로그램 모듈 또는 다른 데이터와 같은 정보의 저장을 위한 임의의 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 이동형 및 고정형 매체를 포함한다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, DVD 또는 다른 광학 디스크 저장 매체, 자기 카세트, 자기 테이프, 자기 디스크 또는 다른 자기 저장 장치, 또는 원하는 정보를 저장하는 데 사용될 수 있고 컴퓨터(110)에 의해 액세스될 수 있는 임의의 다른 매체를 포함하지만, 이에 한정되는 것은 아니다. 통신 매체는 통상적으로 컴퓨터 판독 가능 명령어, 데이터 구조, 프로그램 모듈, 또는 반송파와 같은 변조된 데이터 신호 내의 다른 데이터나 다른 전송 메커니즘을 구현한 것으로서, 임의의 정보 전달 매체를 포함한다. "변조된 데이터 신호"라는 용어는 신호 내에 정보를 인코딩하는 방식에 의해 그 특성이 하나 이상 설정 또는 변경되는 신호를 의미한다. 예컨대, 통신 매체는 유선 네트워크 또는 직접 유선 연결 접속과 같은 유선 매체 및 음파, RF, 적외선 및 다른 무선 매체와 같은 무선 매체를 포함하지만, 이에 한정되는 것은 아니다. 앞서 언급한 매체들의 조합 또한 컴퓨터 판독 가능 매체의 범주에 포함되어야 한다.

시스템 메모리(130)는 ROM(Read Only Memory)(131) 및 RAM(Random Access Memory)(132)와 같은 휘발성 및/또는 비휘발성 메모리의 형태를 한 컴퓨터 저장 매체를 포함한다. 컴퓨터(110) 내의 요소들 사이에서 예컨대 시동중에 정보를 전송하도록 하는 기본 루틴들을 포함하는 BIOS(Basic Input/Output System)(133)는 통상적으로 ROM(131)에 저장된다. RAM(132)는 통상적으로 프로세싱 유닛(120)에 대하여 즉시 액세스될 수 있고/있거나 프로세싱 유닛(120)에 의해 바로 동작되는 데이터 및/또는 프로그램 모듈들을 포함한다. 예컨대, 도 1은 운영 체제(134), 애플리케이션 프로그램들(135), 다른 프로그램 모듈들(136) 및 프로그램 데이터(137)를 도시하고 있지만, 이에 한정되는 것은 아니다.

컴퓨터(110)는 또한 다른 이동형/고정형, 휘발성/비휘발성 컴퓨터 저장 매체를 포함할 수 있다. 예컨대, 도 1은 고정형, 비휘발성 자기 매체에 대한 판독 또는 기록을 수행하는 하드 디스크 드라이브(141), 이동형, 비휘발성 자기 디스크(152)에 대한 판독 또는 기록을 수행하는 자기 디스크 드라이브(151) 및 CD-ROM 또는 다른 광학 매체와 같은 이동형, 비휘발성 광학 디스크(156)에 대한 판독 또는 기록을 수행하는 광학 디스크 드라이브(155)를 도시하고 있지만, 이는 예시일 뿐이다. 예시 운영 환경에서 사용될 수 있는 다른 이동형/고정형, 휘발성/비휘발성 컴퓨터 저장 매체에는 자기 테이프 카세트, 플래시 메모리 카드, DVD, 디지털 비디오 테이프, 고체 상태 ROM 등이 포함되지만, 이에 한정되는 것은 아니다. 하드 디스크 드라이브(141)는 통상적으로 인터페이스(140)와 같은 고정형 메모리 인터페이스 를 통해 시스템 버스(121)에 접속되고, 자기 디스크 드라이브(151) 및 광학 디스크 드라이브(155)는 통상적으로 인터페이스(150)와 같은 이동형 메모리 인터페이스에 의해 시스템 버스(121)에 접속된다.

앞서 설명하고 도 1에 도시된 드라이브들 및 이들의 관련 컴퓨터 저장 매체는 컴퓨터(110)를 위한 컴퓨터 판독 가능 명령어, 데이터 구조, 프로그램 모듈 및 다른 데이터의 저장을 제공한다. 도 1에서, 예컨대 하드 디스크 드라이브(141)는 운영 체제(144), 애플리케이션 프로그램들(145), 다른 프로그램 모듈들(146) 및 프로그램 데이터(147)를 저장하는 것으로서 도시되어 이다. 여기서 주목할 것은, 이들 컴포넌트들은 운영 체제(144), 애플리케이션 프로그램들(145), 다른 프로그램 모듈들(146) 및 프로그램 데이터(147)와 같거나 상이한 것일 수 있다는 점이다. 운영 체제(144), 애플리케이션 프로그램들(145), 다른 프로그램 모듈들(146) 및 프로그램 데이터(147)에는 본 명세서에서 적어도 이들이 상이한 사본들임을 나타내도록 상이한 번호가 부여되어 있다.

사용자는 키보드(162) 및 마우스, 트랙볼 또는 터치 패드로 흔히 일컬어지는 포인팅 장치(161)와 같은 입력 장치를 통해 컴퓨터(110)에 명령 및 정보를 입력할 수 있다. 다른 입력 장치들(도시되지 않음)에는 마이크, 조이스틱, 게임 패드, 위성 접시, 스캐너, 비디오 입력 등이 포함될 수 있다. 이러한 입력 장치들 및 그 밖의 입력 장치들은 종종 시스템 버스에 연결된 사용자 입력 인터페이스(160)를 통해 프로세싱 유닛(120)에 접속되지만, 병렬 포트, 게임 포트, 또는 USB(Universal Serial Bus)와 같은 다른 인터페이스 및 버스 구조에 의해 접속될 수도 있다. 모 니터(191) 또는 다른 유형의 디스플레이 장치 또한 비디오 인터페이스(190)와 같은 인터페이스를 통해 시스템 버스(121)에 접속된다. 모니터에 부가하여, 컴퓨터는 출력 주변 인터페이스(195)를 통해 접속될 수 있는 스피커(197), 프린터(196) 및 비디오 출력과 같은 다른 주변 출력 장치들을 포함할 수도 있다.

컴퓨터(110)는 원격 컴퓨터(180)와 같은 하나 이상의 원격 컴퓨터들에 대한 논리적 접속들을 이용하는 네트워킹된 환경에서 동작할 수 있다. 원격 컴퓨터(180)는 다른 개인용 컴퓨터, 서버, 라우터(router), 네트워크 주변 장치(예컨대 프린터), 네트워크 PC, 피어(peer) 장치 또는 다른 컴퓨터 네트워크 노드일 수 있으며, 통상적으로 개인용 컴퓨터(110)와 관련하여 앞서 기술한 요소들 중 다수 또는 전부를 포함하지만, 도 1에는 메모리 저장 장치(181)만이 도시되어 있다. 도 1에 도시된 논리적 접속에는 LAN(Local Area Network)(171) 및 WAN(Wide Area Network)(WAN)(173)이 포함되지만, 다른 네트워크들도 포함될 수 있다. 이러한 네트워킹 환경은 사무실, 기업 범위 컴퓨터 네트워크, 인트라넷 및 인터넷에 일반적이다.

LAN 네트워킹 환경에서 사용되는 경우, 개인용 컴퓨터(110)는 네트워크 인터페이스 또는 어댑터{예컨대 NIC(Network Interface Card)}(170)를 통해 LAN(171)에 접속된다. 단일 박스로 표시되어 있지만, 네트워크 인터페이스(170)는 다양한 실시예를 가질 수 있고 다양한 방식으로 구현될 수 있다. 한 가지 방식은, 시스템 버스에 직접 접속되는 네트워크 인터페이스 카드 및 시스템 버스에 직접 접속되는 하나 이상의 프로세서를 갖는 처리 모듈이 시스템 버스를 가로질러 서로 통신하는 것이다. 처리 모듈은 오프로드된(offloaded) 네트워크 스택 작업들을 소프트웨어, 하드웨어, 또는 이들의 혼합에 의해 이하 설명할 바와 같이 처리한다. 처리 모듈은 별개의 인터페이스 카드에 있거나, 마더보드의 일부이거나, 내장형 또는 외장형 카드에 있거나, 복수의 프로세서 유닛 중의 또 다른 프로세서일 수 있다. 다른 방식은, 처리 모듈의 기능을 예컨대 네트워크 인터페이스 카드와 같은, 소프트웨어, 하드웨어, 또는 이들의 혼합에 의해 이하 설명할 바와 같이 오프로드된 네트워크 스택 작업들을 처리하는 주변 장치에 내장시키는 것이다. WAN 네트워킹 환경에서 사용되는 경우, 컴퓨터(110)는 통상적으로 모뎀(172) 또는 인터넷과 같은 WAN(173)을 통한 통신을 설정하기 위한 다른 수단을 포함한다. 내장형 또는 외장형일 수 있는 모뎀(172)은 사용자 입력 인터페이스(160) 또는 다른 적합한 메커니즘을 통해 시스템 버스(121)에 접속될 수 있다. 네트워킹 환경에서, 개인용 컴퓨터(110)와 관련하여 기술된 프로그램 모듈 또는 그 일부가 원격 메모리 저장 장치에 저장될 수 있다. 예컨대, 도 1은 원격 애플리케이션 프로그램들(185)이 메모리 장치(181) 상에 존재하는 것으로 도시하고 있으나, 이에 한정되는 것은 아니다. 도시된 네트워크 접속은 예시적인 것으로서, 컴퓨터들간에 통신 링크를 설정하기 위한 다른 수단이 사용될 수 있음을 이해할 수 있을 것이다.

이하의 설명에서는, 다른 언급이 없으면 하나 이상의 컴퓨터에 의해 수행되는 작업의 동작 및 이를 기호로 표시한 것을 참조하여 본 발명을 설명하기로 한다. 따라서, 종종 컴퓨터로 실행되는 것으로 일컬어지는 이러한 동작 및 작업은 구조화된 형태의 데이터를 나타내는 전기 신호들을 컴퓨터의 프로세싱 유닛에 의해 조작 하는 것을 포함한다. 이러한 조작은 데이터를 변형시키거나 이를 컴퓨터의 메모리 시스템 내의 장소에 유지시키는데, 이는 본 기술 분야의 당업자에게 공지된 방식으로 컴퓨터의 작업을 재구성 또는 변경시킨다. 데이터가 유지되는 데이터 구조는 데이터의 형식에 의해 정의되는 특정한 속성을 갖는 데이터의 물리적인 위치이다. 그러나, 본 발명이 상술한 맥락에 따라 기술되고 있지만, 본 기술 분야의 당업자가 이후 설명되는 다양한 동작 및 작업이 하드웨어로도 구현될 수 있다는 점에서 제한적인 의미로 기술된 것은 아니다.

이하의 설명에서는, 네트워크 스택 작업을 수행하는 기능을 갖는 주변 장치가 본 발명을 설명하기 위하여 사용될 것이다. 이하에서 쓰이는 바처럼, 주변 장치(204)는 주변 장치만을 지칭하는 것이 아니라, 오프로드된 IPSec 작업들의 처리와 관련하여 주변 장치가 기술되는 경우(즉, 주변 장치가 오프로드된 IPSec 작업들을 소프트웨어, 하드웨어 또는 이들의 혼합에 의해 처리함), 앞서 설명한 처리 모듈의 다른 실시예들 중 임의의 것을 지칭한다. 도 2a는 네트워킹 모델을 구성하는 컴포넌트들 중 일부와 본 발명의 컴포넌트들의 상호 관계에 관하여 도시하고 있다. 도 2b는 본 발명의 컴포넌트들이 다른 침니에 내장된 경우에 네트워킹 모델을 구성하는 컴포넌트들 중 일부와 본 발명의 컴포넌트들 사이의 상호 관계를 도시하고 있다. 통상 작업 중에, 네트워킹된 메시지들이 애플리케이션(200)에 의해 네트워크 스택(202)을 통해 주변 장치(204)에 전달되며, 여기서 메시지들은 네트워크상의 다른 장치들 및 애플리케이션들에 전달된다. 또한, 네트워킹된 메시지들은 주변 장치를 사용하는 다른 장치들 및 애플리케이션들로부터 수신될 수 있으며, 이러한 주 변 장치는 다시 네트워킹된 메시지들을 네트워크 스택(202)을 통해 애플리케이션(200)에 전달한다. 네트워크 스택(202)은 하나 이상의 중간 소프트웨어 계층(206)을 포함한다. 애플리케이션(200)으로부터 전달되는 데이터는 중간 소프트웨어 계층(들)(206)을 통해 이동하며, 여기서는 예컨대 데이터의 패키징, 신뢰성 있는 데이터의 전송 및 메시지 다이제스트의 계산과 같은 특정한 작업들이 데이터에 대하여 수행될 수 있다.

프로세싱 유닛(120)이 중간 소프트웨어 계층(들)(206)에 대한 IPSec 작업들을 오프로드하지 않도록 하는데 IPSec 스위치(208)를 이용한다(즉, 적어도 하나의 중간 계층들은 IPSec 동작들을 필요로 하거나 IPSec 계층을 가짐). IPSec 스위치(208)가 개별적으로 도시되어 있지만, IPSec 스위치(208)는 네트워크 스택(202)의 중간 계층에 통합될 수도 있다. 다른 중간 계층들이 IPSec 스위치 위에 존재할 수도 있다(도시되지 않음). IPSec 동작을 오프로드한 후에, IPSec 동작을 수행하기 위해 주변 장치(204)에 대한 침니(chinmey; 210)를 통해 주변 장치(204)로 데이터가 송신된다. 이러한 계층 구조에 있어서, IPSec 스위치 위의 중간 소프트웨어 계층들 및 IPSec 동작들은 반드시 호스트 또는 주변 장치에 존재해야 할 필요는 없으며, 임의의 중간 계층들은 완전히 오프로드되거나 호스트 내에 존재하거나 또는 이들 모두의 조합이 될 수 있다(예컨대, 하나 이상의 특정 접속 오프로드).

도 2b를 참조하면, IPSec 침니(210)는 다른 침니들의 아래 또는 위에 위치할 수 있다. 예컨대, IPSec 침니(210)는 TCP 침니(220)의 위 또는 아래에 위치할 수 있다. 중간 소프트웨어 계층(들)(206)에 대한 네트워크 스택 동작들을 수행하지 않도록 프로레싱 유닛(120)을 오프로드하는데 스위치(222)를 이용한다. 스위치(222)가 개별적으로 도시되어 있지만, 스위치(222)는 네트워크 스택(202)의 상위 중간 계층들에 통합될 수 있다는 점에 주의해야 한다. 네트워크 스택 동작들을 오프로드한 후에, 네트워크 스택 동작들을 수행하기 위하여 주변 장치(204)에 대한 침니(210 또는 220)를 통해 사용될 네트워크 스택(202)의 유형에 따라 데이터가 주변 장치(204)로 송신된다. 예컨대, TCP 접속이 오프로드되거나 (UDP와 같은) 다른 전송 프로토콜이 사용되면, IPSec 동작을 수행하기 위하여 침니(210)를 통해 주변 장치로 IPSec 동작들이 송신된다. 마찬가지로, TCP 접속이 오프로드되면, 침니(220)를 통해 TCP 동작들이 주변 장치(204)로 송신된다. TCP 접속이 IPSec 캡슐화/비캡슐화를 요구한다면, 오프로드 타겟(예컨대, 주변 장치)은 IPSec SA 오프로드 객체를 패킷에 적용할 것이다. 이러한 계층 구조에서, 중간 소프트웨어 계층들 및 IPSec 동작들은 반드시 호스트 또는 주변 장치에 존재해야 할 필요가 없으며, 임의의 중간 계층들은 완전히 오프로드되거나 호스트 내에 존재하거나 또는 이들 모두의 조합이 될 수 있다(예컨대, 하나 이상의 특정 접속 오프로드).

접속은 신뢰성 및 비신뢰성 데이터 전송과 단일 캐스트 또는 다중 캐스트 데이터 전송 중의 임의의 조합이 될 수 있다. 중간 계층이 호스트 내에 남아 있으면 호스트는 주변 장치(204) 내의 (아래에서 기술되는 바와 같이) 캐싱된 변수들을 갱신한다. 예컨대, 접속을 위한 전송 제어 블록(TCB; Trnasfer Control Block) 상태 진입은 주변 장치(204)로 오프로드된 네트워크 계층에 대하여 라우트 캐시 엔트리(RTE; Route Cache Entry)를 갖는 전송 계층에 대해 오프로드될 수 있다. 스위치 (222)가 오프로드된 TCB를 위해 침니(220)를 통해 트래픽을 송신하는 동안, 스위치(222)는 동일한 RCE를 공유하는 네트워크 스택(220)을 통해 다른 TCB에 대한 트래픽을 계속하여 전송한다. IPSec 스위치(208)는 침니(210)를 통해 오프로드된 보안 연관(SA; Security Association)에 대해 오프로드된 IPSec 기능들을 위한 트래픽을 전송하고, IPSec 인증 및/또는 암호화/복호화를 요구하는 트래픽에 대해 침니(220)로부터 트래픽을 전송/수신할 수 있다.

스위치(208 또는 222)는 오프로드 요청을 중간 계층(206)에 송신함으로써 오프로드를 초기화한다. 각각의 중간 계층(206)은 오프로드 요청을 거절하거나, 자원 정보를 오프로드 요청에 부가하고, 네트워크 스택(202)의 인접 소프트웨어 계층로 오프로드 요청을 송신한다. 오프로드 요청은, 주변 장치(204)가 접속을 성공적으로 오프로드할 수 있는지 여부를 결정하도록 돕는 (잠재적으로 각각의 네트워크 계층에 대한) 자원 정보를 포함한다. 주변 장치(204)가 오프로드 요청을 수신한 경우에, 접속 및/또는 IPSec 동작을 오프로드하기 위하여 이용 가능한 자원을 갖는지 여부를 계산한다. 오프로드가 불가능하면, 주변 장치(204)는 오프로드 요청을 거절한다. 그렇지 않다면, 주변 장치(204)는 오프로드 요청을 수용하고 접속을 위한 자원을 할당한다. 주변 장치(204)는 중간 소프트웨어 계층(들)(206)에 매개변수 리스트를 갖는 완료 메시지를 송신함으로써 오프로드 요청을 완료한다. 중간 소프트웨어 계층(들)(206) 및 스위치(208 또는 222)가 주변 장치와 통신할 수 있도록, 매개변수 리스트는 중간 소프트웨어 계층(들)(206) 및 스위치(208 또는 222)에 정보를 제공한다. 각각의 중간 소프트웨어 계층(206)이 완료 메시지를 수신하면, 매개변수 리스트으로부터 해당 계층에 대한 정보를 제거하고, 다음 중간 계층(206)으로 완료 메시지의 나머지를 전달하는데, 만약 추가적인 중간 계층들(206)이 존재하지 않는다면 스위치(208 또는 222)로 전달한다.

중간 계층(206)이 오프로드에 대한 완료 메시지를 수신한 경우 또는 원본 오프로드 요청 동안에, 중간 계층(206)은 자신의 상태를 주변 장치(204)에 전달한다. 각각의 상태는 CONST, CACHED 및 DELEGATED의 세 가지 유형의 변수(상태 변수라 불림)를 가질 수 있다. 임의의 특정 중간 계층(206)에 대응하는 상태 객체는 세 가지 유형의 상태 모두를 갖거나, 세 가지 유형의 상태의 서브세트를 가질 수 있다. 오프로드된 접속의 수명 동안 변화하지 않는 CONST 상태 변수들은 일정하다.

CONST 상태 변수들은, 네트워크 스택 및/또는 IPSec 동작의 프로세싱 제어를 오프로드하는 경우(이하에서는 간단히 "오프로드 동안"이라고 칭함)에는 주변 장치(204)에 제공되지만, 상태 객체가 호스트 프로토콜 스택에 업로드되는 경우(이하에서는 간단히 "업로드 동안"이라고 칭함)에는 적절한 중간 계층(206)으로 주변 장치(204)에 의해 반환되지 않는다. 이는, 중간 계층(206)이 CONST 상태 변수들에 대한 값들을 보유하므로, 업로드 동안 전달된 데이터 구조가 훨씬 작아질 수 있기 때문이다.

호스트 프로세서는 CACHED 상태 변수의 소유(ownership)를 유지하고, 호스트 프로세서 내의 CACHED 상태 변수(들)에 대한 임의의 변화가 주변 장치(204)에서 갱신되는 것을 보장한다. CACHED 상태 변수들을 변경하는 제어 메시지들은 네트워크 스택(202)에 의해 처리된다. 결과적으로, 호스트는 오프로드 동안 주변 장치에 CACHED 상태 변수를 기록하지만, 업로드 동안에는 주변 장치로부터 CACHED 상태 변수를 판독할 필요가 없다. 이는 업로드와 연관된 오버헤드를 추가로 저감시켜 준다.

호스트 프로세서는 DELEGATED 상태 변수들의 소유를 주변 장치(204)에 전송한다. DELEGATED 상태 변수는 오프로드 동안 기록되고, 업로드 동안 판독된다. DELEGATED 상태 변수의 제어를 전송함으로써 호스트로의 접속을 업로드하는 것과 관련된 오버헤드가 최소화된다.

따라서, 오프로드 동안, 특정 상태 객체의 상태 변수들 중의 일부의 제어가 호스트 프로세서 내에 유지된다는 점에서 상태 객체들의 제어는 호스트 프로세서와 주변 장치(204) 사이에서 공유되는데, 반면, 특정 상태 객체 중의 다른 상태 변수들의 제어는 주변 장치(204)로 전달된다. 따라서, 각각의 중간 계층와 연관된 상태의 프로세싱에 대한 제어는 호스트 프로세서와 주변 장치 사이에서 명확히 분할되어 각각이 상태의 배타적인 부분을 소유한다.

호스트 프로세서는 필요한 경우에 DELEGATED 상태 변수들에 대해 주변 장치(204)에게 질의할 수 있다. 또한, 호스트 프로세서는 진단을 위해 CONST 또는 CACHED 상태 변수들을 질의할 수 있다. 상태를 세 개의 범주(또는 "변수들")로 나눔으로써 네트워크 스택(202)은 침니(210 및 220)와 명확히 공존하게 된다. 주변 장치에 주어지는 임의의 상태 변수들은 (그러한 상태 변수들에 대한 제어가 주변 장치에 전달되거나 또는 아니거나) 주변 장치와 호스트 스택 사이의 상호 작용의 수를 최적화하기 위해 초기 오프로드 요청에 포함될 수 있다. 상태 객체가 위임된 상태(delegated state)를 포함하지 않거나, 위임된 상태 변수들이 초기 오프로드 요청 및 오프로드 요청의 완료 사이에 변경되지 않을 것이라는 점을 호스트 스택이 보장할 수 있다면, 이러한 작업이 수행될 수 있다.

업로드는 주변 장치(204) 또는 호스트 스택(202)에 의해 초기화될 수 있다. 호스트 스택의 IPSec 동작 초기화는 IPSec 계층(214) 또는 IPSec 계층(214)에 의해 시작될 수 있다. 또한, 네트워크 스택 동작을 위한 업로드는 중간 계층(206)에 의해 간접적으로 초기화될 수도 있는데, 그 이유는 예컨대 중간 계층(206)이 경로 또는 이웃 엔트리를 무효화시키기 때문이다. 업로드가 초기화되면, 주변 장치(204)는 현재의 모든 요청을 완료하고, 상태 객체들의 처리를 호스트 스택으로 넘겨준다. 스위치(222)는 임의의 추가적인 전송 요청을 큐잉하고, 주변 장치에 수신 버퍼를 쌓는 작업을 중단한다. 업로드 동안, 호스트 스택의 중간 계층들은 상태 객체(들)의 제어를 재획득하고, 업로드 요청을 마친다. 업로드 요청이 완료된 후에, 주변 장치(204)는 업로드로 인해 더 이상 사용되지 않는 자원을 해제한다.

일부 상황에서, 특정 접속에 대한 데이터 또는 상태 객체는 다른 주변 장치를 통해 도착하거나, 호스트 프로토콜 스택에 의해 처리될 것이 요구될 수도 있다(예컨대, IP 부분, IP 옵션 또는 확장 헤더의 프로세싱 또는 상이한 네트워크 인터페이스에 도달하는 TCP 세그먼트를 야기하는 라우트 플랩). 이러한 상황이 발생하면, 중간 계층(206)은 또한 주변 장치(204)로 수신된 데이터를 전달하기 위한 전달 인터페이스(forwarding interface)를 가질 수 있다. 주변 장치가 접속 또는 상태 객체와 연관된 업로드 중에 있는 동안, 중간 계층(206)은 주변 장치(204)로 데이터 전달을 시도할 수 있다. 그러므로, 주변 장치(204)는 데이터 패킷을 처리하는데 필요한 상태 객체의 제어를 더 이상 갖지 않을 수 있다. 이러한 상황에서, 주변 장치(204)는 업로드가 진행 중임을 나타내는 에러 메시지를 중간 계층(206)으로 반환한다. 에러 메시지는 입수 데이터를 전달하는 것을 중단하라는 것과, 중간 계층이 상태 객체를 수신할 때까지 추가적인 데이터를 버퍼링할 것을 중간 계층(206)에게 알려준다. 대안으로, 상태 객체의 업로드이 완료된 경우에 주변 장치(204)가 데이터를 버퍼링하고, 그 데이터를 제공하도록, 주변 장치(204) 상의 부가적인 버퍼 메모리를 대가로 입수 데이터는 주변 장치(204)로 전달될 수 있다. 대안으로, 중간 계층(206)이 업로드가 발생하고 있음을 알고 있다면, 중간 계층은 업로드가 완료되어 데이터를 처리할 때까지 요청을 버퍼링하도록 선택할 수 있다.

다중 접속은 중간 소프트웨어 계층(206)에 의해 주변 장치(204)로 오프로드될 수 있다. 오프로드를 위한 중간 소프트웨어 계층의 상태 객체를 레퍼런스하는 상위 계층 상태 객체들(즉, 중간 소프트 계층(206) 상위의 계층의 상태객체들)의 수에 대한 레퍼런스 카운터는 중간 소프트 계층(206)에 의해 유지될 수 있다. 본 명세서에서 사용된 상태 객체는 특정 계층에 대한 상태 변수들(또는 "상태들")의 집합이다. 상술한 바와 같이, 이러한 상태 변수들은 CONST, CACHED 또는 DELEGATED로 범주화될 수 있다. (예컨대, 업로드 요청 동안) 특정 중간 계층의 오프로드된 상태 객체에 대한 참조의 수가 0으로 감소하면, 중간 계층(206)은 중간 계층에 대한 상태 객체를 업로드하기 위하여 주변 장치(204)로 메시지를 송신하고, 중간 계층(206)으로 대응하는 위임 상태 변수들을 송신하며, 중간 계층(206)에 대 한 상태 객체를 삭제한다. 업로드 요청은, 레퍼런스 카운트가 0으로 감소하도록 하는 원본 업로드 요청 동안 또는 그 이후에 발생할 수 있다.

도 3a는 본 발명에 따른 하드웨어 계층(hardware layer; 314)이 예컨대 NIC(network interface card)일 수 있는 주변 장치를 포함하는 실시예를 기술한다. 도 3b는 본 발명에 따른 하드웨어 계층(314)이 예컨대 NIC(network interface card)일 수 있는 주변 장치를 포함하고 IPSec 침니(chimney)(308)가 TCP 침니와 같은 다른 침니(320)에 내장되는 실시예를 기술한다. 이에 추가하여, 도 3a는 전송 계층(Transport Layer; 300), 네트워크 계층(Network Layer; 302) 및 프레이밍 계층(Framming Layer; 304)을 포함하는 네트워크 스택(318) 및 IPSec 스위치(322)를 포함하는 소프트웨어 계층을 기술한다. 네트워크 계층(302)은 또한 "경로 계층(Path Layer)"으로도 알려지고, 프레이밍 계층(304)은 또한 "이웃 계층(Neighbor Layer)"로도 알려졌다.

일반적으로, 애플리케이션(200)은 네트워크화된 메시지를 네트워크 스택(318)을 통해서 주변 장치(예컨대, 하드웨어(314))로 동작하는 동안에 보낸다. 애플리케이션(200)으로부터 보내어진 데이터는 전송 계층(300)을 통과해서 IPSec 스위치(306)로 가는데, 이는 호스트 기반 네트워크 스택(318) 또는 IPSec 침니(308) 아래로 데이터를 내릴지를 제어한다. 전송 계층(300)은 TCP 계층, UDP 계층, ICMP 계층 등일 수 있다. 스위치(306)는 네트워크 스택(318)의 계층에 합체될 수 있음을 주목하라. 네트워크 스택(318) 내의 소프트웨어 계층은 애플리케이션(300)으로부터 데이터를 수신하고, 패킷 형태로 데이터를 패킷화하고, 나온 패킷을 NDIS 미 니드라이버(310)를 통해서 주변 장치 하드웨어(314)로 보낸다. 그것이 페이로드(payload)를 애플리케이션에 주는 것 같이 네트워크 패킷이 수신되는 때에, 소프트웨어 계층은 또한 반대 기능성을 제공한다. 데이터 패킷을 스택(318)을 통해서 전달시에 네트워크 스택(318)이 수행할 수 있는 다른 작업은 오프로드(offload)되지 않은 보안 연관, 신뢰성 있는 데이터 전송 및 메시지 다이제스트의 계산 또는 체크(예컨대, 체크 섬 또는 데이터 패킷에 관한 CRC)에 관한 데이터 암호화 및 복호화를 포함한다. 이들 작업의 다수는 오프로드되지 않고 프로세서 중심적이면 호스트 프로세서에 의해 수행된다..

도 3b로 가서, 애플리케이션(200)은 네크워크화된 메시지를 네트워크 스택(318)을 통해서 주변 장치(예컨대, 하드웨어(314))로 동작 중에 보낸다. 애플리케이션(200)으로부터 보내진 데이터는 TLI(Transport Layer Interface) 스위치(322)를 통과해서 진행하는데, 이는 데이터가 호스트 기반 네트워크 스택(318) 또는 침니(320) 아래로 갈지를 제어한다. TLI 스위치(322)는 네트워크 스택(318)의 탑 계층에 합체될 수 있음을 주목하라. 네트워크 스택(318) 내의 소프트웨어 계층은 애플리케이션(300)으로부터 데이터를 수신하고, 패킷 형태로 데이터를 패킷하고, 나온 패킷을 NDIS 미니드라이버(310)를 통해서 주변 장치 하드웨어(314)로 보낸다. 소프트웨어 계층 및 네트워크 스택(318)은 상술한 것과 동일한 기능을 수행한다.

TLI 스위치(322)는 침니(320) 및 침니 드라이버(312)를 통해서 주변 장치로의 오프로드된 연결에 관한 데이터를 전송해서 CPU로부터 주변 장치로 스택 동작을 오프로드하는데 사용된다. 당업자는 명세서와 청구범위를 읽은 후, NDIS 드라이버 (310)와 침니 드라이버(312)는 동일한 실제 드라이버일 수 있음을 인지할 것이다. 당업자는 NDIS 미니드라이버(310) 및 침니 드라이버(312)의 상부 에지는 MICROSOFT?WINDOWS? 운영체제 내의 NDIS API임을 또한 인지할 것이다. 설명을 위해, 프로토콜 스택에 기반한 TCP(Transmission Control Protocol) 아래의 SIP(Secure Internet Protocol)가 본 발명을 설명하는데 사용될 것이다. 그러나 당업자는 본 명세서를 본 후에, 다수 유형의 주변 장치가 사용될 수 있고, 다른 네트워크 스택이 본 발명에 따른 원리를 사용해서 오프로드될 수 있음을 인식할 것이다. 이에 추가하여, 본 발명은 iSCSI(internet Small Computer System Interface), NFS(Network File System) 또는 CIFS(Common Interface File System)와 같은 더 고도 함수 프로토콜을 오프로드하는데 사용될 수 있다. 오프로드된 프로토콜은 연결지향형(예컨대, TCP)이나 연결 없는 형(예컨대, IPSEC나 UDP)일 수 있다.

네트워크 연결 오프로드를 수행하기 위한 다수의 이유가 있다. 예를 들어, 일부 이유가 아래에 제공되는데, 이에 한정되는 것은 아니다. 시스템 관리자는 특정 서비스를 선택해서 오프로드되도록 할 수 있다. 트래픽(비트나 패킷에 의함)이 상당한 양의 자원을 소모한다면, 특정 연결은 오프로드될 수 있다. 추가해, IPSec 서비스에 추가해 소정 유형의 서비스가 오프로드될 수 있다. 추가해, 관리 정책(aministratice policies)은 프로세싱 오프로드를 구동할 수 있다. 예컨대, 관리자는 구조(organization) 내로부터의 모든 연결이 먼저 오프로드 되거나 특정 애플리케이션에 관한 모든 연결이 먼저 오프로드되는 정책을 가질 수 있다. 사용되고 있는 시스템 자원(예컨대, CPU 이용, 데이터 캐시 사용, 페이지 테이블 캐시 사용, 메모리 밴드 폭)는 호스트 프로세서가 연결을 오프로드 하도록 할 수 있다.

IPSec 기능을 오프로드하기 위한 단계를 기술하기 전에, TCP 연결을 오프로드하는 단계들이 먼저 기술된다. 도 4는 TCP 연결을 오프로드 하기 위해 취해지는 3개 단계를 기술하는데, 도 3b 내의 애플리케이션 계층(200)는 도시 안 되지만, TLI 스위치(322)의 왼편이다. 추가해 단순히 설명의 목적으로, NIC와 같은 주변 장치(370)는 도 4에 도시되는데, 다른 유형의 주변 장치도 동일하거나 유사한 기능을 본 발명에 따라서 수행할 수 있는데, 네트워크 어댑터를 가진 범용 CPU를 포함한다. 일반적으로, 도 4는 TCP 연결을 오프로드하고 각 계층(즉, 전송 계층(300), 네트워크 계층(302), 프레이밍 계층(304)) 및 스위치(306, 322)에 핸들을 제공하는데 필요한 자원을 배분하고, 각 계층(300, 302, 304)을 주변 장치(370)에 오프로드하는 프로세스를 도시한다. 오프로드 전이(offload transition) 동안에, TLI 스위치(322)는 애플리케이션으로부터의/애플리케이션으로의 보내지거나 수신된 모든 메시지를 버퍼링한다. 또는, 전송 계층(300)은 데이터를 버퍼링한다. 오프로드가 완료되면, 버퍼링된 데이터가 주변 장치(370)로 전달된다. 오프로드 전이 동안에 인입되는 패킷이 수신되면, 주변 장치(370)는 전송 계층 위임 상태(delegated state)가 주변 장치(370)로 전달될 때까지 계층(300, 302, 304) 및 스위치(306, 322)를 통해서 데이터를 이동하는 것을 계속한다. 오프로드 전이 동안에 인입되는 패킷을 전송 계층(300)이 수신하면, 그것은 전송 상태 객체 위임 상태의 부분으로나 분리되어 NIC(370)로 데이터를 전달할 것이다.

TLI 스위치(322)는 전송 계층(300)에 오프로드 요청(400)을 보내어서 오프로 드를 개시한다. 오프로드 요청은 다음 계층의 로컬 상태에 대한 포인터(예컨대, 전송 계층(300)에 관한 TCB 포인터, 네트워크 계층(302)에 관한 REC 포인터, 프레이밍 계층(304)에 관한 ARP 엔트리 포인터 또는 NDIS 미니드라이버(310)에 관한 NDIS 미니포트 포인터)를 포함한다. 오프로드 요청은 또한 오프로드 유형(예컨대, TLI 스위치(322)에 관한 TCP, 네트워크 계층(302)에 관한 IPv6 등) 및 주변 장치(370)가 TCP 연결을 성공적으로 오프로드 할 수 있는지를 판정하도록 돕는 자원 정보를 포함한다. TLI 스위치(322)는 또한 주변 장치(370)에 오프로드 핸들을 제공할 수 있다. TLI 스위치(322)는 애플리케이션 샌드(application send)나 수신 버퍼(receive buffer)를 전송 계층(300)으로 보내는 것을 멈추거나, 버퍼를 수신하고, 애플리케이션 이들을 대기열에 넣고 전송 계층(300)이 완료 메시지(completion layer; 420)를 송신할 때까지 대기할 것이다.

전송 계층(300)은 오프로드 요청을 거절하거나 오프로드 요청(402)을 네트워크 계층(302)에 TLI 스위치 자원 정보에 추가된 TCP 자원 정보와 같이 보낸다. 전송 계층(300)은 또한 오프로드 핸들을 주변 장치(370)에 제공할 수 있다. 임의의 현저한 애플리케이션 샌드나 계류중인 수신 버퍼가 있다면, 전송 계층(300)은 버퍼를 TLI 스위치(322)로 반환한다.

네트워크 계층(302)는 오프로드 요청(402)을 수신하고, 연결을 오프로드하는 것을 거절하거나 TCP 자원 정보 및 TLI 스위치 자원 정보에 추가된 네트워크 자원와 함께 프레이밍 계층(304)에 오프로드 요청(404)을 보낸다. 네트워크 계층(302)은 오프로드 핸들을 주변 장치(370)에 또한 제공한다.

프레이밍 계층(304)은 네트워크 자원 요청에 추가된 프레이밍 자원 요청, TCP 자원 정보 및 TLI 스위치 자원 정보와 함께 오프로드 요청(406)을 주변 장치(370)로 보내거나 연결을 오프로드하는 것을 거절한다. 프레이밍 계층(304)은 오프로드 핸들을 주변 장치(370)에 또한 제공한다.

주변 장치(370)는 오프로드 요청을 수신하고 그것이 TCP 연결을 오프로드하는데 이용가능한 자원을 가졌는지를 계산한다. NIC가 오프로드가 가능하다고 판단하지 않으면, 오프로드 요청을 거절한다. NIC 오프로드가 가능하다고 판단되면, 그것은 오프로드 요청을 수락하고 자원(예컨대, TCB, RCE(route cache entry), ARP(address resolution protocol) table entry(ATE))를 할당한다. 주변 장치(370)는 매개변수의 링크된 리스트를 생성하고 리스트를 발송해서 계층(300, 302 및 304)에 건네주고, 매개변수의 링크된 리스트를 가지는 완료 메시지(408)를 프레이밍 계층(304)에 보내어서 오프로드 요청을 완료한다. 매개변수는 오프로드 핸들 및 각 계층(300, 302, 304)에 관한 디스패치 테이블(dispatch table)을 포함한다.

본 명세서에서 사용되는 것과 같이, 오프로드 핸들은 소프트웨어 계층이 주변 장치나 소프트웨어와 통신하는 주변 장치와 통신하도록 하는 메커니즘을 의미한다. 예로서, 오프로드 핸들은 포인터 기반 핸들, 어레이에서의 탐색에 사용되는 정수값, 해시 테이블(hash table)(예컨대, 해싱 함수), 소프트웨어 계층(또는 네트워크 스택) 및 주변 장치 사이의 통신 채널 또는 주변 장치가 상태 객체(state object)를 검색하는데 사용하는 소프트웨어 계층에 의해 전달된 일련의 매개변수일 수 있는데, 이에 한정되는 것은 아니다.

예로서, 중간 소프트웨어 계층(intermediate software layer; 300, 302 및 304)과 주변 장치(370) 사이를 통신하는 매커니즘(디스패치 테이블(dispatch table)이라고도 언급됨)은 함수 호출 포인터, 어레이에서의 탐색에 사용되는 것, 해시 테이블(hash table)(예컨대, 해싱 함수), 소프트웨어 계층(또는 네트워크 스택) 및 주변 장치 사이의 통신 채널 또는 주변 장치가 상태 객체를 검색하는데 사용하는 소프트웨어 계층에 의해 전달된 일련의 매개변수일 수 있는데, 이에 한정되는 것은 아니다. 디스패치 테이블은 주변 장치 초기화나 나중에 교환될 수 있다.

디스패치 테이블은 주변 장치(370)에 데이터를 직접 전송하거나, 주변 장치(370)로부터 직접 데이터를 수신하는데 이용된다. 디스패치 테이블은 진단(diagnostics)을 제공하는데도 사용될 수 있다. 예컨대, 소프트웨어 계층은 두 중간 계층 사이나 최하위 중간 계층와 주변 장치 사이에 삽입되어 시스템을 모니터링하고 시스템이 적절하게 기능하고 있는지 확인하기 위한 폴트(fault)를 주입할 수 있다. 추가적으로, 디스패치 테이블은 필요하면 추가적인 기능성을 추가할 수 있는 소프트웨어 계층에 의해 패치될 수 있다. 예를 들어, 소프트웨어 계층은 필터 드라이버나 가상 주변 장치의 기능성을 제공하기 위해 추가될 수 있다. 삽입된 중간 계층에 관한 함수 포인터로 디스패치 테이블을 중복 기입하는 것에 의해 패치가 전형적으로 수행된다. 그 후, 삽압된 중간 계층에 관한 함수 포인터가 호출되고 삽입된 중간 계층이 그 일을 완료한 때에, 삽입된 중간 계층은 원 디스패치 테이블로부터 원함수 포인터를 호출한다.

프레이밍 계층(304)은 완료 메시지를 수신하면, 그 프레이밍 계층(302)을 위 한 디스패치 테이블과 오프로드 핸들을, 용이한 갱신(예컨대, 목적지 MAC 어드레스 변경 또는 캡슐화 유형 변경)을 위한 ARP 테이블 엔트리에 저장한다. 그 다음, 프레이밍 계층(304)은 ATE에 관한 상태를 이용하여 주변 장치(370)를 갱신한다(310). 프레이밍 계층(304)은 연결 리스트에서 자신의 상태를 삭제하고 그 연결 리스트에 남아있는 정보를 (화살표(412)로 표시된 것처럼) 네트워크 계층(302)으로 전달한다.

네트워크 계층(302)은 그 네트워크 계층(302)을 위한 디스패치 테이블 및 오프로드 핸들을 저장한다. 그 다음, 네트워크 계층(302)은 RCE에 관한 상태를 이용하여 (화살표(414)로 표시된 것처럼) 주변 장치(370)를 갱신한다. 네트워크 계층(302)은 연결 리스트에서 네트워크 계층 정보를 삭제하고 디스패치 테이블과 매개변수로 이루어진 연결 리스트를 포함한 완료 메시지를 (화살표(416)로 표시된 것처럼) 전송 계층(300)으로 전송한다. 네트워크 계층(302)은 오프로드 동안 수신했던 임의의 버퍼링된 IP 프레그먼트를 처리용 주변 장치(370)로 전달할 수도 있고, 네트워크 계층 내에서 그러한 IP 프레그먼트를 처리하여 이들을 전송 계층(300)으로 전송할 수도 있다.

전송 계층(300)은 전송 계층을 위한 오프로드 핸들을 저장하고 자신의 상태를 (화살표(418)로 표시된 것처럼) 주변 장치(370)로 전송한다. 그 다음, 전송 계층은 완료 메시지(420)를 전송한다. 이와 다른 실시예에서는, 전송 계층 및 TLI 스위치가 동일한 계층이고 메시지(420)가 필요로 되지 않는다.

또 다른 실시예에서는, 오프로드 요청과 함께 해당 계층의 상태 객체가 전송 된다. 예컨대, 프레이밍 계층 상태 객체, 네트워크 계층 상태 객체 및 전송 계층 상태 객체가 오프로드 요청과 함께 전송되고, 오프로드 요청과 완료 이벤트 간에 캐싱된 상태가 변경되는 경우 단지 갱신된다. 전체 계층 상태 객체는 위임 상태가 존재하지 않거나 오프로드 요청과 그 오프로드 요청의 완료 사이에서 변경될 수 없는 경우 오프로드 요청과 함께 단지 전송될 수 있다. 오프로드 시퀀스 동안 DELEGATED 상태를 변경할 메시지가 수신된 경우라면, 그 메시지는 통상적으로 처리되지 않을 것이고(버퍼링되어야 한다), 오프로드가 완료되면, 처리를 위하여 해당 오프로드 주변 장치로 그 메시지를 전송해야만 한다. 그러나 CACHED 분류된 상태 변수들이 오프로드 요청과 함께 전송될 수 있고 오프로드 요청과 그 오프로드 요청의 완료 사이에 변경될 수 있다. 이러한 경우에는, CACHED 상태 변경에서의 변경 사항이 기록되어야만 하고, 오프로드가 완료될 때, 그 CACHED 상태가 주변 장치 내에서 갱신되어야만 한다.

일단 TLI 스위치(322)가 완료 메시지(420)를 수신하면, 그 TLI 스위치(322)는 애플리케이션 송수신 버퍼(application send and receive buffers)를 (화살표(422)로 표시된 것처럼) 주변 장치(370)로 전송한다. TLI 스위치(322)는 디스패치 테이블을 이용하여 현재의 그리고 장래의 모든 수신 버퍼들을 포스팅하고 처리를 위하여 NIC(370)에 신호를 보낸다. 오프로드 요청이 완료되기까지 걸리는 시간 동안, 각 계층(300, 302, 304)은 그 오프로드된 상태 객체(즉, 어느 계층에 관한 상태 객체)에 대한 새로운 오프로드 요청을 거절하거나 그 오프로드가 완료되기까지 이들을 큐잉한다. 이와 다른 실시예에서는, 애플리케이션 버퍼가 초기 오프로드 요청에 포함되어 전달된다.

전송 계층(300)은 여전히 유입 TCP 데이터를 처리할 수 있고 전송 상태 객체가 초기 오프로드 요청(402)에 포함되어 주변 장치(370)로 오프로드되지 않았다면 그 TCP 페이로드를 TLI 스위치(322)로 전달할 수 있는 능력을 갖추고 있을 수 있다. 이 후 유입 TCP 데이터가 네트워크 스택(318)을 통하여 도달하는 경우, 그 유입 데이터는 주변 장치(370)로, 그 주변 장치에 의해서 처리되도록 전달된다.

이전에 오프로드된 상태를 참조하는 후속 오프로드 요청이 있을 때, 네트워크 계층(302)과 프레이밍 계층(304)은 이전 오프로드로부터 주변 장치(370)에서 수신했던 오프로드 핸들을 주변 장치(370)로 전해준다. 이는 주변 장치(370)에게 그 주변 장치(370)가 네트워크 계층(302) 및 프레이밍 계층(304)을 위하여 이미 자원을 할당했다는 점을 신호로 알리며, 이에 의해 주변 장치(370) 자원이 보존되고 오프로드 속도가 증가된다.

앞서 언급된 바와 같이, 계층(300, 302, 304)은 그 상태를 주변 장치(370)로 전해준다. 각 상태는 세 가지 유형의 상태 변수, CONST, CACHED 및 DELEGATED를 갖는다. CONST 상태 변수는, 이름에 내포되어 있는 것처럼, 오프로드 접속의 수명 동안 결코 변경되지 않는 상수이다. 따라서, 호스트는 그 접속이 종료될 때 CONST 상태 변수를 계층로 다시 판독할 필요가 없을 것이다. 마찬가지로, 호스트 프로세서는 CACHED 상태 변수를 계속해서 소유하고 호스트 프로세서 내의 CACHED 변수에 대한 임의의 변경 사항이 주변 장치(370) 내에서 갱신된다는 점을 보장한다. 그 결과, 호스트는 기록만 할 것이고 (시스템 진단이 이를 요하지 않는 한) CACHED 상 태 변수를 다시 판독하지 않는다. 그러므로 호스트 CPU는 DELEGATED 상태 변수들의 소유권만을 주변 장치(370)로 전송한다. DELEGATED 상태 변수는 오프로드가 발생한 때 한 번 기록되고, 오프로드가 종료된 때 다시 읽혀진다. 주변 장치(예컨대, NIC)는 DELEGATED 상태 변수들만을 전달하면 되므로, 호스트로의 접속을 다시 전달하는 오버헤드가 감소한다. 또한, 호스트 CPU는 필요한 때에만(예컨대, 통계용으로) DELEGATED 상태 변수들에 대해 주변 장치(370)를 질의한다.

전송 계층(300)을 위한 CONST 상태 변수는 목적지 포트, 소스 포트, 전송 계층 행위를 제어하기 위한 하나 이상의 플래그(예컨대, 윈도우 스케일링이 인에이블되었는지 또는 SACK가 인에이블되었는지), SEND 및 RECV 윈도우 스케일 인자, 원격 종단점(Remote MSS)에 의해서 광고된 초기의 최대 세그먼트 사이즈, 그리고 잠재적 기타 매개변수들을 포함할 수 있다. 앞서 기술된 것처럼, 전술된 각 TCP CONST 변수의 값은 상수이고, TCP 접속의 수명 동안 그 값이 변경되지 않는다.

전송 계층(300)을 위한 CACHED 상태 변수는 TCP 상태 변수와 IP 상태 변수이다. 각 접속별로 네트워크 계층 값들을 겹쳐쓸 수 있게 하는 구성이라면 IP 상태 변수가 전송 구조 내에 포함될 것이 요구될 수 있다. 이들 CACHED 상태 변수로는, 하나 이상의 플래그(예컨대, "Nagle" 알고리즘이 인에이블되어있는지, 또는 TCP "Keep-Alives"가 인에이블되어 있는지)와 "Keep-Alive" 설정(즉, 인터벌, 프로브 수 및 델타), 유효 최대 세그먼트 사이즈(즉 Effective MSS), 초기 디폴트 수신 윈도우(InitialRcvWnd), 주변 장치(370)에 의해서 수신 표시로 복사되는 바이트 수, IPv4를 위한 트래픽 유형에 따라 패킷을 우선 순위화하는 TOS(Type of Service), 그리고 네트워크 내에서 IPv6 패킷이 우선 순위화되도록 하는 최종 트래픽 클래스와 플로우 레이블이 포함된다.

DELEGATED 상태 변수들은 Internet Engineering Task Force(IETF) RFC 793에서 지정된 현재의 TCP 상태, 하나 이상의 플래그(예컨대, 원격 피어에 의하여 접속이 중단되어 차단되었는지), 다음 예상 TCP 수신 세그먼트(즉, RCV.NEXT)에 대한 시퀀스 번호, 수신 윈도우 사이즈(RCV.WND), 제1 비-승인형 데이터에 대한 시퀀스 번호(SND-UNA), 전송될 다음 TCP 세그먼트에 대한 시퀀스 번호, 전송 윈도우 사이즈(SND.WND), 최종 윈도우 갱신에 이용된 세그먼트 시퀀스 번호(SndWl1), 최종 세그먼트 갱신에 이용된 세그먼트 승인 번호(SndWL2), 전송된 최대 시퀀스 번호(SND.MAX), 최대 전송 윈도우(MAZ_WIN) 및 현재 혼잡 윈도우(CWnd)를 포함할 수 있다.

DELEGATED 상태 변수는 또한, 슬로 스타트 임계치(SSTHRESH), 평활화된 라운드 트립 시간(SRTT), 라운드 트립 시간 변동(RttVar), 다음 TCP ACK에서 전송할 타임스탬프 값(TsRecent), 가장 최근 타임스탬프가 수신된 것이 얼마나 오래전인가(TsRecentAge), 동일한 시퀀스 번호에 대해 얼마나 많은 ACK가 수용되었는가(DupAckCont), 전송된 킵얼라이브(keepalive) 프로브의 수(KeepAliveProveCount), 다음 킵얼라이브 만료까지 남은 시간(KeepAlive Count), 다음 재송신 만료시까지 남은 시간(Retransmit TimeoutDelta), 그리고 버퍼링된 수신 데이터로의 포인터(BufferedData - 오프로드 또는 업로드가 진행 중인 동안에 수신된 TCP 데이터)를 더 포함할 수 있다.

네트워크 계층(302)을 위한 CONST 상태 변수는 (IPv4 또는 IPv6 중 어느 하나에 관한) 목적지 IP 어드레스와 (IPv4 또는 IPv6 중 어느 하나에 관한) 소스 IP 어드레스를 포함할 수 있다. 네트워크 계층(302)에 대한 CACHED 상태 변수는 경로 최대 송신 유닛(PathMTU)을 포함할 수 있다. 네트워크 계층(302)을 위한 DELEGATED 상태 변수는 IP 패킷 ID 시작 값을 포함할 수 있다. 프레이밍 계층(304)을 위한 CACHED 상태 변수는 목적지 MAC(Media Access Control) 어드레스, 소스 MAC 어드레스, IETF RFC 2461 Neighbor Discovery를 위한 매개변수(Host 도달가능성 델타 및 NIC 도달가능성 델타), 그리고 헤더의 포맷(예컨대, LLC/SNAP(Logical Link Control/Sub-Network Access Protocol) 포맷 또는 DIX(Digital, Intel, Xerox) 포맷)을 표시하기 위한 플래그를 포함할 수 있다.

네트워크 계층("경로(Path)"라고도 불림) 상태가 복수의 접속 간에 공유될 수 있고 프레이밍 계층("이웃(Neighbor)"이라고도 불림) 상태가 복수의 경로(예컨대, 하나의 라우터를 통과하는 모든 트래픽) 간에 공유될 수 있으므로, 전송 계층 상태는 네트워크 계층 상태 객체를 위한 핸들을 포함할 수 있고 네트워크 계층 상태는 프레이밍 계층 상태 객체를 위한 핸들을 포함할 수 있다. 여러가지 이유에서 이러한 계층 구조가 유지된다. IP ID 네임스페이스가 각 경로마다를 기초로 전체 오프로드된 접속들에 대해 관리되기 때문에, 또는 경로(Path) MTU의 갱신이, 각 TCP 접속마다 이를 개별적으로 설정하기 보다는, 네트워크 계층에서 한번 이루어져서 모든 TCP 접속들에 영향을 줄 수 있기 때문에, 각 접속이 네트워크 계층을 위한 NIC 핸들을 요구할 수 있다. 라우트 갱신이 다음 홉 어드레스를 변경하여 새로운 MAC 어드레스를 포인팅할 수 잇었으므로, 각 경로는 프레이밍 계층 상태 객체를 위한 NIC 핸들을 요구한다. 이러한 계층 구조는 또한 NIC에 의해서 유지될 필요가 있는 상태의 양을 줄인다. 예컨대, IPv4에 대한 ARP 갱신은 IP 어드레스로부터 MAC 어드레스로 매핑을 변경할 수 있다(예컨대, 인터페이스가 서버 상에서 장애 극복하였다(failed over)). 호스트는 캐싱된 변수로서 MAC 어드레스를 보유하므로, 그 캐싱된 상태를 한번 갱신하면 되고 전체 접속은 새로운 인터페이스로 장애 극복된다.

일단 호스트가 TCP 접속을 오프로드하면, 주변 장치(370)가 전송할 패킷들에 대한 패킷 식별자들(예컨대, IP IDs)을 할당하는 역할을 한다. IP ID는 인터페이스 기준별로 또는 계층 상태 객체 기준별로 오프로드된다. 각 경우에 있어서, 주변 장치(370)는 IP ID 네임스페이스의 일부를 할당받는다. 일 실시예에서, 주변 장치(370)는 초기화될 때, 전체 IP ID 네임스페이스의 절반을 할당받고, 호스트 프로토콜 스택은 주변 장치 기준별로 IP_ID 네임스페이스의 자기 부분을 유지한다. 다른 실시예는 경로 기준별로 호스트 프로토콜 스택이 IP_ID 네임스페이스를 유지하도록 해 준다. 주변 장치에는 네트워크 상태 객체가 주변 장치(370)로 전달될 때 사용하기 위한 IP 패킷 ID 시작값이 주어진다. 주변 장치(370)는 전송할 IP 패킷들에 대한 IP ID를 생성하기 위하여 다음의 식을 사용할 수 있다.

Cur_IPID = [(Start_IPID_For_This_Path) + (Counter_For_This_Path) mod32K] mod 64K

Counter_For_This_Path = Counter_For_This_Path + 1

이와 달리, 주변 장치는 정적으로 절반의 네임스페이스를 할당받을 수 있다.

동적으로 IPID 시작 어드레스를 주변 장치(370)로 전달하는 일 실시예가 사용되는 경우, 오프로드된 접속이 업로드되거나 무효가 될 때, 주변 장치(370)는 사용할 다음의 IPID 값을 네트워크 계층로 전달하여 발생하는 다음 오프로드를 위하여 저장하고, 호스트 프로세싱 유닛은 할당받은 IP ID 네임스페이스 일부를 계속 사용한다. 호스트 프로세싱 유닛은 전체 IP ID 네임스페이스를 사용할 수도 있지만, 바람직하게는 네트워크 상에서 IP 패킷들의 최대 존속 기간이 지난 이후에만 그러하다.

주변 장치(370)가 시스템에서 제거되는 경우, 주변 장치(370)가 최대 패킷 존속 기간 이내에 시스템으로 재-삽입되는 경우를 대비하여 주변 장치에서 사용된 마지막 값이 보유될 필요가 있다. 주변 장치(370)가 최대 패킷 존속 기간 이후에 삽입되는 경우, 마지막 값은 보유될 필요가 없다.

주변 장치(370)는 데이터가 수신된 순서대로 수신 버퍼에 데이터를 위치시키고, 오프로드된 접속에 대하여 데이터가 포스팅된 순서대로 애플리케이션 버퍼를 채운다. 다수의 애플리케이션이 수신 버퍼를 포스팅하기 전에 수신 표시(receive indication)를 대기한다. 일 실시예에서 주변 장치(370)는, 데이터가 접속을 위해 도착하였는데, 포스팅된 애플리케이션 수신 버퍼가 없는 경우 사용할 버퍼의 글로벌 풀(global pool of buffers)을 갖는다. 버퍼의 글로벌 풀은 오프로드된 접속들에 대해 이용되며 다음을 구현하는데 사용될 수 있다: 1) TCP 전송 위반 처리(handling of out-or-order TCP transmissions); 2) IP 데이터그램 조각 모음(de- fragmenting IP datagrams); 2) 애플리케이션이 포스팅하는 버퍼들이 제로 카피 알고리즘(zero copy algorithm)을 하기에는 너무 작은 경우, 제로 카피 알고리즘이 아닌 버퍼 카피 알고리즘; 및 4) 애플리케이션이 사전포스팅된(preposted) 버퍼들을 갖지 않는 경우 그 애플리케이션으로 데이터를 지시하기 위한 지시 메커니즘(indicate mechanism). 이와 달리, 버퍼 자원의 효율적인 사용이 문제되지 않는 경우, 버퍼의 접속별 풀(per-connection pool of buffers)이 사용될 수 있다. 이 경우, 버퍼의 글로벌 풀은 오직 애플리케이션이 버퍼를 사전 포스팅하지 않았거나 시스템 자원이 부족한 경우(예컨대, 메모리 내에 애플리케이션 버퍼를 잡아둘 만큼 자원이 충분하지 않은 경우)에만 사용된다.

이제, 도 5a-5d를 살펴보면, 오프로드를 수신한 전형적인 주변 장치(예컨대, NIC)는 오프로드를 나타내는 역 트리 데이터 구조(inverted tree data structure; 500)를 가질 수 있다. 도면들에서, 점선은 주변 장치에 의해 할당된 새로운 상태들을 나타낸다. 도 5a에서, 주변 장치는 ARP 엔트리(502)를 갖는데, ARP 엔트리(502)는 라우트 캐시 엔트리(route cache entry; 504)에 접속되고, 라우트 캐시 엔트리(504)는 TCP 엔트리(506)로서 네트워크 접속에 접속된다. 예를 들면, 모든 네트워크 접속(예컨대, TCP) 트래픽이 라우터로 진행하는 경우, 다음 홉은 항상 동일한 ARP 엔트리(502)가 될 것이다. 라우트 캐시 엔트리(504)가 다음 네트워크 접속 오프로드를 위해 사용될 경우, 오직 새로운 자원이 새롭게 오프로드된 TCP 상태 객체가 된다. 따라서, 호스트 CPU가 네트워크 프로토콜 스택에 대한 오프로드 다운을 개시하는 경우, 자기 상태를 이미 오프로드한 중간 소프트웨어 계층들(예컨대, 네트워크 계층(302) 및 프레임 계층(304))은 이전의 오프로드 요청으로 할당된 오프로드 핸들(offload handle)을 생성하기 위하여 주변 장치를 삽입하기만 하면 될 것이다. 주변 장치(170)는 새로운 자원들(예컨대, TCP 엔트리; 508)을 할당하고, 새로운 자원들의 백업을 위해 오프로드 핸들들을 네트워크 프로토콜 스택으로 전송하기만 하면 된다.

이제 역 트리(500)는 라우트 캐시 엔트리(504)에 접속된 TCP 엔트리(508)를 갖는다(도 5b 참조). 이러한 접근방식은 주변 장치 자원들을 절약하며 오프로드의 속도를 증가시킨다. 또한 캐시 변수 상태가 변경되는 경우, 단 하나의 구조만 갱신하면 된다. 침니(chimney)의 다양한 소프트웨어 계층들에 대해 모든 상태가 단일 엔트리로 오프로드되었다면, 최상 소프트웨어 계층 아래 임의의 상태 갱신에는 복수의 갱신을 필요로 할 것이다.

도 5c는 좀 더 복잡한 구성의 역 트리(500)를 도시한다. ARP 테이블 엔트리(502)를 통과하는 2개의 라우트 캐시 엔트리(504, 510)가 있다. TCP 네트워크 접속들(506, 508)은 라우트 캐시 엔트리(504)를 활용한다. TCP 네트워크 접속들(512, 514)은 라우트 캐시 엔트리(510)를 참조한다. 임의의 ARP 갱신이 발생하면(예컨대, 복수-홈(multi-homed) 서버의 인터페이스가 무상(gratuitous)의 ARP 갱신을 사용하여 페일오버(fails over)한 경우), 오직 엔트리(502)만이 갱신되어야 한다. 이로써 페일오버될 잠재적인 수십 또는 수백만의 접속이 단 하나의 갱신만으로 새로운 인터페이스를 통해 요구되는 주변 장치로 접속된다. 도 5d는 2개의 독립적인 역 트리(엔트리들(502-508)과 엔트리들(510-516))가 라우트 갱신 발생 후 단일의 역 트리(400)로 통합된 것을 도시한다. 라우트 갱신 이전, 라우트 캐시 엔트리(510)에 대한 다음 홉 ARP 엔트리는 ARP 테이블 엔트리(516)이다. 라우트 갱신 이후, 다음 홉 ARP 테이블 엔트리는 ARP 테이블 엔트리(502)이다. 따라서, 역 트리를 사용하면, 프레임 계층, 네트워크 계층 및 전송 계층에 대한 상태가 단일 엔트리로서 오프로드된 경우, 수만 또는 수백만의 갱신보다는 라우트 갱신들이 훨씬 더 효율적으로 처리될 수 있다. 중요한 것은, 역 트리 개념이 한 번에 다중 접속들을 오프로드하는데까지 확장될 수 있다는 점이다.

도 6a 및 6b는 블록 리스트 핸들(block list handle; 또는 "블록 리스트")에 대한 특정 참조를 갖는 본 발명에 따른 추가적인 특징을 도시한 것이다. 일반적으로, 블록 리스트는 침니 오프로드 또는 침니 종료가 진행되는 동안 오프로드 타겟(예컨대, 주변 장치)으로 주어지는 하나의 데이터 구조이다. 따라서, 네트워크 접속을 처리하는 컴포넌트는 "업로드"인 경우 블록 리스트를 호스트로 다시 전송하고, "오프로드"인 경우 주변 장치로 다운 전송하여 참조의 시작점이 임의로 정해지도록 해 준다. 블록 리스트 데이터 구조는 다음 계층 상태 객체(블록 의존)나 동일 계층의 상태 객체들(다음 블록)을 포인팅하는 일련의 포인터들을 포함한다.

좀 더 구체적으로, 블록 의존 포인터들은 계층구조(hierarchy) 내에서 다음의 위쪽 레벨을 포인팅하며, 네트워크 프로토콜 스택 내 중간 소프트웨어 계층들 간에 존재하는 임의의 의존도를 오프로드 타겟에게 알려주기 위해 사용된다. 예를 들면, 이웃(또는 프레임 계층) 상태 객체는, 동일 계층의 TCP 접속에 의존적일 수 있는 경로(또는 네트워크 계층) 상태 객체에 의존적일 것이다. 그러나 다음 블록 포인터는 다른 계층에 있는 동일한 레벨의 데이터 구조를 포인팅한다. 예를 들면, 제1 TCP 접속에 있는 경로(또는 네트워크 계층) 상태 객체는 다른 TCP 접속에 있는 경로 상태 객체를 포인팅할 수 있다.

도 6a는 도 5a-5d에 도시된 바와 유사한 역 트리 데이터 구조를 도시한다. 도 6a의 역 트리는, 상이한 TCP 계층 상태 엔트리들을 갖지만 공통의 경로(또는 네트워크 계층) 상태 엔트리(602)와 공통의 이웃 상태 엔트리(600)를 갖는 2개의 TCP 접속(604, 606; 즉 TCP Conn1과 TCP Conn2)을 도시한다. 한편, 다른 네트워크 접속(608; 즉, TCP Conn3)은 별도의 경로 상태 엔트리(610)를 갖지만, 이웃 상태 엔트리(600)는 공통으로 한다. 전체 시퀀스 계층은, 각 소프트웨어 계층 사이에서 다음 소프트웨어 계층로 접속을 안내하는 일련의 경로 핸들에 의해 정의될 수 있다. 예를 들면, 경로 핸들들(612, 614)은 각각 TCP 상태 객체들(604, 606)을 경로 상태 엔트리(602)로 안내하고, 경로 상태 엔트리(602)는 다시 이웃 상태 엔트리(600)로 안내하는 핸들(616)을 갖는다. 마찬가지로, TCP 상태 엔트리(608)는 경로 상태 엔트리(610)를 포인팅하는 핸들(618)을 갖고, 경로 상태 엔트리(610)는 다시 핸들(620)을 통해 공통의 이웃 상태 엔트리(600)로 안내된다. 본 발명에 따르면, 도 6a는 또한 다음 블록 포인터들에 관하여 표시될 수 있으며, 그에 따라 복수의 네트워크 접속 침니를 한 번에 포함할 수 있다.

도 6b는 블록 리스트 핸들이, 상이한 네트워크 접속들 간에 동시 오프로드(simultaneous offload)를 위하여 다수의 네트워크 접속 블록들을 어떻게 관련시키는지를 도시한 것이다. 도 6a에서와 같이, 도 6b는 다양한 소프트웨어 상태 핸들 들을 포함하는 소프트웨어 계층 블록들에 관한 역 트리를 나타낸다. 공통의 경로 블록(644)과 공통의 이웃 블록(646)을 갖는 TCP 블록들(640, 642)이 도시되어 있다. 세 번째 TCP 블록(648)은 경로 블록(650)과 동일한 이웃 블록(646)을 갖는다. 블록 리스트 핸들은 이웃 블록(646)을 지정하는데, 이웃 블록(646)은 경로 블록(644)을 포인팅하는 의존 블록 포인터(660)를 포함한다. 그러나 도 5a의 이전 역 트리와 대조적으로, 이웃 블록(646)은 다음 블록 포인터(662)를 통해 다른 역 트리 데이터 구조를 포인팅할 수도 있다. 다음 블록 포인터(622)가 없는 경우(예컨대, NULL 값), 이는 블록 리스트 내에 그 역 트리의 그 계층에 다른 역 트리가 없음을 나타내는 신호가 될 수 있다. 마찬가지로, 경로 블록(644)은 역 트리의 완전히 상이한 접속 "분기(branch)"인 경로 블록(650)을 포인팅하는 다음 블록 포인터(644)를 갖는다.

이웃 블록(646)의 경우에서와 같이, 경로 블록들(644, 650)은 둘 다 의존 블록 포인터들(666, 668)과 다음 블록 포인터(664, 670)를 각각 가지며 이로써 경로 블록(650)은 완전히 상이한 역 트리(예컨대, 672)의 상이한 접속 경로를 포인팅할 수도 있다. 또한, 각 TCP 블록들(640, 642, 648)은 동일 역 트리(예컨대, 674) 내에 다른 TCP 블록을 포인팅할 수 있거나 이 트리(예컨대, 672, 676) 내에 더 이상의 블록이 없음을 지시할 수 있는 다음 블록 포인터들(672, 674, 676)을 갖는다. 그러나 이들 포인터들은 정적이지 않다. 즉, 링크들은 경로에 대한 라우트가 변경된 경우, 다음 이웃을 다른 라우트로 변경할 수 있는 것처럼 변경될 수 있다. 이 경우, 예컨대, 경로 블록(650)은 사용하는 이웃 상태 엔트리를 이웃 엔트리1(646) 에서 어떤 다른 이웃(예컨대, 이웃 엔트리2(도시 생략))으로 변경할 것이다. 따라서, 블록 리스트를 사용하면 단일 프로그램 호출로 다중 접속, 경로 및 이웃 엔트리를 오프로드 또는 종료시킬 수 있다.

제한이 아닌 예시로서, 제1 오프로드 요청은 오프로드 타겟(예컨대, NIC)이 각각의 데이터 구조(예컨대, 640, 642, 644, 646등)에 대한 상태(state) 및 핸들(handle)을 할당할 것을 요구하고, 오프로드 타겟의 핸들을 호스트 네트워크 프로토콜 스택에 반환한다. 대체 실시예로는 오프로드 타겟이 TCP 접속 기반마다 상태를 할당하고, 모든 종속 경로(dependent path) 및 이웃 상태를 TCP 접속 상태로 복제하는 것이 있다. 그 후, 오프로드 타겟은 경로 진입을 위한 상태 구조를 할당하나, 경로 상태의 사본을 함유하는 각각의 TCP 상태에 대한 포인터로 상태를 초기화한다. 유사한 루틴이 이웃 상태에 적용될 수 있다. 이는 데이터 전송을 위하여 사용되는 모든 상태가 단일 데이터 구조 내에 포함될 수 있게 하며, 이로 인하여 데이터 전송을 위한 상태 검색(state lookup)의 수를 감소시킨다. 예컨대, TCP 블록(640) 전송 패킷 프로세싱에 대하여, 상태 검색의 수는 3에서 1로 감소한다. 오프로드 타겟이 특정 엔트리에 핸들을 할당한 것이 무효인 경우에는, 상태 객체는 새로운 오프로드 요청이다. 호스트 스택에 의한 이후의 오프로드 요청은 현존하는 경로 또는 이웃 상태 엔트리를 재사용할 수 있다. 블록 리스트(block list)는 각 계층에 대하여 하나의 상태 객체만을 함유할 수 있으며(예컨대, 단일 이웃 상태 객체, 경로 상태 객체 및 TCP 상태 객체), 또는 그것은 도 6a-6b에서 정의된 것보다 더 복잡한 구조일 수 있다. 언급된 바와 같은, 이러한 더 복잡한 구조는, 다중 접 속, 경로 및 이웃 엔트리가 단일 프로그램 호출에서 오프로드되거나 종료될 수 있게 한다.

일단 호스트가 지적한 바와 같이 접속(들)을 오프로드하면, 하나 이상의 소프트웨어 계층이 그들 각각의 상태 객체(들)의 변경을 갱신할 필요가 있을 수 있다. 도 7은 본 발명에서 상태 객체의 캐시된 상태 부분을 갱신하기 위하여 네트워크 프로토콜 스택에 있는 중간 소프트웨어 계층 간에 가능한 신호 순서를 도시한다. 이미 언급된 바와 같이, 이는 소프트웨어 계층이 계층의 CACHED 상태 변수의 변경으로 주변 장치를 갱신할 때 이루어진다. 상태 객체의 CACHED 상태 변수를 갱신하는 것은 중간 소프트웨어 계층 및 주변 장치 상태를 일치하도록 한다.

따라서, 도 7은 각각의 소프트웨어 계층이 주변 장치에 대하여 CACHED 상태 변수를 갱신함에 따라, 각각의 소프트웨어 계층이 미니포트 드라이버(miniport driver; 730)에 도달할 때까지 네트워크 프로토콜 스택을 따라 갱신 신호를 전송하는 것을 도시한다. 예컨대, TCP 계층(720)이 주변 장치에 대하여 CACHED 상태 변수를 갱신할 필요가 있는 경우에는, TCP 계층(720)은 신호(702)를 네트워크 계층(경로)(722)으로 전송하고, 네트워크 계층은 갱신 신호(704)를 프레이밍 계층(이웃)(724)으로 전송하며, 프레이밍 계층이 이번에는 갱신 신호(706)를 네트워크 드라이버 인터페이스 명세(Network Driver Interface Specification: NDIS)(726)로 전송하고, NDIS는 신호(708)를 미니포트 드라이버(730)로 전송한다. 일단 주변 장치에 대하여 CACHED 상태 변수가 갱신된 후에는, 미니포트 드라이버(730)가 신호(710)를 NDIS(726)로 중계하며, NDIS는 TCP CACHED 상태 변수가 주변 장치에 대하 여 갱신되었다는 TCP 계층 신호(signaling)를 위하여 중계(712, 714, 716)의 집합을 지속한다. 대체 실시예로는 CACHED 상태 갱신이, 중간 계층을 통하는 것이 아니라, 오프로드 타겟에 직접적으로 가는 것이 있다.

본 발명은 블록 리스트 데이터 구조를 사용하기 때문에, 이러한 일련의 갱신 및 확인 단계는 CACHED 상태 변수가 초기에 갱신되는 소프트웨어 계층에서만 발생할 필요가 있다. 즉, 예컨대 프레이밍 계층(이웃)(724)이 NIC에 대하여 상태 객체의 CACHED 상태 변수 부분을 갱신할 필요가 있는 경우에는, 단계들(706, 708, 710, 712)만이 발생할 필요가 있을 것이다. 따라서, 네트워크 프로토콜 스택의 상단 소프트웨어 계층은, 프레이밍 계층의 CACHED 상태를 갱신하기 위한 신호 중계에 참여할 필요가 없을 것이다. 블록 리스트에 대하여 다중 접속 상태 변경을 갱신하기 위한 이러한 능력은 또한, 오프로드된 네트워크 접속 각각에 대하여 고도의 접속 통합을 가능하게 한다. 대체 실시예에서, 갱신 통신은 갱신을 수행하는 소프트웨어 계층와 미니포트 드라이버(730) 간에 직접적으로 발생하도록 허용될 수 있다. 그러나 이는 미니포트 드라이버(730)에게 다수의 호출 인터페이스를 필요로 하게 하며, 추가적인 네트워크 프로토콜 계층이 오프로드에 추가됨에 따라 쉽게 확장가능하지 않다.

호스트 CPU 또는 주변 장치가 오프로드된 접속 또는 상태 객체를 종료할 필요가 있는 경우, 본 발명은 유사한 순서의 신호 단계를 제안한다. 예비적 문제로서, 호스트 또는 오프로드 타겟이 오프로드를 종료할 수 있다. 중간 프로토콜 계층은, TCP 접속이 의존하였던 경로 또는 이웃 상태 객체를 무효화 및/또는 종료함 으로써, 오프로드된 TCP 접속을 간접적으로 종료할 수도 있다. 이는 결국 TCP 접속 타임아웃을 야기하거나, 무효화된 경로 또는 이웃 상태 객체 때문에 전송을 할 수 없다는 오프로드 타겟으로부터의 통지(notification)로 귀착하게 될 것이며, 이는 오프로드 타겟이 TCP 접속 오프로드를 종료시키도록 요청하게 될 것이다. 접속 오프로드는 다양한 이유로 종료될 수 있다. 일반적으로, 프로토콜 스택에게 특정 접속을 오프로드하도록 명하는 관리 메커니즘이 존재할 것이다. 관리자가 오프로드되도록 지시한 접속에 대하여 오프로드 타겟이 오프로드의 종료를 요청하는 경우, 호스트는 종료를 승인할 것이며, 이벤트가 관리자를 위하여 로깅(logging)될 것이다.

대안적으로, 네트워크 인터페이스가 고장나면(go down)(예컨대, 미디어 단절(disconnect) 이벤트), 오프로드 타겟은 오프로드된 상태 객체의 종료를 요청해서는 안 된다. 호스트는 정상 신호 이벤트를 통하여 이벤트를 통지받을 것이며, 최고의 행동 방침을 결정할 것이다. 더욱이, 접속이 리셋되는 경우(TCP RST 세그먼트가 수신된 경우 발생함), 오프로드 타겟은 호스트에게 접속 오프로드가 종료되어야 한다는 것을 지시할 것이다. 넥스트-홉(next-hop) 어드레스가 변경된 경우(이웃 상태 객체를 변경시킴), 호스트 스택은 예전 상태 객체가 무효화되기 전에 새로운 상태 객체가 생성될 것을 보장할 것이다. 이는 이웃 또는 경로 상태 객체가 더 이상 유효한지 여부에 대하여 오프로드 타겟이 확신할 수 있게 하며, 호스트 스택으로부터의 경로 및/또는 이웃 상태 객체 갱신에 있어서의 일시적 경쟁 상태(temporary race condition) 때문은 아니다. 대체 실시예로는, 예전 상태 객체가 무효화되기 이전에 새로운 상태 객체가 생성되는 것을 보장하지 않고, 경쟁 상태(race condition)를 다룰 수 있는 오프로드 타겟에 의지하는 것이 있다(즉, 업로드를 요청할 수 있으나, 업로드가 수락되지 않을 것이다).

도 8은, 주변 장치가 오프로드된 TCP 접속의 종료를 요청하는, 네트워크 프로토콜 스택에 있는 중간 소프트웨어 계층들 간에 가능한 신호 순서를 도시한다. 주변 장치가 오프로드를 종료하기로 결정하는 이벤트에서, 주변 장치는 "지시" 함수(호스트 스택에 의해 광고됨)를 호출함으로써 오프로드를 종료하도록 호스트 스택에 요청하며, 주변 장치가 오프로드를 종료하기를 바라는 이유를 포함한다. 이 이유는 다양한 이유일 수 있는데, 긴급 데이터를 수신하였으나 이를 지원하지 않는 것과 같이, 주변 장치가 특정 네트워크 프로토콜 계층 특징을 지원하지 않는 상황을 포함한다. 주변 장치 종료 요청은, 예컨대 미니포트 드라이버(830)로부터 NDIS(826)로의 호출(802)로 시작하는 프로토콜 계층을 통한 일련의 신호(802, 804)에 뒤따르며, 차례로 종료 요청 신호(804)를 TCP 계층(820)으로 전송한다. 일단 호스트가 주변 장치의 종료 요청을 프로세싱하면, 호스트는 미니포트 드라이버(830)에게 요청을 확인하여 종료한다. 일부 업로드 요청은 필수적(즉, 호스트는 항상 업로드할 것임)이고, 일부 업로드 요청은 선택적(즉, 호스트는 업로드할 수 있음)임에 주의하자.

일단 호스트 스택이 오프로드를 종료하기로 결정하면, 도 8은 호스트 스택이 중간 소프트웨어 계층 각각을 통하여 중간 계층에 종료를 경고하는 신호를 전송하는 것을 도시한다. 예컨대, TCP(820)는 네트워크 계층(822)에 종료 신호(810)를 전송하고, 네트워크 계층은 프레이밍 계층(824)에 종료 신호(812)를 전송하며, 네트워크 프로토콜 스택을 따라 신호들(814, 816)이 계속된다. 중간 소프트웨어 계층의 최상위 계층(예컨대, TCP)의 경우에, 일단 TCP 전송 계층(820)(즉, 전송 계층(300))이 종료를 요청하면, TCP(또는 전송) 계층은 오프로드 타겟에 대한 새로운 애플리케이션 전송 또는 수신 버퍼 배치(post)를 중단할 것이며, 주변 장치가 네트워크 접속(들)을 성공적으로 업로드할 때까지 임의의 수신된 TCP 세그먼트를 버퍼링하기 시작할 것이다. 대조적으로, 네트워크 프로토콜 스택에 있는 낮은 소프트웨어 계층 각각은 각각의 계층이 그들의 상태 객체에 대한 최종 의존 블록 리스트 데이터 구조인지 여부를 검사할 것이다. 각각의 중간 계층이 더 이상의 의존 블록을 갖지 않는 경우에는, 각각의 계층이 추가적인 블록 리스트 데이터 구조를 리스트에 추가함으로써 그들 각각의 상태 객체의 종료를 요청할 것이며, 중간 계층의 각각의 상태 객체에 대한 오프로드 타겟 핸들을 포함한다. 추가적인 의존 블록을 가진 경우에는, 상태 객체의 업로드를 요청하지 않고, 다음 계층에게 업로드 요청을 단순히 전달할 것이다. 신호(814, 816) 참조.

오프로드 타겟(예컨대, 주변 장치)이 네트워크 프로토콜 스택을 통하여 요청된 종료를 확인한 경우, 오프로드 타겟은 들어오는 네트워크 접속 데이터를 프로세싱하는 것을 중지하고, 나가는 네트워크 접속 데이터의 프로세싱을 일관된 상태로 이끈다. 미해결의 요청들(즉, 오프로드 종료를 확인하기 이전에 애플리케이션 계층이 네트워크 접속 데이터 버퍼를 배치하였음)에 관하여, 오프로드 타겟은 접속 "업로드"가 "진행중"이라는 상태 신호(840, 842)로 네트워크 프로토콜 스택을 통하 여 다시 응답하며, 버퍼의 소유를 TCP 계층(820)에 반환한다. 임의의 수신된 네트워크 접속 데이터(주변 방치가 원격 컴퓨터(즉, WAN 상의 원격 피어 컴퓨터)에게 이미 수신을 ack하였음)가 존재하나, 호스트의 애플리케이션은 그것을 소비하기 위한 버퍼를 아직 배치하지 않은 경우에는, 주변 장치는 TCP DELEGATED 상태 변수로서 이 배치된 버퍼를 패키징하여 중간 소프트웨어 계층로 반환한다.

어느 경우이든지, 주변 장치는 각각의 중간 소프트웨어 레벨에 대하여 (예컨대, NDIS(826)를 통하여) 각각의 DELEGATED 상태 변수의 제어(예컨대, 신호 852, 854, 856)를 반환하여, 호스트 CPU가 DELEGATED 상태의 제어를 재획득한다. 따라서, 오프로드 타겟은 다양한 계층로부터의 요청된 DELEGATED 상태의 일관된 스냅샷(snapshot)이 만들어졌음을 보장하며, 그 상태를 오프로드블록리스트(OffloadBlockList) 구조와 연관된 상태 구조에 채워넣고, 종료 오프로드 완료 함수(850)를 호출한다. 마찬가지로, 오프로드 블록 리스트 데이터 구조 때문에, 접속 종료 호출은 하나 이상의 접속에 대하여 한 번에 완료될 수 있다.

하나 이상의 NIC 드라이버와 같은, 하나 이상의 물리적 주변 장치 드라이버를 관리하는, 하나 이상의 가상 장치 드라이버(들)가 제공될 수도 있다. 가상 장치 드라이버는 호스트 스택에 대하여 단일 MAC(Media Access Control) 어드레스를 내놓고, 가상 드라이버가 관리하는 하나 이상의 주변 장치 드라이버들과 호스트 스택 간의 매핑을 제공할 수 있다. 또는 가상 장치 드라이버는 하나의(또는 그 이상의) 물리적 주변 장치를 위한 호스트 스택에게 다수의 논리적 인터페이스를 제공하여, 호스트 스택이 존재하는 물리적 주변 장치보다 더 많은 네트워크가 존재하는 것처럼 네트워크 트래픽을 관리하는 것을 가능하게 할 수 있다. 따라서, 호스트 스택이 하나 이상의 가상 장치 드라이버를 보는 방식으로, 주변 장치 드라이버가 추상화되며, 따라서 밑에 있는 하나 이상의 주변 장치 드라이버를 인식하지 않는다. 가상 장치 드라이버는 물리적 장치 드라이버로부터 분리될 수도 있고, 그 내부에 내장될 수도 있음에 주의하자. 대체 실시예에서, 가장 장치 드라이버가 사용되며, 단일 물리적 주변 장치는 다수의 소스 MAC 어드레스를 가능화할 수 있다.

가상 주변 장치는, 모든 호출들을 자신을 통하는 물리적 장치들로 재지정하고, 잠재적으로 시스템에 물리적 주변 장치가 있는 것보다 더 많거나 더 적은 가상 주변 장치가 호스트 스택에 발표하도록 주변 장치 초기화 프로세스에 참여할 수 있게 됨으로써 사용가능하게 된다.

데이터 전송 중에, 주변 장치의 팀 내에서 시스템 페일오버(failover)를 지원을 위하여, 가상 주변 기기는 특정 물리적 장치에 장애가 있는지 여부를 탐지할 수 있다. 이를 지원하기 위하여, 미디어 센스를 상실하였는지를 탐지하는 것 또는, 고정된 간격으로 반복되는 신호의 형태로 된 오프로드된 주변 장치로부터 네트워크 스위치까지의 일정한 중추부(heartbeat)가 상실되었는지를 탐지하는 것을 포함하는 다양한 메카니즘이 존재한다. 주변 장치가 (예를 들면, 신호가 더이상 탐지되지 않음으로 인하여) 중추부가 상실되었다고 탐지한다면, 주변 장치 드라이버는 가상 주변 기기에 이 이벤트를 신호로 전송한다.

본 발명은 가상 주변 장치가 오프로드된 상태 객체를 복구시키고 팀 내의 다른 주변 장치로 네트워크 트래픽을 옮기려는 시도를 할 수 있게 한다. 가상 주변 장치는 다른 물리적 주변 장치에 대한 시스템 페일오버가 일어날 때 호스트 네트워크 스택을 이용하여 스택을 관리하거나, 새로운 프로토콜 오프로드 요청을 중단시키고 새로운 물리적 주변 장치에 직접 상태 객체들을 옮김으로써, 다양한 방식으로 이를 행할 수 있다.

가상 주변 장치가 호스트 프로토콜 스택이 변형 중에 오프로드된 상태 객체 또는 (TCP의 경우)접속을 관리할 수 있게 하도록 선택한다면, 가상 주변 장치는 그 호스트 프로토콜 스택에게 주변 장치로의 연결을 오프로드하는 것을 중단시키고 호스트가 이미 오프로드한 기존의 상태 객체들을 주변 장치로 업로드하라고 요청한다. 가상 주변 장치가 오프로드를 재개할 때까지, 호스트는 이 호스트의 중간 소프트웨어 계층에서의 링크 및 접속들을 프로세싱한다.

가상 장치 드라이버는 하나 이상의 주변 장치의 팀에서 모든 이용가능한 주변 장치에 대한 지식을 가진다. 일단 주변 장치에 장애가 있다면, 가상 장치 드라이버는 접속의 오프로드 및 상태 객체를 수신할 수 있는 새로운 주변 장치를 선택한다. 가상 장치 드라이버가 새로운 주변 장치가 가지 수 있는 자원이 무엇인지 탐지하고 주변 장치에서 임의의 요구되는 상태를 초기화한다. 일단 주변 장치가 초기화되었다면, 가상 장치는 상태 객체의 오프로드를 재개한다.

호스트 스택이 특정 가상 주변 장치에 대한 오프로드를 재개한다면, 이 가상 주변 장치에게 이 장치의 오프로드 기능들을 찾기 위하여 다시 질의한다. 호스트는 새로운 능력 리스트를 이용하여 오프로드될 수 있는 상태 객체 또는 접속을 선택할 것이다. 이는 발표되었던 새로운 주변 장치 기능들에 따라서, 역 트리의 제 어를 전송함으로써(예를 들면, 위임되고, 캐싱되며 일정한 상태 변수들을 전송함으로써) 가상 주변 장치(결과적으로 새로운 주변 장치)로의 접속을 다시 오프로드하는 결과를 일으킬 수 있다. 대안으로, 새로운 물리적 주변 장치가 오프로드를 지원하지 않는다면, 호스트는 이들을 오프로드하는 것을 시도하는 대신에 단순히 중간 소프트웨어 계층을 통해 스스로 접속을 프로세싱하는 것을 계속할 것이다.

대안으로, 가상 주변 장치는 주변장치들 간의 오프로드된 상태 객체들의 변환을 직접 관리하도록 선택할 수 있다. 이러한 과정이 완료되면, 가상 주변 장치는 (오프로드된 상태 객체들을 호스트 프로토콜 스택으로 이동시키는 대신에) 상태는 직접 이동시키면서 여전히 상술한 일련의 이벤트를 이용하여 오프로드 요청을 연기할 수 있고, 시스템 페일오버가 완료될 때 기능들에 대한 임의의 변경을 발표할 수 있다.

특정 상태 객체 및 접속이 오프로드될 수 있더라도, 오프로드 기능들이 변할 때 호스트는 일관된 상태를 유지하고, 호스트는 초기 주변 장치의 시스템 대처 작동 경우에서 새로운 주변 장치를 가지는 매개변수와 재협상할 수 있기 때문에, 본 발명은 주변 장치 장애와 관계 없이, 하나 이상의 상태 객체 또는 접속을 한번에 오프로드하고 업로드하는 새롭고, 강력한 방법을 제공한다.

가상 주변 장치가 하나 이상의 물리적 주변 장치에 복수의 가상 LAN을 지원하도록 구성된다면, 가상 주변 장치는 물리적 장치 초기화를 다시 차단할 것이며, 대신에 하나 이상의 가상 주변 장치를 호스트 스택에 발표하고, 특정 가상 어댑터에 이루어지는 모든 호출이 적절한 가상 LAN 태그 및 물리적 주변 장치에 매핑됨을 보장할 것이다. 오프로드 중에 Virtual ID가 프레이밍 계층 상태 객체에 추가하거나 가상 주변 장치에 대한 새로운 상태 객체를 생성함으로써 초기 오프로드 요청으로 전송된다. 상세히는, 본 발명은 가상 장치가 BlockList 구조에 한 구조를, BlockList의 Framing Layer 구조 바로 아래로, 삽입하거나 Framing Layer BlockList 상태 객체에 VID를 추가하도록 할 수 있다. 전자의 접근법은 가상 주변 장치가 물리적 주변 장치 불투명 데이터를(잠재적으로 벤더 속성 데이터) 지정하도록 할 수도 있다. 접속이 업로드될 때, 추가적인 상태 객체가 오프로드 중에 가상 주변 장치에 의하여 추가되었다면, 가상 주변 장치는 이 구조를 제거하고 Block List의 나머지를 호스트 프로토콜 스택에 건내준다.

지금까지 TCP 접속을 오프로드하고 업로드하는 방법이 기술되었으므로, IPSec 인증 및/또는 암호화에 관련된 계산을 오프로드하는 방법이 기술될 것이다. SA(Security Association)는 보안 서비스를 이 접속이 전달하는 트래픽에 제공하는 단순한 "접속"이다. 2개의 호스트 간의 통상적인 양방향 통신에 보안을 하기 위하여, 2개의 SA(각 방향에 하나씩)가 요구된다. SA는 SPI(Security Parameter Index), IP 목적지 주소, 및 보안 프로토콜(예를 들면, AH(Authentication Header], 또는 ESP(Encapsulating Security Payload]) 식별자로 구성된 트리플(triple)에 의하여 고유하게 식별된다. 기술적으로, AH 및 ESP 보안 모두가 트래픽 스트림에 적용된다면, 2개(또는 그 이상)의 SA가 생성되어 한 방향인 트래픽 스트림에 보안을 제공한다. (통상적인) 두 방향에서 보안이 요구된다면, AH 및 ESP 모두가 이용가능할 경우 잠재적으로 4개의 SA가 필요하다. 설명을 위하여, AH, ESP, 또는 AH 캡슐화 내의 ESP에 대한 SA는 단일한 SA Offload Block으로서 참조된다. SA Offload Block은 네트워크 트래픽의 한방향 또는 양방향 통신에 필요한 SA 상태를 포함할 수 있다. 또한, SA Offload Block은 복수의 SA를 포함할 수 있다. 다음의 설명에서는, 다양한 명령이 언급될 것이다. 이들 명령은 이하 기술될 것이다.

일반적으로, 호스트 스택은 Offload Block 내의 특정 SA가 오프로드될 때, 업로드될 때, 무효화될 때, 리-키될때, 완전한 통합제어(control over)를 유지한다. 호스트 스택 및 오프로드 타겟은, SA 만료에 대한 관대한 및 엄격한 제한 모두에 대한 지원을 포함하는 SA가 무효화될 때에 대한 모든 매트릭을 보유하도록 조정한다. 일반적으로, 이용된 접근법은 IPSec 오프로드 타겟에 대한 타이머 요구사항을 최소화하는 것이다. 관대한 만료 시간 제한은 호스트 스택에 의해 이루어진다. 엄격한 만료는 호스트 스택과 오프로드 모두에 의해 이루어진다 - 호스트 스택은 SA를 삭제하도록 타이머를 보유하며, 오프로드 타겟은 송신되거나 수신된 각 패킷에서의 타임 비교를 하여 엄격한 타임 제한이 초과되지 않았음을 보장한다. 관대한 및 엄격한 바이트 카운트 제한 및 패킷 제한(일련의 수를 래핑하는 것으로부터 보호함)은 오프로드 타겟에 의해 이루어진다.

도 9는 본 발명의 네트워킹 모델 및 컴포넌트를 작성하는 몇몇의 컴포넌트의 내부 관계를 도시한다. 일반적인 동작 중에, 네트워킹된 메세지는 네트워크 스택(902)을 통하여 애플리케이션(900)에 의해 메세지가 네트워크 상의 다른 장치 및 애플리케이션으로 송신되는 주변 장치(904)로 송신된다. 또한, 네트워킹된 메세지 는 주변 장치를 이용하여 다른 장치 및 애플리케이션으로부터 수신될 수 있으며, 그 다음 네트워킹된 메세지는 네트워크 스택(902)으로부터 애플리케이션(900)으로 전달된다. 네트워크 스택(902)은 하나 이상의 중간 소프트웨어 계층(906)을 포함한다. 애플리케이션(900)으로부터 송신된 데이터는 데이터를 패키징하는 것, 신뢰되는 데이터 전송, 및 메세지 다이제스트(digest)의 계산과 같은 데이터에 대해서 수행될 수 있는 특정 동작이 중간 소프트웨어 계층(들)(906)을 통하여 이동한다. 중간 소프트웨어 계층은 전송 계층(908), ("네트워크 계층"이라고도 알려진) 경로 계층(910) 및 ("프레이밍 계층"이라고도 알려진) 이웃 계층(912)을 포함한다. 경로 계층(910)은 오프로드되지 않았던 SA에게 IPSec 동작을 제공함을 유의한다.

스위치(914)는 중간 소프트웨어 계층(들)(906)에 대한 네트워크 스택 동작을 수행하는 것으로부터 프로세싱 유닛(120)을 오프로드하는 데에 이용된다. IPSec 스위치(922)는 중간 계층(906)에 대한 IPSec 동작을 수행하는 것 및/또는 침니(chimney)(916, 918)로부터 프로세싱 유닛(120)을 오프로드하는 데에 이용된다. 스위치(914)가 분리되어 도시되었지만, 스위치(914)는 네트워크 스택(902)의 상위 중간 계층으로 통합될 수 있음을 유의해야 한다. 마찬가지로, IPSec 스위치(922)는 네트워크 스택(902)의 중간 계층으로 통합될 수 있다. 네트워크 스택 동작을 오프로드한 이후에, 데이터가 주변 장치(904)에 대한 침니(916 또는 918)를 통하여 주변 장치(904)에 송신되어 네트워크 스택 동작을 수행한다. 모든 IPSec 동작은 IPSec 스위치(922) 및 침니(920)를 통하여 주변 장치(904)에 송신되어 IPSec 동작을 수행한다. 네트워크 트래픽이 IPSec 스위치(920) 위의 침니(들)(예를 들면, 침 니(916 또는 918))를 통하여 오프로드되었다면 IPSec 스위치(922)를 통한 실제 데이터 전송은 이루어지지 않을 수 있다. 이 경우, 침니(920)를 통하여 IPSec CACHED 상태가 유지되고 오프로드 타겟은 침니(916(또는 918)) 트래픽에 대한 IPSec을 캡슐화/캡슐화해지한다. 이러한 계층구조에서, 중간 소프트웨어 계층 및 IPSec 동작은 호스트 또는 주변 장치에 배타적으로 상주할 필요는 없고 임의의 중간 계층이 완전히 오프로드되거나, 호스트에 남아있거나, 둘다의 조합(예를 들면, 하나 이상의 특정 접속을 오프로드)일 수 있게 한다. 또한, 침니들은 침니들의 위에 또는 침니들 아래에 계층화될 수 있다(예를 들면, IPSEC 침니는 TCP 침니의 위에 또는 아래에 계층화될 수 있고, TCP 침니는 RDMA 침니 아래에 또는 IPSec 침니 위에 있을 수 있다). 각각의 침니(916, 918, 920)는 상부 계층 프로토콜 및 기본적으로 요구되는 프로토콜을 오프로드하는 기능을 제공한다. 예를 들면, IPSec 침니(920)는 IPSec 함수들의 오프로드 및 경로 계층(예를 들면, IPv4 또는 IPv6 기능)와 프레이밍 계층(예를 들면, MAC 계층 캡슐화) 오프로드를 지원한다.

이제 도 10을 참조해 보면, IPSec 침니로의 데이터 전송이 2개의 모드 중 하나로 일어날 수 있다. 제1 모드는 데이터 전송만이 오프로드된 TCP 접속이어야 될 때이다. 이 제1 모드에서, 정상적인 데이터 전송 중에, IPSec 침니 인터페이스는 제어 기능(예를 들면, 리-킹)에만 이용된다. 데이터 전송은 인터페이스(1000)로 나타낸 가장 상위 레벨 침니(예를 들면, TCP 침니(916))로 및 이 침니로부터 직접 일어난다. 제2 모드는 데이터 전송이 오프로드 상태와 오프로드되지 않은 상태가 혼합하여 일어나는 때이다. 데이터 전송이 오프로드된 접속과 오프로드되지 않은 접속을 통하여 (또는 UDP와 같은 다른 프로토콜에서) 일어난다면, 오프로드 타겟은 데이터를 수락하여 2개의 소스: (인터페이스(1002)로 나타낸) IPSec 침니(920) 및 TCP 침니와 IPSec 기능 간의 오프로드 타겟 내의 내부 인터페이스(1000)로부터 암호화/복호화를 할 수 있어야 한다. 상세히는, 아웃바운드 트래픽에서, 압호화되지 않은/인증되지 않은 데이터는 IPSec 침니(920) 또는 자신의 TCP 모듈로의 오프로드 타겟 내부 인터페이스(1000) 중 하나를 통하여 암호화/인증될 오프로드 타겟에 제공될 수 있다. 인바운드 트래픽에서, 오프로드 타겟은 오프로드된 SA에 대한 패킷을 복호화/인증하여 이들이 IPSec 침니 인터페이스(1002)로 전달(hand up)되어야 할지 TCP 오프로드 엔진으로의 내부 인터페이스(1000)로 전달되어야 할 지를 결정하여야 한다.

역 트리 데이터 구조는 도 6a의 역 트리 구조와 유사하다. IPSec 침니(920)는 경로 상태 객체 위에 오프로드 상태의 새로운 계층을 생성하여 SA Offload Block 상태를 캡슐화한다. TCP 접속이 오프로드되고 있다면, 상태 객체는 역 트리의 경로 상태 객체와 TCP 상태 객체 간에 삽입된다. 이는 다음의 쟁점 때문이다. 한 쟁점은 복수의 TCP 상태 객체가 동일한 SA로 매핑될 수 있다는 것이다. 예를 들면, 단일한 SA는 2개의 호스트 컴퓨터 간의 모든 포트 80 트래픽을 보호할 수 있다. 또 다른 쟁점은 복수의 SA가 동일한 경로 엔트리로 매핑될 수 있다는 것이다. 예를 들면, 2개의 호스트 컴퓨터 간에 2개의 서로 다른 SA가 존재한다면, 예를 들면, 하나는 웹 트래픽을 보호하기 위한 것이고 하나는 SMTP 트래픽을 보호하기 위한 것이라면, 둘다 동일한 경로 엔트리로 매핑될 것이다. 또 다른 쟁점은 TCP 상 태 객체가 이와 관련된 보안 정책을 가지지 않을 수 있다는 것이다. 이 객체는 경로 엔트리로 직접 매핑될 수 있다. 다시 말하면, 기기에 적용되는 보안 정책은 특정 서브넷 또는 호스트에 대한 보안이 필요하지 않을 수 있다. 그러므로 목적지가 서브넷/호스트이거나 소스가 서브넷/호스트인 모든 트래픽은 IPSec 보안 요구사항이 필요하지 않게 될 것이다.

도 11은 IPSec 상태 객체를 가지는 역 트리 데이터 구조를 도시한다. 도 6a에서와 같이, 서로 다른 TCP 계층 상태 엔트리들을 가지지만, 서로 다른 IPSec 상태 엔트리(1100, 1102)들을 가지는 2개의 TCP 접속(604 및 606)(즉, TCP Conn1 및 TCP Conn2)이 존재한다. IPSec 상태 엔트리들은 공통된 경로(또는 Network Layer) 상태 엔트리(602) 및 공통된 이웃 상태 엔트리(600)를 가진다. 또 다른 네트워크 접속(608)(즉, TCP Conn3)은 IPSec 엔트리를 가지지 않고 개별적인 경로 상태 엔트리(610)를 가지지만, 공통된 이웃 상태 엔트리(600)를 가진다. 전체 시퀀스 계층구조는 접속을 다음의 소프트웨어 계층으로 지정하는 일련의 경로 핸들에 의해 각 소프트웨어 계층 간에 정의될 수 있다. 예를 들면, 경로 핸들(1104)은 TCP 상태 엔트리(604)를 IPSec 상태 엔트리(110)로 지정하고 경로 핸들(1106)은 TCP 상태 엔트리(606)를 IPSec 상태 엔트리(1102)로 지정한다. 경로 핸들(612 및 614)은 IPSec 상태 엔트리(1100 및 1102)를 각각 경로 상태 엔트리(602)로 지정하고 그 다음 이 경로 상태 엔트리는 이 엔트리를 이웃 상태 엔트리(600)로 지정하는 핸들(616)을 가진다. 마찬가지로, TCP 상태 엔트리(608)는 경로 상태 엔트리(610)를 가리키는 핸들(618)을 가지며, 그 다음 이 경로 상태 엔트리는 핸들(620)을 통해 공통된 이웃 상태 엔트리(600)로 지정된다. 본 발명에 따르면, 도 11은 또한 다음 블럭 포인터에 의하여 한번에 복수의 네트워크 접속 침니를 포함하도록 표현될 수 있다.

도 12는 블록 리스트 핸들(경로 종속성을 나타내는 다양한 다음 및 Dependent 블록 포인터의 컬렉션)이 동시 오프로드 경우 네트워크 연결들 중 일부 네트워크 연결 블록을 어떻게 관련시킬지를 예시한다. 도 11에서와 마찬가지로, 도 12는 다양한 소프트웨어 상태 핸들을 포함하는 소프트웨어 계층 블록에 의하여 역 트리를 나타낸다. 각각의 IPSec 블록(1200 및 1202)를 가진 TCP 블록(640 및 642), 공통 경로 블록(644), 및 공통 이웃 블록(646)이 도시되어 있다. 블록 리스트 핸들은 이웃 블록(646)이 경로 블록(644)을 가리키는 Dependent 블록 포인터(660)를 포함한다고 알려줄 것이다. 경로 블록(644)은 IPSec 블록(1200)을 가리키는 Dependent 블록 포인터(666)를 포함한다. IPSec 블록(1200)은 또한 다음 블록 포인터(1204)를 통해 또 다른 역 트리 데이터 구조를 가리킬 수 있다. 다음 블록 포인터(662)가 사라진 경우(예컨대, NULL 값), 이는 블록 리스트에서 역 트리의 해당 계층에 기타 역 트리가 존재하지 않음을 알릴 수 있다.

경로 블록(644)의 경우에서와 같이, 각각의 IPSec 블록(1200 및 1202)은 각각각의 Dependent 블록 포인터(1206 및 1208)와 각각의 다음 블록 포인터(1204 및 1210) 를 가져서, IPSec 블록(1202)은 또한 완전하게 다른 역 트리의 다른 연결 경로를 가리킬 수 있다. 또한, 각각의 TCP 블록(640 및 642)은 동일한 역 트리 내에 있는 또 다른 TCP 블록을 가리킬 수 있는 다음 블록 포인터(674 및 676)를 가지거 나 트리 내에 더 이상의 블록이 존재하지 않음을 지시할 수 있다. 그러나, 이런 포인터가 정적(static)인 것은 아니다. 즉, 링크들이 예컨대, 임의 경로로의 라우트(route)가 변경될 경우 변경될 수 있으며, 이는 다음 이웃을 다른 라우트로 변경시킬 수 있다. 이런 경우, 예를 들면, 경로 블록(644)은 이것이 사용하는 이웃 상태 엔트리를 이웃 Entry1(646)에서 몇몇 기타 이웃(예컨대, 이웃 Entry2(도시 생략)로 변경할 것이다. 따라서, 블록 리스트의 사용에 의해 다중 연결, 경로, 및 이웃 엔트리가 단일 프로그램 호출로 오프로드 또는 종료될 수 있다.

도 12에 관련하여, 동작하는 동안에, TCP 계층은 2개의 TCP 상태 객체(640 및 642)(즉, 블록)와, TCPConn1을 가리키는 BlockListHandl 및 TCPConn1, 및 TCPConn2를 가리키는 Nextblock을 가진 Conn1 및 Conn2를 포함하는 오프로드 요청을 초기에 생성한다. 미니포트 핸들은 NULL(즉, TCPHndl1 및 TCPHndl2는 NULL임)인데, 왜냐하면 상태가 이전에 오프로드되지 않았기 때문이다. 상태 객체는 IPSec을 요구하는 정책을 가지는 것으로 식별되어서, 오프로드 요청이 IPSec 계층에 전달되도록 한다. IPSec 계층은 하기에 기술된 바와 같이, 연관된 FilterID 및 연관된 SA를 찾는다. 이것은 SA 오프로드 블록 상태를 패키지화하고, TCP 상태 객체(640 및 642)의 DependentBlock 및 NextBlock 포인터를 결정하고, IPSec 상태 객체(1200 및 1202)를 결정한다. 그러면 이것은 오프로드 요청을 IPSec SABlock1을 가리키는 BlockListHndl을 가진 경로 계층에 전달한다. 경로 계층은 IPSec 상태 객체들이 동일한 경로 Entry1에 따른다고 판정한다. 이것은 상태를 적절하게 할당하고, 포인터를 결정하고, BlockListHndl을 PathEntry1을 가리키는 이웃 계층에 전달 한다. 유사한 일련의 이벤트가 이웃 계층에서 발생하여서, 전체 상태 구조가 이웃 Entry1 상태 객체를 가진 오프로드된 타겟으로 전달되도록 한다.

오프로드 타겟이 상태를 오프로드할 것을 동의한다고 가정하면서, 이는 각각의 상태 객체용 불투명한(opaque) 오프로드 핸들을 생성하고, 상태 객체의 해당 값(예컨대, TCPHndl1 및 SABlockHndl1 등)을 설정할 것이다. 완료 루틴이 각각의 계층에 대해 호출될 때, 미니포트 오프로드 핸들은 임의의 나중 요청이 핸들을 포함할 수 있도록 각각의 상태 객체에 대해 호스트 스택 내에 저장된다. 부가적인 오프로드 요청이 동일한 상태의 경우 발생하면, 상태 객체가 할당되고 트리로 삽입되나, 미니포트 오프로드 블록 핸들이 아닌 다른 어떤 상태도 초기화되지 않는다.

IPSec 상태 객체의 내용은 이후의 설계 원리에 기초한다. 한 가지 원리는 폴 기반 알고리즘(poll based algorithms)이 (예컨대, 호스트가 바이트 및 패킷에 관한 관대한 또는 엄격한 시간 제한과, 아웃바운드 유휴 간격(outbound idle interval)을 관리할 수 있게 하기에는) 너무 고가라는 점이다. 또 다른 원리는 고속 링크 상에서 일차적인 Keepalive SA(하기에 기술된 바와 같음)를 소프트웨어로 처리하여, 인바운드 IPSec 패킷의 허용할 수 없이 많은 부분이 소프트웨어에 의해 처리되게 할 수 있다는 점이다. 그러므로, 일 실시예에서 오프로드 타켓은 단일 Keepalive SA(즉, 총 2개의 인바운드 SA)를 처리한다. 그러나, 하나 이상의 Keepalive SA를 가지는 것이 이론적으로는 가능하지만 그 확률은 상당히 낮으며, 이는 필요한 오프로드 타켓 상태를 상당히 증가시키며, 본 발명은 또한 임의 기타 Keepalive SA가 호스트 스택에 유지되게 한다. 다른 원리는 오프로드 타켓의 타이 머 개수가 줄어들어야 한다는 점이다. 구체적으로는, SA용 라이프타임 타이머 및 Keepalive SA를 삭제하기 위한 타이머들은 오프로드되지 않는다.

또 다른 원리는 IPv4 옵션 및 IPv6 확장 헤더의 오프로드 처리가, 빈번하기 않은 사용, 부가된 복잡성, 새로운 옵션/확장이 정의될 가능성, 및 보안 공객의 잠재성의 이유로 인해 바람직하지 않게 보인다 점이다. 그러므로, 호스트 스택은 수신된 IP 옵션/확장 헤더를 처리하고 요구된 IP 옵션/확장 헤더를 생성한다. 이에 대한 예외는 IP 플래그멘테이션과 디플래그멘테이션이다. IP 다이어그램의 플래그멘테이션과 디플래그멘테이션은 UDP 트래픽으로 인해 바람직하게 보인다.

이전에 지시한 바와 같이, 소프트웨어 계층은 하나 이상의 상수 상태 변수, 캐싱된(cached) 상태 변수, 및 위임된(delegated) 상태 변수를 포함할 수 있는 상태 객체를 가진다. IPSec 오프로드 객체는 또한 상수, 캐싱된, 및 위임된 상태 변수를 가진 데이터 구조를 가진다. IPSec 오프로드 객체는 임의 개수의 현재의 SA를 가질 수 있다. 일 실시예에서, 현재의 SA 개수는 주변 장치로 오프로드된 상태 량을 제한하기 위해서 3개로 제한된다.

IPSEC 객체용 CONST 상태 변수는 패킷을 특정 보안 연관(accociation)으로 분류하는데 요구되는 정보와 인바운드 및 아웃바운드 보안 연관에 특정한 정보로 구성된다. CONST 변수는 로컬 및 원격 포트, 로컬 및 원격 IP 주소, 프로토콜 유형, 및 보안 연관 플래그를 포함한다. 로컬 포트(또는 원격 포트) 설정을 0으로 설정하면 로컬 포트(또는 원격 포트)가 와일드카드 포트임을 나타내게 되며, 이는 임의 포트가 사용될 수 있음을 의미한다. 유사하게, 프로토콜 유형이 0이면, 임의 프로토콜이 사용될 수 있다.

보안 연관 플래그는 DynamicSA, InfiniteLife, 및 인바운드 SA용 플래그를 포함한다. DynamicSA 플래그는 SA가 리키링하거나 수동 SA인지 여부에 대한 지시를 제공한다. InfiniteLife 플래그는 SA가 무한대 라이프타임을 가지는지를 명시한다. InfiniteLife 플래그가 지정되지 않으면, 이는 관대한 만료(하기에 설명된 바와 같음)가 도달될 때 리키하는 SA를 위해 리키가 수행된다는 것을 지시한다. 수동 SA의 경우, 지정된 InfiniteLife 플래그는 SA가 영원히 살아 있을 것을 지시한다. InfiniteLife 플래그가 지정되지 않으면, SA는 엄격한 만료가 도달될 때 무효하게 될 것이다. 인바운드 SA용 플래그는 AH 또는 ESP에 대한 재생 체크가 인에이블되어 있는지를 지시하는 InBoundAHReplay 및 InBoundESPReplay를 각각 포함한다.

CACHED 상태 변수는 SA를 첨부, 삭제, 또는 오버라이팅(즉, 교체(replacing))하기 위한 변수와, SA의 라이프타임을 결정하기 위한 변수와, 인바운드 및 아웃바운드 SA에 특정한 정보를 포함한다. CACHED 변수는 연산 코드(opcode), 암호화된 바이트에 기초한 관대한 제한, 및 엄격한 제한, 관대한 만료 및 엄격한 만료되는 패킷 개수에 관한 관대한 제한 및 엄격한 제한, 플래그, AH 및/또는 ESP가 인에이블된 경우에 AH 및/또는 ESP 매개변수, 아웃바운드 유휴 간격(inbound idle interval), 및 기타 변수를 포함한다. NIC는 관대한 및 엄격한 제한에 따르는 것임을 인식해야 한다. 관대한 제한에 도달할 경우, NIC는 호스트 프로세싱 유닛용 네트워크 스택에게 SA를 리키할 것을 경고한다. 엄격한 제한에 도 달할 때, NIC는 보안 연관을 버린다.

연산 코드 변수는 SA가 첨부, 삭제, 또는 교체되어야 하는지를 지시한다. SA가 교체되는 경우, OLDSPI 플래그가 지정된다. 교체된 SA가 인에이블된 AH를 가질 경우, OLDSPI 플래그가 AH SPI로 지정된다. 교체된 SA가 인에이블된 AH를 가지지 않을 경우, OLDSPI 플래그는 ESP SPI로 지정된다. SPI는 IP 주소 마다의 고유한 식별자이고, SA를 식별하는데 사용된다. 이것은 SA가 변수들에 관련하여 동작 중이다란 것을 지시한다.

암호화된 킬로바이트 수가 특정한 제한에 도달하는 때를 비롯하여, 수많은 요인(factor)에 기초하여 관대한 제한에 도달할 수 있다. 그 수에 도달하면, 오프로드 타겟이 호스트 스택에게 경고할 것이고, 그 시점에 SA는 전형적으로 리키된다. 인바운드 SA(즉, 아웃바운드 연결을 위한 아웃바운드 SA에 비교되는 인바운드 연결을 위한 SA)는 리키에 관해 즉시 검증되지 않는데, 왜냐하면 네트워크가 긴 시간 주기 동안 패킷을 저장할 수 있기 때문이다. 오래된 SA상에서 암호화된 및/또는 인증된 모든 패킷이 네트워크로부터 떠나기 위해서, SA가 패킷들이 네트워크로부터 떠나게 되는 주기 동안, Keepalive 상태(즉, keep alive SA)로 이동된다. 전형적으로, 관대한 제한은 SA가 새로운 SA(예컨대, 리키된 것)와 교체되는 시간을 허용하도록 엄격한 제한의 대략 50%로 설정된다. 관대한 제한에서, 리키 프로세스는 개시된다. 암호화된 킬로바이트 수가 특정한 제한에 도달할 때를 비롯하여 수많은 요인에 기초하여, SA가 버려지는 때를 지시하는 엄격한 제한에 도달할 수 있다.

암호화된 바이트 수에 관한 제한과 유사하게, 관대한 만료되는 패킷 수에 관한 관대한 제한은 네트워크 스택이 리키 프로세스를 시작할 것을 경고 받기 이전에 전송된 패킷 수이다. 전송된 패킷 수의 엄격한 제한에 도달하는 경우, SA는 버려진다.

플래그들이, SA가 인바운드 SA인지 혹은 아웃바운드 SA인지 여부, AH가 인에이블되어 있는지 여부, ESP 신임도가 인에이블되어 있는지 여부, ESP 무결성이 인에이블되어 있는지 여부를 지시하기 위해 사용된다. 아웃바운드 유휴 간격이 리키를 개시하는데 사용된다. 아웃바운드 패킷이 SA 상에 보여졌던 마지막 시간이 적어도 아웃바운드 유휴 간격 만큼 많은 시간이었다면, 리키가 개시된다. AH 플래그가 지정된 경우 유효한 AH 매개변수는 AHSPI, AHAlgorithm(AH 무결성 알고리즘 {MD5, SHA1, SHA-256, SHA-384, SHA-512, proprietary1(사적 알고리즘)}), AHKeyLength(AH 무결성 키 길이), 및 AHKey(AH 무결성 키)를 포함한다. conf/intergrity 플래그가 어떻게 지정되는지에 따라 유효한 ESP 매개변수는 ESPSPI, ESPIntAlgorithm(ESP 무결성 알고리즘 {MD5, SHA1, SHA-256, SHA-384, SHA-512, proprietary1}), ESPIntKeyLength(ESP 무결성 키 길이), ESPIntKey (ESP 무결성 키), ESPConfAlgorithm(ESP 신임도 알고리즘 {DES, 3DES, AES-128, AES-192, AES-256, proprietary1}), ESPBlockLength, ESPConfKeyLength (ESP 신임도 키 길이), 및 ESPConfKey(ESP 신임도 키)를 포함한다.

DELEGATED 변수는 실행 정보와, 인바운드 및 아웃바운드 보안 연관에 특정한 정보를 포함한다. DELEGATED 변수는 플래그, SA에 걸쳐 전송되는 바이트의 계수, SA가 유휴에 있었던 틱 수, SA에 걸쳐 전송되는 신임할 만한 바이트 수, SA에 걸쳐 전송되는 인증된 바이트 수, 및 아웃바운드 또는 인바운드 매개변수를 포함한다.

플래그는 SA가 현재 유효한지 여부를 지시하는 유효 플래그를 포함한다. 아웃바운드 및 인바운드 매개변수는 AH가 인에이블되어 있는 경우 AH 매개변수와, conf/integrity 플래그가 어떻게 설정되는지에 따라 유효한 ESP 매개변수를 포함한다. 아웃바운드 AH 매개변수는 LastPacketNum(SA에 걸쳐 전송된 마지막 AH 패킷의 시퀀스 번호)를 포함한다. 아웃바운드 ESP 매개변수는 CurrentIV(현재 초기화 벡터), 및 LastPacketNum(이 SA에 걸쳐 전송된 마지막 ESP 패킷의 시퀀스 번호)를 포함한다. 인바운드 AH 매개변수는 CurrentReplayMap(현재 AH 재생 비트 맵), 및 CurrentReplaySeq(현재 AH 재생 마지막 시퀀스 번호)를 포함한다. 인바운드 ESP 매개변수는 CurrentReplayMap(현재 ESP 재생 비트 맵), 및 CurrentReplaySeq(현재 ESP 재생 마지막 시퀀스 번호)를 포함한다.

현재까지 전반적인 아키텍처 컴포넌트 및 변수가 기술되었으며, IPSec 상태 객체를 오프로드하는 단계들이 기술될 것이다. 주변 장치(904)(예컨대, NIC) 등의 오프로드 타겟은 주변 장치의 능력, 및 스택(902)에 의해 지정된 초기 구성 매개변수를 결합한 데이터 구조를 사용한다. 주변 장치가 명시한 능력은 NIC으로 오프로드될 수 있는 아웃바운드 보안 연관의 개수, NIC으로 오프로드될 수 있는 인바운드 보안 연관의 개수, 및 플래그를 포함한다. 오프로드될 수 있는 인바운드 SA의 개수는 적어도 NIC에 오프로드될 수 있는 아웃바운드 SA의 개수 만큼 많아야 한다. 이 수는 keep alive SA를 고려하기 위해 아웃바운드 SA의 개수의 2배가 될 것(예컨 대, SA 오프로드 블록은 1개의 아웃바운드 SA 및 2개의 인바운드 SA를 가질 수 있음)을 권고하고 있다. 다른 실시예에서, 오프로드 타켓이 그가 지원하는 SA 오프로드 블록의 개수, 및 플래그를 광고한다(advertises). SA 오프로드 블록 매개변수는 아웃바운드 SA, 및 각각의 SA 오프로드 블록용 2개의 인바운드 SA를 가지는 능력을 포함한다.

플래그는 IPSec IPv4 플래그, IPSec IPv6 플래그, 인증 지원 플래그, 및 암호화 지원 플래그를 포함한다. IPSec IPv4 플래그가 지정되는 경우, 오프로드 타켓은 그가 지원하는 모든 인증 및 암호화 알고리즘에 IPv4 지원을 제공해야 한다. IPSec IPv6 플래그가 지정되는 경우, 오프로드 타켓은 그가 지원하는 모든 인증 및 암호화 알고리즘에 IPv4 지원을 제공해야 한다. 인증 지원 플래그는 지원되는 인증 알고리즘을 지시한다. 지원될 수 있는 알고리즘은 MD5_Ah, MD5_Esp, MD5_AhEsp, SHA1_Ah, SHA1_Esp, SHA1_AhEsp, SHA256_Ah, SHA256_Esp, SHA256_AhEsp, SHA384_Ah, SHA384_Esp, SHA384_AhEsp, SHA512_Ah, SHA512_Esp, SHA512_AhEsp, 및 사적 알고리즘을 포함한다. 암호화 지원 플래그는 지원되는 암호화 알고리즘을 지시한다. 지원될 수 있는 알고리즘은 DES_Esp, 3DES_Esp, AES128_Esp, AES192_Esp, AES256_Esp, UMAC_Esp, 및 사적 알고리즘을 포함한다.

스택이 보고된 기능의 임의의 조합을 사용하기로 결정하면, 스택은 초기화 구성 매개변수를 설정할 것이다. 초기화 구성 매개변수는 ReplayWindowSize, EnableSecurityAudit, Idle timeout time, 및 Ticks per Second를 포함한다. ReplayWindowSize는 수신된 패킷이 그 내에 있어야 하는 윈도우 크기를 지정한다. 만약 패킷이 그 윈도우 크기 내에 있지 않으면, 그 패킷은 버려진다. EnableSecurityAudit가 설정되면, 수신 프로세싱에서 에러가 발생하는 경우, 적절한 통계가 갱신된 후에는 패킷이 버려지지 않는다. 대신, 수신 에러에 대한 데이터 버퍼 포맷을 사용하는 IPSecReceiveIndicate 인터페이스를 사용하여 IPSec 계층에 패킷이 전달된다. Idle timeout time은 SA가 유휴상태일 수 있는 시간의 최대 양이다. Ticks per Second는 다른 오프로드 타겟과의 타이밍을 동기화하기 위하여 사용된다.

SA Offload Block의 오프로드를 시작하기 위한 두 가지 방식이 존재한다. 오프로드는 IPSec 모듈(922)에 의해 시작될 수 있고, 또는 중간 계층 스위치(914)에 의해 시작될 수 있다(예를 들어, TCP 침니를 통한 TCP 오프로드 요청의 결과로서). 오프로드 타겟은 SA Offload Block 내의 SA 중 모두 수락하여야 하며, 또는 어떠한 것도 수락해서는 안 된다. 오프로드 시작 요청 내에, 다수의 SA Offload Block이 존재할 수 있다. 오프로드 타겟은 하나의 오프로드 시작 요청 내의 SA Offload Block을 개별적으로 수락 또는 거부할 수 있다.

이제 도 13을 참조하면, SA Offload 블럭을 오프로드하는 단계가 도시된다. 후술되는 설명에서, IPSec 모듈(922)은 TCP 블럭을 포함하는지 여부에 상관없이 오프로드를 요청하는 컴포넌트일 것이다. 도 13에서, 실선은 필수 호출이며, 점선은 (특정 상태에 의존하는) 선택 호출이다. 모든 호출이 비동기적인 것으로 도시되지만, 이것이 필수적인 것은 아니다. 초기 비동기 호출의 리턴을 위한 리턴 화살표는 본 발명의 이해를 혼란스럽게 하는 것을 감소시키고, 이해를 돕기 위하여 도시 되지 않는다. 일 실시예에서, 오프로드 시작 요청(예를 들어, InitiateOffload)은 오프로드될 하나, 둘, 또는 세 개의 SA를 포함할 수 있고, 그것은 최대 하나의 아웃바운드 SA와 최대 2개의 인바운드 SA의 임의의 조합일 수 있다. 프로토콜 스택 아래쪽으로의 호출 시퀀스는 각 계층이 자원을 잠재적으로 오프로드되고 있는 것으로서 플래그할 수 있도록, 임의의 자원 요구사항을 광고할 수 있도록, 오프로드가 성공적인 경우 NIC이 필요로 할 수 있는 업-호출에 대한 임의의 핸들을 광고할 수 있도록, 그리고 네트워크 계층(1322) 및 프레이밍 계층(1324)에서 CONST, CACHED, 및 DELEGATED 상태를 수집할 수 있도록 하기 위한 것이다.

TCP 계층(1320)이 오프로드를 요청하고 오프로드가 IPSec을 필요로 하는 정책을 가질 때, 오프로드가 시작될 수 있다. 이것이 발생하면, 오프로드 요청이 IPSec 모듈(1328)에 전달된다(선(1350)). IPSec 모듈(1328)은 SA Offload Block에 관련된 상태(일 실시예에서 하나의 SA와 3개의 SA까지 사이에 대한 상태를 포함함)를 패키지화하고, 그 상태를 네트워크 계층(1322)에 전송한다(선(1352)). 관련 SA에 대해 전송되거나, 오프로드 상태가 스냅샷된 후 SA에 대해 수신될 임의의 패킷은 오프로드 요청이 완료될 때까지 버퍼링될 것이다. 하나 이상의 SA Offload Block이 단일 호출에서 오프로드될 수 있다는 점을 유의해야 한다. 네트워크 계층은 각 네트워크 상태 객체에 대해 그것의 상태를 패키지화하고(상기 기술된 바와 같이), 그 상태를 IPSec 상태에 추가하며, IPSec 모듈 및 네트워크 계층에 대해 결합된 상태를 프레이밍 계층에 전송한다(선(1354)). 프레이밍 계층은 각 프레이밍 상태 객체에 대해 상태를 패키지화하고, 그 상태를 결합된 상태에 추가하며, 결합 된 상태를 NDIS(1326)에 전송한다(선(1356)). NDIS는 상태들의 Offload Block List(도 12 참조)를 미니포트(1330)에 전달한다(선(1358)). 미니포트(1330)는 오프로드 요청(들)을 수락할 수 있는지를 결정하기 위하여 상태를 조사한다. Offload Block List에 대해 상기 기술된 평가 규칙(즉, 자원의 깊이 우선 만족, 에러 코드가 배치되는 곳, 등)이 적용된다. 이것은 성공적으로 오프로드되는 각 Offload Block 데이터 구조에 대한 Offload Handle의 할당을 포함한다.

오프로드 타겟(즉, 미니포트(1330))이 오프로드를 수락하는 경우, 오프로드 타겟은 요청에 대한 완료 루틴을 호출한다. SA Offload Block이 곧 만료할 SA를 포함하는 경우 오프로드가 시도되지 않음을 유의해야 한다. 완료 루틴은 오프로드 타겟이 상태를 완전히 획득하였고, 언제든지 (TCP 침니 이용 여부에 관계없이) IPSec 데이터를 수신하기 시작할 수 있으며, 수신된 데이터를 호스트 스택에 알릴 수 있음을 나타낸다. 이것은 오프로드 시작 요청이 완료되기 전에 데이터가 IPSec 계층(1328)에 알려질 수 있다는 것을 의미함을 유의해야 한다. 완료 호출은 각 Offload Block에 대한 오프로드 핸들을 리턴한다(선(1360)). 프레이밍 계층은 오프로드 요청에 대한 완료를 수신한다(선(1362)). 오프로드 동안에 목적지 MAC 주소가 변경되면, 이웃 계층은 이웃 상태 객체에 대한 오프로드 핸들을 사용하여 캐싱된 상태를 갱신하기 위하여 오프로드 갱신을 호출한다(선(1364)).

네트워크 계층이 오프로드 요청의 완료를 수신한다(선(1366)). 초기 오프로드 요청과 완료 사이에 경로 MTU(최대 전송 유닛) 갱신이 발생하면, 경로 상태 객체에 대한 오프로드 핸들을 사용하여 오프로드 타겟에 오프로드 갱신 호출이 행해 질 것이다(선(1368)). IPSec 계층(1328)이 오프로드 요청에 대한 완료를 수신한다(선(1370)). 네트워크 계층이 완료 프로세싱을 행한 후, IPSec 오프로드가 요청되지 않은 경우 Offload BlockList에 있는 나머지 데이터 구조들이 IPsec 또는 TCP에 직접 전달되어야 하는지를 결정해야 함을 유의해야 한다. IPSec 캐싱된 상태 중 어떠한 것도 오프로드 요청 동안 변경될 수 없다. 그러나, IPSec 계층은 아웃바운드 또는 인바운드 데이터그램을 버퍼링할 수 있다. 이때, 그것은 임의의 데이터그램을 NIC에 전달하기 위하여 오프로드 타겟에 의해 리턴된 Offload Handle을 사용하는 Offload Forward 인터페이스를 사용할 것이다(선(1372)). 그것은 또한 오프로드 동안에 오프로드 타겟에 포스팅되었던 임의의 아웃바운드 데이터그램을 전달할 것이다(선(1374)).

TCP 계층(1320)이 오프로드를 요청한 경우, 초기 오프로드 요청에 하나 이상의 TCP Offload Block이 존재했다면 TCP 계층(1320)은 오프로드 요청의 완료를 수신한다(선(1376)). TCP 침니(916)에 대한 정상적인 프로세싱이 발생하고, 그것은 수신되어 버퍼링된 세그먼트들이 오프로드 타겟에 전달되거나, 또는 임의의 캐싱된 상태가 변경되는 경우 OffloadUpdate가 발생할 것을 필요로 할 수 있다.

IPSec 상위의 프로토콜 스택 계층(예를 들어, TCP)에 의해 오프로드 요청이 시작되는 경우, IPSec에 대한 BlockList 데이터 구조의 DependentBlock 포인터는 NULL이 아니라는 점(도 12 참조)을 유의해야 한다. SA Offload Block이 이미 오프로드되었다면, IPSec 계층(1328)은 단순히 SA Offload Block에 대한 미니포트 핸들을 이용하여 Offload Block 데이터 구조를 시작할 것이다. 모든 다른 계층(IPSec, 경로, 및 이웃) 프로세싱은 동일하게 유지된다. 이 경우에 대한 기능에 있어서의 주요 차이점은 오프로드 타겟이 오프로드 요청을 어떻게 처리하는지이다. 만약 상위 계층에 대한 오프로드 요청을 수락하기로 선택한다면, 완료 루틴이 호출되는 경우 그 상태 객체를 향하는 임의의 트래픽이 적절한 침니를 통해(즉, IPSec 침니가 아니라) 그 계층에 직접 전달될 것임을 보장해야 한다. 오프로드되지 않는 기타 연결 또는 기타 상위-계층 프로토콜(예를 들어, UDP)에 대한 IPSec 침니 데이터 전달은 변경되지 않은 채 유지된다(즉, SA Offload Block을 사용하는 데이터 이동 및 이벤트 인터페이스가 계속하여 기능함).

동기화에 관하여, IPSec 계층(1328)은 오프로드가 완료될 때까지 인커밍 및 아웃고잉 데이터그램의 제한된 버퍼링에 의해 오프로드 시작 동안에 SA 상태가 변경되지 않음을 보장한다. IPSec 계층(1328)은 지나친 버퍼링이 요구되는 경우 이 타임 프레임 동안 패킷을 버리도록 선택할 수 있다. 만약 그 특정 IPSec 상태, 경로 상태, 또는 이웃 상태에 대해 임의의 부가적인 오프로드 요청(예를 들어, 캐싱된 상태에 대한 갱신, 상태의 무효화, 상위-계층 침니의 오프로드 등)이 발생하는 경우, 및 이들이 아직 오프로드되지 않은 경우, 현재의 오프로드 요청이 완료될 때까지 이들 새로운 오프로드 요청이 차단될 것이다. 오프로드 상태에 대한 임의의 다른 프로세싱이 발생할 수 있기 전에 오프로드 타겟이 각 Offload Block에 대한 Miniport Offload Handle을 리턴해야 하기 때문에 상기 요구사항이 필요하다. 기타 연결, 경로, SA Offload Block, 또는 이웃 구조에 대한 오프로드 요청이 병렬로 발생할 수 있다는 점을 유의해야 한다.

오프로드 타겟(1330)이 오프로드 시작 요청에 대한 완료를 호출한 바로 직후에, 오프로드 시작 요청동안 제공되었던 핸들을 사용하여 수신 데이터를 IPSec 계층(1328)에 알리기 시작할 수 있다. 이것은 IPSec 계층(1328)이 요청의 완료 루틴이 호출되기 전에(및 오프로드 타겟에 대한 미니포르 핸들을 리턴하기 전에) 인커밍 데이터의 프로세싱을 시작할 수 있다는 것을 의미한다. 프로세싱은 오프로드 시작 요청의 완료가 발생할 때까지의 버퍼링을 포함할 수 있다.

오프로드에 대해 어떤 IPSec SA Offload Block이 "최상"인지를 선택하기 위한 IPSec Offload 발견적 방법은 오프로드에 대한 적합성과 결합하여 어느 SA Offload BLock이 가장 많은 트래픽을 가지는지에 상당히 기초한다. SA Offload Block이 오프로드되지 않도록 하는 조건은 대칭이 아닌 인바운드/아웃바운드 SA를 포함하며, 특정 SA에 대한 전달 인터페이스가 지나치게 수행되고 있다. 오프로드가 발생하도록 하거나, 오프로드된 SA Offload Block이 오프로드 타겟에 유지되도록 하는 조건은 SA Offload Block을 통한 많음과 중간 사이의 양의 트래픽 및 SA Offload Block이 의존적 TCP Offload Block을 갖는지를 포함한다.

발생할 수 있는 하나의 쟁점은 곧 만료할 예정이거나 리키의 중앙에 있는 SA를 요구하는 TCP 오프로드 요청이 발생하는 경우이다. 그러한 경우에, 리키가 발생하고 있는 동안 오프로드가 허용될 것이다. 리키가 완료되면, 오프로드 타겟을 갱신하기 위하여 오프로드 갱신 인터페이스가 사용될 것이다. 오프로드 타겟은 관대한 제한(soft limit) 및 엄격한 제한(hard limit)을 시행하며, 이 경우에는 오프로드 시작 요청이 호출될 때 관대한 제한이 이미 도달되었을 것이다. 오프로드 타 겟이 관대한 제한 중 임의의 것을 지난 SA에 대한 오프로드 요청을 수신하면, 관대한 제한에 대한 이벤트를 생성해서는 안 된다. 일반적으로 엄격한 제한을 프로세싱해야 한다. IPSec을 필요로 하는 정책에 의존하는 TCP 오프로드 요청이 발생하지만 IPSec SA 중 어떠한 것도 아직 협정되지 않은 경우, IPSec 모듈은 오프로드 요청을 보류하거나(즉, 나중에 비동기적으로 완료함), 또는 단순히 TCP 침니(916)가 자신이 나중에 다시 시도할 수 있음을 알도록 하는 적절한 이유와 함께 요청을 허용하지 않을 수 있다.

여러 이유로 연결이 IPSec 드라이버에 의해 업로드될 수 있다. 이 이유들은IPSec 계층에 의해 IPSecOffloadForward 인터페이스를 통해 너무 많은 데이터가 오프로드 타겟에 전달되고 있다는 것, 이웃 엔트리 없음, 경로 엔트리 없음, 오프로드 타겟에 대한 매체가 연결되지 않음(이 표식은 IPSec 계층(1328)에 의해 직접 수신되어 적절히 프로세싱될 것이며, 따라서 오프로드 타겟은 모든 표식에 대한 업로드를 생성하지 않음), 호스트 스택이 이미 오프로드된 SA Offload Block을 추가 또는 대체하려고 시도하였는지, 및 호출을 실패한 오프로드 타겟, 정책 변경, 관리 제어, 및 낮은 대역폭 연결(많은 데이터가 전달되고 있지 않음)을 포함한다.

SA Offload Block의 오프로드가 종료(즉, 호스트 스택으로 다시 업로드)될 수 있는 두 가지 방식이 존재한다. 미니포트가 업로드를 시작할 수 있고, 또는 호스트 스택이 업로드를 시작할 수 있다. 호스트 스택의 업로드 시작은 IPSec 계층 상위의 계층에 의해, 또는 IPSec 계층 자체에 의해 시작될 수 있다.

의존적 TCP 상태 객체의 참조 카운트가 0가 될 때까지 특정 SA Offload Block이 업로드되는 것을 방지하는 오프로드된 TCP 연결이 존재할 수 있다(오프로드 타겟이 TCP 침니를 지원하는 경우)는 점을 유의해야 한다. 이것은 오프로드된 모든 TCP 상태 객체가 IPSec Offload 상태 객체가 업로드되기 전에 업로드될 것이라는 것을 보장한다. 따라서, IPSec 침니와 TCP 침니 둘 모두 지원하는 오프로드 타겟은 TCP "Upload All"을 미리 수행하지 않고서는 IPSec "Upload All"을 수행할 수 없다(즉, 그것은 모든 상태가 업로드됨을 보장하기 위하여 IPSec 침니에게 요청하기 전에 TCP 침니에 "Upload All"을 수행해야 한다).

일 실시예에서, 지원되는 유일한 업로드는 호스트 스택이 업로드를 수행하기 위하여 상당한 양의 시간이 걸릴 수 있는 "느린 업로드(lazy upload)"이다. 오프로드된 상태 객체를 갖는 모든 상위 계층 침니를 IPSec 계층이 추적할 필요가 없도록 이 최적화가 행해진다. 오프로드 타겟이 필수 업로드를 야기할 수 있고, 오프로드된 SA Offload Block에 의존하는 여러 상위 계층 침니 객체가 존재했다면, SA Offloac Block이 업로드될 수 있기 전에, 모든 상위 계층 침니가 자신의 상태를 먼저 업로드해야할 것이며, 또는 IPSec 상태가 데이터 전달의 중간에 업로드되는(단지 무효화되는 것이 아님) 상위-계층 침니를 오프로드 타겟이 수용할 수 있어야 할 것이다. 추적될 필요가 있을 호스트 네트워크 스택 상태가 SA Offload Block 별로 매우 클 수 있으며, 오프로드된 SA 오프로드 블럭의 수에 따라 스케일된다. 예를 들어, SA Offload Block 별로 100,000개의 TCP 연결이 존재했고, 여러 SA Offload Block이 존재했다면, 이것은 TCP 연결이 업로드될 필요가 있다는 것을 알릴 수 있도록 호스트 스택에 의해 많은 양의 상태가 저장 및 추적되도록 할 것이다. 본 발 명의 실시예는 대신 IPSec 상태 객체를 "업로드가 필요함"으로 표시한다. 그러면 주기적 타이머가 상위 계층 침니에서 오프로드된 상태를 재평가하기 위하여 시동된다. 타이머는 임의의 의존적 IPSec 상태 객체가 업로드를 요청하였는지를 알기 위하여 오프로드된 연결을 "순회한다(walk)". 업로드가 요청되었으면, 상위 계층 침니가 상태를 업로드할 것이다. IPSec 상태 객체의 참조 카운트가 0이 되면, IPSec 상태 객체 또한 업로드된다. 따라서, 오프로드 타겟은 실제 업로드를 기다리는 동안 SA Offload Block을 통해 데이터를 계속하여 전달해야 한다. 카드 리셋, 전력 상태 변화(즉, 오프로드 타겟이 오프로드된 상태를 유지하도록 허용하지 않는 레벨로 전력 상태가 변하고 있음), 다른 오프로드 타겟에 "소속된(teamed)" NIC에 대한 장애극복 이벤트, 또는 오프로드된 모든 SA가 업로드될 것을 필요로 하는 오프로드 자원의 관리상의 재할당을 포함하는 몇 가지 이유로 모든 SA의 업로드가 필요할 수 있다.

이제 도 14a-b를 참조하면, Terminate Offload에 대한 호출 시퀀스가 도시된다. 오프로드 타겟은 오프로드의 종료를 선택적으로 요청할 수 있고(도 14a), 또는 IPSec 계층의 상위 계층(예를 들어, TCP)이 자신의 상태의 종료를 요청할 수 있다. SA Offload Block 참조 카운트(하기에 기술됨)가 0이 되면, SA Offload Block이 종료될 수 있다. 요청이 무엇으로부터 발생되었는지에 관계없이, Terminate Offload 명령을 실제로 수행하는 것은 IPSec 계층이다.

도 14a는 오프로드의 종료를 요청하기 위해 오프로드 타겟이 취하는 단계들을 도시한다. 이전 세션에 리스팅된 임의의 하나 이상의 이유 때문에, 미니포트 (1330)는 SA Offload Block(하나의 SA과 세 개의 SA 간에 포괄적으로 포함됨)을 업로드하기로 결정한다. 미니포트는 SA Offload Block 핸들 및 이유 코드를 특정함으로써(선(1400)), 오프로드 종료 요청을 나타낸다. 오프로드 종료 요청이 처리되는 동안, 오프로드 타겟은 송수신 데이터그램 요청을 계속 처리해야한다. NDIS는 이 SA Offload Block에 대한 IPSec 콘텍트로 IPSec에 대한 사전 등록 업로드 표식 핸들러(pre-registered upload-indicate handler)를 이용하고, 업로드 표식를 IPSec 계층(1328)에 송신한다(선(1402)). IPSec 계층은 업로드 표식를 획득하고, 요청을 완료한다(선(1404)). 업로드 요청 이유 및 SA Offload Block을 위한 종속 TCP 오프로드된 상태 객체가 존재하는지에 따라, 오프로드 종료 요청이 개시될 수 있거나 그 요청을 개시하지 않도록 결정될 수 있다.

이제 도 14b에서, IPSec 계층(1328)은 SA Offload Block을 위해 갖고 있는 PATH 핸들로 네트워크 계층에 대한 오프로드 종료를 호출한다(선(1410)). IPSec 계층은 이 SA Offload Block에 대해 어떤 추가적인 호출(예를 들어, 갱신, 송신 또는 추가적인 종료 요청)도 호출되지 않을 것임을 보장한다. 이 PATH에 대한 참조 카운트가 1이면(즉, 오프로드 종료 요청이 값을 0으로 낮춤), 네트워크 계층(1322)는 블럭 리스트에 자신의 OffloadBlock(추가적인 오프로드 핸들로 구성됨)을 추가할 것이다. 그것이 핸들을 추가할지 않을지에 상관없이, 그것은 적절한 이웃 핸들로 프레이밍 계층(1324)에 호출을 내릴 것이다. 네트워크 계층이 오프로드를 요청했으면, 프레이밍 계층(1324)은 네트워크 계층(1322)과 같은 단계들을 따를 것이다. 프레이밍 계층이 오프로드를 요청하는지에 상관없이, 그것은 NDIS를 호출할 것이다(선(1414)). NDIS는 블럭 리스트로 미니포트를 호출한다(선(1416)). 오프로드 타겟(1330)은 SA 상태를 패키지화하여 호스트 프로토콜 스택에 리턴한다. 이것은 상태가 일관성 있다는 것을 보장해야 한다. 미니포트(1330)는 OffloadBlockList 내의 유효한 핸들들에 관련된 임의의 상태/자원(TCP, PATH 및 이웃 엔트리)을 자유롭게 해야 한다.

미니포트는 오프로드 종료 요청을 완료한다(선(1420)). 완료 전에, UPLOAD_IN_PROGRESS 호출(예를 들어, OffloadSend, OffloadUpdate 등)로 SA Offload Bloack에 대한 모든 미해결 요청들을 완료하고, 완료될 임의의 OffloadReceiveIndicate 호출을 기다려야 한다. 그것이, 종료 요청을 위한 완료 인터페이스를 호출한 후, 그것은 관련 상태를 재사용하도록 하기 위해 곧장 자유로워진다. 상태가 호스트 프로토콜 계층(예를 들어, 네트워크 스택(902))에 다시 전달되면, 업로드된 SA Offload Block 내에 있었던 SA에 대해 수신된 모든 데이터그램은 통상적인 NDIS 인터페이스를 통해 송신되어야 한다. 요청 완료는 스택을 잘 작동하게 하고, 각 계층에의 오프로드된 상태는 복구된다(선(1422, 1424, 1426)).

SA를 위해 오프로드된 TCP 상태 객체가 존재하면, IPSec 침니(922; IPSec Chimney)는 오프로드의 일시적 종료를 지원하지 않는다. 그 대신에, 느린(lazy) 접근법이 취해진다. IPSec 계층(1328)이 종료될 종속 TCP 상태 객체 모두를 기다리는 동안, IPSec 상태 객체는 무효하다. 주기적으로, TCP 스택(1320)은 적소에 있는 필터들이 여전히 적절한 것인지를 재검증할 것이다. 그들이 적절하지 않으면, TCP는 TCP 상태 객체의 오프로드를 종료할 것이다. 모든 TCP 상태 객체가 종 료되면, IPSec 계층(1328)은 SA Offload Block의 오프로드를 종료할 것이다.

앞서 제시된 바와 같이, IPSec 계층(1328)은 SA Offload Block 참조 카운트를 갖는다. 이에 대한 이유는, 오프로드 타겟이 TCP 침니 및 침니의 다른 유형을 지원하면, 그 계층이 자신의 상태 객체에 대한 오프로드의 종료를 요청할 수 있다는 것이다. IPSec은 매 SA Offload Block 기초에 대한 참조 카운트(즉, SA Offload Block 참조 카운트)를 갖는다. 종속적인 상태 객체에 대한 새로운 오프로드 요청 각각에 대해서, IPSec는 참조 카운트를 증가시킬 것이다. 종속적인 상태 객체의 종료 각각에 대해서, IPSec는 참조 카운트를 감소시킬 것이다. 단일 참조 카운트를 갖는 것은 IPSec 계층 자신이 오프로드를 시작했는지에 대해 나타내지 않는다는 것을 명심해야 한다. 모든 종속적인 블럭들이 업로드됐을 때, IPSec 계층이 업로드하길 원한다는 것을 반드시 의미하는 것은 아니다. 증가 되더라도, IPSec은 참조 카운트가 상위 계층에 의해 증가됐는지와 그것 스스로 증가했는지 간의 차이를 말해줄 수 없기 때문에, IPSec가 오프로드 작업을 요청했을 때, 참조 카운트를 단순히 증가시키지 않는다. 이러한 시나리오를 처리하기 위해, IPSec이 SA Offload Block를 그것이 시작한 오프로드로 표시하도록 하는 개별적인 내부 플래그가 이용될 수 있음으로써, 제어가 유지된다.

네트워크 스택(예를 들어, 네트워크 스택(902))은 오프로드 종료 중간에 SA Offload Block에 대한 IPSec 데이터그램을 수신할 수 있다. 이것은, 오프로드 타겟이 종료 이벤트에 응답하여 자신의 위임 상태를 패키지화할 때 및 IPSec 데이터그램이 하나의 종료된 SA에 도착할 때 일어날 수 있다. 오프로드 타겟은 통상적인 NDIS 경로를 통해 그들을 호스트 스택에 전달하는데, 이는 그것이 위임 상태가 패키지화된 후에는 입력 데이터그램을 처리할 수 없기 때문이다. IPSec 계층이 아직 완료 메시지를 수신하지 않았으면, IPSec 계층은 오프로드 종료 완료 메시지를 수신할 때까지 수신된 데이터그램을 버퍼링하고 있다가 정상적으로 데이터그램을 처리할 것이다. 데이터 전송 인터페이스는 부분적으로 처리된 데이터그램이 오프로드 타겟으로부터 옵션/확장 헤더 프로세싱을 위한 호스트로 송신되게 한다. 이 프로세싱 중간에 업로드가 일어나면, 호스트 스택은 단순히 이 프로세싱을 인수받을 것이다.

앞서 언급된 바와 같이, IPSec 침니(922)는 데이터 전송을 위한 2개의 모드를 지원한다. 한 모드는 IPSec 계층(922)이 침니의 상위 에지(edge)이고 모든 데이터 전송이 데이터그램의 유닛에 있는 경우이다. 다른 모드는 IPSec 침니가 다른 침니(즉, TCP 침니(916)) 내에 임베딩된 경우이다. 두 모델 모두가 동시에 이용가능할 수 있음을 명심해야한다(도 10 참조). 몇몇의 이유로 인해 IPSec 침니와 오프로드 타겟 간의 데이터 전송이 일어날 수 있다. 그 이유에는 다음과 같은 것들이 포함된다: 오프로드되지 않은 SA들 상에서 송수신하기 위한 통상적인 소프트웨어 스택을 이용, 적용되는 SA가 오프로드되면 오프로드 타겟에 IP 데이터그램을 직접 송신하는 IPSec 계층, 오프로드된 SA로 향해 있는 IPSec 데이터 그램을 수신하고 IPSec 데이터그램을 처리할 오프로드 타겟으로 전송하는 IPSec 계층, 오프로드된 SA를 이용하는 데이터그램을 수신하고 데이터그램을 위해 오프로드된 보다 높은 레벨의 침니가 없는 오프로드된 타겟, 및 IPSec 계층에 복호화된/인증된 페이로드 를 송신하는 오프로드 타겟.

동작 동안, 상위 계층 프로토콜(예를 들어, UDP 또는 TCP)은 IPSec에게 전송하기 위해 포매팅된 데이터그램을 전달한다. SA Offload Block을 위한 미니포트 오프로드 핸들과 함께 버퍼 리스트를 오프로드 타겟에 전달하는 데 비동기 인터페이스가 이용된다. 버퍼 리스트가 재사용될 수 있을 때(즉, 전송이 완료되면), 오프로드 타겟은 비동기 요청을 완료한다. 앞서 제시된 바와 같이, 메시지 및 데이터그램을 포함하는 데이터를 전송하는 데 버퍼가 이용된다. 오프로드 타겟에 버퍼는 IPv4 옵션 프로세싱 및 IPv6 확장 헤더 프로세싱의 통고와 함께 곧바로 포스팅된다. IPv6 확장 헤더 또는 IPv4 옵션을 송신하기 위해 임의의 애플리케이션 트래픽이 요구될 수 있기 때문에, IPv6 확장 헤더 또는 IPv4 옵션을 전송하는 것은 보호될 필요가 있다. IPSec IPv6 데이터그램의 전송을 위해, 호스트 프로토콜 스택은 IPv6 확장 헤더를 생성하고, 그들이 아웃고잉 데이터그램의 일부로서 전송되는 OffloadSend의 일부로서 오프로드에 전달한다. 유연성을 최대로 하기 위해, OffloadSend에 포인터가 2개 포함되는데, IPv6 확장 헤더로의 하나의 포인터는 IPSec 확장 헤더(들)(AH를 위한 것 및 ESP를 위한 것의 2개가 있을 수 있음을 명심해야함) 앞에 삽입되고, IPv6 확장 헤더로의 또 다른 포인터는 IPSec 확장 헤더 뒤에 삽입된다. IPSec IPv4 데이터그램의 전송을 위해, 호스트 프로토콜 스택은 IPv4 옵션을 헤더를 생성하고, 그들을 그들이 아웃고잉 데이터그램의 일부로서 전송되는 OffloadSend의 일부로서 오프로드 타겟에 전달한다. 아웃고잉 데이터그램에 삽입되는 IPv4 옵션 헤더를 가리키고 있는 단일 포인터가 OffloadSend 내에서 이용된다. 오프로드 타겟이 IP 프래그먼트를 지원하면, IP 옵션/확장 헤더는 매 매킷 내에 복제되어야 한다. 모든 전송 헤더들이 데이터그램 내에 이미 배치됐기 때문에, 순서화된 전송이 엄격하게 요구되지 않음을 명심해야 한다. 그러나, 상위 계층 프로토콜들이 최대 성능을 보임을 보장하기 위해 순서화된 전송이 강하게 추천된다.

IPv6 확장 헤더가 오프로드 타겟에서 수신된 데이터그램 상에 존재하고 제1 헤더가 IPSec이 아니면, 오프로드 타겟은 통상적인 데이터경로를 거쳐 호스트 스택에 데이터그램을 전송해야 한다. 호스트 스택(902)은 IPSec 헤더가 발견될 때까지 확장 헤더를 처리한 후, 데이터그램을 IPSec 모듈(922)로 전달할 것이며, 여기서 IPSec 모듈(922)은 OffloadForward 인터페이스를 이용하여 그것을 모든 IP 확장 헤더들과 함께 오프로드 타겟(904)에 송신할 것이다. 그 후 오프로드 타겟은 IPSec에 대한 IPSec 확장 헤더 프로세싱을 수행한다. AH가 이용가능하면, 모든 IPSec 확장 헤더는 데이터그램 검증(즉, 불변한 및 변할 수 있는 필드에 대한 해싱(hashing))을 이용가능하게 하도록 존재 되어야 함을 명심해야 한다. 오프로드 타겟이 행해질 때 IPv6 확장 헤더가 하나도 남아있지 않으면, 오프로드 타겟은 IP 헤더 전체 또는 일부분을 포함하는 패킷 포맷의 IPSecOffloadReceiveIndicate를 호출한다. 좀 더 많은 IPv6 확장 헤더가 존재하면(IPSec 확장 헤더 뒤에), 오프로드 타겟은 처리되지 않은 확장 헤더 및 애플리케이션 페이로드(복호화된/인증된)를 포함하는 패킷 포맷의 IPSecOffloadReceiveIndicate를 호출한다.

제1 확장 헤더가 IPv6이면, IPSec가 아닌 확장 헤더가 발견되거나 ULP 헤더 가 발견될 때까지 오프로드 타겟은 IPv6 헤더(들)를 처리한다. IPSec가 아닌 확장 헤더가 발견되면, 페이로드 타겟은 IP 헤더 전체, 암호화된/인증된 ULP 페이로드 및 다음 IPv6 확장 헤더까지의 오프셋을 포함하는 패킷 포맷의 IPSecOffloadReceiveIndicate를 호출한다.

수신 상에 IPv4 옵션이 존재하면, 오프로드 타겟은 수신된 데이터그램을 통상적인 NIC 인터페이스를 통해 호스트 스택(902)에 전달해야 한다. 호스트 스택이 옵션을 처리하고, 처리할 데이터그램을 IPSec 모듈(922)에 송신한 후, IPsec 모듈(922)은 표현된 모든 옵션들이 존재하는 IPSecOffloadForward 인터페이스를 통해 오프로드 타겟(904)에 데이터그램을 전달할 것이다. 오프로드 타겟은 전달된 패킷 상에서 IPv4 옵션 프로세싱을 수행하지 않으며, AH가 이용가능한 경우에만 IP 옵션들을 이용한다(즉, 그것은 AH 해싱에 대한 IPv4 옵션(불변의 것 대 쉽게 변하는 것)들을 파싱하거나 ESP에 대한 IPSec 헤더를 발견할 수 있어야함). IPSec 옵션을 처리한 후, IP 헤더 및 ULP 복호화된/인증된 페이로드는 처리되지 않은 임의의 IP 옵션들까지의 오프셋으로 호스트 스택으로 다시 전달된다(즉, IPSec 헤더(들) 뒤 언디든지).

상위 계층 프로토콜이 TCP가 아니면, IPSec 침니는 오프로드 타겟이 IP 프래그먼트를 생성하게 할 수 있다. 예를 들어, TCP는 변할 때 경로 MTU에 매칭하도록 자신의 아웃바운드 버퍼를 재분할할 것이지만, UDP는 그렇지 않을 것이다. 그러므로, 송신 경로를 통한 데이터 그램 크기가 경로 MTU를 초과하면, 오프로드 타겟은 IPv4 프래그먼트를 생성할 수 있어야 한다. IPSec 데이터그램의 수신을 위해, 다 음 헤더가 IPSec 헤더(IPv4)이거나 확장 헤더(들)가 IPSec 확장 헤더(IPv6)를 포함하면, IP 프래그먼트(IPv4 또는 IPv6)는 오프로드 타겟에 의해 처리되어야 한다. 그러나, 오프로드 타겟이 경계된 총 버퍼링양을 갖기 때문에, 데이터그램이 도착하고 이용가능한 IP 디프래그먼트 버퍼 공간이 없으면, 오프로드 타겟은 패킷을 버려야 한다. 그 대신에, 통상적인 NIC 데이터 경로로 그것을 송신(시도)해야한다. 추가적으로, 오프로드 타겟은, 데이터그램이 통상적인 경로로 송신된 후 데이터그램이 인터넷 패킷 수명 동안 (전형적으로 120초) 통상적인 경로로 송신될 때 같은 프래그먼트 ID를 갖는 나중에 도착한 또는 이미 그것의 디프래그먼트 버퍼 내의 모든 프래그먼트들을 전달해야 한다. 오프로드 타겟이 호스트 스택으로 전달된 IP 프래그먼트 ID를 추적하기 위한 공간을 다 써버리면, 그것은 모든 프래그먼트를 호스트 스택으로 전달해야 한다. 호스트 스택에 송신된 IP 프래그먼트를 추적하는 데 관련된 상태가 명확하기 때문에, 디프래그먼트를 위한 지원은 선택적임을 명심해야 하다.

오프로드 타겟은 포스팅될 수 있는 총 송신 요청 개수를 제한하지 않아야 한다. 오프로드 타겟이 그것에 포스팅되어 있는 송신 요청들을 처리하기 위해 요구되는 메모리를 갖지 않으면, 오프로드 타겟은 소프트웨어로 버퍼를 관리할 필요가 있다. 버퍼가 포스팅되고 유효한 아웃바운드 SA가 없으면(예를 들어, 아웃바운드 SA가 함께 시작하기 위해 존재하지 않았거나 오프로드 갱신 호출을 통해 삭제되었음), 오프로드 타겟은 에러를 리턴하고 버퍼를 전송하지 않는다. 버퍼가 포스팅되고 아웃바운드 SA가 무효하면, 버퍼는 버려지고 호출을 에러로 종료되어야 한다.

IPSec 모듈(922)은 단일 SA Offload Block을 이용하는 복수의 상위 계층들을 가질 수 있음을 명심해야 한다. 이것의 결과로서, 오프로드 타겟에 버퍼를 사전 포스팅하기 위한 메커니즘이 존재하지 않는데, 이는 상위 계층 프로토콜 상태가 수신 버퍼에 임베딩될 것을 요청하기 때문이다. 그러므로, 오프로드 타겟이 완료 데이터그램이 수신되고 처리될 때까지 페이로드를 저장하는 데 이용하는 버프들의 풀(pool)을 갖는 경우, 표식 인터페이스만이 IPSec 침니(922)를 위해 이용된다. 완료 데이터그램이 수신 및 처리되면(즉, 복호화/인증), 오프로드 타겟은 데이터그램을 IPSec 계층(922)에 직접 나타낸다. 오프로드 타겟은 표 1내의 정보를 호스트 스택에 나타낸다.

SA Offload Block 스택 핸들
SPI	(IP 주소 없이는 SPI가 기술적으로 고유하지 않는 동안, SA Offload Block은 SA들 둘다에 대해 같은 IP 주소를 갖으며, 이에 따라 SA Offload Block를 갖는 SPI만이 필요하다는 것을 명심해야 함)
플래그	인증된, 복호화된, 에러가 일어난, 무효한 SPI를 제외한 에러가 일어난, IP 처리가 필요한 (보다 많은 IP 옵션/확장 핸들러)
에러 유형(에러 플래그가 설정될 때만 유효함)
	EVENT_IPSec_AUTH_FAILURE - 인증이 요구되지만, 데이터그램에 대해서는 실패했음.
	복호화 실패
	재생 확인 실패
	EVENT_IPSec_BAD_PACKET_SYNTAX - 무효한 패킷 구문론을 갖는 수신된 IPSec 데이터 그램(들)
	EVENT_IPSec_UNEXPECTED_CLEARTEXT - (TCP 상태 객체가 오프로드 타겟 내에 존재하고, 오프로드 타겟이 인커밍 데이터그램을 TCP상태 객체에 전달하려고 했지만, 데이터그램이 명백한 텍스트였을 때만 발생됨)
	EVENT_IPSec_BAD_SPI_RECEIVED - (TCP 상태 객체가 오프로드 타겟 내에 존재하고, 오프로드 타겟이 인커밍 복호화된/인증된 데이터그램을 TCP상태 객체에 전달하려고 했지만, 데이터그램 SPI가 TCP에 의해 요구되는 SPI과 매칭하지 않을 때만 발생됨)
	EVENT_IPSec_CRYPTO_INVALID_PROTOCOL
	EVENT_IPSec_Received_Multicast_MAC
NetBufferList	수신된 패킷 전체를 포함하여 MAC 헤더 등을 포함함
다음 처리되지 않은 IPv6 확장 헤더까지의 버퍼 내의 오프셋(모든 확장 헤더가 행해지면 페이로드)

인바운드 오프로드(offload)된 SA(예를 들어, SA는 오프로드 갱신 인터페이스를 통해 제공되지 않거나 이미 삭제됨)에 매치되지 않는 SPI를 갖는 목적 IP 주소에 대해 IPSec 데이터그램이 수신되면, 오프로드 타겟은 수신된 데이터그램을 네트워크 스택 위로 전송해야 한다.

수신된 데이터그램의 IPSec 프로세싱이 에러로 실패하면, 적절한 통계치가 증가되어야 하고, 인터페이스 상에 EnableSecurityAudit 플래그가 설정되었고 오프로드된 SA에 매칭되는 SPI가 발견되면, 패킷 컨텐츠는 호스트에 전송된다. 패킷 컨텐츠는 IPSecRecerveIndicate 호출을 이용하여 호스트에 전송된다. 오프로드된 SA에 대한 SPI가 발견될 수 없으면 IPSec 오프로드 타겟에 의해 에러가 발견되는 경우에도, 오프로드 타겟은 그것을 처리해야 하고 대신에 인입 데이터그램을 통상적인 수신 경로 위로 전송한다는 것을 유념한다. 수신된 데이터그램이 MAC 계층 브로드캐스트 또는 멀티캐스트 주소를 포함하고 SPI/네트워크 계층 주소가 오프로드된 SA 오프로드 블럭에 매칭되면, 인터페이스 EnableSecurityAudit 플래그가 설정되지 않는 한, 오프로드 타겟은 패킷을 떨어뜨리고 통계치를 증가시켜야 한다. EnableSecurityAudit 플래그가 설정되면, 데이터그램은 처리되지 않고, IPSec 침니(chimney) 인터페이스를 통해 호스트 네트워크 스택에 전송된다.

IPSec 계층은 몇몇 이유로 IPSec 데이터그램을 포함하는 패킷을 오프로드 타겟에 전송한다. 이러한 이유는, SA 오프로드 블럭이 전송된 인터페이스와는 다른 인터페이스 상에 도달하는 데이터그램이, 데이터그램은 IPv4 또는 IPv6 옵션/확장 헤더를 포함하기 때문에, 통상적인 NIC 인터페이스, 오프로드 개시 프로세스 동안의 레이스 조건, 및 오프로드 종료 프로세스에서의 레이스 조건을 통해 경로 계층 프로세싱에 대한 오프로드 타겟에 의해 호스트 스택 위로 송신되었다는 것이다. 전송하는 인터페이스는 IPSec 데이터그램을 전송하는 프로세스에서 사용된다. 오프로드 타겟에 전송하는 인터페이스는 비동기식이며, SA 오프로드 블럭 미니포트 핸들, (인증되고 복호화된) 플래그, MAC 헤더를 포함한 수신된 전체 패킷을 포함하는 NetBufferList, 다음의 미처리된 IP 옵션/확장 헤더에 대한 버퍼로의 오프셋(또는 모든 옵션/확장 헤더가 행해지는 경우 페이로드)을 포함한 타겟 정보를 건네준다. IPSec 계층은, 전송하는 인터페이스를 통한 과도한 트래픽을 검출하면, SA 오프로드 블럭을 업로드할 수 있다.

전술된 바와 같이, 데이터 전송의 제2 모드는 IPSec 침니가 다른 침니(916, 918) 내에 내장되어 있는 곳이다. 예를 들어, TCP 침니가 IPSec 침니의 상단에 층을 이루면, 데이터 전송은 시스템 작업 로드에 따라, IPSec 침니와 TCP 침니 둘 다를 통해, 또는 TCP 침니만을 통해 일어날 수 있다. 모든 데이터 전송이 더 높은 계층 침니를 통해 일어나면, OffloadSenc 및 OffloadReceiveIndicate IPSec 침니 인터페이스(이하에 상세히 설명됨)는 사용되지 않는다. 전송하는 인터페이스, 이벤트 지시 인터페이스, 종료 오프로드 및 무효화 오프로드 인터페이스를 포함한 모든 다른 인터페이스는 사용된다. 모든 기능은 어느 상위 레벨 침니가 제자리에 있는지에 관계없이 이러한 인터페이스에 대해 동일하게 남는다. 전술한 바와 같이, 업로드가 요구되면, 프로세싱은 "레이지(lazy)" 상태가 된다. TCP 스택은 주기적으로, 더 이상 유효하지 않은(즉, 종료 오프로드를 수행) 오프로드된 상태 객체를 모을 것이다. SA 오프로드 블럭에 대한 참조 카운트가 0에 이를때, SA 오프로드 블럭은 업로드될 것이다. IPSec 침니가 종료 오프로드가 수행될 수 있도록 참조 카운트가 0에 이르기를 기다리고 있는 동안, 특정 SA 오프로드 블럭에 대한 OffloadInvalidate를 수행할 수 있다.

데이터 전송이 TCP 침니를 통할 때 송신 프로세싱은 직접적이다. 송신 측 상에, TCP 침니는 오프로드 타겟에 의해 TCP 세그먼트들로 분할되는 애플리케이션 버퍼를 붙힌다. 오프로드 타겟은 (InitiateOffload 호출동안 건네받은 OffleadBlockList로부터) SA 오프로드 블럭 내에서 적절한 아웃바운드 SA를 발견하기에 충분한 상태를 갖는다. 오프로드 타겟은 SA에 의해 지시된 대로 IPSec 프로세싱을 수행하고, 데이터그램을 전송한다. 수신 측 상에서, TCP 침니가 사용되면, IPSec 침니는 인입 IPSec 페이로드의 TCP 프로세싱 전에 (SA에 대한 암호화가 가능한 경우) 패킷을 복호화할 필요가 있다. 또한, IPSec 침니는 TCP 프로세싱 전에 (가능한 경우) 패킷을 인증하여, TCP 에러 처리가 호스트 스택과 동일한 방식으로 수행할 것을 보장해야 한다(예를 들어, 인증/복호화 에러가 발생하면, 어떤 TCP 통계치도 증가되지 않음). TCP 프로세싱이 일어나기 전에, 오프로드 타겟은, 인입 IPSec 데이터그램이 InitiateOffload 가 발행했을 때 TCP 상태 객체에 의해 참조되었던 SA 오프로드 블럭을 이용하여 프로세싱되었음을 검증해야 한다. SPI 값은 오프로드의 수명 동안 변경될 것이고, 인바운드 트래픽에 대한 특정 SA 오프로드 블럭에 관련된 SPI가 2개까지 존재할 수 있다는 것을 유념한다.

하나 이상의 Keepalive SA가 존재하면, 호스트 스택은 임의의 인입 데이터그램을 처리하는 것을 담당한다. 임의의 인식되지 않은 데이터그램(즉, 오프로드되지 않았던 SPI를 포함함)을 통상적인 NIC 인터페이스를 통한 프로세싱을 위해 호스트 스택에 전송하기 위해 PSec 침니 오프로드 타겟이 요구된다. 호스트 스택은 IPSec 데이터그램을 처리하고, 그것을 TCP에 전송한다. TCP는 일반적인 프로세싱을 위해 TCP 침니 전송 인터페이스를 통해 그것을 오프로드 타겟에 전송하며, 플래그는 TCP 세그먼트가 보안 프로세싱을 통과하였음을 나타낸다. 이런 플래그는 필요로 되는데, 이는 그렇지 않은 경우 오프로드 타겟이 명백한 텍스트 에러(상술됨)와 보안 검사를 통과한 수신 세그먼트를 분간할 수 없기 때문이다.

상술된 TCP 침니 아키텍처에 의해 애플리케이션이 미리-배치된 수신 버퍼가 오프로드 타겟에 직접적으로 배치될 수 있다. 오프로드 타겟은 (TCP 프로세싱 이후에) 잠재적으로, 인증된/복호화된 데이터를 직접 이러한 버퍼들에 DMA할 수 있다. 따라서, TCP는 애플리케이션에 제로 사본 데이터 수신을 제공할 수 있다. 일 실시예에서, IPSec 침니의 관점에서, 오프로드 타켓은 미리-배치된 버퍼의 내용을 수정하기 전에, (인에이블된 경우) 페이로드를 인증한다.

IPSec 침니는 SA 오프로드 블럭이 오프로드되는 동안, SA 오프로드 블럭으로의 갱신을 처리하는 데 상당한 다양성(versatility)을 제공한다. 다양성의 한 분야는 리키(re-keying)에 있다. 리키의 이유는 도달되는 SA 수명(즉, SA가 유효할 수 있는 최대 시간량에 도달되었음), 및 SA가 리키되어야 한다고 지시하는 오프로드 타겟을 포함한다. SA 오프로드 블럭은 리키에 업로드되지 않는다. 대신에, 모든 리키 동작이 적절히 행해진다.

이제 도 15를 보면, 리키 동안, IKE(Internet Key Exchange)는 우선 개시자(initiator)에서 새로운 인바운드 보안 연관을 이해한다. 응답자(responder)는 새로운 인바운드 및 새로운 아웃바운드 보안 연관을 이해한다. 응답자로부터의 응답은 개시자가 아웃바운드 보안 연관을 이해하게 한다. IPSec 드라이버는 새로운 인바운드 보안 연관을 획득할 때 즉시 오래된 인바운드 보안 연관을 즉시 제거할 수 없다. 개시자의 경우, IKE 메시지는 피어에 도달해야 하고, 피어는 새로운 인바운드 및 아웃바운드 보안 연관을 이해하도록 그것을 처리해야 한다. 개시자가 오래된 인바운드 SA를 삭제할 수 있기 전에, 인-플라이트(in-flight) 데이터 모두(즉, IPSec에 의한 모든 패킷 출력, 여전히 응답자 NIC의 출력 큐 내에 있거나 네트워크에서 "인 플라이트"임)는 처리될 필요가 있다. 오래된 SA는 Keepalive SA로서 불린다.

마찬가지로, 응답자는 개시자가 새로운 아웃바운드 SA를 이해하기를 기다려야 하고, 응답자가 자신의 오래된 인바운드 SA를 삭제할 수 있기 전에, 오래된 인바운드 SA에 대해 모든 큐잉되고 인-플라이트인 패키지를 처리해야 한다. 이 기능을 제공하기 위해, 호스트는 어느 SA를 통해 인바운드 IPSec 패킷이 들어올 수 있는지를 알지 못하기 때문에, 리키동안, 소정 시간동안 활성화되는 2개의 인바운드 보안 연관을 갖는 것이 필수적이다. 이것을 설명하기 위해, 새로운 아웃바운드 SA가 이해된 후 Keepalive 인바운드 SA를 특정 시간(예를 들어, 20초, 50초, 120초 등)동안 활성으로 유지하는 데 타이머가 사용된다. Keepalive SA에 대한 고정된 시간보다 더 빨리 만료하는 데 관대한 제한이 설정되는 경우, 하나 이상의 Keepalive SA가 유효해지는 것이 가능하다는 것을 유념한다. 본 발명은, 몇몇 구현이 하나 이상의 Keepalive SA를 지원할 수 없다 하더라도, (상술한 바와 같이, 단 하나만이 오프로드될 것이어도)하나 이상의 Keepalive SA를 지원한다.

SA의 최대 수명은 IPSec 계층에 의해 처리된다(즉, 그것은 오프로드 타겟이 아니라 관련된 타이머를 관리할 것임). 관대한 제한에 도달하는 경우, SA 리키가 일어날 것이다. 어려운 제한에 도달하는 경우, 갱신 오프로드 인터페이스는 적절한 SA를 삭제하기 위해 호출될 것이다. SA가 Keepalive SA가 된 경우, IPSec 계층은 타이머를 유지하고 적절한 시기에 SA를 삭제할 것이다. 이것은 오프로드 타겟에 대해 요구되는 단 하나의 타이머 함수에 귀착한다. 요구된 타이머 함수는 인바운드 SA 아이들 타임이다. 아웃바운드 SA 아이들 타임과 같은 다른 타이밍 동작에 있어서, 오프로드 타겟은 오직 타임스탬프를 비교할 필요가 있다. 상술된 접근은 종종 비싼 동작인 하드웨어로 처리된 타이머 함수의 개수를 감소시킴으로써, IPSec 함수를 오프로드하는 하드웨어 비용을 감소시킨다.

오프로드 타겟이 수행하는 다른 비교는 아웃바운드 SA 아이들 타임 아웃바운드 SA 수명의 어려운 제한(각각의 패킷에 대해 비교됨), 인바운드 SA 수명의 어려운 제한(각각의 패킷에 대해 비교됨), 관대하고 어려운 패킷 카운트 제한(각각의 패킷에 대해 비교됨)이다.

오프로드 IPSec 기능에 취해지는 전체 단계, 및 몇몇 구현 상세사항이 설명되었고, 이제 인터페이스를 설명할 것이다. IPSec 침니 아키텍처는 특정 계층(예를 들어, 이웃 계층, 경로 계층, TCP 계층 및 IPSec 계층)에 특정적인 상태 객체 핸들의 사용을 통해 TCP 침니에 대한 기존 호출 인터페이스에 영향을 주도록 설계된다. 대응하는 완료 호출을 갖는 흔한 호출은 InitiateOffload, InitiateOffloadComplete, TerminateOffload, TerminateOffloadComplete, UpdateOffload, UpdateOffloadComplete, QueryOffload 및 TerminateOffloadComplete이다. InitiateOffload는 오프로드를 개시하는 데 사용된다. TerminateOffload는 오프로드 블럭을 종료하는 데 사용된다. 상술된 UpdateOffload는 IPSec 오프로드 블럭에 대해 사용되어 변수를 갱신하고/갱신하거나 하나 이상의 보안 연관을 추가, 삭제 또는 대체한다. QueryOffload는 델리게이트된 변수에 대한 오프로드 블럭에 질의하는 데 사용된다.

TCP 침니를 갖는 흔하지 않은 인터페이스는 IPSecPFFloadTargetEvent 인터페이스 및 데이터 전송 인터페이스를 포함한다.

InitiateOffload 인터페이스는 SA 오프로드 블럭이라고 불리는 새로운 유형의 오프로드 블럭 구조를 제공한다. 미니포트는 호스트 스택이 오프로드된 상태를 참조하는 데 사용하는 초기 오프로드 동안 SA 오프로드 블럭 핸들을 생성한다. SA 오프로드 블럭은 아웃바운드 SA, 인바운드 SA 및 keepalive SA 중 임의의 조합으로 하나 이상의 SA를 포함할 수 있다. InitiateOffload 인터페이스는 최소한으로서, 다음의 상태 오프로드들, 즉, 하나의 인바운드 SA와 하나의 아웃바운드 SA; 두개의 인바운드 SA(하나는 keepalive SA)와 하나의 아웃바운드 SA; 하나의 인바운드 SA; 및 하나의 아웃바운드 SA를 지원한다.

OffloadUpdate 인터페이스는 SA 오프로드 블럭 내의 특정 SA가 조작되게 한다. 오프로드 타겟 핸들, 인바운드/아웃바운드 SA에 대한 플래그 및 SPI의 조합은 SA 블럭 내의 특정 SA를 선택하는 데 사용된다(전술된 바와 같이, 기술적으로는 SPI는 특정 IP 주소에 대해서만 유일하지만, 하나의 아웃바운드 SA만이 존재하고, 2개의 아웃바운드 SA가 존재하는 경우, 둘 다 동일한 IP 주소를 가질 것이므로, IP주소는 필요하지 않음). InitiateOffload 인터페이스는 (하나의 leepalive SA가 지원된다는 일 실시예의 제한을 가지고) SA가 현재 유효하다면 어느 것이든 오프로드하는 능력을 제공하고, 추가 SA가 이해되거나(예를 들어, SA는 keepalive 상태로 이동하거나 새로운 SA가 이해됨), 오버라이트되거나(몇몇 조건 하에서 아웃바운드 SA 또는 인바운드 keepalive SA), OffloadUpdate 인터페이스를 이용하여 삭제될 때 오프로드 상태를 갱신한다. 이것을 지원하기 위해, 인터페이스는 Add(new_SPI), Replace(old_SPI, new_SPI) 및 Delete(old_SPI)에 대한 시멘틱을 생성하고, 이것은 하나의 호출로 결합되어 다음의 기능, 즉, 아웃바운드 SA 추가; 인바운드 SA 추가; 아웃바운드 SA를 대체; 인바운드 SA를 대체; 인바운드 SA를 추가하고 아웃바운드 SA를 대체; 인바운드 SA를 대체하고 아웃바운드 SA를 대체; 인바운드 SA를 삭제; 인바운드 SA 및 아웃바운드 SA를 삭제; 2개의 인바운드 SA 및 하나의 아웃바운드 SA를 삭제; 및 아웃바운드 SA를 삭제를 지원할 수 있다. 추가 SA가 추가되고 새로운 SA(들)에 이용가능한 불충분한 하드웨어가 있다면, 미니포트는 갱신에 실패할 수 있다. 이 실패가 일어나면, 호스트 스택은 SA 오프로드 블럭을 업로드할 것이다.

SA는 다음의 이유, 즉, keepalive SA가 만료됨(인바운드 SA); 최대 SA 수명이 도달되었음; 및 관리상의 이유로 삭제될 수 있다. UpdateOffload 삭제 동작은 삭제 동작 내에 포함된 SA 오프로드 블럭 내의 특정 SA에 적용된다. UpdateOffload에 대한 완료가 호출되면, 오프로드 타겟은 그 특정 SA에 관련된 모든 상태를 제거해야 한다. 예를 들어, 제거 동작은 오프로드된 SA의 개수를 3개에서 2개로 변경할 수 있고, UpdateOffload 추가 동작이 수행될 수 있다. 삭제된 SA에 대한 모든 수신 또는 전송 프로세싱은 마치 SA가 전혀 오프로드되지 않은 것과 같다. TCP 침니 오프로드된 접속은 IPSec 침니 SA 오프로드 블럭에 의존하고, 요구된 아웃바운드 SA가 삭제되었으면, TCP 침니 접속은 임의의 데이터를 송신하고 마치 경로 상태가 무효화된 것과 유사한 방식으로 그 에러를 처리해야 한다(예를 들어, 아웃바운드 트래픽 뿐만 아니라 정상의 TCP 재송신 타임아웃 프로세싱에 대해 유효한 상태가 존재하지 않는다는것을 호스트 스택에 나타냄).

새 아웃바운드 SA가 OffloadUpdate Replace 동작으로 측량될 때, 오프로드 타겟은 구 아웃바운드 SA 상태 전체(캐시되고 위임된 상태-Const 상태는 여전히 동일함)를 오버라이트한다. 오프로드 타겟은, 특정 데이터그램이 구 SA 상태 또는 신 SA 상태 둘 중 하나로 완전히 엔코딩될 수 있도록 현재 구 SA를 이용하는 도중인 아웃바운드 패킷에서 처리를 완료할 필요가 있을 것이다. OffloadSend 요청은, 아마도 많은 양의 데이터를 나타내는 IPSec 데이터그램을 포함할 수 있다는 것을 유의한다. 이 때문에, 오프로드 타겟은 OffloadSend 요청 도중에 처리하는 것을 중지할 수 있어야 하고, 이것이 시작한 임의의 IPSec 데이터그램의 엔코딩을 마칠 수 있어야 하고, 나머지 OffloadSend(및 큐된 임의의 다른 것들)에 대해 새 아웃바운드 SA에로의 이행을 할 수 있어야 한다. 일단 새 SA로의 이행이 완료되면, OffloadUpdate 호출은 완료될 수 있다. OffloadUpdate Replace가 AH 및 ESP SPIs 및 그 관련된 알고리즘, 키, 수명 등도 변경할 수 있다는 것을 유의한다.

킵얼라이브 타이머(keepalive timer)를 유지하는 호스트 및 일반 인터페이스때문에, 오프로드 타겟은 인바운드 SA가 킵얼라이브 상태에 있는지, 미숙한 활성 상태에 있는지 또는 활성 상태에 있는지를 알지 못한다. 그 결과로서, 상기 인터페이스에 의해 특정 행동들이 지원된다. 그 행동들은 이하와 같다:

IPSec 양방향 데이터 전송을 위한 초기 키잉(initial keying):

·(개시자에 의한) 미숙한 활성 인바운드 SA의 InitiateOffload

·(응답자에 의한) 아웃바운드 및 인바운드 SA의 InitiateOffload

·(미숙한 활성 인바운드 SA가 InitiateOffload로 오프로드된 후 개시자에 의해) 아웃바운드 SA를 추가하기 위한 UpdateOffload

IPSec SA의 제1 리키(rekey):

·새 인바운드 SA를 추가하기 위한 UpdateOffload (개시자 - 구 인바운드 SA는 킵얼라이브 SA가 되지만, 오프로드 타겟은 이를 알지 못함)

·(응답자에 의해) 새 인바운드 SA를 추가하고 구 아웃바운드 SA를 대체하기 위한 UpdateOffload

·아웃바운드 SA를 대체하기 위한 UpdateOffload(개시자)

IPSec SA의 제2 리키:

·인바운드 SA를 대체하기 위한 UpdateOffload(개시자)

·(응답자에 의해) 인바운드 SA를 대체하고 구 아웃바운드 SA를 대체하기 위한 UpdateOffload

·아웃바운드 SA를 대체하기 위한 UpdateOffload(개시자)

그리고 마지막으로, 킵얼라이브 타이머가 발동된 후 또는 리키없이 SA의 수명이 만료된 경우:

·인바운드 SA를 삭제하기 위한 UpdateOffload(개시자 및 응답자)

·인바운드 SA 및 아웃바운드 SA를 삭제하기 위한 UpdateOffload(킵얼라이브가 존재하지 않음)

·인바운드 SAs 및 아웃바운드 SA 둘 다를 삭제하기 위한 UpdateOffload

추가, 대체 및 삭제의 조합의 복잡성 때문에 침니(chimney)에 대해 취해진 어프로치는, 갱신이 하나, 둘 또는 세 개의 SA를 포함할 수 있도록 하는 것이고, 여기서 각 SA는 {추가, 삭제, 대체} 세트의 연산자를 지닌다. 오프로드 타겟에 대한 인터페이스를 단순화하기 위해, 오프로드된 TCP 접속이 IPSec을 이용하여 시작하는 것을 필요로 하는 새 IPSec 필터가 측량되는 경우, 오프로드된 접속은 업로드되고 다시 오프로드될 것이다. 호스트 스택이 SA Block 내의 개개의 SA의 위치를 관리하는 것을 책임을 지지 않도록 하기 위해, SA Offload Block 내의 SA를 찾기 위해 SA Offload Block Handle, 인바운드/아웃바운드 SA 및 SPI의 조합을 사용하는 것이 행해진다. IPSec SA Offload Block이 하나 이상의 킵얼라이브 SA를 필요로 하는 경우, 나머지 킵얼라이브 SA들은 호스트 소프트웨어 스택에 의해 처리될 수 있다.

오프로드 타겟으로부터 호스트로의 표시 호출 인터페이스는, 일반 이벤트(예를 들어 침니에 일반적인 것) 및 IPSec에 대한 특정 이벤트를 표시하기 위해 사용된다. EventIndicate 호출은 일반 이벤트에 대해 사용된다. IPSecEventIndicate 호출은 IPSec에 대한 특정 이벤트에 대해 사용된다. SA 만료 또는 오프로드 타겟 개시화 리키로 인해 오프로드 타겟은 리키를 요청하기 위해 또는 특정 SA가 만료된 IPSec 계층을 알려주기 위해 IPSecEventIndicate를 호출할 것이다. IPSecEventIndicate는 SA Offload Block Handle, SPI, SPI가 인바운드 SA용인지 또는 아웃바운드 SA용인지를 지정하는 플래그, ActionRequested 및 ActionReason과 같은 인수를 포함한다. ActionRequested 및 그 관련 ActionReason은 ReKeyRequest 및 SAInvalidated이다.

ReKeyRequest와 관련된 이벤트 통보는 KBytesSoftReached 및 OutboundPacketSoftReached이다. KBytesSoftReached 이벤트는 전송된 킬로바이트의 수가 관대한 제한 한계에 도달했고 SA 리키 프로세스가 개시되어야 한다는 것을 호스트에게 통보한다. OutboundPacketSoftReached 이벤트는 데이트에 전송된 패킷의 수가 관대한 제한에 도달했고 호스트 스택이 리키 동작을 시작해야 한다는 것을 호스트에게 통보한다.

SAInvalidated 이벤트는 제한에 도달했기 때문에 SA가 유효하지 않다(즉 만료됨)는 표시를 호스트 스택에 제공한다. SAInvalidated 이벤트는 KbytesHardReached, OutboundPacketHardReached, IdleTimeReached, Packet count limit hit을 포함한다. KbytesHardReached는 전송된 킬로바이트의 수가 엄격한 제한에 도달했으며 SA가 무효해야만 한다는 것을 나타낸다. OutboundPacketHardReached는 전송된 패킷의 개수가 엄격한 제한에 도달했음을 나타낸다. IdleTimeReached는 SA가 특정 시간동안 데이터를 전송하지 않았음을 나타낸다. 아웃바운드 SA에 대해, IPSec 데이터그램의 시도되는 전송에 의해 점검이 구동된다. 최종 전송 시간이 저장되어 현재 시간과 비교된다. 그것이 한계 이상이면, 오프로드 타겟은 호스트에게 통지하고, 패킷을 드롭하고, SA를 무효한 것으로 마크한다. 원격 피어가 충돌될 경우 데드락이 발생하지 않는다는 것을 보장하기 위해 이러한 점검이 필요하다. 통상적인 유휴 간격은 2분이다. 인바운드 SA에 대해, 시기적절한 방식으로 자원이 정리된다는 것을 보장하기 위해 타이머에 의해 점검이 구동된다. 타이머는 특정 SA상의 IPSec 패킷의 수신시 리셋된다. 통상적인 유휴 간격은 5분이다. packet count limit hit은 패킷 개수 제한에 도달했음을 나타낸다.

데이터 전송 인터페이스는 OffloadSend, OffloadSendComplete 및 OffloadReceiveIndicate를 포함한다. OffloadSend 및 OffloadSendComplete는, 호스트 스택이 전송될 데이터그램에 삽입될 IPv6 확장 헤더 또는 IPv4 옵션을 생성할 수 있다는 것을 가정한다. 이것은 AH 및 ESP 헤더 전 또는 후에 옵션을 삽입하는 것을 포함한다. 따라서 OffloadSend 인터페이스는 상술된 바와 같이 AH/ESP 헤더 전에 또는 후에 포함될 IPv6 확장 헤더에 대한 두 개의 추가 포인터를 포함한다(대안의 실시예는 제3의 포인터가 AH와 ESP 헤더 간에 옵션을 포함하도록 함). IPv4에 대해, 인터페이스는 상술된 바와 같이 IPv4 옵션의 단일 리스트를 가능하게 한다. 대안의 실시예는, 옵션이 AH 및 ESP 헤더의 앞에, 그 사이에 또는 뒤에 있는 것을 가능하게 하기 위해 제2 또는 제3의 포인터를 허용한다. (IPSec receive에 대한) OffloadReceiveIndicate는 데이터가 수신되었음을 나타낸다. OffloadReceiveIndicate는, 처리되지 않은 다음 헤더에 대한 IP 옵션/확장 헤더로의 인덱스 및 date에 대해 행해진 임의의 처리의 결과를 기술하는 플래그 세트와 함께, SPI 및 전체 IP 헤더, 그리고 페이로드를 포함할 수 있다(대안의 실시예는 MAC 헤더, 또는 아무 옵션이 없는 경우 IPSec 페이로드만을 포함할 수 있다). AH 및/또는 ESP 헤더는 유효한 데이터를 포함할 필요가 없다는 것을 유의한다.

QueryOffload 인터페이스는 호스트 스택이 SA의 오프로드된 상태를 질의하는 것을 허용한다. 매개변수는 SA Offload Block Handle 및 OffloadBlockList이다. QueryOffload 인터페이스는 SA의 위임 상태를 질의하는 데에 통상적으로 사용된다. 이것은 각종 이유로 필요할 수 있다. 디버그동안, 이것은 또한 오프로드 타겟 및 호스트가 동기화에 있다는 것을 보장하게 위해 Const 및 캐시된 변수의 상태를 질의할 수 있다.

OffloadInvalidate 인터페이스는 오프로드된 SA가 무효하다는 것을 나타낸다. SA Offload Block 내의 특정 SA는 만료될 수 있는데(무효하게 될 수 있는데), 그 이유는 오프로드 타겟이 무효를 유발하거나, 또는 호스트가 OffloadInvalidate를 호출하기 때문이다. 무효한 SA는 삭제된 SA와 다름을 유의해야 한다. SA의 삭제는 Delete의 opcode와 함께 OffloadUpdate 인터페이스를 통해 발생할 수 있다. 그 경우, 오프로드 타겟에 SA에 대한 상태가 남아있지 않다. 그러나, SA가 무효한 경우, SA Offload Block의 TerminateOffload가 발생할 때까지 상태가 오프로드 타겟에 여전히 남아 있다. TerminateOffload는 호스트에게 다시 전송될 위임 상태 전부를 요청할 것이다. OffloadInvalidate는 관리적인 이유(예를 들어 정책 변경)로 발생할 수 있고 또는 오프로드의 종료가 요청되었기 때문에 발생할 수 있는데, 종속 TCP 상태 객체의 refcount가 0이 아니므로, 오프로드는 아직 종료될 수 없다. refcount가 0이 되는 것을 기다리는 동안, SA는 무효하다. OffloadInvalidate에 대한 인수는 Miniport SA Offload Block Handle과 OffloadBlockList이다. 무효한 SA가 아웃바운드 SA인 경우, OffloadSend로의 호출이 오류로 완료되어야 하고 데이터는 전송되지 않는다. 무효한 SA가 인바운드 SA인 경우, (인터페이스 통계가 가능하지 않은 경우) 수신된 데이터그램은 드롭되고 적절한 오류 카운터가 증가된다.

통계로 다시 돌아와서, 오프로드 타겟은 SA Offload Block이 오프로드되는지 여부에 상관없이 호스트 통계 레포팅이 영향을 받지 않도록 통계를 유지한다. 호스트 프로토콜 스택은 각각의 호스트 통계 및 각각의 SA 통계를 유지한다. IPSec 침니는 호스트 전반의 통계가 질의될 때마다 그 인터페이스 통계에 대해 가능한 인터페이스에 대해 IPSec 침니 각각을 질의할 것이다. IPSec 오프로드 타겟은 경로 계층에 대한 TCP 침니 정의 통계 및 데이터 링크 계층(즉, 프레이밍 계층)에 대해 정상 NDIS 통계를 유지한다. 또한, 이것은 IPSec 데이터그램이 오프로드 타겟에 의해서 소비될 때에만(즉, 종래의 데이터 경로로 전송되지 않음) 증가되는 이하의 IPSec 통계를 유지해야만 한다.

각각의 인터페이스 통계는 32 비트 카운터와 64 비트 카운터를 포함한다. 32 비트 카운터는 NumBadSPIPackets, NumPacketsNotDecrypted, NumPacketsNotAuthenticated 및 NumPacketsWithReplayDetection이다. 64 비트 카운터는 ConfidentialBytesSent, ConfidentialBytesReceived, AuthenticatedBytesSent, AuthenticatedBytesReceived, OffloadedBytesSent 및 OffloadedBytesReceived이다. 이 카운터들이 64 비트 카운터를 구현하기 위해 하드웨어를 꼭 필요로 하는 것이 아니라는 것을 유의한다. 예를 들어, 하드웨어는 상위 32 비트를 추적하기 위해 호스트 미니포트에 대한 이벤트인 캐리-아웃으로 32 비트 카운터를 구현할 수 있다. 오프로드 타겟 상호작용 없이 호스트 스택에 의해서만 유지되는 각각의 인터페이스 통계는 NumActiveAssociations, NumOffloadedSAs, NumPendingKeyOps, NumKeyAdditions, NumKeyDeletions, NumReKeys, NumActiveTunnels, TransportBytesSent, TransportBytesReveived, BytesSentInTunnels 및 BytesReceivedInTennels이다.

각각의 SA 통계는 관대한 및 엄격한 제한을 지원하기 위해 오프로드 타겟이 일부 통계를 추적할 것을 요청한다. 동일한 각각의 인터페이스 카운터가 사용되어 각각의 SA 기반으로 통계 질의를 구현한다. 통계 질의가 오프로드된 SA에 대한 것인 경우, 이하의 64 비트 카운터 값을 채우기 위해 OffloadQuery 인터페이스가 사용되어 특정 SA에 대한 위임 상태를 검색할 것이다: ConfidentialBytesSent(아웃바운드 SA에 대해 DELEGATED 매개변수 CurrentConfBytes를 사용함); ConfidentialBytesReceived(인바운드 SA에 대해 DELEGATED 매개변수 CurrentConfBytes를 사용함); AuthenticatedBytesSent(아웃바운드 SA에 대해 DELEGATED 매개변수 CurrentAuthBytes를 사용함); AuthenticatedBytesReceived(인바운드 SA에 대해 DELEGATED 매개변수 CurrentAuthBytes를 사용함); TotalBytesSent(아웃바운드 SA에 대해 DELEGATED 매개변수 CurrentBytes를 사용함); TotalBytesReceived(인바운드 SA에 대해 DELEGATED 매개변수 CurrentBytes를 사용함); OffloadedBytesSent(오프로드가 개시될 때, 호스트 스택은 TotalBytesSent의 값을 기록할 것임. OffloadedBytesSent 매개변수가 필요한 경우, 호스트 프로토콜 스택은 SA에 대한 CurrentBytes를 찾기 위해 오프로드 타겟에 대해 DELEGATED 상태를 질의할 것이고, SA가 오프로드되었을 때의 값을 뺀 값을 리턴할 것임); 및 OffloadedBytesReceived(OffloadedBytesSent와 동일한 방식이지만, 인바운드 SA에 적용됨).

보안 위협이 떠오르는 문제점이다. 본 발명은 공지의 위협을 고려한다. 도 16으로 돌아가서, 외부 위협은, TLNPI 인터페이스(아마도 사용자 모드에서-커널 모드 컴포넌트는 신뢰되는 컴포넌트임) 위에 있는 애플리케이션으로부터 또는 와이어(wire)로부터 시스템으로 주사될 수 있다. 와이어 소스는 네 개의 데이터 경로 중 하나가 실행되도록 할 수 있다. 네 개의 데이터 경로는 종래의 네트워킹 스택 데이터 경로, 오프로드 NIC 데이터 경로, (다른 인터페이스상에서 패킷을 전달함으로써) 호스트 스택으로부터 오프로드 NIC로의 IPSec 전달 인터페이스 및 IPSec 엔진과 TCP 엔진과의 선택적인 오프로드 타겟 내부 인터페이스(이것은 TCP 침니가 오프로드 타겟에 의해 지원될 때에만 가능함)이다. 이것은 또한 관리자가 Offload Manager 순서화를 제어할 수 있도록 하는 특권 모드 인터페이스이다.

데이터 경로가 아닌 내부 공격 포인트는, 새로운 펌웨어를 NIC로 로드할 것이고(모든 NIC가 이것을 지원하지는 않음), 제어 경로를 실행하여 오프로드된 IPSec SA Offload Block의 상태를 갱신할 것이고, 제어 경로를 실행하여 업로드 또는 다운로드를 집행할 것이다.

호스트 프로토콜 스택이 모든 SA 셋업 및 해체를 수행하기 때문에 SA 셋업/해체와 관련된 새로운 위협은 없다. 따라서, 프로토콜 스택에 대한 기존의 보안 분석이 SA 셋업에 적용된다. IKE, ICMP, ARP 및 RIPv4 메시지와 같은 모든 제어 패킷이 또한 호스트 스택에 의해 처리되고, 따라서 이러한 메시지의 처리를 강화하는 호스트 스택은 제 자리에 남아 있다. 그러나, 호스트 스택의 상태가 갱신되는 경우, 캐시된 사본은 NIC에 남아 있고, 이것은 IPSec 오프로드 타겟으로의 제어 경로가 실행되도록 할 수 있다.

SA 상태가 다양한 이유로 인해 오프로드되는 경우, 호스트 스택은 IPSec 데이터그램을 전달 인터페이스를 통해 NIC에 포워드할 수 있다. 한가지 이유는 IPv4 옵션으로 인한 것이다. 데이터그램이 IPv4 옵션을 포함하는 경우, 데이터그램은 IPSec 프로세싱 이전에 IPv4 옵션 프로세싱을 위하여 호스트 스택으로 포워드된 다음, 오프로드 타겟으로 포워드된다. 다른 이유는 IPv6 확장 헤더로 인한 것이다. 데이터그램이 IPv6 옵션을 포함하는 경우, 그 데이터그램은 호스트 스택으로 포워드된다. IPv6 확장 헤더들은 반드시 순서대로 프로세싱되어야 하기 때문에, 호스트 스택과 오프로드 타겟 간의 여러번의 이동(trip)을 유발할 수 있는 몇가지 병적인 경우가 존재한다. 최악의 경우는 패킷이 AH와 ASP를 사용했고, 또한 AH 헤더 앞에, AH와 ESP 헤더 사이에, 그리고 ESP 헤더 뒤에 IPv6 확장 헤더들이 존재하는 경우이다. 또다른 이유는 IP 프레그먼트으로 인한 것이다. 오프로드 타겟은 IP 프레그먼트들을 재조립할 수 있지만, 재조립 공간이 고갈되면, 특정 데이터그램을 위한 모든 프레그먼트를 통상의 호스트 인터페이스를 통해 이동시킬 옵션을 갖게 된다. 이러한 경우, 호스트는 데이터그램을 재조립한다. 일단 재조립되고 난 후, 그 데이터그램이 오프로드된 SA를 타겟으로 하는 IPSec 패킷인 경우, 그것은 프로세싱을 위하여 IPSec 오프로드 타겟으로 포워드된다. 다른 이유는, IPSec 데이터그램이 다른 인터페이스로부터 수신되었고 호스트 IPSec 스택에 의해 수신되었다는 것이다. 또다른 이유는, 오프로드가 발생한 때에, IPSec 데이터그램이 호스트 스택으로 가고 있는 중이었다는 것이다. 이것이 과도 조건(transient condition)이다.

위험 자산의 리스트는, 통상적인 NIC(통상적인 경로에 대한 보안 분석에 변화가 없음); 오프로드 NIC 자원(주로 IPSec SA 오프로드 블록, IP 재조립 버퍼, IPSec 전송 버퍼(모든 NIC에 대한 것은 아님) 및 CPU(존재하는 경우에만)); 시스템 안정성; IPSec SA 오프로드 블록 상태(자격증명서 포함); 경로 상태; 이웃 상태; 및 데이터 무결성을 포함한다. IPSec 침니(chimney)가 "보안 감시" 모드를 지원하며, 이것은 오프로드 타겟이 통상적으로 에러로 인해 (적절한 에러 카운터를 증가시킨 후에) 누락될 임의의 수신된 데이터그램을 호스트 스택에 포워드할 것을 요구한다는 점에 주목해야 한다. 이것은, 어떠한 특정한 위협을 반드시 완화시키는 것은 아니지만, 시스템 관리자가 시스템을 공격하고 있을 수 있는 패킷들을 검사하는 능력을 보유할 것을 보장해 준다.

스푸핑(spoofing), 탬퍼링(tampering) 및 부인(repudiation)과 관련하여, SA 오프로드 블록은 SA의 IKE 협상 이후에만 오프로드되기 때문에, 전통적인 형태의 와이어 공격(wire attack) 중 소정 유형들은 적용되지 않는다. 아마도, (IPSec 인증 또는 암호화 알고리즘이 크랙되지 않았다는 가정 하에서) 익명 공격(anonymous attack)이나 중간자 공격(man-in-the-middle attack)은 가능하지 않을 것이다. 오프로드 타겟은 IP 어드레스 SPI가 오프로드된 SA와 일치하는 경우에만 인입 패킷을 프로세스할 것이다. 적이 오프로드된 SA를 공격하는 경우, 하드웨어는 호스트보다 훨씬 빨리 그 패킷을 누락시킬 수 있으므로, 시스템은 종래의 소프트웨어 스택보다 더 민감하게 반응할 것이다. 적이 오프로드되지 않은 SA를 공격하거나 IPSec을 사용하지 않는 경우의 위협 모델은 기존의 소프트웨어 스택 위협 모델과 동일하다. 적이 IP 프레그먼트(v4 또는 v6)으로 스푸핑, 탬퍼링 또는 부인을 시도하는 경우, 전달 인터페이스가 사용될 수 있다. 호스트 스택이 패킷의 불량 여부를 검증하기 위한 해시 또는 복호화를 반드시 수행하지 않아도 되므로, 최종 CPU 활용도가 호스트 스택 단독인 경우에서보다는 여전히 더 좋을 것으로 기대된다. 호스트 스택은 단순히 패킷을 재조립하여 오프로드 타겟으로 포워드하고, 오프로드 타겟은 공격 패킷을 누락시킬 것이다 (또한 카운터를 증가시키고, 잠재적으로 로깅이 가능한 경우에는 그 패킷을 호스트로 포워드할 것이다).

정보 공개와 관련하여, 새로운 와이어 프로토콜은 존재하지 않기 때문에 정보 공개를 위한 새로운 메커니즘을 위한 기회는 거의 없으며, 유일한 API의 변경은 특권을 갖는 관리자가 오프로드 매니저 우선순위화를 설정할 수 있게 하는 것과 임의의 애플리케이션이 SA가 현재 오프로드되어 있는지를 볼 수 있게 하는 것이다. 관심사항은, 가치있는 NIC 자원(주로 한정된 개수의 오프로드 SA) 및/또는 CPU 자원을 소비하는 업로드/오프로드를 강제하려고 시도하는 다양한 공격들을 적용하는 것이 가능한지의 여부이다. 한가지 공격 방식은 업로드/오프로드를 유발하여, 인터페이스에게 오프로드/업로드가 성공적이었는지를 확인하라는 질의를 보내고, 그 형태의 공격을 반복하여 그것이 보다 더 성공적이도록 시도하는 것일 것이다. 이러한 공격이 제대로 적용되기 위해서는, 공격자가 로컬 호스트 상에 있거나, 또는 원격 위치로부터 로컬 호스트 상의 통계자료를 질의할 수 있어야만 한다. 그러나, 이것은 시스템 관리자에 의해 발견될 수 있으며, 시스템 관리자는 발견적 학습법을 적용하여, 그 서브넷/호스트로부터의 오프로드를 디스에이블시키거나, 로컬 접속으로의 오프로드를 제한하거나, 또는 소정의 조합 동작을 행할 수 있다.

이론의 여지는 있지만, 원격 노드가 코드를 오프로드된 NIC에 로드하게 되는 경우에는 다른 형태의 정보 공개가 발생할 수 있다 (나중에 더 상세하게 설명됨). 다른 문제점은, 이제는 오퍼레이팅 시스템뿐만 아니라 오프로드 타겟에도 키들이 존재하기 때문에, 임의의 새로운 공격이 노출되는지의 여부이다. 사용자 모드로부터 하드웨어로 액세스할 수 있는 메커니즘은 존재하지 않기 때문에, 이러한 자원을 공격하는 유일한 방법은 커널이 손상되어 있는 경우뿐이다.

서비스 거부 공격(denial of service attack)과 관련하여, IPSec 침니에 대한 공격은 인증되지 않은 원격 피어, 또는 인증되었으나 감염된 원격 피어에 의해 행해질 수 있다. 앞에서 설명한 바와 같이, 미지의 공격자가 오프로드된 SA를 공격하려고 시도하는 경우, 공격 패킷의 초기에 누락으로 인해, 오프로드되지 않은 SA를 공격할 때보다 시스템 성능이 실질적으로 더 양호할 것이다. 원격 노드가 공격할 수 있는 주요 자원은 IP 재조립 버퍼, 오프로드된 SA의 강제 업로드, 오프로드 NIC CPU 사이클, 호스트 CPU 사이클 및 시스템 안정성이다.

IP 재조립 버퍼를 공격하는 것과 관련하여, 원격 노드가 IP 프레그먼트를 전송하는 경우, 데이터그램을 프로세싱하고 재조립된 데이터그램을 IPSec 엔진에 전달하기 위해서, 상당량의 IP 재조립 버퍼 공간이 관련 오프로드 NIC CPU 사이클과 함께 소비될 수 있다. 오프로드 타겟은 그 버퍼 공간을 초과하는 임의의 데이터그램을 호스트에 보내게 된다 (물론, 오프로드 타겟은 주어진 IP 데이터그램의 일부를 오프로드 타겟 내에 저장하지 않고 다른 세그먼트들을 호스트에 보내도록 주의해야 한다). 이에 의해, 호스트는 IP 프레그먼트 공격을 추적할 수 있게 된다. 데이터그램을 인증/복호화하려고 시도할 때에 호스트 스택에 의해 절약된 계산 사이클들로 인해, 오프로드된 SA가 공격받고 있는 경우에 최종 이득이 있을 것으로 예상된다는 점에 주목해야 한다. 호스트 스택은 패킷의 프레그먼트화를 해소한 후에, 그 패킷을 인증/복호화될 오프로드된 SA에 포워드할 것이다. 이러한 방식을 이용하면, 공격자가 재조립 버퍼를 오버런하려고 시도하는 경우에, 호스트 스택 완화가 계속 적절하게 유지된다.

오프로드된 SA의 강제 업로드와 관련하여, 업로드되고 있는 SA들이 광범위하게 다양한 애플리케이션들에 의해 사용되고 있는 경우, 이것은 시스템 성능에 영향을 미칠 수 있다. 특히 관심이 가는 것은, 업로드를 강제할 수 있는 "매직(magic)" 수신 패킷 또는 송신 패킷이 존재하는가이다. 가장 일반적인 그룹 정책은 2개의 엔드노드 간의 모든 통신에 대하여 SA 오프로드 블록을 이용하는 것이다. 따라서, 매직 패킷이 가능하다면, 2개의 호스트 간의 모든 통신이 시행될 것이다. IPSec 침니는 원격 또는 로컬 애플리케이션이 업로드를 유발하는 것을 허용하지 않도록 명확하게 설계되어 있다. 따라서, 이러한 유형의 공격은 가능하지 않다. 그러나, IP 옵션/확장 헤더 프로세싱을 위해 요구되는 전달으로 인해, 완화가 인터페이스에 추가하는 복잡성은 상당하다. 이것은 나중에 설명되는 것과 같은 CPU 사이클에 대한 잠재적인 공격을 발생시킨다.

CPU 사이클 공격과 관련하여, 호스트 CPU 사이클을 소비하는 주된 방법은 전달 인터페이스의 과도한 사용을 통한 것이다. 여기에서의 분석을 위해 사용되는 핵심적인 기준은, 오프로드 타겟이 특정 프로세싱에 대하여 오프로드가 존재하지 않았을 경우에 호스트 스택이 가졌을 것보다 더 많은 CPU 사이클을 도입하는지의 여부이다. 원격 노드는 (특정 NIC로 오프로드된) SA를 생성한 다음, 현재의 경로와 대안적인 경로를 왕복하여, IPSec 데이터그램이 다른 NIC에 도착하게 할 수 있다. 데이터그램을 오프로드 타겟에 포워드하고 공격 데이터그램을 누락시키는 데에 필요한 총 CPU 사이클은, 패킷을 인증하거나 복호화하는 데에 필요한 사이클보다 더 적을 것으로 보여진다. 따라서, IPSec 침니의 최종 효과는 공격 패킷을 누락시키기 위한 계산 사이클의 감소이다. 전달 인터페이스에 대한 다른 공격은 IPv4/v6 옵션 또는 확장 헤더를 보내는 것이다. IPv4 옵션 및 IPv6 확장 헤더들에 관련하여서는, a) 인증은 되었지만 악의적인 애플리케이션을 갖고 있는 원격 호스트가 업로드를 강제하기 않을 것과 b) 로컬 애플리케이션이 업로드를 필요로 할 패킷을 보내지 않을 것을 보장하기 위해, 상당한 복잡성이 존재한다.

매직 패킷이 허용되지 않기 때문에, 모든 IPv4 옵션과 IPv6 확장 헤더는 호스트에 의해 프로세싱된다 (이것은 새로운 옵션이 생성될 때의 포워드 호환성을 보장하고, 또한 오프로드 타켓 내의 잠재적인 공격 표면을 제거한다). 그러나, 이러한 방식은 IP 옵션/확장 헤더 프로세싱을 인에이블시키기 위하여 전달 인터페이스를 통한 공격 형태들을 도입한다. IPv4에 대하여, 옵션들을 순서대로 프로세싱할 필요는 없다. 따라서, 오프로드 타겟은 옵션 프로세싱을 위하여 데이터그램을 호스트에 포워드할 것이다 (즉, 비-오프로드 패킷 코드-경로). 호스트는 옵션 프로세싱을 마친 후, 데이터그램을 IPSec 프로세싱을 위하여 오프로드 타겟으로 포워드할 것이다. 마찬가지로, 전달 인터페이스를 통할 때에조차도 오프로드로 인해 사이클 카운트가 감소하기 때문에, 이러한 공격은 오프로드를 갖지 않는 호스트 스택의 경우보다 더 많은 CPU 사이클을 소비하지 않을 것으로 예상된다. IPv6에 대하여, 최악의 패킷은 AH 및 ESP 헤더 둘다를 갖는 것이다. 확장 헤더가 IPSec AH 헤더 앞에, AH와 ESP 헤더 사이에, 그리고 ESP 헤더 뒤에 있는 경우에 확장 헤더들이 순서대로 프로세싱될 것을 보장하기 위해서는, IPSec 오프로드만이 인에이블된다면 패킷이 I/O 버스를 이론적으로 5회 횡단해야 하고, IPSec 침니 및 TCP 침니가 인에이블된다면 잠재적으로 7회 횡단해야 한다. 다음의 시퀀스는 이벤트들의 병적 순서화이다. 첫째로, 초기 확장 헤더를 프로세스하기 위하여, 데이터그램이 호스트 스택으로 포워드된다. 그 다음, 데이터그램은 AH 프로세싱을 위하여 오프로드 타겟으로 포워드되고, 성공적으로 인증된다 (즉, 인증된 호스트가 감염된다). 오프로드 타겟은 AH 프로세싱을 수행한 후에 전달하며, 오프로드 타겟은 또다른 확장 헤더 프로세싱을 위하여 데이터그램을 호스트 스택에 표시한다. 호스트 스택은 확장 헤더를 프로세싱하고, 데이터그램을 ESP 프로세싱을 위하여 오프로드 타겟에 포워드한다. 오프로드 타겟이 ESP 프로세싱을 수행하고, 데이터그램이 전달하며, 오프로드 타겟은 또다른 확장 헤더 프로세싱을 위하여 데이터그램을 호스트 스택에 표시한다. 호스트 스택은 확장 헤더 프로세싱을 완료하고, 데이터그램을 TCP에 포워드하며, TCP는 그 데이터그램을 오프로드된 TCP 접속에 포워드한다. 오프로드 타겟은 TCP 세그먼트를 프로세스하고, 페이로드를 애플리케이션에 표시한다.

IPSec 스택은 AH와 ESP 헤더 간에 IPv6 확장 헤더를 전송하지 않을 것이므로, 상기의 패킷 포맷은 발생하기 어렵다. 또한, TCP가 전달 인터페이스를 통한 상당량의 트래픽을 보는 경우, TCP는 접속을 업로드할 것이다. 이것은 트랜지션을 5까지, 가능하게는 3까지 감소시킨다. 공격 피어가 알려지지 않은 경우(전형적인 공격), 인증이 실패한 때에, 데이터그램이 AH 프로세싱을 위해 오프로드 타겟에 포워드된 후에, 프로세싱이 중단된다. 원격 피어가 인증 및 복호화를 전달할 수 있는 경우 (예를 들어, 신뢰된 피어가 바이러스에 감염된 경우), 상기 시퀀스를 실행하는 것이 가능하다. IPSec 침니는 과도한 전달을 로그하기 위한 메커니즘을 포함할 것이고, 이에 의해 관리자는 불편을 주는 피어에 대하여 적절한 동작을 취할 수 있게 된다. 이러한 경우는 인증되고 감염된 클라이언트에서만 발생할 것이므로, 완화는 직선적이다. 즉, 해당 클라이언트로부터의 더 이상의 트래픽을 중단시키기 위한 필터를 설치하는 것이다.

공격 패킷이 순수한 소프트웨어 호스트 스택의 경우보다 더 많은 CPU를 소비하는지의 여부와 관련하여 상기를 검토하여 보면, CPU 활용의 주된 추가는, 전달 오버헤드와 IPSec 침니 수식 표시 오버헤드이다. CPU 활용의 주된 감소는 인증/복호화 오프로드로 인한 것이다. 데이터그램 사이즈에 따라, 최종 효과는 오프로드된 경우에서의 완벽한 승리(완전한 MTU 데이터그램)이거나 또는 거의 비기는 것(즉, 최종 CPU 활용이 거의 동일함)이다. 따라서, 주된 부작용은 인증된 원격 호스트로 인한 버스 대역폭 활용이며, 이것은 큰 위험으로 나타나지는 않는다.

다른 DOS 기반 공격은 이웃 갱신 또는 라우팅 갱신을 삽입하여, 잘못된 MAC 어드레스가 선택되게 하거나 또는 잘못된 인터페이스가 선택되게 하는 것이다. 이것은 호스트 스택에 관련된 기존의 보안 문제이며, 호스트 스택은 이러한 유형의 메시지들 전부를 계속하여 프로세싱하기 때문에, IPSec 침니로 인한 새로운 공격 시나리오는 존재하지 않는다. 미세한 차이는, (캐싱된 상태의 갱신로 인하여) 공격시에 호스트와 NIC 둘다에서 추가의 CPU 사이클이 소비될 수 있다는 것이다. 그러나, 이것은 MAC 어드레스를 변경할 수 있는 보다 더 중요한 공격 윈도우에 비하면, 상당히 작은 부작용이다 (이것을 스푸핑 및/또는 부인의 한 형태로도 볼 수 있음에 유의해야 한다).

공격의 다른 형태는 특권의 상승(elevation of privilege)이다. 특권의 상승에 관련된 주된 관심사는, 소정의 보안되지 않은 메커니즘(또는 버그)에 의한 오프로드 IPSec 구현이 원격 노드가 코드를 오프로드 타겟에 로드할 수 있게 하는지의 여부이다. NIC 제조자에 대한 조건들은, 원격 엔티티가 인증되어 있지 않은 경우에 제조자가 NIC에 코드를 직접 로드할 수 있게 하는 것을 포함해야 한다.

특권 상승의 다른 형태는, 시스템 관리자가 SA의 오프로드(즉, 접속이 관리자가 원하는 것보다 더 좋은 서비스를 얻게 됨)를 금지하도록 오프로드 매니저를 구성할 때 오프로드를 강제하는 것, 또는 큐 내에서 그 자체를 촉진하는 발견적 학습법을 추측함으로써 오프로드를 위한 다른 프로세스들에 비교하여 SA의 우선순위를 변경하는 것이다. 이것은 정보 공개 공격에 관한 논의에서 이미 검토되었다.

본 발명의 원리들이 적용될 수 있는 많은 가능한 실시예들과 관련하여, 도면들에 관련하여 여기에 설명된 실시예는 단지 설명의 목적을 위한 것이며, 본 발명의 범위를 한정하기 위한 것이 아님을 알아야 한다. 예를 들어, 본 기술분야의 숙련된 기술자라면, 소프트웨어로 나타난 실시예의 구성요소들이 하드웨어로 구현될 수도 있고 그 반대도 마찬가지이며, 본 발명의 취지를 벗어나지 않고서도 실시예들의 구성 및 세부사항이 수정될 수 있음을 알 것이다. 그러므로, 여기에 개시된 본 발명은 그러한 모든 실시예들이 아래의 청구항들 및 그 등가물들의 범위 내에 포함되도록 하는 것이다. 따라서, 본 발명의 범위는 상기의 상세한 설명이 아니라 첨부된 특허청구범위에 의해 나타난다. 청구항들의 등가물의 의미 및 범위 내에 포함되는 모든 변경들도 그 범위 내에 포함된다.

본 발명은 집적된 호스트 프로토콜 스택 관리로 오프로드하는 보안 인터넷 프로토콜을 위한 방법 및 장치를 제공한다.

Claims (20)

1. 네트워크 프로토콜 스택의 하나 이상의 중간 소프트웨어 계층의 시퀀스, 및 보안 인터넷 프로토콜 계층을 포함하는 컴퓨터화된 시스템(computerized system)에서 사용하기 위해 저장된 컴퓨터 실행가능 명령어들을 포함하는 컴퓨터 판독가능 기록 매체로서 - 상기 중간 소프트웨어 계층들 각각은 네트워크 프로토콜 상태 객체를 갖고, 상기 보안 인터넷 프로토콜 계층은 상태 객체를 가지고, 상기 컴퓨터 실행가능 명령어들은 실행 시, 상기 컴퓨터화된 시스템으로 하여금, 하나 이상의 목적지 프로세싱 컴포넌트와 하나 이상의 소스 프로세싱 컴포넌트 간의 제어를 전달하기 위한 단계들을 수행하게 하고, 상기 제어는 설정된 네트워크 통신의 무결성을 계속 유지하면서, 보안 연관(security association, SA) 오프로드 블록 내의 적어도 하나의 보안 연관을 위한 적어도 하나의 보안 연관 함수와 복수의 상태 객체를 프로세싱하는 데에 요구됨 -,

   상기 컴퓨터 실행가능 명령어들은, 실행 시, 상기 컴퓨터화된 시스템으로 하여금,

   상기 SA 오프로드 블록에 대해 상태 객체를 패키지화(packaging up)하고, 상기 SA 오프로드 블록에 대한 상태 객체를 상기 보안 인터넷 프로토콜 계층 아래에 있는 상기 중간 소프트웨어 계층들을 통하여 송신하는 단계 - 상기 보안 인터넷 프로토콜 계층 아래에 있는 중간 소프트웨어 계층들 각각은 자신의 네트워크 프로토콜 상태 객체를 상기 SA 오프로드 블록에 대한 상태 객체에 추가함 -,

   상기 SA 오프로드 블록에 대한 상태 객체 및 상기 보안 인터넷 프로토콜 계층 아래에 있는 상기 중간 소프트웨어 계층들의 네트워크 프로토콜 상태 객체들을 포함하는 오프로드 블록 데이터 구조를 생성하는 단계,

   상기 오프로드 데이터 구조를, 상기 소스 프로세싱 컴포넌트로부터 상기 목적지 프로세싱 컴포넌트로 전달하는 단계, 및

   상기 목적지 컴포넌트가 상기 오프로드 블록 데이터 구조를 수신하였고 상기 적어도 하나의 보안 연관 함수를 프로세스할 준비가 되어 있음을 나타내는 완료 메시지를 수신하는 단계

   를 포함하는 단계들을 수행하게 하는 컴퓨터 판독가능 기록 매체.
2. 제1항에 있어서,

   상기 SA 오프로드 블록에 대한 SA 자원 조건들을 상기 보안 인터넷 프로토콜 계층 아래에 있는 상기 중간 소프트웨어 계층들을 통하여 상기 목적지 프로세싱 컴포넌트에 송신하는 단계를 수행하기 위한 컴퓨터 실행가능 명령어들을 더 포함하고, 상기 보안 인터넷 프로토콜 계층 아래에 있는 상기 중간 소프트웨어 계층들 각각은 자신의 자원 조건들을 상기 SA 오프로드 블록에 대한 SA 자원 조건들에 추가하는 컴퓨터 판독가능 기록 매체.
3. 제2항에 있어서,

   상기 SA 오프로드 블록에 대한 SA 자원 조건들을 상기 보안 인터넷 프로토콜 계층 아래에 있는 상기 중간 소프트웨어 계층들을 통하여 상기 목적지 프로세싱 컴포넌트에 송신하는 단계는, 상기 SA 자원 조건들을 상기 오프로드 블록 데이터 구조 내로 패키지화하는 단계를 포함하는 컴퓨터 판독가능 기록 매체.
4. 제1항에 있어서,

   상기 목적지 프로세싱 컴포넌트와 상기 소스 프로세싱 컴포넌트 중 하나는 주변 장치인 컴퓨터 판독가능 기록 매체.
5. 제1항에 있어서,

   상기 SA 오프로드 블록에 대한 상태 객체는 복수의 상태 변수를 포함하고, 상기 복수의 상태 변수는 캐싱된 상태 변수들을 포함하는 컴퓨터 판독가능 기록 매체.
6. 제5항에 있어서,

   상기 캐싱된 상태 변수들은 연산코드 변수(opcode variable), 암호화된 바이트들에 관한 관대한 제한(soft limit) 및 엄격한 제한(hard limit), 관대한 만료(soft expiration)에 대한 패킷의 개수에 관한 관대한 제한, 관대한 엄격한 만료(soft hard expiration)에 대한 패킷의 개수에 관한 엄격한 제한 및 플래그들 중 적어도 하나를 포함하는 컴퓨터 판독가능 기록 매체.
7. 제6항에 있어서,

   상기 캐싱된 상태 변수들은 OLDSPI 플래그를 더 포함하는 컴퓨터 판독가능 기록 매체.
8. 제1항에 있어서,

   상기 SA 오프로드 블록에 대한 상태 객체는 복수의 상태 변수를 포함하고, 상기 복수의 상태 변수는 일정한(constant) 상태 변수들을 포함하는 컴퓨터 판독가능 기록 매체.
9. 제8항에 있어서,

   상기 일정한 상태 변수들은 로컬 및 원격 포트들, 로컬 및 원격 IP 어드레스들, 프로토콜 유형 및 보안 연관 플래그들을 포함하는 컴퓨터 판독가능 기록 매체.
10. 제9항에 있어서,

    상기 보안 연관 플래그들은 DynamicSA 플래그, InfiniteLife 플래그, 및 플래그들 또는 인바운드 보안 연관들을 포함하는 컴퓨터 판독가능 기록 매체.
11. 제1항에 있어서,

    상기 SA 오프로드 블록에 대한 상태 객체는 복수의 상태 변수를 포함하고, 상기 복수의 상태 변수는 위임된 상태 변수들을 포함하는 컴퓨터 판독가능 기록 매체.
12. 제11항에 있어서, 위임된 상태 변수들은, 플래그들, SA를 통해 전송된 바이트들의 카운트, SA가 유휴상태인 순간의 횟수, 상기 SA를 통해 전송된 신뢰적인(confidential) 바이트의 개수, 상기 SA를 통해 전송된 인증된 바이트의 개수, 및 아웃바운드 또는 인바운드 매개변수들 중 하나를 포함하는 컴퓨터 판독가능 기록 매체.
13. 제1항에 있어서, 상기 소스 프로세싱 컴포넌트로부터 상기 목적지 프로세싱 컴포넌트로 제어를 전송하는 단계들 동안에 수신된 데이터그램을 상기 목적지 프로세싱 컴포넌트로 전달하는 것을 포함하는 단계를 수행하기 위한 컴퓨터 실행가능 명령어들을 더 포함하는 컴퓨터 판독가능 기록 매체.
14. 제1항에 있어서, 상기 소스 프로세싱 컴포넌트로부터 상기 목적지 프로세싱 컴포넌트로 제어를 전송하는 단계들 동안에 캐싱된 변수가 변하였으면, 상기 캐싱된 변수를 갱신하는 것을 포함하는 단계를 수행하기 위한 컴퓨터 실행가능 명령어들을 더 포함하는 컴퓨터 판독가능 기록 매체.
15. 제14항에 있어서, 상기 캐싱된 변수는 연산코드 변수, 암호화된 바이트들에 대한 관대한 제한 및 엄격한 제한, 관대한 만료에 대한 패킷의 개수에 대한 관대한 제한, 관대한 엄격한 만료에 대한 패킷의 개수에 관한 엄격한 제한, 및 플래그들 중 적어도 하나를 포함하는 컴퓨터 판독가능 기록 매체.
16. 제15항에 있어서, 상기 연산코드 변수는 SA가 추가, 삭제 또는 대체되어야 하는 지를 나타내는 컴퓨터 판독가능 기록 매체.
17. 제1항에 있어서, 상기 오프로드 블럭 데이터 구조는 다음 블럭 포인터 및 종속 블럭 포인터로 상태 객체들 및 네트워크 프로토콜 상태 객체들을 링크시키며, 상기 보안 인터넷 프로토콜 계층 위의 프로토콜 스택 계층이 상기 소스 프로세싱 컴포넌트로부터 상기 목적지 프로세싱 컴포넌트로 제어를 전송하기 시작하였으면, 상기 SA 오프로드 블럭에 대한 상기 종속 블럭 포인터는 NULL이 아닌(non-NULL) 컴퓨터 판독가능 기록 매체.
18. 제1항에 있어서, 상기 소스 프로세싱 컴포넌트와 상기 목적지 프로세싱 컴포넌트 간의 제어의 전송이 완료된 후, 상기 SA 오프로드 블럭에 보안 연관을 추가하는 것을 포함하는 단계를 수행하기 위한 컴퓨터 실행가능 명령어들을 더 포함하는 컴퓨터 판독가능 기록 매체.
19. 제1항에 있어서, 상기 소스 프로세싱 컴포넌트와 상기 목적지 프로세싱 컴포넌트 간의 제어의 전송이 완료된 후, 상기 SA 오프로드 블럭 내의 보안 연관을 삭제하는 것을 포함하는 단계를 수행하기 위한 컴퓨터 실행가능 명령어들을 더 포함하는 컴퓨터 판독가능 기록 매체.
20. 제1항에 있어서, 상기 소스 프로세싱 컴포넌트와 상기 목적지 프로세싱 컴포넌트 간의 제어의 전송이 완료된 후, 상기 SA 오프로드 블럭 내의 보안 연관을 또 다른 보안 연관으로 대체하는 것을 포함하는 단계를 수행하기 위한 컴퓨터 실행가능 명령어들을 더 포함하는 컴퓨터 판독가능 기록 매체.

Images