KR20150146406A - 패킷들의 유연한 수정을 실현하기 위해 제네릭 수정 인스트럭션을 사용하는 방법 및 이의 장치 - Google Patents

패킷들의 유연한 수정을 실현하기 위해 제네릭 수정 인스트럭션을 사용하는 방법 및 이의 장치 Download PDF

Info

Publication number
KR20150146406A
KR20150146406A KR1020150084526A KR20150084526A KR20150146406A KR 20150146406 A KR20150146406 A KR 20150146406A KR 1020150084526 A KR1020150084526 A KR 1020150084526A KR 20150084526 A KR20150084526 A KR 20150084526A KR 20150146406 A KR20150146406 A KR 20150146406A
Authority
KR
South Korea
Prior art keywords
protocol
generic
header
packet
bytes
Prior art date
Application number
KR1020150084526A
Other languages
English (en)
Other versions
KR102368166B1 (ko
Inventor
치린지브 싱
자히 다니엘
제랄드 슈미트
사우린 파텔
Original Assignee
캐비엄, 인코포레이티드
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 캐비엄, 인코포레이티드 filed Critical 캐비엄, 인코포레이티드
Publication of KR20150146406A publication Critical patent/KR20150146406A/ko
Application granted granted Critical
Publication of KR102368166B1 publication Critical patent/KR102368166B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/745—Address table lookup; Address filtering
    • H04L45/7453—Address table lookup; Address filtering using hashing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/30—Peripheral units, e.g. input or output ports
    • H04L49/3009—Header conversion, routing tables or routing tags
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

패킷 헤더들을 수정하기 위한 장치의 실시예들은 제네릭화된 프로토콜 헤더들에 커맨드들을 적용함으로써 패킷들의 프로그램가능한 수정들에 관련된다. 인커밍 패킷들의 프로토콜 헤더 각각은 패킷 헤더들에 대한 수정들을 실현하기 위해 해당 프로토콜에 특정된 제네릭 포맷으로 나타낸다. 프로토콜 헤더로부터의 누락 필드들이 검출되고, 그리고 프로토콜 헤더는, 프로토콜 헤더가 누락 필드들을 포함하는 해당 프로토콜의 모든 가능한 필드들을 포함하도록, 최대 사이즈로 확장된다. 필드들 각각은 프로토콜 헤더가 대응하는 프로토콜의 변형에 상관없이 동일한 오프셋을 갖는다. 수정은 확장된 프로토콜 헤더들에 적용된 커맨드들의 세트를 사용한다. 따라서 모든 커맨드들은 이들 커맨드들이 인커밍 헤더들 (예를 들어, 사이즈 및 프로토콜) 에 독립적이기 때문에 제네릭이다.

Description

패킷들의 유연한 수정을 실현하기 위해 제네릭 수정 인스트럭션을 사용하는 방법 및 이의 장치{METHOD OF USING GENERIC MODIFICATION INSTRUCTIONS TO ENABLE FLEXIBLE MODIFICATIONS OF PACKETS AND AN APPARATUS THEREOF}
본 발명은 패킷 헤더 수정들에 관한 것이다. 보다 구체적으로, 본 발명은 패킷들의 유연한 수정을 실현하기 위해 제네릭 수정 인스트럭션을 사용하는 방법 및 그 장치에 관한 것이다.
네트워크 패킷은 인터넷이 사용하는 프로토콜들, 예를 들어 TCP/IP/이더넷 (Transmission Control Protocol/Internet Protocol/Ethernet Protocol) 을 통해서 데이터를 반송한다. 통상적인 스위치는 패킷들을 수신지 또는 다른 스위치로 전송하기 이전에 인커밍 패킷들의 다양한 필드들을 수정할 수 있다. 인커밍 패킷들은 다양한 이유들로 인해서, 예를 들어 패킷들이 어디로 포워딩되고 있는지, 수신지가 지원하는 프로토콜, 패킷들의 우선순위, 프로토콜 헤더의 인커밍 포맷 등으로 인해서 수정된다. 네트워크 프로토콜들이 진화함에 따라서, 프로토콜 헤더의 하나 이상의 필드들이 선택 사양적일 수 있으며, 이는 스위치의 하드웨어를 복잡하게 하는데, 그 이유는 프로토콜 헤더 내의 소정의 필드가 언제나 고정된 오프셋으로 있는 것이 아닐 수 있기 때문이다.
패킷 수정 동안에, 종래 기술의 스위치는 해당 패킷 내의 프로토콜 레이어 각각을 선형적으로 프로세싱한다. 이러한 프로세싱은 레이턴시를 포함하여서 네트워크와 관련된 성능 문제들을 야기하며, 이는 구현을 위해서 프로세싱 리소스들이 과잉제공되게 할 수 있다.
패킷 헤더들을 수정하기 위한 장치의 실시예들은 제네릭화 (generalize) 된 프로토콜 헤더들에 커맨드들을 적용함으로써 패킷들의 프로그램가능한 수정들에 관련된다. 인커밍 패킷들의 프로토콜 헤더 각각은 패킷 헤더들에 대한 수정들을 실현하기 위해 해당 프로토콜에 특정된 제네릭 포맷 (generic format) 으로 나타낸다. 프로토콜 헤더로부터의 누락 필드들이 검출되고, 그리고 프로토콜 헤더는, 프로토콜 헤더가 누락 필드들을 포함하는 해당 프로토콜의 모든 가능한 필드들을 포함하도록, 최대 사이즈로 확장된다. 필드들 각각은 프로토콜 헤더가 대응하는 프로토콜의 변형에 상관없이 동일한 오프셋을 갖는다. 수정은 확장된 프로토콜 헤더들에 적용된 커맨드들의 세트를 사용한다. 따라서 모든 커맨드들은 이들 커맨드들이 인커밍 헤더들 (예를 들어, 사이즈 및 프로토콜) 에 독립적이기 때문에 제네릭이다.
일 양태에서, 네트워크 디바이스의 리라이트 엔진의 방법이 제공된다. 방법은, 프로토콜 헤더에 대한 제네릭 포맷에 따라 패킷의 프로토콜 헤더 각각을 제네릭화하는 단계를 포함한다. 제네릭 포맷은 프로토콜의 모든 가능한 필드들을 포함한다. 이와 같이, 필드들 각각은 프로토콜 헤더가 대응하는 프로토콜의 변형과 상관없이 동일한 오프셋을 갖는다. 제네릭화된 프로토콜 헤더 각각은 비트 벡터를 포함한다. 비트 벡터는 제네릭화된 프로토콜 헤더의 바이트 각각에 대하여 바이트 당 비트 (bit per byte) 를 포함한다. 비트 벡터는 무효한 (invalid) 필드들에 대해 0으로 마킹된 비트들 및 유효한 필드들에 대해 1로 마킹된 비트들을 갖는다. 본 명세서에서, 무효한 필드는 수신된 패킷의 프로토콜 헤더 내에 존재하지 않는 필드이고, 유효한 필드는 수신된 패킷의 프로토콜 헤더 내에 존재하는 필드이다.
방법은 또한 적어도 하나의 제네릭화된 프로토콜 헤더를 수정하기 위해 네트워크 스위치의 메모리 내에 저장된 제네릭 커맨드들의 세트로부터 적어도 하나의 커맨드를 사용하는 단계를 포함한다. 적어도 하나의 제네릭화된 프로토콜 헤더의 수정은 네트워크 스위치의 아웃고잉 포트의 에그레스 포트 타입 (egress portType) 에 기초한다. 적어도 하나의 제네릭화된 프로토콜 헤더의 수정은 업데이트된 비트 벡터를 발생시킨다. 일부 실시예들에서, 방법은 또한 얼마나 많은 비트들이 변화되는지 결정하기 위해 비트 벡터 및 업데이트된 비트 벡터에 XOR 연산을 수행하는 단계를 포함한다.
제네릭 커맨드들의 세트는 인커밍 패킷 헤더들과 상관없이 헤더 수정을 위해 사용되기 때문에, 제네릭 커맨드들의 세트는 프로토콜의 제 1 변형의 패킷 헤더를 수정하고 프로토콜의 제 2 변형의 패킷 헤더를 수정하기 위해 사용될 수 있다. 유사하게, 프로토콜의 제 1 변형의 패킷 헤더를 수정하고 프로토콜의 제 2 변형의 패킷 헤더를 수정하기 위해 사용될 수 있다.
또 다른 양태에서, 네트워크 스위치의 방법이 제공된다. 방법은, 네트워크 스위치의 메모리 내에 제네릭 커맨드들의 세트를 유지하는 단계를 포함한다. 일부 실시예들에서, 제네릭 커맨드들의 세트 내의 각각의 커맨드는 소프트웨어가 프로그램하는 마이크로코드로서 동작한다.
일부 실시예들에서, 제네릭 커맨드들의 세트는 Delete 커맨드를 포함하고, Delete 커맨드의 파라미터들은 Start 및 Size를 포함한다. Delete 커맨드는 비트 벡터 내에서 Size 바이트들에 대응하는 비트들을 0으로 마킹함으로써 Start 위치로부터 제네릭화된 프로토콜 헤더 내에서 Size 바이트들을 삭제한다.
일부 실시예들에서, 제네릭 커맨드들의 세트는 Copy 커맨드를 포함하고, Copy 커맨드의 파라미터들은 Source, SourceOffset , Size, DestinationOffset, Bitmask , copyConstantBitMask 및 copyConstantData를 포함한다. Copy 커맨드는 Source의 SourceOffset으로부터 제네릭화된 프로토콜 헤더의 DestinationOffset으로 Size 바이트들의 데이터를 카피한다. 일부 실시예들에서, Copy 커맨드는 비트마스크 연산들을 위해 Bitmask를 사용한다. 일부 실시예들에서, copyConstantBitMask가 비트 위치에 “1”을 포함할 때, copyConstantData 내의 대응하는 위치로부터의 바이트는 대응하는 위치에서 제네릭화된 프로토콜 헤더 내로 카피된다. 일부 실시예들에서, copyConstantData는 메모리 내에 저장되고 소프트웨어로 규정된다. 대응하는 수신지 바이트들의 유효성은 Source의 데이터의 유효성에 의존하고, 비트 벡터 내에서 무효한 바이트들을 나타내는 비트들은 0으로 마킹되고 비트 벡터 내에서 유효한 바이트들을 나타내는 비트들은 1로 마킹된다.
일부 실시예들에서, 제네릭 커맨드들의 세트는 Move 커맨드를 포함하고, Move 커맨드의 파라미터들은 StartOffset , DestinationOffset 및 Size를 포함한다. Move 커맨드는 제네릭화된 프로토콜 헤더 내의 Size 바이트들을 StartOffset으로부터 DestinationOffset으로 이동시킨다. 대응하는 수신지 바이트들의 유효성은 Source 내의 데이터의 유효성에 의존하고, 대응하는 소스 바이트들은 무효가 되고, 비트 벡터 내에서 무효한 바이트들을 나타내는 비트들은 0으로 마킹되고 비트 벡터 내에서 유효한 바이트들을 나타내는 비트들은 1로 마킹된다.
방법은 또한 네트워크 스위치의 인커밍 포트에서 패킷을 수신하는 단계, 및 프로토콜 헤더에 대한 제네릭 포맷에 따라 패킷의 프로토콜 헤더 각각을 제네릭화하는 단계를 포함한다. 프로토콜 헤더 각각을 제네릭화하는 단계는, 패킷의 프로토콜 헤더로부터 누락 필드들을 검출하는 단계, 및 검출에 기초하여, 누락 필드들을 포함시킴으로써 프로토콜 헤더를 제네릭 포맷으로 확장시키는 단계를 포함한다. 제네릭화된 프로토콜 헤더 각각은 무효한 필드들에 대해 0으로 마킹된 비트들 및 유효한 필드들에 대해 1로 마킹된 비트들을 갖는 비트 벡터를 포함한다.
방법은 또한 제네릭화된 프로토콜 헤더에 제네릭 커맨드들의 세트로부터 적어도 하나의 커맨드를 적용함으로써 제네릭화된 프로토콜 헤더들 중 적어도 하나의 프로토콜 헤더를 수정하여, 비트 벡터를 업데이트하는 단계를 포함한다.
방법은 또한 업데이트된 비트 벡터에 기초하여 새로운 프로토콜 헤더를 형성하는 단계, 및 네트워크 스위치의 아웃고잉 포트를 통해 새로운 프로토콜 헤더를 갖는 패킷을 전송하는 단계를 포함한다. 일부 실시예들에서, 방법은 또한 새로운 프로토콜 헤더를 갖는 패킷을 전송하기 전에, 수행된 모든 연산들에 대해 부가되거나 삭제된 바이트들의 수를 카운팅하는 단계를 포함한다.
또 다른 양태에서, 네트워크 스위치가 제공된다. 네트워크 스위치는 패킷들을 수신 및 전송하기 위한 입력 포트 및 출력 포트를 포함한다.
네트워크 스위치는 또한 제네릭 커맨드들의 세트를 저장하기 위한 메모리를 포함한다. 제네릭 커맨드들의 세트는 인커밍 헤더들과 상관없이 헤더 수정들을 위해 사용된다. 일부 실시예들에서, 제네릭 커맨드들의 세트는 Delete 커맨드, Copy 커맨드 및 Move 커맨드를 포함한다.
네트워크 스위치는 또한 제네릭 커맨드들의 세트로부터 적어도 하나의 커맨드를 사용함으로써 수정을 위해 패킷들 각각의 프로토콜 헤더 각각을 제네릭화하도록 패킷들을 프로세싱하기 위한 리라이트 엔진을 포함한다.
일부 실시예들에서, 프로토콜 헤더 각각은 대응하는 프로토콜에 특정된 소프트웨어로 규정된 맵핑사항들 중 하나에 따라 제네릭화된다. 일부 실시예들에서, 제네릭화된 프로토콜 헤더 각각은 무효한 필드들에 대해 0으로 마킹된 비트들 및 유효한 필드들에 대해 1로 마킹된 비트들을 갖는 비트 벡터를 포함한다.
전술한 바는 유사한 참조 부호들이 상이한 도면들에 걸쳐서 동일한 부분들을 지칭하는 첨부 도면들에서 예시된 바와 같은, 본 발명의 예시적인 실시예들의 다음의 보다 구체적인 설명으로부터 명백해질 것이다. 도면들은 반드시 실제 축척대로 되지는 않으며, 대신에 본 발명의 실시예들을 예시할 시에 강조되었다.
도 1은 패킷들의 예시적인 프로토콜 레이어 조합들을 예시한다.
도 2는 본 발명의 일부 실시예들에 따른 로컬 프로토콜 테이블의 예시적인 구조를 예시한다.
도 3은 본 발명의 일부 실시예들에 따른 네트워크 스위치의 예시적인 방법을 예시한다.
도 4는 본 발명의 일부 실시예들에 따른 네트워크 스위치의 다른 예시적인 방법을 예시한다.
도 5는 본 발명의 일부 실시예들에 따른 인커밍 패킷의 레이어들의 제네릭 포맷들 (generic formats) 로의 헤더 확장의 도를 예시한다.
도 6a 및 도 6b는 본 발명의 일부 실시예들에 따른 프로토콜 헤더의 예시적인 제네릭화를 예시한다.
도 7a 내지 도 7c는 본 발명의 일부 실시예들에 따른 프로토콜 헤더의 또 다른 예시적인 제네릭화를 예시한다.
도 8a 내지 도 8c는 본 발명의 일부 실시예들에 따른 프로토콜 헤더의 또 다른 예시적인 제네릭화를 예시한다.
도 9a 내지 도 9f는 본 발명의 일부 실시예들에 따른 프로토콜 헤더의 예시적인 수정을 예시한다.
도 10a 내지 도 10e는 본 발명의 일부 실시예들에 따른 프로토콜 헤더의 다른 예시적인 수정을 예시한다.
도 11은 본 발명의 일부 실시예들에 따른 리라이트 엔진 (rewrite engine) 의 방법을 예시한다.
도 12는 본 발명의 일부 실시예들에 따른 네트워크 스위치의 또 다른 방법을 예시한다.
도 13은 본 발명의 일부 실시예들에 따른 네트워크 스위치의 또 다른 방법을 예시한다.
도 14는 본 발명의 일부 실시예들에 따른 네트워크 스위치의 또 다른 방법을 예시한다.
도 15는 본 발명의 일부 실시예들에 따른 네트워크 스위치의 또 다른 방법을 예시한다.
도 16은 본 발명의 일부 실시예들에 따른 리라이트 엔진의 다른 방법을 예시한다.
도 17은 본 발명의 일부 실시예들에 따른 네트워크 스위치의 또 다른 방법을 예시한다.
도 18은 본 발명의 일부 실시예들에 따른 리라이트 엔진의 또 다른 방법을 예시한다.
도 19는 본 발명의 일부 실시예들에 따른 네트워크 스위치의 또 다른 방법을 예시한다.
도 20은 본 발명의 일부 실시예들에 따른 레이어 구조의 예시적인 도면을 예시한다.
도 21은 본 발명의 일부 실시예들에 따른 리라이트 엔진의 또 다른 방법을 예시한다.
도 22는 본 발명의 일부 실시예들에 따른 네트워크 스위치의 또 다른 방법을 예시한다.
다음의 설명에서, 다수의 세부사항들이 설명을 위해서 제시된다. 그러나, 본 발명은 이러한 특정 세부사항들 사용 없이 실시될 수 있음을 본 기술 분야의 당업자는 이해할 것이다. 따라서, 본 발명은 도시된 실시예들로 한정되는 것이 아니며 본 명세서에서 기술된 원리들 및 특징들에 부합되는 가장 넓은 범위가 부여되어야 한다.
서론
네트워크 디바이스, 예를 들어 네트워크 스위치는 네트워크 트래픽을 스위칭/라우팅할 수 있다. 네트워크 스위치는 패킷들을 수신 및 송신하기 위해 적어도 하나의 입력/인커밍 포트 및 적어도 하나의 출력/아웃고잉 포트를 포함한다. 일부 실시예들에서, 네트워크 스위치는 또한 파서 및 리라이터를 포함한다. 파서는 네트워크 패킷들의 컨텐츠들을 식별하기 위한 하나 이상의 파서 엔진들을 포함할 수 있으며, 리라이터는 패킷들이 네트워크 스위치로부터 전송되기 이전에 이 패킷들을 수정하기 위한 하나 이상의 리라이트 엔진들을 포함할 수 있다. 파서 엔진(들) 및 리라이트 엔진(들)은 유연성이 있고 프로그램가능한 방식으로 동작한다.
네트워크 스위치는 또한 네트워크 스위치에 의해서 사용되는 데이터를 저장하기 위한 메모리를 포함한다. 예를 들어, 메모리는 제네릭 커맨드들의 세트를 저장한다. 간략하게는, 제네릭 커맨드들은 프로토콜 헤더들을 수정하는데 전형적으로 사용된다. 다른 실례로서, 메모리는 또한 프로토콜들의 제네릭 포맷들의 소프트웨어로 규정된 맵핑사항들을 저장한다. 간략하게는, 각 프로토콜 헤더는 대응하는 프로토콜에 특정된 소프트웨어로 규정된 맵핑사항들 중 하나에 따라서 나타낸다. 자명할 바와 같이, 이러한 맵핑사항들은 새로운 프로토콜들을 포함하여서, 프로토콜의 상이한 변형들 및 상이한 프로토콜들 상에서 사용될 수 있다. 또 다른 예로서, 메모리는 또한 프로토콜 테이블을 저장한다. 간략하게는, 프로토콜 테이블은 프로토콜 테이블 내로 프로그램된 프로토콜 레이어 조합 각각의 프로토콜 레이어 각각의 레이어 정보를 포함한다. 또 다른 예로서, 메모리는 또한 카운터들 및 통계사항들을 포함한다.
이더넷에서, 패킷들은 다수의 프로토콜 레이어들을 포함한다. 프로토콜 레이어 각각은 상이한 정보를 반송한다. 잘 알려진 레이어들의 일부 실례들은 다음과 같다:
● 이더넷
● PBB 이더넷
● ARP
● IPV4
● IPV6
● MPLS
● FCOE
● TCP
● UDP
● ICMP
● IGMP
● GRE
● ICMPv6
● VxLAN
● TRILL
● CNM
이론적으로는, 이 프로토콜 레이어들은 임의의 순서로 발생할 수 있다. 그러나, 이러한 레이어들의 오직 일부 잘 알려진 조합들만이 발생한다. 이러한 레이어들의 유효한 조합들의 일부 실례들은 다음과 같다:
● 이더넷
● 이더넷, ARP
● 이더넷, CNM
● 이더넷, FCoE
● 이더넷, IPV4
● 이더넷, IPV4, ICMP
● 이더넷, IPV4, IGMP
고유한 패킷 식별자
일부 실시예들에서, 네트워크 스위치는 17 개의 프로토콜들 및 8 개의 프로토콜 레이어들을 지원한다. 따라서, 817 개의 가능한 프로토콜 레이어 조합들이 존재한다. 도 1은 패킷들의 예시적인 프로토콜 레이어 조합들을 예시한다. 예를 들어, 패킷은 3 개의 프로토콜 레이어 조합, 예를 들어 이더넷, IPv4 및 ICMP을 포함할 수 있다. 다른 예로서, 패킷은 7 개의 프로토콜 레이어 조합, 예를 들어, 이더넷, IPv4, UDP, VxLAN, 이더넷 및 ARP을 포함할 수 있다.
817 개의 가능한 프로토콜 레이어 조합들이 존재할지라도, 이러한 레이어들 중 오직 일부 잘-알려진 조합들만이 발생한다. 모든 알려진 프로토콜 레이어 조합들은 고유하게 식별되며 패킷 식별자 (PktID) 로 지칭되는 고유한 넘버 (number) 로 변환된다. 네트워크 스위치의 메모리 내에 저장된 프로토콜 테이블은 각 알려진 프로토콜 레이어 조합의 각 레이어의 레이어 정보를 포함하도록 프로그램된다. 실제로, 로컬 프로토콜 테이블은 256 개 미만의 프로토콜 레이어 조합들을 포함한다. 일부 실시예들에서, 이러한 로컬 테이블은 212 개의 알려진 프로토콜 레이어 조합들을 포함한다. 로컬 테이블은 보다 많거나 보다 적은 프로토콜 레이어 조합들을 포함하도록 프로그램된다.
도 2은 본 발명의 일부 실시예들에 따른 로컬 프로토콜 테이블 (200) 의 예시적인 구조를 예시한다. PktID를 사용하여서 인덱싱된, 이 로컬 테이블 (200) 내의 프로토콜 레이어 조합 각각은 레이어0 정보, 레이어1 정보 및 레이어N 정보로서 도시된 바와 같은, 이 프로토콜 레이어 조합의 프로토콜 레이어 각각에 대한 정보를 포함한다. PktID를 인덱싱함으로써, 패킷의 모든 N 레이어들에 대한 정보가 액세스 또는 검색될 수 있다.
프로토콜 레이어 각각에 대한 정보는 적어도 다음을 포함한다: Layer Type, Layer Data Offset 및 Miscellaneous Information. 그러나, 보다 많은 정보가 이 로컬 테이블 (200) 내에 저장될 수 있다. 간략하게는, Layer Type은 프로토콜 레이어의 연관된 프로토콜 (예를 들어, IP/TCP/UDP/이더넷) 을 말하며, Layer Data Offset은 프로토콜 레이어 내의 레이어 데이터의 시작 위치를 제공하며, Miscellaneous Information는 예를 들어 체크섬 및 길이 데이터와 같은 데이터를 포함한다.
전형적으로, 파서 엔진은 네트워크 스위치에서 수신된 인커밍 패킷의 PktID를 식별할 수 있다. 리라이트 엔진은 이 PktID를 프로토콜 테이블에 대한 키로서 사용하는데, 이 키는 수정을 위해서 패킷의 프로토콜 레이어 각각을 제네릭화 (generalize) 하는데 필요한 모든 정보를 리라이트 엔진에 제공한다. 달리 말하면, 리라이트 엔진은 파서 엔진으로부터의 파싱된 결과들을 수신하는 대신에, 프로토콜 테이블로부터 패킷 내의 프로토콜 레이어들 각각에 대한 정보에 액세스 또는 검색하기 위해서 이 PktID를 사용한다.
Layer Type. 패킷의 하나 이상의 필드들 상의 해시와 Layer Type의 고유한 조합은 리라이트 엔진에 프로토콜 레이어 각각에 대한 "제네릭 포맷"을 제공한다. 일부 실시예들에서, 이 고유한 조합은 메모리 내에 저장된 프로토콜들의 제네릭 포맷들의 소프트웨어로 규정된 맵핑사항들 중 하나를 특정한다. 제네릭 포맷은 소프트웨어 커맨드들을 사용하여서 프로토콜 레이어들을 확장하고 프로토콜 레이어들을 수정하기 위해서 리라이트 엔진에 의해서 사용된다. 이 정보는 또한 리라이트 엔진에 프로토콜 레이어 각각이 패킷 내에서 어디서 시작하는지를 알려준다.
Layer Data Offset. 리라이트 엔진은 인커밍 헤더 레이어를 수정하기 위해서 데이터를 사용한다. 이 데이터는 패킷 내의 임의의 위치에 분포될 수 있다. 레이어 크기들이 변할 수 있기 때문에, 리라이트 엔진이 수정들 동안에 사용할 필요가 있는 데이터에 대한 오프셋들도 변할 수 있으며, 이는 리라이트 엔진이 어떤 데이터를 어디로부터 픽업하는 것과 관련하여서 하드웨어 유연성을 제약한다.
인커밍 패킷 헤더들로부터 추출된 데이터는 레이어형 방식으로 배열된다. 추출된 데이터 구조는, 레이어-데이터-구조의 시작 오프셋들이 PktID마다 고유하게 되도록, 구성된다. 각 레이어의 Layer Data Offset이 사용되어서 수정들을 위해서 추출된 데이터의 위치를 식별한다. 패킷 내에서의 레이어들의 구조 및 레이어들로부터 추출된 데이터의 위치들이 패킷의 PktID를 통해서 식별되기 때문에, 소프트웨어 및 하드웨어는 동일한 고유한 식별자를 사용하여서 추출된 데이터를 관리하며 이는 리라이트 엔진에서 커맨드들을 단순화시킨다.
Miscellaneous Information. 예를 들어 체크섬 및 길이 데이터와 같은 정보는 리라이트 엔진에, 해당 프로토콜 레이어에 대한 특정 핸딩 (handing) 요건들, 예를 들어 체크섬 재-계산 및 헤더 길이 업데이트를 알려준다.
패킷 제네릭화 스키마는 소프트웨어로 하여금, 순수하게 소정의 프로토콜 레이어에만 기초하고 이 프로토콜 레이어를 선행하는 또는 후행하는 (proceeding) 레이어들과는 무관한 제네릭 커맨드들의 작은 세트를 규정하게 할 수 있다. 패킷 제네릭화 스키마는 또한 프로토콜 변경들 및 추가들로부터 자신을 추후에-지키기 위해서 (future-proof) 하드웨어 유연성을 제공한다.
도 3은 본 발명의 일부 실시예들에 따른 네트워크 스위치의 예시적인 방법 300 을 예시한다. 네트워크 스위치는 전형적으로 파서 엔진 및 리라이트 엔진을 포함한다.
단계 305에서, 파서 엔진은 인커밍 패킷을 검사하여서 패킷의 PktID를 식별한다. 일부 실시예들에서, 패킷의 파싱된 데이터를 리라이트 엔진에 전달하기보다는, 파서 엔진은 PktID를 리라이트 엔진에 전달한다.
단계 310에서, 리라이트 엔진은 네트워크 스위치에 의해서 수신된 패킷들의 상이한 패킷 구조들을 규정하는 프로토콜 테이블을 참조한다. 리라이트 엔진은 PktID를 프로토콜 테이블에 대한 키로서 사용하여서 수정을 위해서 필요한 패킷의 프로토콜 레이어 각각에 대한 정보를 추출한다.
단계 315에서, 리라이트 엔진은 프로토콜 테이블 내에 저장된 데이터에 기초하여서 패킷을 수정한다. 전형적으로, 리라이트 엔진은 패킷을 수정하기 이전에 패킷의 프로토콜 레이어 각각을 확장시킨다. 이러한 프로토콜 레이어 확장 및 수정은 본 명세서의 다른 곳에서 논의된다.
도 4는 본 발명의 일부 실시예들에 따른 네트워크 스위치의 다른 예시적인 방법 400 을 예시한다. 네트워크 스위치는 전형적으로 메모리 및 적어도 하나의 인커밍 포트를 포함한다.
단계 405에서, 프로토콜 테이블이 메모리 내에 저장된다. 프로토콜 테이블은 패킷들의 상이한 패킷 구조들을 규정한다. 패킷 구조들 각각이 PktID에 의해서 인덱싱된다. 패킷 구조들 각각은 프로토콜 레이어 조합을 나타내며 프로토콜 레이어 조합의 프로토콜 레이어 각각의 레이어 정보를 포함한다. 프로토콜 테이블은 새로운 프로토콜을 나타내는 새로운 패킷 구조를 추가하도록 업데이트될 수 있다. 프로토콜 테이블은 또한 프로토콜에서의 변경에 응답하여서 패킷 구조를 수정하도록 업데이트될 수 있다.
단계 410에서, 패킷이 인커밍 포트에서 수신된다.
단계 415에서, 패킷의 PktID가 식별된다. 일부 실시예들에서, 파서 엔진이 이 패킷의 PktID를 식별한다.
단계 420에서, 패킷의 프로토콜 레이어 각각에 대한 정보가 액세스된다. 전형적으로, 이 정보는 프로토콜 테이블 내에 위치된다. 일부 실시예들에서, 이 정보는 대응하는 프로토콜에 대한 제네릭 포맷에 따라서 패킷의 프로토콜 헤더를 제네릭화하도록 사용된다. 제네릭 포맷은 메모리 내에서 소프트웨어로 규정된다.
본 명세서의 다른 곳에서 설명될 바와 같이, 제네릭화된 프로토콜 헤더는 적어도 하나의 커맨드를 제네릭화된 프로토콜 헤더에 적용함으로써 수정될 수 있다. 일부 실시예들에서, 제네릭화된 프로토콜 헤더는 제네릭화된 프로토콜 헤더를 수정하는데 사용된 데이터의 위치를 결정하기 위한 정보를 사용함으로써 수정된다. 네트워크 스위치의 리라이트 엔진은 전형적으로 프로토콜 헤더를 제네릭화하고 및 제네릭화된 프로토콜 헤더를 수정한다.
제네릭 포맷
위에서 간략하게 설명된 바와 같이, 리라이트 엔진은 패킷들의 프로그램가능한 수정들을 가능하게 하도록 대응하는 프로토콜에 특정된 제네릭 포맷 내의 패킷들의 각 프로토콜 헤더를 나타내며, 이로써 패킷 헤더들을 수정할 시에 하드웨어 및 소프트웨어 유연성을 발생시킨다.
도 5는 본 발명의 일부 실시예들에 따른 제네릭 포맷들로의 인커밍 패킷의 레이어들의 헤더 확장의 도 (500) 를 예시한다. 도 5에서, 인커밍 패킷은 8 개의 헤더 프로토콜 레이어들을 포함한다. 프로토콜 레이어 각각은 각각의 프로토콜에 대한 헤더를 갖는다. 보다 많은 또는 보다 적은 프로토콜 레이어들이 상술한 바와 같이 가능하다. 리라이트 엔진은 도 5에서 예시된 바와 같이, 프로토콜 헤더들 중 임의의 것으로부터 누락 필드들 (missing fields) 을 검출하고 각 프로토콜 헤더를 그의 제네릭 포맷으로 확장시킬 수 있다. 정규 (canonical) 레이어는 그의 제네릭 포맷으로 확장된 프로토콜 레이어를 말한다. 간략하게는, 각 정규 레이어는 무효 필드들에 대해서는 0으로 마킹된 비트들 및 유효 필드들에 대해서는 1로 마킹된 비트들을 갖는 비트 벡터를 포함한다.
도 6a 내지 도 8c는 본 발명의 일부 실시예들에 따라서 리라이트 엔진이 이더넷 프로토콜 상에서 어떻게 동작하는지의 실례들을 예시한다. 도 6a 내지 도 8c에서 예시된 실례들은 리라이트 엔진이 프로토콜, 예를 들어 이더넷 프로토콜의 상이한 변형들 상에서 동작할 수 있음을 입증한다. 각 실례는 이더넷 프로토콜의 인커밍 헤더 및 그의 대응하는 제네릭 포맷을 예시한다. 다른 프로토콜들은 논의되지 않지만, 리라이트 엔진은 다른 프로토콜들 상에서도 유사하게 동작할 수 있음이 주목된다.
도 6a는 인커밍 패킷의 예시적인 이더넷 패킷 헤더의 포맷 (600) 을 예시한다. 이더넷 패킷 헤더 (600) 는 22 바이트이며 및 다음과 같은 5 개의 필드들을 포함한다: Source Address (SA) 필드, Destination Address (DA) 필드, Service VLAN Tag 필드, Customer VLAN Tag 필드 및 EtherType 필드. SA 필드 및 DA 필드는 각각 6 바이트이다. Service VLAN Tag 필드 및 Customer VLAN Tag 필드는 각각 4 바이트이다. EtherType 필드는 2 바이트이다. 이더넷 패킷 헤더 (600) 를 갖는 패킷은 이더넷 패킷의 최대 변형 (variant) 이며, 22 바이트의 최대 크기를 갖는다.
리라이트 엔진은 이더넷 패킷 헤더 (600) 를 프로세싱하며 이더넷 패킷 헤더 (600) 로부터 필드들 중 어느 것도 누락되지 않음을 결정한다. 이더넷 패킷 헤더 (600) 의 제네릭 포맷은 따라서 이더넷 패킷 헤더 (600) 의 것과 동일한데, 그 이유는 이더넷 패킷 헤더 (600) 는 모든 가능한 필드들을 포함하기 때문이다. 도 6b는 도 6a의 이더넷 패킷 헤더 (600) 를 나타내는 비트 벡터 (605) 를 예시한다. 비트 벡터 (605) 의 각 비트는 이더넷 패킷 헤더 (600) 의 22 바이트 중 하나에 대응한다. 비트 벡터 (605) 는 모두 1을 포함하는데, 그 이유는 모든 필드들이 이더넷 패킷 헤더 (600) 내에서 존재하기 때문에 이더넷 패킷 헤더 (600) 의 모든 필드들이 유효하거나 값을 가지기 때문이다. 따라서, 이더넷 패킷 헤더 (600) 는 {22'b111111_111111_1111_1111_11} 의 제네릭 포맷으로 나타낸다.
도 7a는 인커밍 패킷의 또 다른 예시적인 이더넷 패킷 헤더의 포맷 (700) 을 예시한다. 이더넷 패킷 헤더 (700) 는 18 바이트이며 오직 4 개의 필드들: SA 필드, DA 필드, Customer VLAN Tag 필드 및 EtherType 필드만을 포함한다. 이더넷 패킷 헤더 (700) 에는 Service VLAN Tag 필드가 누락되어 있다. 이더넷 패킷 헤더 (700) 를 갖는 패킷은 이더넷 패킷의 다른 변형이다.
리라이트 엔진은 이더넷 패킷 헤더 (700) 를 프로세싱하고, Service VLAN Tag 필드가 이더넷 패킷 헤더 (700) 로부터 누락되었음을 결정하고, 누락된 Service VLAN Tag 필드를 이더넷 패킷 헤더 (700) 의 제네릭 포맷의 적합한 위치에 포함시킴으로써 이더넷 패킷 헤더 (700) 를 22 바이트의 그의 최대 크기로 확장시킨다. 도 7b는 확장된 이더넷 패킷 헤더의 제네릭 포맷 (700') 을 예시한다. 확장된 이더넷 패킷 헤더 (700') 는 누락된 Service VLAN Tag 필드를 포함하여서, 이더넷 프로토콜의 모든 가능한 필드들을 포함한다. 확장된 이더넷 패킷 헤더 (700') 내의 유효한 필드들은, 그들이 이더넷 패킷 헤더 (700) 내에 존재하기 때문에, SA 필드, DA 필드, Customer VLAN Tag 필드 및 EtherType 필드이다. 확장된 이더넷 패킷 헤더 (700') 내의 무효한 필드는 Service VLAN Tag 필드인데, 그 이유는 이 필드는 이더넷 패킷 헤더 (700) 내에 존재하지 않고 확장된 이더넷 패킷 헤더 (700') 내로 부가되었기 때문이다.
도 7c는 도 7b의 확장된 이더넷 패킷 헤더 (700') 를 나타내는 비트 벡터 (705) 를 예시한다. 비트 벡터 (705) 의 각 비트는 확장된 이더넷 패킷 헤더 (700') 의 22 바이트 중 하나에 대응한다. 비트 벡터 (705) 는 SA 필드, DA 필드, Customer VLAN Tag 필드 및 EtherType 필드인 모든 유효한 필드들에 대해서는 모두 1을 포함한다. 비트 벡터 (705) 는 오직 Service VLAN Tag 필드만인 모든 무효한 필드들에 대해서는 0을 포함한다. 따라서, 이더넷 패킷 헤더 (700) 는 {22'b111111_111111_0000_1111_11} 의 제네릭 포맷에 의해서 나타낸다.
도 8a는 인커밍 패킷의 또 다른 예시적인 이더넷 패킷 헤더의 포맷 (800) 을 예시한다. 이더넷 패킷 헤더 (800) 는 14 바이트이며 오직 3 개의 필드들: SA 필드, DA 필드 및 EtherType 필드만을 포함한다. 이더넷 패킷 헤더 (800) 에는 Service VLAN Tag 필드 및 Customer VLAN Tag 필드가 누락되어 있다. 이더넷 패킷 헤더 (800) 를 갖는 패킷은 이더넷 패킷의 가장 작은 변형이다.
리라이트 엔진은 이더넷 헤더 (800) 를 프로세싱하고, Service VLAN Tag 필드 및 Customer VLAN Tag 필드가 이더넷 패킷 헤더 (800) 로부터 누락되었다고 결정하고, 누락된 (missing) Service VLAN Tag 필드 및 누락된 Customer VLAN Tag 필드를 이더넷 패킷 헤더 (800) 의 제네릭 포맷의 적합한 위치에 포함시킴으로써 이더넷 패킷 헤더 (800) 를 22 바이트의 그의 최대 크기로 확장시킨다. 도 8b는 확장된 이더넷 패킷 헤더의 제네릭 포맷 (800') 을 예시한다. 확장된 이더넷 패킷 헤더 (800') 는 누락된 Service VLAN Tag 필드 및 누락된 Customer VLAN Tag 필드를 포함하여서, 이더넷 프로토콜의 모든 가능한 필드들을 포함한다. 확장된 이더넷 패킷 헤더 (800') 내에서의 유효한 필드들은 SA 필드, DA 필드 및 EtherType 필드인데, 그 이유는 이들이 이더넷 패킷 헤더 (800) 내에 존재하기 때문이다. 확장된 이더넷 패킷 헤더 (800') 내에서의 무효한 필드는 Service VLAN Tag 필드 및 Customer VLAN Tag 필드인데, 그 이유는 이들이 이더넷 패킷 헤더 (800) 내에 존재하지 않지만, 확장된 이더넷 패킷 헤더 (800') 내에 부가되었기 때문이다.
도 8c는 도 8b의 확장된 이더넷 패킷 헤더 (800') 를 나타내는 비트 벡터 (805) 를 예시한다. 비트 벡터 (805) 의 각 비트는 확장된 이더넷 패킷 헤더 (800') 의 22 바이트 중 하나에 대응한다. 비트 벡터 (805) 는 SA 필드, DA 필드 및 EtherType 필드인 모든 유효한 필드들에 대해서는 1을 포함한다. 비트 벡터 (805) 는 Service VLAN Tag 필드 및 Customer VLAN Tag 필드인 모든 무효한 필드들에 대해서는 0을 포함한다. 따라서, 이더넷 패킷 헤더 (800) 는 {22'b111111_111111_0000_0000_11} 의 제네릭 포맷에 의해서 나타낸다.
도 6a 내지 도 8c에서 예시된 바와 같이, 인커밍 이더넷 헤더의 변형과 상관없이, 일단 이더넷 헤더의 제네릭 포맷으로의 확장이 수행되면, 필드 오프셋들은 최대 크기의 이더넷 헤더 (예를 들어, 도 6a의 이더넷 패킷 헤더 (600)) 와 동일하게 된다. 헤더 확장은 유리하게는 인커밍 이더넷 헤더와 상관없이 소프트웨어 커맨드들의 동일한 세트가 동작하게 하는데, 그 이유는 이더넷 헤더가 그의 최대 크기의 이더넷 헤더로 확장되었기 때문이다. 이로써, 예를 들어 EtherType 필드를 수정하는 커맨드는 어느 이더넷 헤더가 수신되는지 상관없이 언제나 동일한 오프셋을 포인팅할 것이다.
헤더들의 제네릭 포맷들은 패킷 헤더를 수정하는 측면에서 하드웨어 및 소프트웨어 유연성을 발생시킨다. 하드웨어는 필드들이 패킷 헤더들 내에서 어디에 상주하는지에 상관없이 패킷 헤더들을 수정할 수 있다. 하드웨어는 새로운 프로토콜들을 지원하도록 소프트웨어에 의해서 프로그램될 수 있다. 소프트웨어는 다양한 헤더 프로토콜들에 대해서 하드웨어 테이블 내의 제네릭 포맷들을 프로그램한다.
가정 1 (인커밍 패킷이 단일 태깅된 (tagged) 이더넷 패킷이며 아웃고잉 패킷은 비태깅된 (untagged) 이더넷 패킷임): 네트워크 스위치의 입력 이더넷 포트가 Customer VLAN Tag를 갖는 패킷들을 수신 중이며, 패킷들이 비태깅된 상태로 출력 이더넷 포트로 포워딩되어야 한다고 가정한다. 도 9a는 이 인커밍 이더넷 포트에서 수신된 패킷의 예시적인 이더넷 패킷 헤더의 포맷 (900) 을 예시한다. 이 인커밍 이더넷 포트에서 수신된 패킷에 대해서, 소프트웨어는 이더넷 헤더의 제네릭 포맷이 {22'b111111_111111_0000_1111_11} 이 되도록 프로그램한다. 리라이트 엔진은 헤더 프로토콜 레이어를 수신하고 메모리로 인덱싱하는데, 이는 이 헤더 프로토콜에 대한 제네릭 포맷이 {22'b111111_111111_0000_1111_11} 이다는 것을 하드웨어에 알린다. 이 경우에, 하드웨어는 처음의 12 개의 연속적인 바이트 (각각 1로 마킹됨) 및 다음의 6 개의 바이트 (각각 1로 마킹됨) 가 4 바이트만큼 시프트될 것으로 예상한다. 0으로 마킹된 비트 벡터 내에서의 4 비트에 대응하는 4 바이트는 무효하다.
{22b'111111_111111_0000_1111_11} 의 제네릭 포맷에 기초하여서, 리라이트 엔진은 도 9b에 도시된 확장된 헤더 (905) 로 인커밍 헤더 프로토콜 레이어를 확장시키고, 확장된 헤더 레이어 (905) 의 각 바이트에 대해서 바이트 당 비트 (bit per byte) 를 유지한다. 확장된 헤더 (905) 에 대한 대응하는 비트 벡터 (910) 가 도 9c에 도시된다. 비트 벡터 (910) 는 어느 바이트가 유효하고 어느 바이트가 무효한지를 하드웨어에 알린다.
포워딩 결정에 기초하여서, 이 가정 1에서, 패킷은 비태깅된 상태로 포워딩될 필요가 있다. 아웃고잉 이더넷 포트의 에그레스 포트타입 (egress portType) 에 기초하여 하드웨어는 이 하드웨어에 Customer VLAN Tag를 삭제하라고 알리는 커맨드 테이블로 인덱싱한다. Customer VLAN Tag는 언제나 고정된 오프셋, 즉 16에서 시작한다. 커맨드가 제네릭 포맷에 적용되기 때문에, Customer VLAN Tag를 삭제하라는 커맨드는 "위치 16으로부터 시작하는 (Customer VLAN Tag의) 4 바이트를 삭제하는 것"이다. 하드웨어는 4 개의 바이트들이 무효하다고 간단히 마킹하고 이들을 삭제한다. 도 9d는 비태깅된 이더넷 헤더 (915) 를 제네릭 포맷으로 예시한다. 도 9e는 비태깅된 이더넷 헤더 (915) 에 대한 비트 벡터 (920) 를 예시한다. 모든 무효한 바이트를 제거한 후에, 하드웨어는 도 9f에 도시된 새로운 헤더 (925) 를 형성한다. 새로운 헤더 (925) 를 갖는 패킷이 아웃고잉 이더넷 포트를 통해서 전송된다.
가정 2 (인커밍 패킷이 이중 태깅된 이더넷 패킷이며 아웃고잉 패킷은 비태깅된 이더넷 패킷임): 네트워크 스위치의 입력 이더넷 포트가 Service VLAN Tag 및 Customer VLAN Tag를 갖는 패킷들을 수신 중이며 패킷들은 비태깅된 상태로 출력 이더넷 포트로 포워딩될 필요가 있다고 가정한다. 도 10a는 이 인커밍 이더넷 포트에서 수신된 패킷의 예시적인 이더넷 패킷 헤더의 포맷 (1000) 을 예시한다. 이 인커밍 이더넷 포트에서 수신된 패킷에 대해서, 소프트웨어는 이더넷 헤더의 제네릭 포맷이 {22'b111111_111111_1111_1111_11} 이 되도록 프로그램한다. 리라이트 엔진은 헤더 프로토콜 레이어를 수신하고 및 메모리로 인덱싱하는데, 이는 하드웨어에 이 헤더 프로토콜에 대한 제네릭 포맷이 {22'b111111_111111_1111_1111_11} 이다는 것을 알린다. 이 경우에, 하드웨어는 모든 22 개의 연속 바이트 (각각 1로 마킹됨) 를 예상한다.
{22'b111111_111111_1111_1111_11}의 제네릭 포맷에 기초하여서, 리라이트 엔진은 인커밍 헤더 프로토콜 레이어를 확장시킬 필요가 없는데 그 이유는 헤더 프로토콜이 이미 그의 최대 크기에 있기 때문이다. 헤더 (1000) 에 대한 대응하는 비트 벡터 (1005) 가 도 10b에 도시된다. 비트 벡터 (1005) 는 하드웨어에 어느 바이트가 유효하고 어느 바이트가 무효한지를 알린다.
포워딩 결정에 기초하여서, 이 가정 2에서, 패킷은 비태깅된 상태로 포워딩될 필요가 있다. 아웃고잉 이더넷 포트의 에그레스 포트타입에 기초하여 하드웨어는 Customer VLAN Tag 및 Service VLAN Tag를 삭제하라는 것을 하드웨어에 알리는 커맨드 테이블로 인덱싱한다. Customer VLAN Tag는 언제나 고정된 오프셋, 즉 16에서 시작한다. 마찬가지로, Service VLAN Tag는 언제나 고정된 오프셋, 즉 12에서 시작한다. 커맨드들이 제네릭 포맷에 적용되기 때문에, Customer VLAN Tag를 삭제하라는 커맨드는 "위치 16으로부터 시작하는 (Customer VLAN Tag 중의) 4 바이트를 삭제하는 것"이고, Service VLAN Tag를 삭제하라는 커맨드는 "위치 12로부터 시작하는 (Service VLAN Tag 중의) 4 바이트를 삭제하는 것"이다. 하드웨어는 8 바이트를 무효하다고 간단하게 마킹하고 이들을 삭제한다. 도 10c는 제네릭 포맷 내의 비태깅된 이더넷 헤더 (1010) 를 예시한다. 도 10d는 비태깅된 이더넷 헤더 (1010) 에 대한 비트 벡터 (1015) 를 예시한다. 모든 무효한 바이트를 제거한 후에, 하드웨어는 도 10e에 도시된 새로운 헤더 (1020) 를 형성한다. 새로운 헤더 (1020) 를 갖는 패킷은 아웃고잉 이더넷 포트를 통해서 전송된다.
가정 3 (인커밍 패킷들은 비태깅된, 단일 태깅된 또는 이중 태깅된 이더넷 패킷 중 하나이며 아웃고잉 패킷은 이중 태깅된 이더넷 패킷임): 네트워크 스위치의 입력 이더넷 포트는 어떠한 태그들, Service VLAN Tag, Customer VLAN Tag, 또는 이 양 태그들 없이 패킷들을 수신 중이며, 패킷들은 이중 태킹된 상태로 그러나 새로운 태그들과 함께 출력 이더넷 포트로 포워딩될 필요가 있다. 인커밍 패킷이 이중 태깅되면, 소프트웨어는 이더넷 헤더의 제네릭 포맷이 {22b'111111_111111_1111_1111_11}이 되게 프로그램한다. 인커밍 패킷이 비태깅되면, 소프트웨어는 이더넷 헤더의 제네릭 포맷이 {22'b111111_111111_0000_0000_11}이 되게 프로그램한다. 인커밍 패킷이 단일 태깅되면, 소프트웨어는 이더넷 헤더의 제네릭 포맷을 {22'b111111_111111_0000_1111_11}이 되도록 프로그램한다.
포워딩 결정에 기초하여서, 이 가정 3에서, 패킷은 이중 태깅된 상태로 포워딩될 필요가 있다. 아웃고잉 이더넷 포트의 에그레스 포트타입에 기초하여 하드웨어는 Customer VLAN Tag 및 Service VLAN Tag를 대체하도록 하드웨어에 말하는 커맨드 테이블로 인덱싱한다. Customer VLAN Tag는 언제나 고정된 오프셋, 즉 16에서 시작한다. 마찬가지로, Service VLAN Tag는 언제나 고정된 오프셋, 즉 12에서 시작한다. 이러한 경우들 각각에 있어서, 커맨드들은 동일하다. 커맨드들이 제네릭 포맷에 적용되기 때문에, 커맨드들은 "(Service VLAN Tag에 대한) 4 바이트를 layerData.locationX로부터 startLocation=12로 카피하는 것" 및 (Customer VLAN Tag에 대한) 4 바이트를 layerData.locationY로부터 startLocation=16으로 카피하는 것"이며, 여기서 컨텐츠들은 layerData.locationX 및 layerData.locationY에 의해서 특정된 위치들로부터 카피된다.
상기 가정들 1 내지 3에서 입증된 바와 같이, 리라이트 엔진은 하드웨어에서 단순화되며, 메모리 내에서 설정된 소프트웨어 커맨드를 작게 유지한다. 이로써, 커맨드들을 유지하는데 요구되는 하드웨어 메모리가 얕아진다.
도 11은 본 발명의 일부 실시예들에 따른 리라이트 엔진의 방법 1100을 예시한다. 단계 1105 에서, 리라이트 엔진은 인커밍 패킷의 프로토콜 헤더로부터 누락된 필드들을 검출한다.
단계 1110에서, 이 검출에 기초하여서, 리라이트 엔진은 프로토콜 헤더를 대응하는 프로토콜에 대한 제네릭 포맷으로 확장시킨다. 이 제네릭 포맷은 프로토콜의 모든 가능한 필드들을 포함한다. 필드들 각각은 프로토콜 헤더가 이 프로토콜의 어느 변형에 대응하는지에 상관없이 동일한 오프셋을 갖는다. 리라이트 엔진은 확장된 프로토콜 헤더에 대한 비트 벡터를 유지하며, 이 비트 벡터는 확장된 프로토콜 헤더의 각 바이트에 대하여 바이트 당 비트를 포함한다. 리라이트 엔진은 각 유효한 필드의 각 바이트에 대해서 비트를 가용하다고 마킹하며, 여기서 각 유효한 필드는 인커밍 패킷의 프로토콜 헤더 내에 존재하는 필드이다. 리라이트 엔진은 각 무효한 필드의 각 바이트에 대해서 비트를 비가용하다고 (unavailable) 마킹하며, 여기서 각 무효한 필드는 인커밍 패킷의 프로토콜 헤더 내에 존재하지 않는 필드이다.
일부 실시예들에서, 단계 1105 및 1110는 인커밍 패킷의 프로토콜 레이어 각각에 대해서 수행된다.
도 12는 본 발명의 일부 실시예들에 따른 네트워크 스위치의 또 다른 방법 1200을 예시한다. 일부 실시예들에서, 네트워크 스위치는 프로토콜들의 제네릭 포맷의 소프트웨어로 규정된 맵핑을 가능하게 하며, 이 소프트웨어로 규정된 맵핑사항들을 네트워크 스위치의 메모리 내에 저장한다. 네트워크 스위치는 프로토콜 헤더들을 제네릭화하기 위해서 리라이트 엔진을 포함한다. 단계 1205에서, 패킷이 네트워크 스위치의 인커밍 포트에서 수신된다.
단계 1210에서, 패킷의 프로토콜 헤더가 대응하는 프로토콜에 대한 제네릭 포맷에 따라서 제네릭화된다. 상술한 바와 같이, 하드웨어는 네트워크 스위치의 메모리 내에 저장된 맵핑사항들 중 하나에 따라서 프로토콜 헤더를 확장시킨다. 확장된 비트 벡터에 대한 비트 벡터는 하드웨어에 어느 바이트가 유효하고 어느 바이트가 무효한지를 말한다.
단계 1215에서, 제네릭화된 프로토콜 헤더가 적어도 하나의 커맨드를 이 제네릭화된 프로토콜 헤더에 적용함으로써 수정된다. 상술한 바와 같이, 아웃고잉 이더넷 포트의 에그레스 포트타입에 기초하여 하드웨어는 프로토콜 헤더에 적용할 적어도 하나의 커맨드를 결정하기 위해서 커맨드 테이블로 인덱싱한다.
단계 1220에서, 새로운 헤더를 형성하기 위해 수정된 프로토콜 헤더의 모든 무효한 바이트가 제거된다.
단계 1225에서, 새로운 헤더를 갖는 패킷이 네트워크 스위치의 아웃고잉 포트를 통해서 전송된다.
도 13은 본 발명의 일부 실시예들에 따른 네트워크 스위치의 또 다른 방법 1300을 예시한다. 단계 1305에서, 네트워크 스위치는 프로토콜들의 제네릭 포맷들의 소프트웨어로 규정된 맵핑들을 포함하도록 구성된다. 이 소프트웨어로 규정된 맵핑사항들은 네트워크 스위치의 메모리 내에 저장된다.
단계 1310에서, 패킷이 네트워크 스위치의 인커밍 포트에서 수신된다.
단계 1315에서, 패킷의 프로토콜 헤더가 소프트웨어로 규정된 맵핑사항들 중 하나에 기초하여서 제네릭화된다.
단계 1320에서, 제네릭화된 프로토콜 헤더에 대한 비트 벡터가 유지된다. 이 비트 벡터는 제네릭화된 프로토콜 헤더의 각 바이트에 대해 바이트 당 비트를 포함한다.
제네릭화된 프로토콜 헤더의 최적화된 표현
각 인커밍 레이어는 임의의 개수의 바이트, 예를 들어 64 바이트 또는 128 바이트 또는 심지어 보다 많은 수의 바이트를 포함할 수 있다. 위의 실례들에서, 확장된 이더넷 헤더는 22 바이트를 갖는다. 비트 벡터에서 프로토콜 레이어의 모든 바이트를 나타내는 것은 효율적이지 않은데, 그 이유는 워스트 케이스 (worst case) 프로토콜에 대한 할당은 메모리 집약적이기 때문이다. 현대의 SOC (system-on-chip) 설계들에서, 임베딩된 메모리의 면적 및 전력 예산이 통상적으로 전체 칩 예산을 지배한다. 이로써, 한정된 메모리 리소스들을 효율적으로 사용하는 것이 중요하다.
대부분의 프로토콜들이 소수의 "홀들 (holes)" 또는 무효한 바이트를 가지면, 제네릭 포맷 헤더를, 연속 바이트의 카운터 및 불연속 바이트를 나타내는 보다 작은 비트 벡터로 나타내는 것이 보다 저렴하다. 일부 실시예들에서, 이 보다 작은 비트 벡터의 크기는 전형적으로 고정되지만, 이 크기는 프로그램가능하다. 이 크기는 프로토콜이 나타내기 위해서 저장되어야 하는 불연속 바이트의 최대 개수를 결정하는 프로토콜의 통계사항에 기초하여서 조정될 수 있다.
일부 실시예들에서, 패킷의 각 제네릭 포맷 헤더는 2 개의 필드들: continuous_byte 필드 및 bitvector 필드들을 포함하는 데이터 구조를 사용한 최적화된 방식으로 나타낸다. continuous_byte 필드는 프로토콜 레이어의 시작으로부터의 연속 유효한 바이트의 수를 나타낸다. bitvector 필드는 프로토콜 레이어의 바이트 당 비트 표현이다. bitvector 필드는 "홀들" 또는 무효한 바이트를 나타낸다. bitvector 필드는 모든 프로토콜들이 아니라면 대부분의 모든 프로토콜들을 수용할 수 있다. 따라서, 최적화된 표현은 {continuous_byte, bitvector} 로 나타낼 수 있다. 데이터 구조는 프로토콜 헤더의 크기와 독립적이다.
예를 들어, 도 6b의 비트 벡터 (605) 의 컴팩트한 표현은 {22, 0000_0000_0000_0000) 이며, 이는 도 6a의 이더넷 패킷 헤더 (600) 의 시작으로부터 22 개의 연속 바이트를 나타낸다. bitvector 필드는 모두 0들을 포함하는데 그 이유는 무효한 바이트가 존재하지 않기 때문이다.
다른 예로서, 도 7c의 비트 벡터 (705) 의 컴팩트한 표현은 {12, 0000_1111_1100_000} 이며, 이는 도 7b의 확장된 이더넷 패킷 헤더 (300') 의 시작으로부터 12 개의 연속 바이트 및 다음의 4 개의 무효한 바이트 및 이어서 6 개의 유효한 바이트를 나타낸다.
또 다른 예로서, 도 8c의 비트 벡터 (805) 의 컴팩트한 표현은 {12, 0000_0000_1100_0000} 이며, 이는 도 8b의 확장된 이더넷 패킷 헤더 (800') 의 시작으로부터 12 개의 연속 바이트 및 다음의 8 개의 무효한 바이트 및 이어서 2 개의 유효한 바이트를 나타낸다.
도 14는 본 발명의 일부 실시예들에 따른 네트워크 스위치의 또 다른 방법 1400을 예시한다. 단계 1405에서, 확장된 프로토콜 헤더가 획득된다. 상술한 바와 같이, 확장된 프로토콜 헤더는 대응하는 프로토콜에 대한 제네릭 포맷에 따라서 제네릭화된 인커밍 패킷의 프로토콜 헤더이다. 전형적으로, 리라이트 엔진은 프로토콜 헤더로부터 누락 필드들을 검출하고, 검출에 기초하여서 제네릭 포맷에 따라서 프로토콜 헤더를 확장시킴으로써 프로토콜 헤더를 제네릭화한다. 제네릭 포맷은 프로토콜의 모든 가능한 필드들을 포함하며, 필드들 각각은 프로토콜 헤더가 이 프로토콜의 어느 변형에 대응하는지에 상관없이 동일한 오프셋을 갖는다.
단계 1410에서, 확장된 프로토콜 헤더의 표현이 유지된다. 이 표현은 continuous_byte 필드 및 bitvector 필드를 포함하는 데이터 구조이다.
단계 1415에서, continuous_byte 필드는 확장된 프로토콜 헤더의 시작으로부터의 연속 유효한 바이트의 수로 설정된다.
단계 1420에서, bitvector 필드의 비트는 연속 유효한 바이트 이후의 각 무효한 필드의 각 바이트에 대해서 비가용하다고 마킹된다. 각 무효한 필드는 인커밍 패킷의 프로토콜 헤더 내에 존재하지 않는 필드이다.
단계 1425에서, bitvector 필드의 비트는 연속 유효한 바이트 이후의 각 유효한 필드의 각 바이트에 대해서 가용하다고 마킹된다. 각 유효한 필드는 인커밍 패킷의 프로토콜 헤더 내에 존재하는 필드이다.
도 15는 본 발명의 일부 실시예들에 따른 네트워크 스위치의 또 다른 방법 1500을 예시한다. 단계 1505에서, 패킷은 네트워크 스위치의 인커밍 포트에서 수신된다.
단계 1510에서, 패킷의 프로토콜 헤더는 대응하는 프로토콜에 대한 제네릭 포맷에 따라서 제네릭화된다. 전형적으로, 리라이트 엔진은 프로토콜 헤더를 제네릭화하도록 구성된다.
단계 1515에서, 제네릭화된 프로토콜 헤더는 프로토콜 헤더의 크기와 무관한 데이터 구조로 나타낸다. 일부 실시예들에서, 데이터 구조는 continuous_byte 필드 및 bitvector 필드를 포함하며, 여기서 continuous_byte 필드는 프로토콜 헤더의 시작으로부터의 연속 유효한 바이트의 수를 나타내며, bitvector 필드는 프로토콜 헤더의 바이트 당 비트 표현이다.
이러한 데이터 구조는 다양한 프로토콜 레이어들에 대한 표현을 제네릭화하는 것을 도우며, 프로토콜 헤더 레이어의 크기에 대한 의존성을 제거한다. 비트 벡터의 컴팩트한 표현은 유리하게는 하드웨어 비용을 줄인다.
헤더 수정을 위한 제네릭 커맨드들
수정은 확장된 프로토콜 헤더들에 적용되는 제네릭 커맨드들의 세트를 사용한다. 이로써, 모든 커맨드들이 일반적인데 그 이유는 이러한 커맨드들이 인커밍 헤더들 (예를 들어, 크기 및 프로토콜) 과 무관하기 때문이다.
테이블 1은 프로토콜 헤더 수정들을 위해 리라이트 엔진에 의해서 사용된 제네릭 커맨드들을 열거한다. 이러한 제네릭 커맨드들의 작은 세트는 인커밍 패킷 헤더들 (예를 들어, 크기, 프로토콜) 과 상관없이 헤더 수정을 위해서 사용되는데, 그 이유는 패킷 헤더들이 수정 이전에 제네릭화되었기 때문이다. 전형적으로, 제네릭 커맨드들은 소프트웨어가 프로그램한 마이크로코드로서 동작한다.
테이블 1
커맨드 기술
CMD: DELETE
파라미터들: Start, Size 		Start 위치에서 시작하고, 이 삭제 커맨드는 소정의 프로토콜 레이어 내에서 Size 바이트들의 수를 삭제한다.
* 얼마나 많은 바이트들이 삭제되는지를 계속 추적함.
CMD: COPY
파라미터들: Source, SourceOffset, Size, DestinationOffset, Bitmask, copyConstantBitMask, copyConstantData 		이 카피 커맨드는 다양한 소스들, 예를 들어 추출된 레이어 데이터, 파서에 의해서 추출된 공동 필드들, 헤더의 현 레이어로부터 데이터를 카피하고 이들을 DestinationOffset에서 시작하는 현 헤더 레이어로 카피한다.
* 소스에서 유효한 모든 바이트에 대해서, 이 카피 커맨드는 대응하는 수신지 바이트가 유효하게 한다.
* 소스에서 무효한 모든 바이트에 대해서, 이 카피 커맨드는 수신지에서의 바이트를 무효화시킨다. (이 카피 커맨드는 또한 이 경우에 삭제 커맨트 역할을 한다.)
* copyConstantBitMask 내의 비트 값이 1이면, 대응하는 데이터 바이트는 상수 데이터로부터 온다. 이는 이 카피 커맨드를 사용하여서 상수 값들을 특정화하는 것을 가능하게 한다.
* 얼마나 많은 바이트가 부가 또는 삭제되는지를 계속 추적함.
CMD: MOVE
파라미터들:StartOffset, DestinationOffset, Size 		이 이동 커맨드는 프로토콜 레이어 내에서 바이트들을 이동시킨다. 이 이동 커맨드는 주로 MPLS 라벨들을 효율적으로 푸시 (push) 및 팝핑 (pop) 하는데 사용된다.
* 소스에서 유효한 모든 바이트에 대해서, 이 이동 커맨드는 수신지 내의 대응하는 데이터를 카피하고, 수신지 바이트를 유효화하고, 소스 바이트를 무효화한다.
* 소스에서 무효한 모든 바이트에 대해서, 이 이동 커맨드는 수신지 바이트 및 소스 바이트를 무효화한다.
* 얼마나 많은 바이트가 부가 또는 삭제되는지를 계속 추적함.
DELETE 커맨드는 Size 바이트를 무효화함으로써 Start 위치로부터 현 제네릭화된 프로토콜 레이어 내의 Size 바이트를 삭제한다. 이러한 바이트를 나타내는 비트 벡터의 비트들은 0으로 마킹된다.
COPY 커맨드는 Size 바이트의 데이터를 Source의 SourceOffset으로부터 현 제네릭화된 헤더 레이어의 DestinationOffset으로 카피한다. COPY 커맨드는 데이터의 유효성이 Source에서 유효한지의 여부에 따라서 대응하는 수신지 바이트를 유효하게 하거나 무효하게 한다. 무효한 바이트를 나타내는 비트 벡터의 비트들은 0으로 마킹된다. 유효한 바이트를 나타내는 비트 벡터의 비트들은 1로 마킹된다. COPY 커맨드는 또한 비트마스크 연산들을 위해서 Bitmask를 사용한다. COPY 커맨드는 또한 copyConstantBitMask 및 copyConstantData를 사용한다. copyConstantBitMask가 비트 위치에서 "1"을 포함하면, copyConstantData 내의 대응하는 위치로부터의 바이트는 대응하는 위치에서의 현 제네릭화된 헤더 레이어로 카피된다. 일부 실시예들에서, 상수 데이터는 테이블 내에 저장된다. 일부 실시예들에서, 상수 데이터는 소프트웨어로 규정된다.
MOVE 커맨드는 현 제네릭화된 프로토콜 레이어 내의 Size 바이트를 StartOffset으로부터 DestinationOffset으로 이동시킨다. MOVE 커맨드는 데이터의 유효성이 Source에서 유효한지의 여부에 따라서 대응하는 수신지 바이트를 유효하게 하거나 무효하게 하며, 소스 바이트를 무효하게 한다. 무효한 바이트를 나타내는 비트 벡터의 비트들은 0으로 마킹된다. 유효한 바이트를 나타내는 비트 벡터의 비트들은 1로 마킹된다.
부가된 또는 삭제된 바이트의 수가 적어도 하나의 카운터를 사용함으로써 수행된 모든 연산들에 대해서 카운트된다. 적어도 하나의 카운터는 하드웨어 카운터이다. 이와 달리, 적어도 하나의 카운터는 소프트웨어 카운터이다. 적어도 하나의 카운터는 통계적 목적 및 다른 이유들로 카운트를 계속 추적한다. 일부 실시예들에서, 리라이트 엔진은 얼마나 많은 비트들이 변경되었는지를 하드웨어에 알리기 위해서 2 개의 비트 벡터들-최초의 것 및 수정된 것-에 대해 XOR 연산을 수행하며, 이는 삭제 또는 부가된 바이트의 수를 계산하는데 사용된다.
도 16은 본 발명의 일부 실시예들에 따른 리라이트 엔진의 다른 방법 1600을 예시한다. 리라이트 엔진은 네트워크 스위치의 일부이며 패킷들이 네트워크 스위치로부터 전송되기 이전에 패킷들을 수정한다. 단계 1605에서, 패킷의 각 프로토콜 헤더가 이 프로토콜 헤더에 대한 제네릭 포맷에 따라서 제네릭화된다. 제네릭 포맷은 프로토콜의 모든 가능한 필드들을 포함한다. 이로써, 필드들 각각은 프로토콜 헤더가 프로토콜의 어느 변형에 대응하는지에 상관없이 동일한 오프셋을 갖는다. 각 제네릭화된 프로토콜 헤더는 비트 벡터를 포함한다. 비트 벡터는 제네릭화된 프로토콜 헤더의 각 바이트에 대한 바이트 당 비트를 포함한다. 비트 벡터는 무효한 필드들에 대해서는 0으로 마킹된 비트들을 포함하고, 유효한 필드들에 대해서는 1로 마킹된 비트들을 포함한다. 여기서, 무효한 필드는 수신된 패킷의 프로토콜 헤더 내에 존재하지 않는 필드이며, 유효한 필드는 수신된 패킷의 프로토콜 헤더 내에 존재하는 필드이다.
단계 1610에서, 적어도 하나의 제네릭화된 프로토콜 헤더를 수정하기 위해 네트워크 스위치의 메모리 내에 저장된 제네릭 커맨드들의 세트로부터의 적어도 하나의 커맨드가 사용된다. 이러한 적어도 하나의 제네릭화된 프로토콜 헤더 수정은 네트워크 스위치의 아웃고잉 포트의 에그레스 포트타입에 기초한다. 이러한 적어도 하나의 제네릭화된 프로토콜 헤더 수정은 비트 벡터 업데이트를 발생시킨다.
제네릭 커맨드들의 세트는 인커밍 패킷 헤더들와 상관없이 헤더 수정을 위해서 사용되기 때문에, 프로토콜의 제 1 변형의 패킷 헤더를 수정하고 프로토콜의 제 2 변형의 패킷 헤더를 수정하기 위해 제네릭 커맨드들의 세트가 사용될 수 있다. 마찬가지로, 제 1 프로토콜의 패킷 헤더를 수정하고 제 2 프로토콜의 패킷 헤더를 수정하기 위해 제네릭 커맨드들의 세트가 사용될 수 있다.
도 17은 본 발명의 일부 실시예들에 따른 네트워크 스위치의 또 다른 방법 1700을 예시한다. 단계 1705에서, 제네릭 커맨드들의 세트가 네트워크 스위치의 메모리 내에 유지된다.
단계 1710에서, 패킷이 네트워크 스위치의 인커밍 포트에서 수신된다.
단계 1715에서, 패킷의 각 프로토콜 헤더가 프로토콜 헤더에 대한 일반적인 포맷에 따라서 제네릭화된다. 패킷의 프로토콜 헤더로부터 누락 필드들이 검출된다. 검출에 기초하여서, 프로토콜 헤더가 이 누락 필드들을 포함함으로써 제네릭 포맷으로 확장된다. 각 제네릭화된 프로토콜 헤더는 무효한 필드들에 대해서는 0으로 마킹된 비트들 및 유효한 필드들에 대해서는 1로 마킹된 비트들을 갖는 비트 벡터를 포함한다. 여기서, 무효한 필드는 수신된 패킷의 프로토콜 헤더 내에 존재하지 않는 필드이며, 유효한 필드는 수신된 패킷의 프로토콜 헤더 내에 존재하는 필드이다.
단계 1720에서, 제네릭화된 프로토콜 헤더들 중 적어도 하나가 제네릭 커맨드들의 세트로부터의 적어도 하나의 커맨드를 제네릭화된 프로토콜 헤더에 적용함으로써 수정되며, 이로써 비트 벡터가 업데이트된다.
단계 1725에서, 새로운 프로토콜 헤더가 업데이트된 비트 벡터에 기초하여서 형성된다.
단계 1730에서, 새로운 프로토콜 헤더를 갖는 패킷이 네트워크 스위치의 아웃고잉 포트를 통해서 전송된다. 일부 실시예들에서, 새로운 프로토콜 헤더를 갖는 패킷이 전송되기 이전에, 부가되거나 삭제된 바이트의 수가 수행된 모든 연산들에 대해서 카운트된다.
수정된 프로토콜 헤더들을 수축 (collapse) 하기 위해서 비트 벡터들을 사용하는 것
리라이트 엔진은 수정을 위해서 제네릭 포맷에 기초하여서 프로토콜 헤더를 확장시키기 위해서 각 프로토콜 헤더에 대한 비트 벡터를 사용할 뿐만 아니라, 리라이트 엔진은 또한 프로토콜 헤더를 제네릭 포맷으로부터 "정규 (regular)" 헤더로 수축시키기 위해서 비트 벡터를 사용한다. 전형적으로, 비트 벡터 내의 각 비트는 제네릭화된 프로토콜 헤더의 바이트를 나타낸다. 비트 벡터 내에서 0으로 마킹된 비트는 무효한 바이트에 대응하는 한편, 비트 벡터 내에서 1로 마킹된 비트는 유효한 바이트에 대응한다. 리라이트 엔진은 비트 벡터를 사용하여서, 모든 커맨드들이 제네릭화된 프로토콜 헤더 상에서 동작된 후에 모든 무효한 바이트를 제거하여서, 새로운 프로토콜 헤더를 형성한다. 따라서, 리라이트 엔진은 비트 벡터들을 사용하여서 패킷들의 프로토콜 헤더들의 확장 및 수축을 가능하게 하여, 제네릭 커맨드들의 세트를 사용함으로써 패킷들의 유연한 수정을 가능하게 한다.
예를 들어, 가정 1을 다시 참조하면, 도 9e의 비트 벡터 (920) 는 삭제 커맨드가 도 9b의 제네릭화된 프로토콜 헤더 (905) 에 적용된 후의 도 9d의 수정된 프로토콜 헤더 (915) 를 나타낸다. 이 가정 1에서, Customer VLAN Tag는 삭제되고, 이로써 Customer VLAN Tag의 4 바이트를 무효화시킨다. 이로써, Customer VLAN Tag에 대응하는 비트 벡터 (920) 내의 비트들은 0으로 마킹된다. 모든 커맨드들, 즉 가정 1에서 삭제 커맨드가 동작된 후에, 리라이트 엔진은 비트 벡터 (920) 를 사용하여서 모든 무효한 바이트를 제거하며, 이로써 비트 벡터 (920) 를 수축시킨다. 새로운 프로토콜 헤더가 수축 비트 벡터에 기초하여서 형성된다. 도 9f는 모든 무효한 바이트가 제거된 후의 새로운 프로토콜 헤더 (925) 를 예시한다. 새로운 헤더 (925) 를 갖는 가정 1에서의 패킷이 아웃고잉 이더넷 포트를 통해서 전송된다.
또 다른 예로서, 가정 2를 다시 참조하면, 도 10d의 비트 벡터 (1015) 는, 삭제 커맨드들이 도 10a의 프로토콜 헤더 (1000) 에 적용된 후의 도 10c의 수정된 프로토콜 헤더 (1010) 를 나타낸다. 이 가정 2에서, Service VLAN Tag 및 Customer VLAN Tag는 삭제되고, 이로써 Service VLAN Tag 의 4 바이트 및 Customer VLAN Tag의 4 바이트를 무효화한다. 이로써, Service VLAN Tag 및 Customer VLAN Tag에 대응하는 비트 벡터 (1015) 내의 비트들은 0으로 마킹된다. 모든 커맨드들, 가정 2에서는 즉 2 개의 삭제 커맨드들이 동작된 후에, 리라이트 엔진은 비트 벡터 (1015) 를 사용하여서 모든 무효한 바이트를 제거하고, 이로써 비트 벡터 (1015) 를 수축시킨다. 새로운 프로토콜 헤더가 수축 비트 벡터에 기초하여서 형성된다. 도 10e는 모든 무효한 바이트가 제거된 후의 새로운 프로토콜 헤더 (1020) 를 예시한다. 새로운 헤더 (1020) 를 갖는 가정 2에서의 패킷이 아웃고잉 이더넷 포트를 통해서 전송된다.
도 18은 본 발명의 일부 실시예들에 따른 리라이트 엔진의 또 다른 방법 1800을 예시한다. 리라이트 엔진은 네트워크 스위치의 일부이며 패킷들이 네트워크 스위치로부터 전송되기 이전에 패킷들을 수정한다. 단계 1805에서, 각 제네릭화된 프로토콜 헤더에 대한 비트 벡터가 유지된다. 제네릭화된 프로토콜 헤더는 제네릭 포맷으로 확장된 패킷의 프로토콜 헤더이다. 제네릭 포맷은 프로토콜의 모든 가능한 필드들을 포함한다. 필드들 각각은 프로토콜 헤더가 프로토콜의 어느 변형에 대응하는지에 상관없이 동일한 오프셋을 갖는다. 비트 벡터는 제네릭화된 프로토콜 헤더의 각 바이트에 대하여 바이트 당 비트를 포함한다.
단계 1810에서, 비트 벡터는 적어도 하나의 제네릭화된 프로토콜 헤더의 수정에 기초하여서 업데이트된다. 이 수정은 적어도 하나의 제네릭화된 프로토콜 헤더를 수정하기 위해서 네트워크 스위치의 메모리 내에 저장된 제네릭 커맨드들의 세트로부터의 적어도 하나의 커맨드를 사용한다.
단계 1815에서, 업데이트된 비트 벡터는 적어도 하나의 제네릭화된 프로토콜 헤더를 압축하는데 사용된다. 일부 실시예들에서, 단계 1815 이전에, XOR 연산이 비트 벡터 및 업데이트된 비트 벡터에 대해서 수행되어서 얼마나 많은 비트들이 변경되었는지를 결정하며, 이는 리라이트 엔진이 삭제되거나 부가된 바이트를 계산하게 한다.
도 19는 본 발명의 일부 실시예들에 따른 네트워크 스위치의 또 다른 방법 1900을 예시한다. 단계 1905에서, 패킷이 네트워크 스위치의 인커밍 포트에서 수신된다.
단계 1910에서, 패킷의 각 프로토콜 헤더가 프로토콜 헤더에 대한 제네릭 포맷에 따라서 제네릭화된다. 패킷의 프로토콜 헤더로부터 누락 필드들이 검출된다. 이 검출에 기초하여서, 프로토콜 헤더는 누락 필드들을 포함함으로써 제네릭 포맷으로 확장된다.
단계 1915에서, 각 제네릭화된 프로토콜 헤더에 대한 비트 벡터가 유지된다. 이 비트 벡터는 무효한 필드들에 대해서는 0으로 마킹된 비트들 및 유효한 필드들에 대해서는 1로 마킹된 비트들을 포함한다.
단계 1920에서, 제네릭화된 프로토콜 헤더 중 적어도 하나가 수정되며, 이로써 비트 벡터를 업데이트한다. 이러한 수정은 적어도 하나의 제네릭화된 프로토콜 헤더를 수정하기 위해서 네트워크 스위치의 메모리 내에 저장된 제네릭 커맨드들의 세트로부터의 적어도 하나의 커맨드를 사용한다. 적어도 하나의 제네릭화된 프로토콜 헤더의 수정은 네트워크 스위치의 아웃고잉 포트의 에그레스 포트타입에 기초한다.
단계 1925에서, 업데이트된 비트 벡터는 업데이트된 비트 벡터 내에서 0으로 마킹된 비트 각각을 제거하도록 업데이트된 비트 벡터를 시프트시킴으로써 수축된다.
단계 1930에서, 컴팩트한 프로토콜 헤더가 수축된 비트 벡터에 기초하여서 형성된다. 적어도 컴팩트한 프로토콜 헤더를 갖는 패킷은 네트워크 스위치의 아웃고잉 포트를 통해서 전송된다. 일부 실시예들에서, 패킷 전송 이전에, 수행된 모든 연산들에 대해 부가되거나 삭제된 바이트의 수가 카운트된다.
포인터 구조
포인터 구조가 사용되어서, 제네릭화를 위해서 인커밍 패킷 내의 상이한 프로토콜 레이어들을 추출하고 이 프로토콜 레이어들의 수정들 후에 패킷을 재구성한다. 포인터 구조는 N+1 레이어 포인터들 및 패킷의 모든 헤더들의 총 크기를 포함한다. 전형적으로, 포인터 구조는 패킷을 개별 레이어들로 분할하고 이어서 이들을 다시 지능적으로 서로 연결 (stitch) 하도록 리라이트 엔진에 의해서 사용되기 위해서, 파서 엔진에 의해서 제공된 데이터를 사용하여 초기에 업데이트된다. 패킷이 개별 레이어들로 분할된 후에, 리라이트 엔진은 프로토콜 헤더들을 제네릭화시키고, 제네릭화된 프로토콜 헤더들을 수정하고, 제네릭화된 프로토콜 헤더들을 모든 무효한 바이트를 제거함으로써 압축한다. 레이어 포인터들이, 각 레이어가 수정된 후에, 리라이트 엔진에 의해서 업데이트된다. 이러한 업데이트된 레이어 포인터들은 패킷을 네트워크 스위치로부터 전송하기 이전에 상이한 프로토콜 레이어들을 다시 서로 연결하는데 사용된다.
도 20은 본 발명의 일부 실시예들에 따른 레이어 구조의 예시적인 도 2000를 예시한다. 인커밍 패킷이 다음과 같은 프로토콜 레이어들을 포함한다고 가정한다: 전용 (proprietary) 헤더, 이더넷, IPv4, UDP, VxLAN 및 이더넷. 또한 네트워크 스위치의 파서 엔진이 8 개까지의 레이어들을 파싱할 수 있으며, 리라이트 엔진은 오직 처음의 N 개의 프로토콜 레이어들만을 (예를 들어 N = 4) (이는 소프트웨어 요건 및/또는 하드웨어 능력 때문임) 수정할 수 있다고 가정하자. 일부 실시예들에서, 파서 엔진은 데이터, 예를 들어 패킷의 각 프로토콜 헤더의 시작 위치를 리라이트 엔진에 제공한다.
리라이트 엔진이 패킷의 처음의 4 개의 프로토콜 레이어들을 수정할 수 있기 때문에, 리라이트 엔진은 오직 파서 엔진으로부터의 관련 데이터만, 즉 처음의 4 개의 프로토콜 레이어들: 전용 헤더, 이더넷, IPv4 및 UDP에 대한 데이터만을 사용한다. 이 데이터를 사용하여서, 패킷에 대한 포인터 구조가 초기화된다: 패킷 내의 전용 헤더 (즉, 레이어 0) 에 대한 시작 위치인, 0으로 설정된 LayerPointer0, 패킷 내의 이더넷 헤더 (즉, 레이어 1) 에 대한 시작 위치인, 16으로 설정된 LayerPointer1, 패킷 내의 IPv4 헤더 (즉, 레이어 2) 에 대한 시작 위치인, 36으로 설정된 LayerPointer2, 패킷 내의 UDP 헤더 (즉, 레이어 3) 에 대한 시작 위치인, 48로 설정된 LayerPointer3, 및 및 리라이트 엔진이 수정하지 않는 헤더들의 나머지 부분에 대한 시작 위치인, 56으로 설정된 LayerPointer4. 일부 실시예들에서, 리라이트 엔진은 헤더들의 크기를 계산하고 HeaderSize (즉, 모든 헤더들의 총 크기) 를 223으로 설정한다.
레이어 포인터들을 사용함으로써, 리라이트 엔진은 수정을 위해서 상술한 바와 같이, 처음의 4 개의 프로토콜 레이어들 (즉, 전용 헤더, 이더넷, IPv4, UDP) 을 제네릭화한다. 수정 후에, 리라이트 엔진은 모든 무효한 바이트를 제거함으로써 수정된 프로토콜 헤더들을 압축한다. 전형적으로, 레이어 포인터들은 프로토콜 헤더들이 수정된 후에 업데이트된다.
레이어 포인터들은 엔드 포인터를 형성한다. 엔드 포인터는 HeaderSize와 함께 헤더들의 바디와 연관되며, 이 바디는 수정되지 않고 이후 연결을 위해서 순방향 반송되는 헤더의 부분이다. 모든 수정들이 수행되고 수정된 프로토콜 헤더들이 압축된 후에, 수정된 레이어 포인터들이 사용되어서 수정된 헤더들을 다시 헤더들의 바디와 연결시킨다 (stitch).
리라이트 엔진은 리라이트 엔진이 수정할 수 있는 레이어들의 수로 한정될 수 있다. 일부 실시예들에서, 리라이트 엔진은 또한 리라이트 엔진이 임의의 소정의 프로토콜 레이어를 얼마나 많이 확장시킬 수 있는지로 한정될 수 있다. 이러한 실시예들에서, 리라이트 엔진은 2 개의 인접하는 레이어 포인터들을 감산함으로써 프로토콜 레이어의 크기를 추출한다. 레이어 크기가 리라이트 엔진의 하드웨어 역량을 초과하면, 리라이트 엔진들은 간단히 이전의 레이어 포인터를 사용하여 지능적으로 바디를 형성한다.
프로토콜 레이어가 40 바이트보다 많이 확장될 수 없지만, 해당 프로토콜의 가장 큰 변형이 64 바이트라고 가정하자. 일부 실시예들에서, 리라이트 엔진은 수정을 위해서 헤더 프로토콜을 최대 40 바이트까지 확장한다. 수정 후에, 레이어 포인터들을 사용하여서, 리라이트 엔진은 나머지 바이트를 수정된 바이트로 유사하게 연결할 수 있다.
레이어 포인터들의 사용은 하드웨어 로직 및 복잡도를 크게 감소시키는데 그 이유는 오직 하나의 소정의 프로토콜 레이어만을 다루는 것이 필요하기 때문이다. 하드웨어 커맨드들의 범위는 소정의 레이어로 한정된다. 커맨드들 엔진이 선행하는 레이어 또는 이를 후행하는 레이어에 의존하지 않기 때문에, 커맨드들 하드웨어는, 보다 많은 커맨드들이 레이어마다 필요하다면, 다중-패스 방식으로 (in multi-pass fashion) 으로 사용될 수 있다. 달리 말하면, 커맨드들이 커맨드들과 연관된 내부 상태를 가지지 않기 때문에, 다수의 커맨드들은 병렬로 사용될 수 있다. 마찬가지로, 다수의 레이어들이 병렬로 수정될 수 있다.
도 21은 본 발명의 일부 실시예들에 따른 리라이트 엔진의 또 다른 방법 2100을 예시한다. 리라이트 엔진은 네트워크 스위치의 일부이며, 패킷들이 네트워크 스위치로부터 전송되기 이전에 패킷들을 수정한다. 단계 2105에서, 패킷 각각에 대한 포인터 구조가 유지된다. 포인터 구조는 패킷의 모든 헤더들의 총 크기 및 레이어 포인터들을 포함한다. 레이어 포인터들 각각은 패킷 내의 해당 레이어의 시작 위치에 대응한다.
포인터 구조는 N+1 개의 레이어 포인터들을 포함한다. 리라이트 엔진은 패킷의 N 개의 레이어들을 수정한다. 레이어 포인터들은 엔드 포인터를 형성한다. 총 크기와 함께 엔드 포인트는 헤더들의 바디를 표시한다. 헤더들의 바디는 리라이트 엔진에 의해서 수정되지 않은 헤더들의 부분이다.
단계 2110에서, 패킷의 레이어들이 레이어 수정들을 위해서 레이어 포인터들에 기초하여서 분할된다. 패킷의 프로토콜 헤더로부터의 누락 필드들이 검출된다. 검출에 기초하여서, 프로토콜 헤더가 대응하는 프로토콜에 대한 제네릭 포맷으로 확장된다. 제네릭 포맷은 프로토콜의 모든 가능한 필드들을 포함한다. 필드들 각각은 프로토콜 헤더가 프로토콜의 어느 변형에 대응하는지에 상관없이 동일한 오프셋을 갖는다. 각 제네릭화된 프로토콜 헤더는 무효한 필드들에 대해서 비가용하거나 0으로 마킹된 비트들 및 유효한 필드들에 대해서 가용하거나 1로 마킹된 비트들을 갖는 비트 벡터를 포함한다. 제네릭화된 프로토콜 헤더를 수정하기 위해 제네릭 커맨드들의 세트로부터의 적어도 하나의 커맨드가 사용된다. 전형적으로, 비트 벡터는 수정 이후에 업데이트된다.
단계 2115에서, 레이어 포인터들이 레이어 수정들에 기초하여서 업데이트된다.
단계 2120에서, 레이어들이 업데이트된 레이어 포인터들에 기초하여서 다시 서로 연결된다.
도 22는 본 발명의 일부 실시예들에 따른 네트워크 스위치의 또 다른 방법 2200을 예시한다. 단계 2205에서, 패킷이 네트워크 스위치의 인커밍 포트에서 수신된다.
단계 2210에서, 포인터 구조가 사용되어서 패킷의 프로토콜 레이어들을 분리시킨다. 포인터 구조는 패킷의 N+1 개의 위치들로의 N+1 개의 레이어 포인터들 및 패킷의 모든 헤더들의 총 크기를 포함한다. 이 위치들은 프로토콜 레이어들의 시작 위치들을 포함한다. 포인터 구조는 패킷의 파싱된 데이터에 기초하여서 초기화된다.
단계 2215에서, 분리된 프로토콜 레이어들이 수정을 위해서 제네릭화된다. 각 레이어에 대해서, 그 레이어의 크기가 추출되어서 그 크기가 이 레이어를 수정하기 위한 하드웨어 역량을 초과하는지의 여부가 결정된다. 그 크기는 포인터 구조 내의 2 개의 인접하는 레이어 포인터들을 감산함으로써 추출된다. 이 결정사항에 기초하여서, 2 개의 인접하는 레이어 포인터들 중 처음 것이 사용되어서 바디가 형성된다.
단계 2220에서, 포인터 구조가 수정에 기초하여서 업데이트된다.
단계 2225에서, 업데이트된 포인터 구조가 사용되어서 수정된 프로토콜 레이어들을 다시 서로 지능적으로 연결하여서 새로운 프로토콜 헤더를 형성한다.
단계 2230에서, 새로운 프로토콜 헤더를 갖는 패킷이 네트워크 스위치의 아웃고잉 포트를 통해서 전송된다.
본 기술 분야의 당업자는 다른 용도들 및 이점들이 역시 존재함을 이해할 것이다. 본 발명이 다수의 특정 세부사항들을 참조하여서 기술되었지만, 본 기술 분야의 당업자는 본 발명이 본 발명의 범위를 벗어나지 않고 다른 특정 형태들로 구현될 수 있다는 것을 인식할 것이다. 따라서, 본 발명은 전술한 예시적인 세부사항들에 의해서 한정되기보다는 첨부된 청구항들에 의해서 규정된다는 것을 본 기술 분야의 당업자는 이해할 것이다.

Claims (27)

  1. 네트워크 디바이스의 리라이트 엔진 (rewrite engine) 의 방법으로서,
    프로토콜 헤더에 대한 제네릭 포맷 (generic format) 에 따라 패킷의 상기 프로토콜 헤더 각각을 제네릭화 (generalize) 하는 단계로서, 상기 제네릭화된 프로토콜 헤더 각각은 무효한 (invalid) 필드들에 대해 0으로 마킹된 비트들 및 유효한 필드들에 대해 1로 마킹된 비트들을 갖는 비트 벡터를 포함하는, 상기 프로토콜 헤더 각각을 제네릭화하는 단계; 및
    적어도 하나의 제네릭화된 프로토콜 헤더를 수정하기 위해 상기 네트워크 스위치의 메모리 내에 저장된 제네릭 커맨드들의 세트로부터 적어도 하나의 커맨드를 사용하는 단계를 포함하는, 네트워크 디바이스의 리라이트 엔진의 방법.
  2. 제 1 항에 있어서,
    상기 제네릭 포맷은 상기 프로토콜의 모든 가능한 필드들을 포함하고,
    상기 필드들 각각은 상기 프로토콜 헤더가 대응하는 프로토콜의 변형과 상관없이 동일한 오프셋을 갖는, 네트워크 디바이스의 리라이트 엔진의 방법.
  3. 제 1 항에 있어서,
    상기 비트 벡터는 상기 제네릭화된 프로토콜 헤더의 바이트 각각에 대하여 바이트 당 비트 (bit per byte) 를 포함하는, 네트워크 디바이스의 리라이트 엔진의 방법.
  4. 제 1 항에 있어서,
    상기 적어도 하나의 제네릭화된 프로토콜 헤더의 수정은 상기 네트워크 스위치의 아웃고잉 포트의 에그레스 포트 타입 (egress portType) 에 기초하는, 네트워크 디바이스의 리라이트 엔진의 방법.
  5. 제 1 항에 있어서,
    상기 적어도 하나의 제네릭화된 프로토콜 헤더의 수정은 업데이트된 상기 비트 벡터를 발생시키는, 네트워크 디바이스의 리라이트 엔진의 방법.
  6. 제 5 항에 있어서,
    얼마나 많은 비트들이 변화되는지 결정하기 위해 상기 비트 벡터 및 상기 업데이트된 비트 벡터에 XOR 연산을 수행하는 단계를 더 포함하는, 네트워크 디바이스의 리라이트 엔진의 방법.
  7. 제 1 항에 있어서,
    상기 제네릭 커맨드들의 세트는 프로토콜의 제 1 변형의 패킷 헤더를 수정하고 상기 프로토콜의 제 2 변형의 패킷 헤더를 수정하기 위해 사용되는, 네트워크 디바이스의 리라이트 엔진의 방법.
  8. 제 1 항에 있어서,
    상기 제네릭 커맨드들의 세트는 제 1 프로토콜의 패킷 헤더를 수정하고 제 2 프로토콜의 패킷 헤더를 수정하기 위해 사용되는, 네트워크 디바이스의 리라이트 엔진의 방법.
  9. 네트워크 스위치의 방법으로서,
    상기 네트워크 스위치의 메모리 내에 제네릭 커맨드들의 세트를 유지하는 단계;
    상기 네트워크 스위치의 인커밍 포트에서 패킷을 수신하는 단계;
    프로토콜 헤더에 대한 제네릭 포맷에 따라 상기 패킷의 상기 프로토콜 헤더 각각을 제네릭화하는 단계로서, 제네릭화된 프로토콜 헤더 각각은 무효한 필드들에 대해 0으로 마킹된 비트들 및 유효한 필드들에 대해 1로 마킹된 비트들을 갖는 비트 벡터를 포함하는, 상기 프로토콜 헤더 각각을 제네릭화하는 단계;
    상기 제네릭화된 프로토콜 헤더에 상기 제네릭 커맨드들의 세트로부터 적어도 하나의 커맨드를 적용함으로써 상기 제네릭화된 프로토콜 헤더들 중 적어도 하나의 프로토콜 헤더를 수정하여, 상기 비트 벡터를 업데이트하는 단계;
    상기 업데이트된 비트 벡터에 기초하여 새로운 프로토콜 헤더를 형성하는 단계; 및
    상기 네트워크 스위치의 아웃고잉 포트를 통해 상기 새로운 프로토콜 헤더를 갖는 상기 패킷을 전송하는 단계를 포함하는, 네트워크 스위치의 방법.
  10. 제 9 항에 있어서,
    상기 제네릭 커맨드들의 세트 내의 각각의 커맨드는 소프트웨어가 프로그램하는 마이크로코드로서 동작하는, 네트워크 스위치의 방법.
  11. 제 9 항에 있어서,
    상기 제네릭 커맨드들의 세트는 Delete 커맨드를 포함하고,
    상기 Delete 커맨드의 파라미터들은 Start 및 Size를 포함하는, 네트워크 스위치의 방법.
  12. 제 11 항에 있어서,
    상기 Delete 커맨드는 상기 비트 벡터 내에서 Size 바이트들에 대응하는 비트들을 0으로 마킹함으로써 Start 위치로부터 상기 제네릭화된 프로토콜 헤더 내에서 Size 바이트들을 삭제하는, 네트워크 스위치의 방법.
  13. 제 9 항에 있어서,
    상기 제네릭 커맨드들의 세트는 Copy 커맨드를 포함하고,
    상기 Copy 커맨드의 파라미터들은 Source, SourceOffset , Size, DestinationOffset, Bitmask , copyConstantBitMask 및 copyConstantData를 포함하는, 네트워크 스위치의 방법.
  14. 제 13 항에 있어서,
    상기 Copy 커맨드는 Source의 SourceOffset으로부터 상기 제네릭화된 프로토콜 헤더의 DestinationOffset으로 Size 바이트들의 데이터를 카피하는, 네트워크 스위치의 방법.
  15. 제 13 항에 있어서,
    상기 Copy 커맨드는 비트마스크 연산들을 위해 Bitmask를 사용하는, 네트워크 스위치의 방법.
  16. 제 13 항에 있어서,
    copyConstantBitMask가 비트 위치에 “1”을 포함할 때, copyConstantData 내의 대응하는 위치로부터의 바이트는 대응하는 위치에서 상기 제네릭화된 프로토콜 헤더 내로 카피되는, 네트워크 스위치의 방법.
  17. 제 13 항에 있어서,
    copyConstantData는 상기 메모리 내에 저장되고 소프트웨어로 규정되는, 네트워크 스위치의 방법.
  18. 제 13 항에 있어서,
    대응하는 수신지 바이트들의 유효성은 Source의 데이터의 유효성에 의존하고,
    상기 비트 벡터 내에서 무효한 바이트들을 나타내는 비트들은 0으로 마킹되고 상기 비트 벡터 내에서 유효한 바이트들을 나타내는 비트들은 1로 마킹되는, 네트워크 스위치의 방법.
  19. 제 9 항에 있어서,
    상기 제네릭 커맨드들의 세트는 Move 커맨드를 포함하고,
    상기 Move 커맨드의 파라미터들은 StartOffset , DestinationOffset 및 Size를 포함하는, 네트워크 스위치의 방법.
  20. 제 19 항에 있어서,
    상기 Move 커맨드는 상기 제네릭화된 프로토콜 헤더 내의 Size 바이트들을 StartOffset으로부터 DestinationOffset으로 이동시키는, 네트워크 스위치의 방법.
  21. 제 19 항에 있어서,
    대응하는 수신지 바이트들의 유효성은 Source 내의 데이터의 유효성에 의존하고,
    대응하는 소스 바이트들은 무효가 되고 (invalid),
    상기 비트 벡터 내에서 무효한 바이트들을 나타내는 비트들은 0으로 마킹되고 상기 비트 벡터 내에서 유효한 바이트들을 나타내는 비트들은 1로 마킹되는, 네트워크 스위치의 방법.
  22. 제 9 항에 있어서,
    프로토콜 헤더 각각을 제네릭화하는 단계는,
    상기 패킷의 상기 프로토콜 헤더로부터 누락 필드들을 검출하는 단계; 및
    상기 검출에 기초하여, 상기 누락 필드들을 포함시킴으로써 상기 프로토콜 헤더를 상기 제네릭 포맷으로 확장시키는 단계를 포함하는, 네트워크 스위치의 방법.
  23. 제 22 항에 있어서,
    상기 새로운 프로토콜 헤더를 갖는 상기 패킷을 전송하기 전에, 수행된 모든 연산들에 대해 부가되거나 삭제된 바이트들의 수를 카운팅하는 단계를 더 포함하는, 네트워크 스위치의 방법.
  24. 네트워크 스위치로서,
    패킷들을 수신 및 전송하기 위한 입력 포트 및 출력 포트;
    제네릭 커맨드들의 세트를 저장하기 위한 메모리로서, 상기 제네릭 커맨드들의 세트는 인커밍 헤더들과 상관없이 헤더 수정들을 위해 사용되는, 상기 메모리; 및
    상기 제네릭 커맨드들의 세트로부터 적어도 하나의 커맨드를 사용함으로써 수정을 위해 상기 패킷들 각각의 프로토콜 헤더 각각을 제네릭화하도록 상기 패킷들을 프로세싱하기 위한 리라이트 엔진을 포함하는, 네트워크 스위치.
  25. 제 24 항에 있어서,
    프로토콜 헤더 각각은 대응하는 프로토콜에 특정된 소프트웨어로 규정된 맵핑사항들 중 하나에 따라 제네릭화되는, 네트워크 스위치.
  26. 제 24 항에 있어서,
    제네릭화된 프로토콜 헤더 각각은 무효한 필드들에 대해 0으로 마킹된 비트들 및 유효한 필드들에 대해 1로 마킹된 비트들을 갖는 비트 벡터를 포함하는, 네트워크 스위치.
  27. 제 24 항에 있어서,
    상기 제네릭 커맨드들의 세트는 Delete 커맨드, Copy 커맨드 및 Move 커맨드를 포함하는, 네트워크 스위치.
KR1020150084526A 2014-06-19 2015-06-15 패킷들의 유연한 수정을 실현하기 위해 제네릭 수정 인스트럭션을 사용하는 방법 및 이의 장치 KR102368166B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14/309,650 US9531848B2 (en) 2014-06-19 2014-06-19 Method of using generic modification instructions to enable flexible modifications of packets and an apparatus thereof
US14/309,650 2014-06-19

Publications (2)

Publication Number Publication Date
KR20150146406A true KR20150146406A (ko) 2015-12-31
KR102368166B1 KR102368166B1 (ko) 2022-02-25

Family

ID=53541502

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020150084526A KR102368166B1 (ko) 2014-06-19 2015-06-15 패킷들의 유연한 수정을 실현하기 위해 제네릭 수정 인스트럭션을 사용하는 방법 및 이의 장치

Country Status (7)

Country Link
US (1) US9531848B2 (ko)
EP (1) EP2958286B1 (ko)
JP (1) JP6594672B2 (ko)
KR (1) KR102368166B1 (ko)
CN (1) CN105282136B (ko)
HK (1) HK1220835A1 (ko)
TW (1) TW201605207A (ko)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110471776B (zh) * 2019-06-27 2022-02-08 浙江口碑网络技术有限公司 应用数据通信方法、装置及系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020163935A1 (en) * 2001-05-04 2002-11-07 Terago Communications, Inc. System and method for providing transformation of multi-protocol packets in a data stream
US20070078997A1 (en) * 2005-10-05 2007-04-05 Microsoft Corporation Efficient endpoint matching using a header-to-bit conversion table

Family Cites Families (63)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5805808A (en) 1991-12-27 1998-09-08 Digital Equipment Corporation Real time parser for data packets in a communications network
US5793954A (en) * 1995-12-20 1998-08-11 Nb Networks System and method for general purpose network analysis
US6088356A (en) 1997-06-30 2000-07-11 Sun Microsystems, Inc. System and method for a multi-layer network element
US6341129B1 (en) 1998-04-03 2002-01-22 Alteon Networks, Inc. TCP resegmentation
US7333484B2 (en) 1998-08-07 2008-02-19 Intel Corporation Services processor having a packet editing unit
FI106504B (fi) 1998-10-06 2001-02-15 Nokia Networks Oy Datan segmentointimenetelmä tietoliikennejärjestelmässä
US6356951B1 (en) * 1999-03-01 2002-03-12 Sun Microsystems, Inc. System for parsing a packet for conformity with a predetermined protocol using mask and comparison values included in a parsing instruction
US6789116B1 (en) 1999-06-30 2004-09-07 Hi/Fn, Inc. State processor for pattern matching in a network monitor device
CN100407324C (zh) 1999-12-02 2008-07-30 松下电器产业株式会社 光盘记录方法及其光盘记录装置
JP3613102B2 (ja) 1999-12-14 2005-01-26 日本電気株式会社 フレーム構成方法、フレーム構成装置およびフレーム構成転送システム
JP4099930B2 (ja) 2000-06-02 2008-06-11 株式会社日立製作所 ルータ装置及びｖｐｎ識別情報の設定方法
GB0023169D0 (en) 2000-09-20 2000-11-01 Ibm Message parsing in message processing systems
WO2002032080A1 (en) * 2000-10-11 2002-04-18 Broadcom Corporation Cable modem system and method for supporting packet pdu compression
US6904057B2 (en) 2001-05-04 2005-06-07 Slt Logic Llc Method and apparatus for providing multi-protocol, multi-stage, real-time frame classification
JP4460195B2 (ja) * 2001-08-06 2010-05-12 株式会社日立製作所 パケット転送装置およびルーティング制御装置
US20030037154A1 (en) * 2001-08-16 2003-02-20 Poggio Andrew A. Protocol processor
US7580408B2 (en) 2001-11-21 2009-08-25 Alcatel Lucent Configurable packet processor
US7236501B1 (en) 2002-03-22 2007-06-26 Juniper Networks, Inc. Systems and methods for handling packet fragmentation
US7187694B1 (en) 2002-03-29 2007-03-06 Pmc-Sierra, Inc. Generic packet parser
JP2003308206A (ja) 2002-04-15 2003-10-31 Fujitsu Ltd プロセッサ装置
US20050232303A1 (en) 2002-04-26 2005-10-20 Koen Deforche Efficient packet processing pipeline device and method
US7408957B2 (en) 2002-06-13 2008-08-05 International Business Machines Corporation Selective header field dispatch in a network processing system
US7415596B2 (en) 2003-01-24 2008-08-19 Gigafin Networks, Inc. Parser table/production rule table configuration using CAM and SRAM
US20050281281A1 (en) 2003-01-24 2005-12-22 Rajesh Nair Port input buffer architecture
US7706363B1 (en) 2003-06-11 2010-04-27 Radlan Computer Communications, Ltd Method and apparatus for managing packets in a packet switched network
GB0320957D0 (en) * 2003-09-08 2003-10-08 Qinetiq Ltd Document authentication
US7411957B2 (en) 2004-03-26 2008-08-12 Cisco Technology, Inc. Hardware filtering support for denial-of-service attacks
US7822032B1 (en) * 2004-03-30 2010-10-26 Extreme Networks, Inc. Data structures for supporting packet data modification operations
US7385984B2 (en) * 2004-03-30 2008-06-10 Extreme Networks, Inc. Packet processing system architecture and method
US7580350B1 (en) 2004-03-30 2009-08-25 Extreme Networks, Inc. System for deriving packet quality of service indicator
US7568047B1 (en) 2004-04-30 2009-07-28 Nortel Networks Limited Method and apparatus for adaptive service label management
JP4392294B2 (ja) 2004-06-15 2009-12-24 株式会社日立製作所 通信統計収集装置
JP4156568B2 (ja) 2004-06-21 2008-09-24 富士通株式会社 通信システムの制御方法、通信制御装置、プログラム
US7474619B2 (en) 2004-07-22 2009-01-06 International Business Machines Corporation Method and apparatus for providing fragmentation at a transport level along a transmission path
US7570661B2 (en) 2005-06-14 2009-08-04 Microsoft Corporation Script-based parser
US9143585B2 (en) 2006-07-07 2015-09-22 Wi-Lan Inc. Method and system for generic multiprotocol convergence over wireless air interface
US7710959B2 (en) * 2006-08-29 2010-05-04 Cisco Technology, Inc. Private VLAN edge across multiple switch modules
CN101563908B (zh) 2006-12-19 2013-01-09 国际商业机器公司 分析网络流的装置和方法
US7822875B1 (en) 2006-12-22 2010-10-26 Marvell International Ltd. Method for flexible modifications to a packet
IL190134A (en) 2007-03-12 2012-07-31 Marvell Israel Misl Ltd Method and system for determining the location of fields in information units
US8825592B2 (en) 2008-03-12 2014-09-02 Web Access, Inc. Systems and methods for extracting data from a document in an electronic format
US7843919B2 (en) 2008-03-20 2010-11-30 International Business Machines Corporation Ethernet virtualization using a network packet alteration
KR101456563B1 (ko) 2008-05-14 2014-10-31 삼성전자주식회사 멀티 홉 릴레이 환경에서 대역폭 할당 요청과 할당 방법 및시스템
CN102273149A (zh) * 2008-12-23 2011-12-07 莫维克网络公司 一种利用多层协议的透明代理设备
US8234369B2 (en) 2008-12-23 2012-07-31 Verizon Patent And Licensing Inc. Web page response monitoring
US8902886B2 (en) 2009-04-23 2014-12-02 International Business Machines Corporation Canonicalization of network protocol headers
US8111704B2 (en) 2009-06-26 2012-02-07 Intel Corporation Multiple compression techniques for packetized information
US9008082B2 (en) 2009-12-07 2015-04-14 Telefonaktiebolaget L M Ericsson (Publ) Handling data packets received at a routing node
CN101777791B (zh) * 2009-12-18 2012-05-23 深圳市科陆电子科技股份有限公司 一种同时兼容多种电力负控系统通信协议的方法及其系统
US8472438B2 (en) 2010-04-23 2013-06-25 Telefonaktiebolaget L M Ericsson (Publ) Efficient encapsulation of packets transmitted on a packet-pseudowire over a packet switched network
EP2567524B1 (en) 2010-05-03 2019-06-26 Nokia Technologies Oy Protocol overhead reduction
US8537815B2 (en) 2010-06-17 2013-09-17 Apple Inc. Accelerating data routing
US8705533B1 (en) 2010-12-10 2014-04-22 Juniper Networks, Inc. Fast packet encapsulation using templates
TW201246867A (en) 2011-05-06 2012-11-16 Ralink Technology Corp Packet processing accelerator and method thereof
US8521905B2 (en) 2011-12-22 2013-08-27 Telefonaktiebolaget L M Ericsson (Publ) System for flexible and extensible flow processing in software-defined networks
US8711860B2 (en) 2011-12-22 2014-04-29 Telefonaktiebolaget L M Ericsson (Publ) Controller for flexible and extensible flow processing in software-defined networks
US9282173B2 (en) 2012-02-17 2016-03-08 Viavi Solutions Inc. Reconfigurable packet header parsing
EP2790411B1 (en) 2012-10-17 2017-04-12 Sony Corporation Data processing device, data processing method, and program
EP2915287B1 (en) 2012-10-30 2018-12-05 Viavi Solutions Inc. Method and system for identifying matching packets
US9219694B2 (en) 2013-03-15 2015-12-22 Wisconsin Alumni Research Foundation Content addressable memory with reduced power consumption
US9769701B2 (en) 2013-06-14 2017-09-19 Texas Instruments Incorporated Header compression for wireless backhaul systems
US9444914B2 (en) 2013-09-16 2016-09-13 Annapurna Labs Ltd. Configurable parser and a method for parsing information units
US9628382B2 (en) 2014-02-05 2017-04-18 Intel Corporation Reliable transport of ethernet packet data with wire-speed and packet data rate match

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020163935A1 (en) * 2001-05-04 2002-11-07 Terago Communications, Inc. System and method for providing transformation of multi-protocol packets in a data stream
US20070078997A1 (en) * 2005-10-05 2007-04-05 Microsoft Corporation Efficient endpoint matching using a header-to-bit conversion table

Also Published As

Publication number Publication date
JP2016005283A (ja) 2016-01-12
US20150373159A1 (en) 2015-12-24
CN105282136B (zh) 2020-05-05
EP2958286B1 (en) 2019-05-01
JP6594672B2 (ja) 2019-10-23
CN105282136A (zh) 2016-01-27
KR102368166B1 (ko) 2022-02-25
EP2958286A1 (en) 2015-12-23
TW201605207A (zh) 2016-02-01
US9531848B2 (en) 2016-12-27
HK1220835A1 (zh) 2017-05-12

Similar Documents

Publication Publication Date Title
US20240022652A1 (en) A method of using bit vectors to allow expansion and collapse of header layers within packets for enabling flexible modifications and an apparatus thereof
US9473601B2 (en) Method of representing a generic format header using continuous bytes and an apparatus thereof
KR102337518B1 (ko) 패킷의 구조를 식별하기 위해 고유한 패킷 식별자를 사용하는 방법 및 이의 장치
KR102368168B1 (ko) 수정을 위해 패킷을 개별 레이어들로 분할하고 수정 후에 레이어들을 지능적으로 다시 연결하는 방법 및 이의 장치
KR102380012B1 (ko) 프로그램가능한 수정들을 실현하기 위해 제네릭 포맷으로 패킷들을 수정하는 방법 및 이의 장치
KR102368166B1 (ko) 패킷들의 유연한 수정을 실현하기 위해 제네릭 수정 인스트럭션을 사용하는 방법 및 이의 장치

Legal Events

Date Code Title Description
N231 Notification of change of applicant
N231 Notification of change of applicant
A201 Request for examination
N231 Notification of change of applicant
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant