KR20140019730A

KR20140019730A - 버퍼 통계 트래킹

Info

Publication number: KR20140019730A
Application number: KR1020130075356A
Authority: KR
Inventors: 브루스 콴; 푸니트 아가왈; 모한 칼쿤테; 마틴 런드; 브래드 매튜
Original assignee: 브로드콤 코포레이션
Priority date: 2012-08-07
Filing date: 2013-06-28
Publication date: 2014-02-17
Also published as: TW201408009A; CN103580910A; KR101451149B1; EP2696536A1

Abstract

여기서 제시된 시스템들 및 방법들은 (패킷-스위칭 네트워크의) 스위치가 버퍼 통계를 트래킹하고, 임박한 문제를 나타내는 버퍼 통계가 임계치에 도달한 것에 대응하여 하드웨어 중단 또는 시스템 스냅샷과 같은 이벤트를 트리거한다. 스위치 그 자체가 네트워크 관리자에게 경보를 발하기 위해 이벤트를 트리거하므로, 네트워크 관리자는 잠재적인 문제들을 식별하기 위해 더 이상 데이터의 산더미 사이를 면밀히 조사할 필요가 없다. 또한, 스위치는 문제가 발생하기 전에 이벤트를 트리거하므로, 네트워크 관리자는 문제가 발생하기 전에 치료 동작을 제공할 수 있다. 이 타입의 이벤트-트리거링 메커니즘은 패킷-스위칭 네트워크들의 관리자를 더 관리하기 쉽게 만든다.

Description

버퍼 통계 트래킹{BUFFER STATISTICS TRACKING}

본 발명은 일반적으로 패킷-스위칭 네트워크들, 특히, 스위치들의 버퍼 통계를 트래킹하는 시스템들 및 방법들에 관한 것이다.

일반적으로, 패킷-스위칭 네트워크들에서, 스위치들은 네트워크 관리자들에 의해 폴링(polling)될 수 있는 버퍼 통계를 유지한다. 따라서, 네트워크 관리자는 네트워크 관리자의 관심을 요구할 수 있는 임의의 잠재적인 이슈들을 식별하기 위해 스위치들로부터 버퍼 통계를 주기적으로 폴링할 것이다. 그 대신에, 네트워크 관리자는 특정 스위치에 관해 발생한 문제에 대응하여 버퍼 통계를 폴링할 것이다. 불행히도, 수백 개의(또는 심지어 수천 개의) 스위치들을 갖는 큰 네트워크들에 대해서, 폴링된 데이터의 양은 흔들릴(staggering) 수 있고, 완전한 양의 데이터를 검토하는 것은 엄청나게 힘든 일일 수 있다.

본 발명의 목적은 스위치들의 버퍼 통계를 효율적으로 트래킹하는 시스템들 및 방법을 제공하는 것이다.

일 측면에 따르면, 버퍼를 갖는 스위치에서, 방법은:

(a) 통계의 타입을 결정하는 단계로서, 상기 통계의 타입은:

(a1) 현재 사용-카운트; 및

(a2) 최대 사용-카운트로 구성된 그룹으로부터 선택된 적어도 하나인, 상기 결정하는 단계;

(b) 상기 결정된 통계의 타입에 대한 사용-카운트를 트래킹하는 단계로서, 상기 사용-카운트는:

(b1) 이그레스 사용-카운트;

(b2) 인그레스 사용-카운트; 및

(b3) 기기 사용-카운트로 구성된 그룹으로부터 선택된 적어도 하나인, 트래킹하는 단계;

(c) 상기 사용-카운트에 대응하는 임계치와 비교하는 단계; 및

(d) 상기 사용-카운트가 상기 대응하는 임계치를 초과하면 이벤트를 트리거하는 단계를 포함한다.

바람직하게, 상기 방법은:

(e) 리셋 명령을 수신하는 단계; 및

(f) 상기 리셋 명령에 대응하여 상기 사용-카운트를 리셋하는 단계를 더 포함한다.

일 측면에 따르면, 시스템은:

버퍼와 관련된 사용-카운트(use-count)를 저장하는 사용-카운트 레지스터;

상기 사용-카운트에 대응하는 임계치를 저장하는 임계치 레지스터; 및

상기 사용-카운트를 상기 임계치와 비교하는 메모리 관리 유닛(MMU, memory management unit)을 포함하고, 상기 MMU는 상기 사용-카운트가 상기 임계치를 초과할 때 이벤트를 트리거(trigger)한다.

바람직하게, 상기 사용-카운트 레지스터는 이그레스(egress) 사용-카운트를 더 저장한다.

바람직하게, 상기 이그레스 사용-카운트는:

이그레스 유니캐스트(UC, egress unicast) 큐(queue) 사용-카운트;

이그레스 큐-그룹 공유된 사용-카운트;

이그레스 포트 사용-카운트;

이그레스 멀티캐스트(MC, egress multicast) 버퍼-풀(BP, buffer-pool) 사용-카운트;

이그레스 UC 플러스 MC(UC+MC) BP 사용-카운트들; 및

이그레스 중앙 처리 장치(CPU, central processing unit) 큐 사용-카운트를 포함하는 그룹으로부터 선택된 적어도 하나이다.

바람직하게, 상기 사용-카운트 레지스터는 인그레스 사용-카운트를 더 저장한다.

바람직하게, 상기 인그레스 사용-카운트는:

인그레스 포트 및 우선순위 그룹(PG, priority group) 유니캐스트 플러스 멀티캐스트(UC+MC) 공유된 사용-카운트;

인그레스 포트 PG 헤드룸(headroom) 사용-카운트;

인그레스 포트 버퍼 풀(BP) UC+MC 공유된 사용-카운트; 및

인그레스 BP UC+MC 공유된 사용-카운트를 포함하는 그룹으로부터 선택된 적어도 하나이다.

바람직하게, 상기 사용-카운트 레지스터는 기기 사용-카운트를 더 저장한다.

바람직하게, 상기 이벤트는 하드웨어 중앙 처리 장치(CPU) 중단(interrupt)이다.

바람직하게, 상기 이벤트는 상기 사용-카운트를 업데이트하는 것을 정지시키는 명령이다.

바람직하게, 상기 이벤트는 전용 비트(dedicated bit)가 상기 사용-카운트가 상기 임계치를 초과했다는 것을 표시하도록 설정되는 것이다.

일 측면에 따르면, 네트워크 스위치에서, 방법은:

버퍼와 관련된 사용-카운트를 트래킹하는 단계;

상기 트래킹된 사용-카운트가 미리 정의된 임계치를 초과하는지 여부를 결정하는 단계; 및

상기 사용-카운트가 상기 미리 정의된 임계치를 초과하면 이벤트를 트리거(trigger)하는 단계를 포함한다.

바람직하게, 상기 이벤트를 트리거하는 단계는:

중앙 처리 장치(CPU, central processing unit) 중단(interrupt)을 발행하는(issue) 단계를 포함한다.

바람직하게, 상기 이벤트를 트리거하는 단계는:

상기 사용-카운트의 업데이트를 정지하는 단계를 포함한다.

바람직하게, 상기 이벤트를 트리거하는 단계는:

전용 비트가 상기 사용-카운트가 상기 미리 정의된 임계치를 초과한다는 것을 표시하도록 설정하는 단계를 포함한다.

바람직하게, 상기 사용-카운트를 트래킹하는 단계는:

이그레스 사용-카운트를 트래킹하는 단계를 포함한다.

바람직하게, 상기 이그레스 사용-카운트를 트래킹하는 단계는:

이그레스 유니캐스트(UC, egress unicast) 큐(queue) 사용-카운트를 트래킹하는 단계;

이그레스 큐-그룹 공유된 사용-카운트를 트래킹하는 단계;

이그레스 포트 사용-카운트를 트래킹하는 단계;

이그레스 멀티캐스트(MC, egress multicast) 버퍼-풀(BP, buffer-pool) 사용-카운트를 트래킹하는 단계;

이그레스 UC 플러스 MC(UC+MC) BP 사용-카운트들을 트래킹하는 단계; 및

이그레스 중앙 처리 장치(CPU, central processing unit) 큐 사용-카운트를 트래킹하는 단계를 포함하는 그룹으로부터 선택된 적어도 하나의 단계를 포함한다.

바람직하게, 상기 사용-카운트를 트래킹하는 단계는:

인그레스 사용-카운트를 트래킹하는 단계를 포함한다.

바람직하게, 상기 인그레스 사용-카운트를 트래킹하는 단계는:

인그레스 포트 및 우선순위 그룹(PG, priority group) 유니캐스트 플러스 멀티캐스트(UC+MC) 공유된 사용-카운트를 트래킹하는 단계;

인그레스 포트 PG 헤드룸(headroom) 사용-카운트를 트래킹하는 단계;

인그레스 포트 버퍼 풀(BP) UC+MC 공유된 사용-카운트를 트래킹하는 단계; 및

인그레스 BP UC+MC 공유된 사용-카운트를 트래킹하는 단계를 포함하는 그룹으로부터 선택된 적어도 하나의 단계를 포함한다.

본 발명에 따르면, 스위치들의 버퍼 통계를 효율적으로 트래킹하는 시스템들 및 방법이 제공된다.

본 제시의 많은 측면들은 다음 도면들을 참조하여 더 잘 이해될 수 있다. 도면들의 구성요소들은 본 제시의 원리를 명확히 설명하는데 대신에 놓은 범위, 주안점에 대해 필수적이지는 않다. 더욱이, 도면들에서, 유사한 참조 번호는 일련의 도면들에 걸쳐서 대응하는 부분들을 지시한다.
도 1은 스위치가 버퍼 통계에 기반하여 이벤트를 트리거하는 방법의 일 실시예를 보여주는 흐름도이다.
도 2는 트래킹에 대한 버퍼 통계를 선택하는 방법의 일 실시예를 보여주는 흐름도이다.
도 3은 스위치에서 사용-카운트를 트래킹하는 방법의 일 실시예를 보여주는 흐름도이다.
도 4는 스위치에서 이벤트를 트리거하는 방법의 일 실시예를 보여주는 흐름도이다.
도 5는 스위치의 이그레스 통계를 트래킹하는 방법의 일 실시예를 보여주는 흐름도이다.
도 6은 스위치의 인그레스 통계를 트래킹하는 방법의 일 실시예를 보여주는 흐름도이다.

일반적으로, 패킷-스위칭 네트워크들에서, 스위치들은 네트워크 관리자들에 의해 폴링(polling)될 수 있는 버퍼 통계를 유지한다. 따라서, 스위치가 이슈(issue)(예를 들어, 큐(queue) 길이가 너무 길어짐)를 만나면, 네트워크 관리자는 이슈들을 격리하고 치료 동작을 제공하기 위해 문제가 있는 스위치로부터의 버퍼 통계를 폴링할 수 있다. 불행히도, 버퍼 통계가 폴링되는 시간에 의해, 문제는 이미 발생했고(예를 들어, 네트워크 정체), 그 시점에서 네트워크 관리자의 역할은 단순히 문제를 고치는 것이다(네트워크 트래픽을 다른 스위치들로 재-라우팅함).

대신에, 네트워크 관리자는 문제들을 방지해보려는 노력으로 버퍼 통계를 주기적으로 폴링할 수 있다. 요컨대, 버퍼 통계를 검토함에 의해, 네트워크 관리자는 문제를 막기 위해 사용 가능한 자원들을 재할당할 수 있다. 불행히도, 수백 개의(심지어 수천 개의) 스위치들을 갖는 큰 네트워크들에 대해, 폴링된 데이터의 양은 흔들릴(staggering) 수 있고, 완전한 양의 데이터를 검토하는 것은 엄청나게 힘든 일일 수 있다. 이것은 버퍼 통계에 대해 모든 스위치들을 폴링하는 것은 고장 직전인 몇몇 스위치들뿐만 아니라 정상적으로 동작하는 많은 스위치들에 대한 정보의 수집을 야기하기 때문이다. 따라서, 잠재적인 문제를 식별하기 위해 데이터의 늪 사이를 면밀히 검토하는 것은 많은 시간이 걸리는 일이다.

여기서 제시된 시스템들 및 방법들은 스위치가 임박한 문제를 표시할 수 있는 버퍼가 임계치에 도달한 것에 대응하여 버퍼 통계를 트래킹하고, 하드웨어 중단(interrupt) 또는 시스템 스냅샷(snapshot)과 같은 이벤트를 트리거하도록 한다. 스위치 자신이 네트워크 관리자에게 알리기 위해 이벤트를 트리거하므로, 네트워크 관리자는 더 이상 잠재적인 문제들을 식별하기 위해 데이터의 산더미 사이를 면밀히 검토할 필요가 없다. 또한, 스위치는 문제가 일어나기 전에 이벤트를 트리거하므로, 네트워크 관리자는 문제가 발생하기 전에 치료 동작을 제공할 수 있다. 이 타입의 이벤트-트리거링 메커니즘은 패킷-스위칭 네트워크들의 관리를 더 처리하기 쉽게 한다.

이벤트-트리거링 메커니즘을 구현하기 위해, 스위칭 시스템은 스위치 버퍼와 관련된 사용-카운트를 저장하는 사용-카운트 레지스터를 포함한다. 이 사용-카운트는 이그레스 통계, 인그레스 통계, 또는 기기 통계를 가리킬 수 있고, 큐 당(per-queue) 기반, 포트 당(per-port) 기반, 또는 풀 당(per-pool) 기반으로 모니터될 수 있다. 시스템은 또한 각각의 사용-카운트와 관련된 적절한 임계치 값들을 저장하는 임계치 레지스터를 포함한다. 시스템의 메모리 관리 유닛(MMU, memory management unit)은 사용-카운트가 임계치를 초과하는지 여부를 결정하기 위해 사용-카운트를 임계치와 비교한다. 그리고, 사용-카운트가 임계치를 초과하면, MMU는 이벤트를 트리거한다. 이벤트는 하드웨어 중앙 처리 장치(CPU, central processing unit) 중단일 수 있고, 그것은 네트워크 관리자에게 스위치 버퍼가 어떤 임계치를 초과했음을 알린다. 또한 이벤트는 임계치가 초과되었을 때 스위치의 스냅샷일 수 있다. 이와 같이, 이벤트는 사용-카운트들을 업데이트하는 것을 정지시키는 명령의 발행일 수 있다. 대안으로, 이벤트는 단순히 레지스터의 전용 비트를 설정하는 것일 수 있고, 이것은, 폴링될 때, 비트가 설정된 특정 스위치에 네트워크 관리자의 주의를 끌게 한다.

현실의 버퍼에서의 메커니즘을 알리는 것을 구현하는 것에 추가하여, 유사한 메커니즘은 가상 큐들에서 구현될 수 있다. 따라서, 실제 큐(또는 현실의 물리적 포트)를 모니터링하는 것보다, 가상 큐는, 예를 들어, 토큰 버킷 미터(token bucket meter)를 이용하여 구현될 수 있다. 토큰 버킷 미터는 관련 기술 분야에서 알려져 있으므로, 여기서는 간략한 논의만 제공된다. 가상 큐는 실제 큐의 행동을 그림자처럼 따라 다님에 의해 실제 큐를 모방한다. 그러나, 가상 큐가 실제 큐보다 더 느린 레이트(rate)로 비우도록(drain) 구성될 수 있으므로, 가상 큐의 사용-카운트는 실제 큐의 사용-카운트들보다 더 빠르게 누적될 수 있다. 이것은 잠재적 문제들의 더 빠른 감지를 야기하고, 또한 큐 증가로부터의 임의의 레이턴시(latency) 영향을 줄이거나 제거한다.

간단한 개요를 제공하면서, 도면들에 도시된 실시예들의 설명에 대해 참조가 지금 자세히 만들어진다. 몇몇 실시예들이 이 도면들과 관련되어 설명되지만, 본 발명을 여기 제시된 실시예 또는 실시예들에 한정하려는 것은 아니다. 반대로, 모든 대안들, 변형들, 및 등가물들을 포함하려는 것이다.

도 1은 버퍼 통계에 기반하여 스위치가 이벤트를 트리거하는 방법의 일 실시예를 보여주는 흐름도이다. 도 1에 도시된 바와 같이, 프로세스는 모니터될 통계의 타입(예를 들어, 현재 사용-카운트, 최대 사용-카운트 등)의 결정(110)으로 시작한다. 통계의 타입의 결정(110)을 위한 프로세스의 일 실시예가 도 2를 참조하여 보여진다.

통계의 타입이 결정되면(110), 스위치(여기서는 스위치 그 자체로 단순히 지칭됨)에 대한 버퍼 통계 모니터링 메커니즘은 그 통계에 대한 사용-카운트를 트래킹한다(120). 트래킹 메커니즘은 사용-카운트를 연속적으로 증가시키는 증가의 카우트-레지스터 만큼 단순할 수 있다. 사용-카운트를 트래킹하는(120) 방법의 일 실시예는 도 3을 참조하여 보여진다.

스위치는 그리고는 트래킹된 사용-카운트를 임계치 레지스터에 저장될 수 있는 임계치와 비교한다(130). 사용-카운트가 임계치를 초과하지 않으면, 시스템은 사용-카운트를 계속해서 트래킹한다(120). 그 대신에, 사용-카운트가 임계치를 초과하면, 시스템은 이벤트(예를 들어, 하드웨어 중단, 시스템 스냅샷 등)를 트리거한다(140). 이벤트를 트리거하는(140) 프로세스의 일 실시예는 도 4를 참조하여 보여진다.

이때에, 받아들일 수 있는 성능을 획득하기 위해, 네트워크 관리자 또는 운영자는 종종 트래픽-의존적인 MMU 버퍼 입장 설정들을 조정할 필요가 있을 수 있다는 것에 주목할 가치가 있다. 다시 말해서, 이벤트-트리거드 메커니즘의 성능은 적절한 임계치 값을 설정하는 것에 의존한다. 예를 들어, 임계치 값이 너무 높게 설정되면, 사용-카운트는 이벤트를 트리거하지 않고 손쉽게 위급한(alarming) 값을 초과할 수 있다. 대신에, 임계치가 너무 낮게 설정되면, 받아들일 수 있는 (및 정상의) 사용-카운트들조차도 불필요하게 이벤트를 트리거할 수 있다.

이벤트가 트리거되면(140), 시스템은 네트워크 관리자가 사용-카운트들을 리셋하기를 기다리고(150), 리셋(reset) 명령이 발행되면 사용-카운트들을 리셋한다(160). 사용-카운트들을 리셋한(160) 직후에, 시스템은 사용-카운트들을 트래킹하는 단계(120)로 돌아간다.

위에서 언급된 바와 같이, 도 2는 트래킹을 위한 버퍼 통계를 선택하는 방법의 일 실시예를 보여주는 흐름도이다. 도 2에 도시된 바와 같이, 시스템은 네트워크 관리자가 현재 사용-카운트를 모니터하기를 원하는지 여부를 결정한다(210). 그렇다면, 시스템은 현재 사용-카운트를 트래킹한다(220). 대신에, 네트워크 관리자가 최대 사용-카운트에 기반하여 이벤트들을 트리거하고 경보를 발하기를 원하면, 시스템은 최대 사용-카운트를 트래킹한다(230). 사용-카운트들의 트래킹은 도 3을 참조하여 더 자세히 도시된다.

도 3에 도시된 바와 같이, 스위치는 이그레스 사용-카운트들(310), 인그레스 사용-카운트들(340), 기기 사용-카운트들(370), 또는 이 사용-카운트들 모두의 조합을 트래킹한다. 이것을 하기 위해, 스위치는 그것이 이그레스 사용-카운트들을 트래킹해야 하는지를 결정하고(320), 그렇다면 이그레스 사용-카운트를 트래킹한다(330). 이그레스 사용-카운트들을 트래킹하는(330) 방법의 일 실시예는 도 5를 참조하여 도시된다. 스위치는 그것이 인그레스 사용-카운트들을 트래킹해야 하는지를 결정하고(350), 그렇다면 홀로 또는 이그레스 사용-카운트들의 트래킹(310)과 결합하여 인그레스 사용-카운트를 트래킹한다(360). 인그레스 사용-카운트들을 트래킹하는(360) 방법의 일 실시예는 도 6을 참조하여 도시된다. 스위치는 그것이 기기 사용-카운트들을 트래킹해야 하는지를 결정하고(380), 그렇다면 홀로 또는 이그레스 및 인그레스 사용-카운트들의 트래킹(310, 330)과 결합하여 기기 사용-카운트를 트래킹한다(390). 알 수 있는 바와 같이, 트래킹할 사용-카운트 파라미터들은 융통성이 있다.

도 4는 스위치에서 이벤트를 트리거하는 방법의 일 실시예를 보여주는 흐름도이다. 대략, 이벤트는 프로세서 중단(410), 시스템 스냅샷(440), 또는 단순히 레지스터의 전용 비트의 트리거링(470)일 수 있다. 몇몇 실시예들에 대해, 이벤트는 선택적인 시스템 스냅샷을 지닌 중단 트리거, 또는 선택적인 시스템 스냅샷을 지닌 전용 비트("스티키(sticky) 비트")를 설정하는 것일 수 있다. 일 실시예에서, 스위치는 중앙 처리 장치(CPU) 중단이 발행되어야 하는지 여부를 결정하고(420), 그렇다면, CPU 중단을 발행한다(430). 중단은 네트워크 관리자에게 특정 사용-카운트가 임계치를 초과했다는 것을 경보를 발한다. 스위치는 다음에 그것이 스위치 버퍼들 통계의 스냅샷을 찍어야 하는지 여부를 결정하고(450), 그렇다면, 사용-카운트들을 업데이트하는 것을 정지시키는 명령을 발행한다(460). 시스템 스냅샷(440)은 홀로 또는 CPU 중단(410)과 결합하여 수행될 수 있다. 스위치는 또한 이벤트를 트리거링하는 것(480)에 대응하여 레지스터의 전용 비트를 설정하도록(490) 구성될 수 있다. 이 전용 비트는 그것의 대응하는 임계치를 초과하는 사용-카운트를 가리킨다. 따라서, 관리자에게 다루기 힘든 양의 정보를 제공하는 대신에, 각각의 스위치에 대한 하나의 전용 비트는 네트워크 관리자에 의해 쉽게 소화될 수 있는 관리하기 쉬운 양의 정보를 제공한다.

도 5는 스위치의 이그레스 통계를 트래킹하는(310) 방법의 일 실시예를 보여주는 흐름도이다. 위에서 언급된 바와 같이, 다양한 이그레스-관련 통계가 큐 당 트래킹될 수 있다. 구현에서, 이 큐 당(per-queue) 정보는 유니캐스트(UC, unicast) 당(per-unicast) 또는 멀티캐스트(MC, multicast) 당(per-multicast) 기반으로 더 분리될 수 있다. 도 5는 UC 및 MC 큐들이 분리되는 일 실시예를 제공한다. 그러나, 이런 입도(granularity)의 미세한 레벨이 일반적으로는 필요하지 않다는 것은 이해되어야 한다. 도 5에 도시된 바와 같이, 이그레스 유니캐스트(UC) 사용-카운트들을 모니터하기로 한 결정(510)은 스위치가 이그레스 UC 큐 사용-카운트를 트래킹하도록(515) 한다. 유사하게, 이그레스 큐-그룹 공유된 사용-카운트들을 모니터하기로 한 결정(520)은 스위치가 이그레스 큐-그룹 공유된 사용-카운트들을 트래킹하도록(525) 한다. 이그레스 포트 사용-카운트들, 이그레스 멀티-캐스트(MC) 버퍼 풀(BP, buffer pool) 사용-카운트들, 이그레스 UC 플러스 MC(UC+MC) BP 사용-카운트들, 및 이그레스 CPU 사용-카운트들에 대한 유사한 결정들(530, 540, 550, 560)은 스위치가 그 사용-카운트들을 트래킹하도록(535, 545, 555, 565) 한다. 다시 말해서, 네트워크 관리자의 필요 또는 바램에 기반하여 이 사용-카운트들 중 하나 이상이 트래킹된다.

도 5에서 이그레스 통계가 트래킹되는(310) 방법과 유사하게, 인그레스 통계 트래킹(340)은 도 6의 흐름도를 통해 도시된다. 스위치는 다음 사용-카운트들: 인그레스 우선순위 그룹(PG, priority group) UC+MC 사용-카운트들, 인그레스 포트 PG 헤드룸(headroom) 사용-카운트들, 인그레스 포트 BP UC+MC 공유된 사용-카운트들, 및 인그레스 BP UC+MC 공유된 사용-카운트들 중 하나 이상을 모니터링해야 하는지 여부를 결정한다(610, 620, 630, 640). 그 후에, 스위치는 원하는 사용-카운트들을 트래킹한다(615, 625, 635, 645). 도 5를 참조하여 언급된 바와 같이, UC 및 MC는 분리될 필요가 없으나, 대신에, 모니터링은 큐-당 기반으로 수행될 수 있다.

알 수 있는 바와 같이, 복수의 상이한 변수들이 스위치에 의해 모니터될 수 있다. 그리고, 임계치(또는 경보(alarm) 레벨)을 초과하는 특정 변수에 대응하여, 스위치는 네트워크 관리자에게 경보를 발하는 하드웨어 이벤트를 트리거한다.

버퍼 통계에 기반하여 이벤트를 트리거하는 방법을 일반적으로 설명하는 데 추가하여, 이 제시는 또한 카운트 레지스터들에 대한 특정 파라미터들 및 버퍼 통계의 트래킹을 구현하기 위한 값들을 제공한다. 현재 사용-카운트들 또는 최대 사용-카운트들을 저장할지 여부에 대한 결정은 1-비트 레지스터에 기반할 수 있고, 여기서, 0-값은 현재 사용-카운트들을 트래킹하고 1-값은 최대 사용-카운트들을 트래킹한다. 유사하게, 1-비트 트래킹-인에이블(enable) 비트는 1-값은 사용-카운트들을 계속해서 업데이트하는 반면 0-값은 사용-카운트들을 업데이트하거나 캡처링(capturing)하는 것을 정지하도록 설정될 수 있다.

버퍼 통계 또는 사용-카운트 값들은 오히려 레지스터에 저장되고, 여기서 각각의 레지스터의 연속적인 증가는 사용-카운트들, 버퍼들의 유닛들에서의 증가를 나타낸다. 당업자는 카운트 사이즈가 가장 나쁜- 경우 전체 버퍼 사용을 다루기에 충분해야 한다는 것을 이해할 것이다. 또한, 프로파일(profile) 인덱스는 어느 임계치가 어느 사용-카운트 값에 대응하는지를 식별하기 위해 사용될 수 있다.

각각의 트리거링 이벤트들은 또한 1-비트 값에 의해 식별될 수 있다. 따라서, 예를 들어, 하드웨어 중단에 대한 0-값은 CPU 중단이 발행되지 않을 것을 지시할 수 있고, 반면, 1-값은 CPU 중단의 발행을 야기한다. 유사하게, 스냅샷에 대한 0-값은 사용-카운트들의 계속적 업데이트들을 야기할 수 있고, 반면에 시스템 스냅샷에 대한 1-값은 사용-카운트가 정지할 것을 야기할 수 있다.

각각의 트리거링 이벤트에 대해, 레지스터는 어떤 타입의 사용-카운트(예를 들어, 이그레스 큐 전체, 이그레스 큐-그룹 공유된, 이그레스 포트 BP 공유된, CPU 큐 전체 등)가 이벤트를 트리거했는지를 나타내기 위해 사용될 수 있고, 반면에 다른 레지스터는 이벤트를 트리거하는 것을 일으킨 포트, 풀 또는 큐의 식별을 제공한다. 포트 번호들 및 버퍼 풀들에 기반한 트리거들에 대해, 8-비트 레지스터가 이용될 수 있고, 여기서 처음 6 비트는 포트 번호를 나타내고, 반면 나머지 2 비트는 풀 번호를 나타낸다. 알 수 있는 바와 같이, 이 정보를 저장하는 레지스터의 사이즈는 사용-카운트들의 타입들, 사용-카운트들의 최대값들, 사용-카운트들을 트리거한 기기들의 개수 등을 수용하기 위해 커스터마이즈(customize)될 수 있다. 이 사용-카운트 레지스터들을 구성할 수 있는 무수한 방법들이 있으므로, 당업자가 위에서-언급된 설명으로부터 사용-카운트 레지스터들을 손쉽게 구현할 수 있으므로, 특정 비트-값들을 지닌 추가적인 예들은 여기서 생략된다.

사용-카운트들이 이벤트를 트리거하기 위해 사용되는 프로시져(procedure)를 구현함에 의해, 네트워크 관리자는 모든 스위치들에 대한 모든 버퍼 통계를 폴링하지 않고 더 세밀한 입자에 대해 패킷-스위칭 네트워크가 수행하는 방법을 손쉽게 검사할 수 있다. 이 타입의 트래킹 메커니즘은 네트워크 성능의 더 간결한 리뷰를 허용하고, 따라서 네트워크 관리자가 시스템 성능을 최적화하도록 네트워크 구성요소들을 재구성하도록 허용한다.

메모리 관리 유닛(MMU)은 하드웨어, 소프트웨어, 펌웨어(firmware), 또는 그들의 조합으로 구현될 수 있다. 선호되는 실시예(들)에서, MMU는 관련 분야에서 잘 알려진 다음 기술들: 데이터 신호들에 대해 논리 기증들을 구현하기 위한 논리 게이트(gate)들을 갖는 별개의 논리 회로(들), 적절한 결합의 논리 게이트들을 갖는 어플리케이션 특정 통합 회로(ASIC, application specific integrated circuit), 프로그래머블 게이트 어레이(들)(PGA, programmable gate array(s)), 필드 프로그래머블 게이트 어레이(FPGA, field-programmable gate array) 등의 임의의 것 또는 조합을 이용하여 하드웨어로 구현된다. 대안적인 실시예에서, MMU는 메모리에 저장되고 적절한 명령 실행 시스템에 의해 실행되는 소프트웨어 또는 펌웨어로 구현된다.

흐름도의 임의의 프로세스 설명들 또는 블록들은 프로세스에서 특정 논리 기능들 또는 단계들을 구현하기 위한 하나 이상의 실행가능한 명령들을 포함하는 모듈들, 세그먼트들 또는 코드의 일부들을 나타내는 것으로 이해되어야 하고, 본 제시의 관련 분야의 당업자에 의해 이해될 바와 같이, 실질적으로 동시 또는 반대 순서를 포함하여 도시되거나 논의된 것과 다른 순서로 기능들이 실행될 수 있는 대안적인 구현들은 본 제시의 선호되는 실시예의 범위 내에 포함된다.

이벤트들의 트리거링은 논리 기능들을 구현하기 위한 실행가능한 명령들의 순서화된 리스트를 포함하는 하드웨어 또는 소프트웨어 코드에 의해 실행될 수 있고, 명령 실행 시스템, 장치, 또는 기기 예를 들어, 컴퓨터-기반 시스템, 프로세서-포함 시스템, 또는 명령 실행 시스템, 장치 또는 기기로부터 명령들을 불러와서 명령들을 실행할 수 있는 다른 시스템에 의해 또는 결합하여 사용되기 위한 임의의 컴퓨터-판독가능 매체로 구현될 수 있다. 이 문서의 맥락에서, "컴퓨터-판독가능 매체"는 명령 실행 시스템, 장치 또는 기기에 의해 또는 결합하여 사용을 위한 프로그램을 포함하거나, 저장하거나, 전달하거나, 전파하거나 전송할 수 있는 임의의 수단일 수 있다. 컴퓨터-판독 가능 매체는 예를 들어, 전자, 마그네틱, 광, 전자기, 적외선, 또는 반도체 시스템, 장치 기기, 또는 전파 매체일 수 있으나, 이에 한정되지 않는다. 컴퓨터-판독가능 매체의 더 특정한 예들(완벽하지 않은 리스트)은 다음: 하나 이상의 와이어(wire)들을 갖는 전기 연결(전자), 포터블(portable) 컴퓨터 디스켓(마그네틱), 임의 접속 메모리(RAM, random access memory)(전자), 판독 전용 메모리(ROM, read-only memory)(전자), 소거 가능한 프로그래머블 판독 전용 메모리(erasable programmable read only memory)(EPROM 또는 플래시 메모리)(전자), 광섬유(광), 및 포터블 컴팩트 디스크(compact disc) 판독 전용 메모리(CDROM)(광)을 포함할 수 있다. 프로그램은 예를 들어, 종이 또는 다른 매체의 광 스캐닝을 통해 전자적으로 캡쳐되어, 필요하다면 적절한 방법으로 컴파일(compile)되거나, 해석되거나, 또는 그렇지 않으면 프로세스된 후, 컴퓨터 메모리에 저장될 수 있으므로, 컴퓨터-판독 가능 매체는 심지어 종이 또는 프로그램이 프린트될 수 있는 다른 적절한 매체일 수 있다.

예시적인 실시예들이 보여지고 설명되었지만, 설명된 바와 같이 본 제시에 대한 많은 변경들, 수정들 또는 대안들이 만들어질 수 있다는 것은 당업자에게 명확할 것이다. 예를 들어, 여기서 사용-카운트가 논의되나, 패킷 레이트들도 유사한 방법으로 모니터될 수 있다는 것은 이해되어야 한다. 따라서, 모든 이런 변경들, 수정들 및 대안들은 본 제시의 범위 이내인 것으로 간주되어야 한다.

Claims

시스템으로서,
버퍼와 관련된 사용-카운트(use-count)를 저장하는 사용-카운트 레지스터;
상기 사용-카운트에 대응하는 임계치를 저장하는 임계치 레지스터; 및
상기 사용-카운트를 상기 임계치와 비교하는 메모리 관리 유닛(MMU, memory management unit)을 포함하고, 상기 MMU는 상기 사용-카운트가 상기 임계치를 초과할 때 이벤트를 트리거(trigger)하는, 시스템.
제1항에 있어서, 상기 사용-카운트 레지스터는 이그레스(egress) 사용-카운트를 더 저장하는, 시스템.
제2항에 있어서, 상기 이그레스 사용-카운트는:
이그레스 유니캐스트(UC, egress unicast) 큐(queue) 사용-카운트;
이그레스 큐-그룹 공유된 사용-카운트;
이그레스 포트 사용-카운트;
이그레스 멀티캐스트(MC, egress multicast) 버퍼-풀(BP, buffer-pool) 사용-카운트;
이그레스 UC 플러스 MC(UC+MC) BP 사용-카운트들; 및
이그레스 중앙 처리 장치(CPU, central processing unit) 큐 사용-카운트를 포함하는 그룹으로부터 선택된 적어도 하나인, 시스템.
청구항 1 내지 3 중 어느 한 항에 있어서, 상기 사용-카운트 레지스터는 인그레스 사용-카운트를 더 저장하는, 시스템.
청구항 4에 있어서, 상기 인그레스 사용-카운트는:
인그레스 포트 및 우선순위 그룹(PG, priority group) 유니캐스트 플러스 멀티캐스트(UC+MC) 공유된 사용-카운트;
인그레스 포트 PG 헤드룸(headroom) 사용-카운트;
인그레스 포트 버퍼 풀(BP) UC+MC 공유된 사용-카운트; 및
인그레스 BP UC+MC 공유된 사용-카운트를 포함하는 그룹으로부터 선택된 적어도 하나인, 시스템.
청구항 1 내지 5 중 어느 한 항에 있어서, 상기 사용-카운트 레지스터는 기기 사용-카운트를 더 저장하는, 시스템.
청구항 1 내지 6 중 어느 한 항에 있어서, 상기 이벤트는 하드웨어 중앙 처리 장치(CPU) 중단(interrupt)인, 시스템.
청구항 1 내지 7 중 어느 한 항에 있어서, 상기 이벤트는 상기 사용-카운트를 업데이트하는 것을 정지시키는 명령인, 시스템.
청구항 1 내지 8 중 어느 한 항에 있어서, 상기 이벤트는 전용 비트(dedicated bit)가 상기 사용-카운트가 상기 임계치를 초과했다는 것을 표시하도록 설정되는 것인, 시스템.
네트워크 스위치에서의 방법으로서,
버퍼와 관련된 사용-카운트를 트래킹하는 단계;
상기 트래킹된 사용-카운트가 미리 정의된 임계치를 초과하는지 여부를 결정하는 단계; 및
상기 사용-카운트가 상기 미리 정의된 임계치를 초과하면 이벤트를 트리거(trigger)하는 단계를 포함하는, 방법.
청구항 10에 있어서, 상기 이벤트를 트리거하는 단계는:
중앙 처리 장치(CPU, central processing unit) 중단(interrupt)을 발행하는(issue) 단계를 포함하는, 방법.
청구항 10 또는 11에 있어서, 상기 이벤트를 트리거하는 단계는:
상기 사용-카운트의 업데이트를 정지하는 단계를 포함하는, 방법.
청구항 10 내지 12 중 어느 한 항에 있어서, 상기 이벤트를 트리거하는 단계는:
전용 비트가 상기 사용-카운트가 상기 미리 정의된 임계치를 초과한다는 것을 표시하도록 설정하는 단계를 포함하는, 방법.
청구항 10 내지 13 중 어느 한 항에 있어서, 상기 사용-카운트를 트래킹하는 단계는:
이그레스 사용-카운트를 트래킹하는 단계를 포함하는, 방법.
버퍼를 갖는 스위치에서의 방법으로서,
(a) 통계의 타입을 결정하는 단계로서, 상기 통계의 타입은:
(a1) 현재 사용-카운트; 및
(a2) 최대 사용-카운트로 구성된 그룹으로부터 선택된 적어도 하나인, 결정하는 단계;
(b) 상기 결정된 통계의 타입에 대한 사용-카운트를 트래킹하는 단계로서, 상기 사용-카운트는:
(b1) 이그레스 사용-카운트;
(b2) 인그레스 사용-카운트; 및
(b3) 기기 사용-카운트로 구성된 그룹으로부터 선택된 적어도 하나인, 트래킹하는 단계;
(c) 상기 사용-카운트에 대응하는 임계치와 비교하는 단계; 및
(d) 상기 사용-카운트가 상기 대응하는 임계치를 초과하면 이벤트를 트리거하는 단계를 포함하는, 방법.