KR100345539B1

KR100345539B1 - 제어 헤더 필드 및 유형 헤더 필드를 기반으로 한 광섬유채널 프레임 맵핑 방법

Info

Publication number: KR100345539B1
Application number: KR1020007012132A
Authority: KR
Inventors: 피아꼬피터; 로우취브레들리; 헨손칼엠
Original assignee: 에멀럭스 코포레이숀
Priority date: 1998-05-01
Filing date: 1999-04-26
Publication date: 2002-07-26
Also published as: JP2002513968A; WO1999057644A1; KR20010043204A; CA2330014A1; EP1075677A4; JP4173636B2; EP1075677A1; CA2330014C; US6098125A

Abstract

컴퓨터 링크내의 데이터의 프레임을 처리 또는 전송하기 위한 본 발명의 방법 및 장치는 라우팅 제어 및 각 프레임 내의 유형 필드를 기반으로 하는 호스트 메모리(312) 내의 특정 버퍼 링에 들어오는 프레임을 맵핑한다. 더 상세하게는, 광섬유 채널 링크 포드(302)는 수신기 라우팅 코드(RRCode) 레지스터(400)를 포함하는데, 이 레지스터는 라우팅 제어(R_CTL)매치 및 마스크 필드, 유형 매치 및 마스크 필드를 설정하기 위한 호스트 소프트웨어를 허용한다. 링크 포트는 수신된 프레임을 저장하는데 사용되는 여러 R_CTL/TYPE 호스트 메모리 버퍼 링 중에서 결정되는 대응하는 수신된 프레임 내의 R_CTL/TYPE 필드에 대하여 매치 및 마스크 하기 위해 이러한 레지스터를 사용한다. 링크 포트는 프래임에 연합된 프래임의 개시(SOF) 상태 워드 내에 코드(RRCode)를 위치시킨다. RRCode는 특정 R_CTL/TYPE 호스트 메모리 버퍼 링을 나타내거나, 매치 된 것이 없음을 나타내거나 다중 매치가 발견 됐음을 나타낸다. 프로토콜 엔진(306)은 수신된 프레임의 SOF 상태 워드 내의 RRCode 필드를 읽고, 직접 메모리 호출(DMA) 연산을 적절한 R_CTL/TYPE 버퍼 링에 큐잉시킨다. 호스트는 그 후 지시된 버퍼 링의 항목을 처리할 것이다. 버퍼 링이 프레임 유형에 대하여 "미리 정렬"된 이후로, 호스트는 들어오는 프레임에 더 효과적으로 응답할 것이다.

Description

제어 헤더 필드 및 유형 헤더 필드를 기반으로 한 광섬유 채널 프레임 맵핑 방법{METHOD OF MAPPING FIBRE CHANNEL FRAMES BASED ON CONTROL AND TYPE HEADER FIELDS}

컴퓨터 및 주변기기가 최근들어 급격히 확산되었다. 이로 인하여 이러한 디바이스들의 상호 접속의 개선된 방법에 대한 요구를 발생시켰다. 다른 종류의 컴퓨터 및 주변 구성요소들이 서로 통신하는 것이 가능하도록 네트워킹 페러다임은 매우 다양하게 개발되어 왔다.

이러한 네트웍을 통해 데이터가 교환될 수 있는 속도에는 병목현상이 존재한다. 네트웍 구조의 속도의 증가는 더 빠른 컴퓨터 처리 속도와 보조를 맞추지 못하기 때문에 이는 놀라운일이 아니다. 컴퓨터 칩의 처리능력은 역사적으로 약 18개월마다 두 배가되어 점차적으로 강력한 머신 및 "부족한 대역폭" 응용을 야기하게 되었다. MIPS(초당 백만 번의 명령어 처리)처리 능력당 일반적으로 초당 1 메가비트의 입력/출력이 요구되는 것으로 추정되었다. 쉽게 200 MIPS를 초과하는 현재의CPU에 있어서 네트웍이 이러한 빠른 속도에 맞추는 것은 어렵다.

광역 네트웍 및 채널(channel)은 컴퓨터 네트웍 구성을 위해 개발된 두 개의 방법이다. 통상적인 네트웍[예컨대, 랜(LAN)에 의한 것 및 왠(WAN)에 의한 것]은 많은 유연성 및 상대적으로 큰 거리 능력을 제공한다. 기업 시스템 접속(Enterprise System Connection)(ESCOM) 및 소형 컴퓨터 시스템 인터페이스(Small Computer System Interface)(SCSI) 같은 채널은 고도의 성능과 신뢰도를 높이도록 개발되어 왔다. 채널은 일반적으로 컴퓨터 사이 및 컴퓨터와 주변기기 사이의 전용의 짧은 거리 접속에 사용된다.

채널 및 네트웍의 각 특징은 "광섬유 채널(Fibre Channel)"로 알려진 새로운 네트웍 표준에 통합되었다. 광섬유 채널 시스템은 채널의 속도와 신뢰성에 네트웍의 유연성 및 접속성을 결합한다. 광섬유 채널 제품은 266Mbps 또는 1062Mbps와 같은 매우 높은 데이터 속도에서 실행될 수 있다. 이러한 속도는 압축되지 않고 완전한 동작(full motion)의, 고품질 영상과 같은 요구 어플리케이션을 처리하는 데 충분한 것이다.

통상적으로, 광섬유 채널을 배치하는 3가지 방법은 간단한 점 대 점 연결(simple point-to-point connections); 중재 루프(arbitrated loop); 및 교환 패브릭(switched fabric)이다. 가장 간단한 형태는 점 대 점 연결이며, 임의의 두 개의 광섬유 채널 시스템을 직접적으로 간단히 연결한다. 중재 루프는 광섬유 채널 링 연결이며, 이것은 중재를 통해 대역폭에 공유된 접근을 제공하는 광섬유 채널링 연결이다. 전환된 광섬유 채널 네트웍은 "패브릭(fabric)"이라고 불리며, 교차점교환(cross-point switching)의 잇점을 차용함으로써 최고의 성능을 가져온다.

광섬유 채널 패브릭은 통상적인 전화 시스템등과 유사하게 동작한다. 패브릭은 광섬유 채널 인터페이스 포트를 갖는 워크스테이션, 개인용 컴퓨터(PC), 서버, 라우터, 메인프레 및 저장 장치와 같은 다양한 장치들을 연결할 수 있다. 이러한 각 장치는 프레임의 헤더에 목적 포트의 어드레스를 삽입함으로써 패브릭을 "호출"하는 근원지 포트(origination port)를 포함할 수 있다. 패브릭 채널 사양은 이 프레임의 구조를 정의한다(이 프레임 구조는 본 발명에 의하여 설명되고 이하에서 기술될 데이터 전송 관련 논점을 이끌어냄).

광섬유 채널 패브릭은 바람직한 연결을 설정하는 모든 일을 하므로, 프레임 발생기는 복잡한 라우팅 알고리즘과 연관시킬 필요가 없다. 거기에는 설정을 위한 복잡하지 않은 영구 가상 회로(PVCs)가 있다. 광섬유 채널 패브릭은 16만 개의 주소 보다 더 많은 처리가 가능하므로, 매우 큰 네트웍을 수용하기에 적합하다. 패브릭은 간단하게 포트를 부가함으로써 확장될 수 있다. 완전하게 구성된 광섬유 채널 네트웍의 총 데이터 전송률은 초당 테라 비트의 영역 안에 있을 수 있다.

광섬유 채널 연결의 3개의 각 기본적 형태가 도 1에 도시되어 있는데, 광섬유 채널 기술을 사용하는 여러 방법을 보여준다. 특히, 컴퓨터 본체 상호 간을 연결하는 점 대 점 연결(100)이 도시되었다. 광섬유 채널 중재 루프(102)가 디스크 저장 유닛의 연결로 도시되었다. 광섬유 채널 교환 패브릭(104)은 워크스테이션(106), 컴퓨터 본체(108), 서버(110), 디스크 드라이버(112) 및 근거리 통신망(LAN):(114)을 연결한다. LAN은 예컨대, 이더넷(Ethernet),토큰 링(TokenRing) 및 FDDI(Fibre Distributed Data Interface) 네트웍을 포함한다.

안시(ANSI) 규격(X3.230-1994)은 광섬유 채널 네트웍을 결정한다. 이 사양은 광섬유 채널 기능을 다섯 개의 층으로 분류한다. 도 2에 도시한바와 같이 광섬유 채널의 다섯 개의 기능 층은 물리적 미디어 층(FC-0), 코딩 및 인코딩 층(FC-1); 프레임 프로토콜(framing protocal) 및 노드간의 흐름 제어를 포함하는 실제의 전송 메카니즘(FC-2), 공통 서비스 층(FC-3), 상부 층 프로토콜(FC-4)이다.

광섬유 채널이 상대적으로 높은 속도에서 동작할지라도, 더 빠른 프로세서의 요구를 충족시키기 위하여 속도를 더욱더 증가시키는 것이 바람직하다. 이를 실행하는 한가지 방법은 인터페이스 지점에서 발생하는 지연을 제거 또는 감소시키는 것이다. 이러한 지연 중의 하나는 FC-1 층에서 FC-2 층으로 프레임 전송을 하는 동안 발생한다. 이 인터페이스에서, 광섬유 채널 데이터 링크에 의해 링크된 장치들은 연속적으로 광섬유 채널 프레임을 수신한다. 프로토콜 엔진(PENG)은 각 프레임을 수신하여, 다음 층에서 수신된 것을 처리하며, 도 2에 FC-2 층이 도시되었다. 프로토콜 엔진의 기능은 각 프레임을 확인하는 것; 호스트에 각 프레임을 전달하는 직접 메모리 호출(DMA)연산을 대기 행렬에 넣는 것; 및 전송 프레임을 구축하는 것을 포함한다. 광섬유 채널 프레임은 여러 유형으로 도착한다. 각 프레임은 헤더(header) 및 페이로드(payload) 부분을 포함한다. 프레임 헤더의 한 부분은 라우팅 제어 필드 및 유형(R_CTL/TYPE)필드이며, 이것은 프레임 유형의 표시 및 라우팅 정보를 제공한다(상기 R_CTL/TYPE 필드는 분리 라우팅 및 유형 필드로서 충족될 수 있음). 광섬유 채널 네트웍은 인터넷에 호환되는 TCP/IP 프레임을 인식 및 취급할 수 있다. TCP/IP 프레임은 링크 제어 프레임 및 데이터 프레임을 포함하며, TCP/IP 프레임 각각의 프레임 헤더 내의 상기 R_CTL/TYPE 필드에 의해 서로 식별된다. TCP/IP 프레임은 일반적으로 광섬유 채널 프레임의 다른 유형과는 다르게 처리될 필요가 있다. 특히, TCP/IP 프레임은 특정 시간 내의 호스트 프로세서로부터의 응답을 요구할 수 있는데, 이러한 응답이 없을 경우 오류가 일어난다.

일반적인 프레임 취급의 통상적 방법은 프레임과 프레임 기초 사이상의 호스트 CPU의 연루에 의존한다. 예를 들면, 수신 프레임의 확인 및 DMA 연산 및 승인의 설정은 통상적으로 호스트 CPU를 포함하여, 프레임 전송 및 수신 속도를 제한하고, 호스트 CPU가 다른 태스크를 실행하는 것을 막는다. 더욱이, 소프트웨어 프로토콜 "스택(stack)"을 포함하는 호스트 CPU는 광섬유 채널과 같은 빠른 네트웍에 뒤지지 않는 데 어려움이 있다.

통상적인 광섬유 채널 호스트 어뎁터에 있어서, 프레임 라우팅 기능은 기판 상의 마이크로 프로세서에 의해 실행된다. 그러나, 저 경비의 구현에 있어서, 마이크로프로세서를 기반으로 하는 제품들은 전용의 하드웨어 또는 시퀀서 기반의 솔루션 등의 제품으로 대체될 수 있다. 이러한 솔루션에 있어서, 기판 상의 프로세서는 프레임 안의 R_CTL/TYPE 필드를 처리하기에 충분한 전산 능력을 갖지 못하여, 프레임은 처리를 위하여 호스트 메모리에 전달되어야만 한다. 프레임 유형의 분류에 있어서의 호스트에 의해 소비된 시간은 들어오는 요청에 응답함에 있어서의 과도한 지연의 원인이 된다.

전술한 것을 고려하면, 본 발명의 목적은, 광섬유 채널 네트웍과 같은 고속네트웍에서 데이터 전송 처리 속도를 증가시키는 것, 프로토콜 엔진의 데이터 프레임의 처리를 빠르게 하는 기술을 제공하는 것, 프로토콜 엔진 및 호스트 CPU 및 시스템 기억장치 사이의 데이터 왕래를 최소화 하는 것, 하드웨어 내에서의 광섬유 채널 프레임 라우팅의 실행, 및 호스트 소프트웨어 능률을 프레임의 특정 유형상으로 라우팅을 실행하기 위해 하드웨어를 사용함으로써 개선하는 것을 포함하며, 더 상세하게는 R_CTL/TYPE 필드를 기반으로 하는 특정 호스트 기반의 링 안으로 프레임의 초기 맵핑을 실행하는 것을 포함한다.

본 발명은 컴퓨터 네트웍에 관련된 것으로, 더 상세하게는 제어 헤더 필드 및 유형 헤더 필드를 기반으로 하여 프레임을 맵핑함으로써 프레임의 시퀀스를 발생하고 전송하는 것에 관련되어있다.

도 1은 광섬유 채널 기술을 활용한 복잡한 컴퓨터 네트웍 종래 기술의 블록도.

도 2는 광섬유 채널 표준 종래 기술의 다섯 기능 층의 블록도.

도 3은 본 발명에 따른 바람직한 통신 처리 시스템의 블록도.

도 4는 본 발명에 따른 바람직한 통신 처리 시스템에 있어서의 레지스터 및 버퍼 상호 작용의 블록도.

도 5는 본 발명의 바람직한 실시예에 따른 헤더 필드에 기반을 둔 맵핑 프레임의 간략한 흐름도.

도 6은 본 발명에 따른 헤더 필드에 기반을 둔 맵핑 프레임의 흐름도.

각각의 도면 안에서 동일한 참조 번호 및 명칭은 동일한 구성요소를 지시한다.

본 발명은 컴퓨터 데이터 링크 안에서의 데이터 프레임의 처리 및 전송을 지시하고 있다. 바람직한 실행에 있어서, 본 발명은 광섬유 채널 프로토콜 엔진이 각 프레임에 있어서의 라우팅 제어 및 유형 필드를 기반으로 하는 호스트 메모리 안의 특정 버퍼 링으로 들어오는 프레임을 맵핑 하는 것을 허락한다.

더 상세하게는, 본 발명에 따른 광섬유 채널 링크(NL-PORT)는 수신기 라우팅 코드(RRCode) 레지스터를 포함하고 있으며, 이 레지스터는 호스트 소프트웨어가 라우팅 제어(R_CTL) 매치(match) 및 마스크 필드(mask field), 및 유형 매치 및 마스크 필드를 설정하게 한다. 상기 NL-Port는 여러 R_CTL/TYPE 호스트 메모리 버퍼 링 중의 하나를 이 수신된 프레임을 저장하는데 사용되도록 결정하기 위한 수신된 프레임 안의 상응하는 R_CTL/TYPE 필드에 대하여 매치 시키고 마스크하기 위하여 이러한 레지스터를 사용한다. 바람직한 실시예에 있어서, NL-Port는 3-비트 코드(RRCode field)를 프레임에 결합된 프레임 상태 워드의 SOF(start of frame)안에 위치한다. 상기 RRCode는 특정 R_CTL/TYPE 호스트 메모리 버퍼 링을 지시하거나, 또는 매치 되지 않은 것이 발견되거나 다중 매치가 발견된 것을 나타낸다.

프로토콜 엔진(PENG)은 수신된 프레임의 SOF 상태 워드 안의 RRCode 필드를 읽고, 적절한 R_CTL/TYPE 버퍼 링을 위하여 직접 메모리 호출(DMA) 연산 대기 행렬에 넣는다. 상기 PENG은 지시된 R_CTL/TYPE 버퍼 링에 대한 버퍼 리스트 엔트리(buffer list entry)(BLE)를 "끌어당긴다(pull)". 이것은 호스트 메모리 내의 현재 시작하는 어드레스 및 저장 위치를 위한 길이를 지시한다. 그 다음, 상기 PENG은 수신된 프레임의 헤더 및/또는 페이로드를 지시된 버퍼 리스트 엔트리에 의해 인용된 호스트 메모리 안에 기록한다. 마지막으로, PENG은 기록 연산이 완료된 경우 응답을 호스트 구동장치에 보낸다. 호스트는 그 다음 지시된 버퍼 링의 항목을 처리할 것이다. 버퍼 링이 프레임 유형에 대하여 "미리 정렬"된 이후로, 호스트는 들어오는 프레임에 더 효과적으로 응답할 것이다.

본 발명의 이점은 개선된 호스트 소프트웨어 효과, 더 높은 속도의 수신 프레임 처리, 수신된 프레임의 더 빠른 라우팅 포함하는데, 이 이점은 특정 유형의 프레임에 관련된 호스트 버퍼 링에 라우팅을 실행하기 위해 하드웨어를 사용함에 의한다.

본 발명에 따른 또 다른 많은 실시예의 상세한 설명은 수반되는 도면 및 이후의 설명에서 설명된다. 본 발명에 따른 다른 특징, 목적 및 이점은 설명 및 도면과 청구항에 의해 명백해질 것이다.

개요

본 발명은 특정 유형의 프레임에 대한 라우팅을 하기 위해 하드웨어를 사용함으로써, 부분적으로 호스트 소프트웨어 효율을 개선한다. 광섬유 채널 네트웍 구조의 일부로서 구현된 경우, 본 발명은 호스트 메모리 내의 버퍼의 특정 링으로 들어오는 수신 프레임을 맵핑하는 광섬유 채널 프레임 헤더 안에서 라우팅 제어/유형(R_CTL/TYPE)필드를 사용한다.

도 3은 광섬유 채널 네트웍을 사용하기 위한 바람직한 통신 처리 시스템을 도시한다. 직렬 데이터는 광섬유 채널 데이터 링크(300)를 따라서 수신된다. 데이터 링크(300)로부터 수신된 프레임은 NL_Port(302)에 의해 처리되는데, 이 NL_Port(302)는 워드 안으로 들어오는 직렬 데이터를 디코드 및 병렬화 한 후 워드를 알려진 유형의 프레임으로 조립(assemble)한다.

프레임은 일반적으로 3개의 부분, 머리부분(preamble), 데이터 즉 "페이로드" 부분 및 후미 부분(trailer portion)을 포함한다. 광섬유 채널 데이터 링크에 있어서, 예컨대, SOF 워드(4 바이트), 프래임 헤더(24 바이트), 0 및 2112 사이의 페이로드 바이트, 및 CRC(cyclical redundancy check)워드(4 바이트)를 포함하는 데이터 부분 및 프레임 끝(end of frame):(EOF) 워드(4 바이트)를 포함한다. 링크 적용을 제어하는데 사용되는 프레임 헤더는, 장치 프로토콜 이동을 제어하며, 놓치거나 잘못된 프레임을 검출한다. 상기 CRC 워드는 데이터의 왜곡과 같은 전송의 문제가 있는지, 또는 전송 기간동안 프레임의 일부분이 없어지는 지를 나타낸다.

NL_Port(302)도 역시 수신된 각 프레임에 대하여 CRC 워드를 점검하며, CRC 상태 지시자 "양호-나쁨(good-bad)"의 결과를 EOF 워드로부터 발생되는 EOF 상태 워드 내의 다른 상태 정보 비트에 부가한다. NL_Port(302)는 그 후 수신 프레임 FIFO 버퍼(304)내에 각 프레임을 기록한다. 게다가 바람직한 수신 프레임 FIFO 버퍼 모듈(304)의 상세한 설명이 1997,9월 23일에 출원되고 계류중이며 본 발명의 양수인에게 양도된 미국 특허 출원 제 08/935,898호의 "프레임 끝 바이패스를 갖는 수신 프레임 FIFO(RECEIVE FRAME FIFO WITH END OF FRAME BYPAS)"의 명세서에 개시되어 있으며, 본 명세서에서 참조함으로써 구현된다,

프레임은 그 다음 프로토콜 엔진(PENG);(306)으로 지칭되는 전-이중(full-duplex) 통신 프로세서에 의해 수신된다. 여러 기능이 PENG(306)에 의해 수행되며, 1)직접 메모리 호출(DMA) 채널(316)을 통해 프로세서(314)의 호스트 메모리(312)안으로 수신된 프레임 내의 데이터를 기록하기 위해 호스트 명령이 대기 행렬에 들어가는 기능, 2)프레임이 수신될 다음 논리적 프레임(logical frame)임을 보증하기 위한 프레임 헤더를 확인 하는 기능, 3)프레임이 결함이 있는지 없는지를 결정하는 기능, 수신된 프레임 또는 호스트-발생 전송 명령에 응답하여 전송 프레임을 발생시키는 기능을 포함한다.

PENG(306)은 수신 프레임 FIFO 버퍼(304)로부터 헤더가 수신됨에 따라서 프레임 헤더를 프로토콜 버퍼(310)내에서 확인한다. PENG(306)은 또한 전송 프레임을 만들고 전송 프레임 FIFO 버퍼(308)를 통해 데이터 링크(300)에 전송한다. NL_Port(302), 수신 프레임 FIFO 버퍼(304), 및 PENG(306)은 특정 용도 집적 회로(application specific intergrated circuit)(ASIC)와 같은 단일 칩(single chip)상에서 구현될 수 있다. 바람직한 PENG(306)의 더 상세한 설명이 1997,9월 24일에 출원되고 계류중이며 본 발명의 양수인에게 양도된 미국 특허 출원 제 08/937,066호의 "전-이중 통신 프로세서(FULL-DUPLEX COMMUNICATION PROCESSOR)"의 명세서에 개시되어 있으며, 본 명세서에서 참조함으로써 구현된다, 프레임 확인에 관한 정보에 대해서는, 1998,3월 26일에 출원되고 계류중이며 본 발명의 양수인에게 양도된 미국 특허 출원 제 09/048,930호의 "맵핑되지 않은 광섬유 채널 프레임에 대한 호스트 버퍼 배치 및 확인 방법(METHOD OF VALIDATION AND HOST BUFFER ALLOCATION FOR UNMAPPED FIBRE CHANNEL FRAMES)"의 명세서에 개시되어 있으며, 본명세서에서 참조한다.

레지스터 매칭 및 마스킹

도 4는 본 발명의 바람직한 통신 처리 시스템에 따른 레지스터 및 버퍼 상호 작용의 블록도 이다. 바람직한 실시예에 있어서, NL_Port(302), 수신 프레임 FIFO 버퍼(304), 프로토콜 엔진(PENG):(306), 및 수신기 라우팅 코드("RRCode") 레지스터(400)의 매치 및 마스크 조정은 단일 집적 회로(402) 내에서 구현된다. 상기 RRCord 레지스터(400)는 NL_Port(302)에 결합된다. 예컨대, RRCord 레지스터(400)는 RRCode 저장을 위한 3개의 32비트 레지스터(400-0, 400-1, 400-2)를 포함한다.

각각의 RRCord 레지스터(400-0, 400-1, 400-2)는 유형 매치, 유형 마스크, R_CTL 매치, R_CTL 마스크를 결정하는 필드 값을 저장할 수 있다. 이들 필드의 항목은 수신된 프레임내의 상응하는 필드와 비교될 수 있다. 이러한 방법으로, RRCord는 다중 유형 값 및/또는 다중 R_CTL 값 및 그들의 조합에 매칭되도록 결정될 수 있다. 대표적인 실시예에 있어서, RRCode 레지스터의 각각의 매치 또는 마스크 필드는 8 비트이다. 마스크 비트는 매치 비트가 비교될 값을 나타내는 동안에, 비교할 프레임의 R_CTL 및 유형 필드 내의 상응하는 비트를 나타낸다. 예컨대, "10001000"의 매스크 값은 매치 값에 대하여 비교되는 단지 비트 3 및 7(0 위치에 있는 우측의 최하위 비트로부터 센 것임)만을 의미한다. NL_Port(302)가 프레임을 수신할 때, RRCode 레지스터(400)의 항목은 각 프레임 안의 R_CTL 및 유형 필드와 비교된다. 특히 프레임 헤더 내에서의 R_CTL 및 유형 필드의 값의 각각의 설정은 프레임 및 각각의 버퍼 링 사이의 연합을 결정한다. 바람직한 실시예에 있어서, 3개의 R_CTL/TYPE 버퍼 링이 있는데, 0, 1, 2는 RRCode 레지스터 400-0, 400-1, 400-2에 대응된다.

만약 매치가 RRCode 레지스터(400)항목의 설정 및 수신된 프레임의 R_CTL 및 유형 필드 사이에서 이루어진다면, NL_Port(302)는 프레임 헤더 및/또는 페이로드를 저장하기 위해 사용되는 버퍼 링을 나타내는 RRCode를 발생한다. 다른 일은 RRCode 내에서 마찬가지로 잘 인코드될 것이다. 바람직한 실시예에 있어서, 3개의 비트는 단일 RRCode 내에서 다음의 결과를 인코드하는 데 사용된다.

RRCode 의미

=========================================

000 매치 된 것이 발견되지 않음

001 RRCode 레지스터 0 만이 매치 됨

010 RRCode 레지스터 1 만이 매치 됨

011 RRCode 레지스터 2 만이 매치 됨

1xx 다중의 RRCode 레지스터가 매치 됨

생성된 RRCode는 그 후 수신된 프레임에 연관된 SOF 상태 워드 안으로 NL_Port(302)에 의해 바람직하게 삽입된다. 다음으로, PENG(306)은 수신된 프레임의 SOF 상태 워드 안의 RRCode 필드를 읽고, 상응하는 프레임 헤더 및/또는 페이로드를 저장하기 위하여 적절한 R_CTL/TYPE 버퍼 링(420)에 직접 메모리 호출(DMA) 연산을 대기 행렬에 넣는다. 바람직한 실시예에 있어서, 버퍼 링은 다음의 연합된프레임 유형을 다루기 위해 결정되는데, 그 프레임 유형은 전송 제어 프로토콜/인터넷 프로토콜(TCP/IP) 버퍼(420-0), 버퍼 링크 서비스(BLS) 버퍼(420-1), 및 확장된 링크 서비스(ELS) 버퍼(420-2)이다. 바람직한 실시예에 있어서, R_CTL/TYPE 버퍼 링(420)은 광섬유 채널 프로토콜(FCP) 응답기 프레임(이것은 국부적으로 생기는 FCP 교환을 위한 것이다.)을 제외한 모든 프레임을 수신하기 위해 사용된다. RRCode "000" 또는 "1xx"를 초래하는 프레임은 고정의 R_CTL/TYPE 버퍼 링을 사용할 것이다. 마지막으로, PENG(306)은 프래임이 저장되고 연산이 완료된 경우 호스트 구동장치에 응답을 보낸다.

분리된 R_CTL/TYPE 버퍼 링(420)은 적절한 구동장치 삽입 지점에 대한 들어오는 프레임을 디멀티플렉싱 하는 호스트를 돕는다. 버퍼 링은 호스트에 의해 제일 먼저 처리되는 최고로 높은 우선 순위의 R_CTL/TYPE 버퍼 링(400-0)으로 바람직하게 우선된다, 우선 순위는 낮은 우선 순위의 고정 R_CTL/TYPE 매치를 고려한다. 이 구성은 TCP/IP와 같은 높은 레벨의 프로토콜을 취급하기에 특히 만족스럽게 적합한데, 이는 광섬유 채널 네트웍 전반에 걸쳐, 이러한 프로토콜이 다른 프로토콜 보다 더욱 시기 적절한 방식의 호스트로부터의 응답을 요구하게 된 이후이다. 형태에 의해 우위 결정 및 분류된 프레임에 의해서, 호스트는 프레임 시퀀스의 일정 형태에 더 빠르게 응답하기 위하여 프로그램 될 수 있다.

바람직한 실행에 있어서, R_CTL/TYPE 버퍼 링(420)은 버퍼 기술자(記述子)(buffer Descriptor)(452)의 고정된 크기로 된 연속되는 목록(list)(450)의 수단에 의해 바람직하게 결정된다. 목록(450)은 논리적 링과 같은 하드웨어에 의해 처리된다. 버퍼 기술자(452)는 두 개의 워드로 구성되는데, 실제의 저장 버퍼의 개시점(바람직하게 워드 경계 상에)을 지시하는 어드레스(456) 및 버퍼 내의 워드의 총 수에 대한 길이(length)(예컨대, 바이트 수)(456)이다. 이러한 버퍼 링의 간접적인 한정은 본 기술분야에서 잘 알려진 사실이다.

동작 흐름

도 5는 본 발명의 바람직한 실시예에 따른 헤더 필드를 기반으로 하는 맵핑 프레임의 방법에 대한 간결화된 흐름도 이다. NL_Port(302)는 광섬유 채널 데이터 링크(300)(단계 500)로부터 프레임을 수신하며, 수신된 프레임의 R_CTL/TYPE 필드를 읽는다(단계 502). 별개의 RRCode는 RRCode 레지스터(400)의 항목에 대한 R_CTL/TYPE 필드의 비교를 기반으로 하는 프레임에 할당된다(단계 504). 프레임은 RRCode 값을 기반으로 한 처리를 위해 PENG(306)에 보내진다(단계 506). 특히, PENG(306)은 프레임을 지정된 RRCode에 대응하는 3개의 버퍼 링(420)중의 하나에 저장하거나 만약 RRCode가 RRCode 레지스터(400)와 매치 되지 않음을 나타내는 경우 고정 버퍼 링 내에 저장된다(단계 508).

도 6은 본 발명의 바람직한 실시예에 따른 R_CTL/TYPE 헤더 필드를 기반으로 하는 광섬유 채널 프레임 맵핑 방법의 더 상세한 흐름도를 도시한다. 더 상세하게는, NL_Port(302)는 광섬유 채널 데이터 링크(300)로부터 광섬유 채널 프레임을 수신하고 수신된 프레임의 R_CTL/TYPE 필드를 판독한다(단계 600). 만약 수신된 프레임의 R_CTL/TYPE 필드가 RRCode 레지스터(400-0)와 매치 된다면(즉, TCP/IP 프레임을 지시함):(단계 602), NL_Port(302)는 3비트 RRCode를 001 값을 갖는 수신된 프레임의 SOF 상태 워드 필드 안에 위치시킨다(단계 604).

그러나, 만약 수신된 프레임의 R_CTL/TYPE 필드가 RRCode 레지스터(400-1)와 매치 된다면(즉, BLS 프레임을 지시함):(단계 606), NL_Port(302)는 010 값을 갖는 수신된 프레임의 SOF 상태 워드 필드 안의 3비트 RRCode를 위치시킨다(단계 608).

대안으로, 만약 수신된 프레임의 R_CTL/TYPE 필드가 RRCode 레지스터(400-2)와 매치 된다면(즉, ELS 프레임을 지시함):(단계 610), NL_Port(302)는 011 값을 갖는 수신된 프레임의 SOF 상태 워드 필드 안의 3비트 RRCode를 위치시킨다(단계 612).

그러나, 만약 수신된 프레임의 R_CTL/TYPE 필드의 값이 3개의 R_CTL/TYPE RRCode 레지스터(400)중의 하나와 매치 되지 않는다면, RRCode는 초기값(바람직하게는 000)으로 설정되는데 이것은 프로토콜엔진(PENG):(306)에 프레임이 초기 R_CTL/TYPE 버퍼 링 안에 저장 되는 것을 알려준다(단계 614).

프레임은 그 후 프레임의 SOF 상태 워드 필드 내에 배정된 RRCode의 값을 기반으로한 처리를 위하여 PENG(306)에 보내진다. PENG(306)은 수신된 프레임의 배정된 RRCode 판독하고(단계 616), DMA 연산을 상응하는 버퍼 링에 큐잉(queueing)한다(단계 618).

더 상세하게는 단계(618)는 다음의 기능들을 수행한다 즉, 만일 수신된 프레임의 RRCode가 "001"과 같으면(단계 620), PENG(306)은 DMA 연산을 TCP/IP 버퍼 링(420-0)에 줄서게 한다(단계 622). 만약 수신된 프레임의 RRCode가 "010"과 같으면(단계 624), PENG(306)은 DMA 연산을 BLS 버퍼 링(420-1)에 줄서게 한다(단계626). 만약 수신된 프레임의 RRCode가 "011"과 같으면(단계 628), PENG(306)은 DMA 연산을 ELS 버퍼 링(420-2)에 줄서게 한다(단계 630).

선택적으로, 만약 다중 매치가 RRCode 레지스터(400)에 이루어진다면, 수신된 프레임의 RRCode는 독특한 값으로 설정될 것이며,(바람직하게는 1xx 임) 여기서 "xx"는 모든 값이 될 것이다.

본 발명의 많은 실시예가 기술되었다. 그럼에도 불구하고, 본 발명의 정신 및 영역을 벗어나지 않는 범위에서 여러 변경이 행해질 수 있다는 것은 말할 나위도 없을 것이다. 예를 들면, 상술된 수많은 단계 및 실험이 다른 시퀀스 내에서도 수행될 수 있으며, 여전히 같은 결과를 얻는다. 따라서, 다른 실시예들은 다음 청구항들의 영역 내에 있다.

Claims

네트웍 시스템으로부터 수신된 변화하는 유형의 프레임의 맵핑 방법에 있어서:

(a) 연관된 헤더 및 페이로드를 포함하는 프레임을 수신하는 단계와,

(b) 상기 수신된 프레임의 상기 헤더의 적어도 하나 이상의 필드를 판독하는 단계와,

(c) 각각의 필드를 적어도 하나 이상의 대응하는 미리 정의된 매치 값과 비교하는 단계와,

(d) 코드를 상기 비교 결과를 기반으로 상기 수신된 프레임에 배정하는 단계와,

(e)상기 수신된 프레임으로부터의 데이터를 상기 코드에 대응하는 버퍼 내에 저장하는 단계

를 포함하는 프레임 맵핑 방법.
제1항에 있어서, 상기 비교하는 단계 이전에 각각의 필드를 미리 정의된 대응하는 마스크 값으로 마스크하는 단계를 더 포함하는 프레임 맵핑 방법.
제1항에 있어서, 상기 네트웍 시스템은 광섬유 채널 네트웍인 것인 프레임 맵핑 방법.
제3항에 있어서, 상기 필드는 R_CTL/TYPE 필드인 것인 프레임 맵핑 방법.
제3항에 있어서, 상기 적어도 하나의 프레임 유형은 TCP/IP 프레임 유형인 것인 프레임 맵핑 방법.
제1항에 있어서:

(a) 각각의 버퍼에 우선 순위를 배정하는 단계와,

(b) 우선 순위를 기반으로 버퍼의 항목을 처리하는 단계를 더 포함하는 프레임 맵핑 방법.
제1항에 있어서, 상기 각각의 버퍼는 링 버퍼인 것인 프레임 맵핑 방법.
네트웍 시스템으로부터 수신된 변화하는 유형의 프레임의 맵핑 시스템에 있어서:

(a) 연관된 헤더 및 페이로드를 포함하는 프레임을 수신하기 위한 수신기 회로와,

(b) 적어도 하나 이상의 미리 정의된 매치 값을 저장하기 위한 적어도 하나 이상의 레지스터와,

(c) 수신된 프레임의 상기 헤더의 적어도 하나 이상의 필드를 각각의 대응하는 미리 정의된 각 레지스터의 매치 값과 비교하기 위한 비교 회로와,

(d) 코드를 상기 비교 결과를 기반으로 상기 수신된 프레임에 배정하기 위한 코드 배정 회로와,

(e)상기 수신된 프레임으로부터의 데이터를 상기 코드에 대응하는 버퍼 내에 저장하기 위한 버퍼 저장 시스템을 포함하는 것인 프레임 맵핑 시스템.
제8항에 있어서, 각각의 레지스터는 각각의 미리 정의된 매치 값과 연관된 미리 정의된 마스크 값을 저장하고, 상기 비교 회로는 비교하기 전에 대응하는 미리 정의된 마스크 값에 의해 각각의 필드를 마스크 하는 것인 프레임 맵핑 시스템.
제8항에 있어서, 상기 네트웍 시스템은 광섬유 채널 네트웍인 것인 프레임 맵핑 시스템.
제10항에 있어서, 상기 적어도 하나의 필드는 R_CTL/TYPE 필드인 것인 프레임 맵핑 시스템.
제10항에 있어서, 상기 적어도 하나의 프레임 유형은 TCP/IP 프레임 유형인 것인 프레임 맵핑 시스템.
제8항에 있어서, 상기 코드는 우선 순위와 연관되어있고, 상기 버퍼 저장 시스템은 상기 우선 순위를 기반으로 상기 수신된 프레임으로부터의 데이터를 저장하는 것인 프레임 맵핑 시스템.
제8항에 있어서, 각각의 버퍼는 링 버퍼인 것인 프레임 맵핑 시스템.