KR100343905B1 - 네트워크 구성요소 관리 방법 - Google Patents

Abstract

본 발명은 근거리 통신망(local area network), 월드 와이드 웹(world wide web) 또는 인터넷과 같은 컴퓨터 인터넷을 포함하는 특정 통신 링크를 통하여 원격 통신 네트워크의 다수의 네트워크 구성요소를 원격 관리하는 방법에 관한 것이다. 관리 컴퓨터는 컴퓨터 인터넷을 포함하는 통신 링크를 통하여 구성요소 관리 시스템 서버에 접속된다. 또한, 다수의 네트워크 구성요소 중 적어도 하나는 컴퓨터 인터넷을 통해 구성요소 관리 서버에 접속되고, 다수의 네트워크 구성요소 중 적어도 하나는 관리 컴퓨터와 적어도 하나의 네트워크 구성요소 사이의 구성요소 관리 서버를 통해 전달되는 통신을 통하여 관리된다. 바람직하게, 관리는 적어도 하나의 네트워크 구성요소의 관리와 관련된 객체를 갖는 클라이언트 워크스테이션에서 대화형 웹 페이지를 생성하는 관리 서버에 의해 가능하게 된다. 대화형 웹 페이지는 컴퓨터 인터넷을 통해 관리 서버로부터 관리 컴퓨터로 송신되고, 관리 컴퓨터와 네트워크 구성요소 사이의 관리 통신을 위해 관리 컴퓨터의 대화형 웹 페이지에서 디스플레이된다. 대화형 웹 페이지의 객체는 바람직하게는 네트워크의 구성요소의 작업(operation), 관리(administration), 보존(maintenance) 모두와 관련된 객체를 포함한다. 대화형 웹 페이지는 원격 통신 네트워크의 각 네트워크 구성요소를 위한 상세 상태 요약 페이지(detailed status summary page)와 다수의 네트워크 구성요소 모두의 비교적 주요한 시스템의 상태 요약(relatively high system status summary)과 원격 통신 네트워크 내의 모든 액티브 알람의 리스트를 포함한다. 다수의 네트워크 구성요소 각각은 구성요소 관리 서버를 네트워크 구성요소에 인터페이스하는 관리 중개자 애플리케이션(management agent application)을 가진 관련 애플리케이션 프로세서를 구비한다. 애플리케이션 프로세서는 선택적으로 보존 태스크를 수행하기 위하여 구성요소 관리 서버로부터 관리 중개자 애플리케이션을 통해 보존 애플리케이션(maintenance application)으로 인터페이스되는 네트워크 구성요소 커맨드 요청(network element command request)의 보존을 수행하는 보존 애플리케이션을 포함한다. 구성요소 관리 서버는 애플리케이션 프로세서 특정 이벤트(application processor specific event)와 커맨드 승인(command acknowledgment)을 구비한다.

Description

네트워크 구성요소 관리 방법{METHOD FOR COMPUTER INTERNET REMOTE MANAGEMENT OF A TELECOMMUNICATION NETWORK ELEMENT}

본 발명은 전반적으로 원격 통신 네트워크에 관한 것으로, 보다 상세하게는 원격 통신 네트워크의 네트워크 구성요소를 관리하는 것에 관한 것이다.

관리 컴퓨터 또는 워크스테이션이 관리 컴퓨터 프로그램 또는 관리 애플리케이션을 실행하여, 해당 네트워크 구성요소 세트와 관련된 관리 중개자(agent) 컴퓨터 프로그램 세트나 관리 중개자를 관리하는 네트워크 관리 시스템이 주지되어 있다. 이러한 주지의 관리 시스템은 관리 애플리케이션과 네트워크 구성요소 사이의 인터페이스를 정의하는 각각의 네트워크에 대해 관리 정보 기반(management information base)을 채용하는 통신 프로토콜을 이용하고 있다. 이러한 관리 시스템은 개개의 네트워크 구성요소에서만 구현될 수 있으며, 원격 통신 네트워크를 대규모로 관리하는 데에는 성공적으로 이용되지 못해 왔다.

본 발명에 따르면, 컴퓨터 인터넷을 포함하는 특정 통신 링크를 통하여 원격통신 네트워크의 네트워크 구성요소를 원격 관리하는 방법이 제공된다. 관리 컴퓨터는 컴퓨터 인터넷을 포함하는 통신 링크를 통하여 구성요소 관리 시스템 서버에 접속된다. 또한, 다수의 네트워크 구성요소 중 적어도 하나는 컴퓨터 인터넷을 통해 구성요소 관리 서버에 접속되고, 그 다수의 네트워크 구성요소 중 적어도 하나는 관리 컴퓨터와 적어도 하나의 네트워크 구성요소 사이의 구성요소 관리 서버를 통하여 전달되는 통신을 통하여 관리된다.

바람직하게, 관리는, 클라이언트 워크스테이션에서 적어도 하나의 네트워크 구성요소의 관리와 관련된 객체를 갖는 대화형 웹 페이지(interactive web page)를 생성하는 관리 서버에 의해 가능하게 된다. 대화형 웹 페이지는 컴퓨터 인터넷을 통해 관리 서버로부터 관리 컴퓨터로 송신되고, 관리 컴퓨터와 네트워크 구성요소 사이의 관리 통신을 위해 관리 컴퓨터의 대화형 웹 페이지에서 디스플레이된다. 대화형 웹 페이지의 객체는 바람직하게는 네트워크 구성요소의 작업(operation), 관리(administration), 보존(maintenance) 이들 세 가지 모두와 관련된 객체를 포함한다.

본 발명의 일 실시예에서, 대화형 웹 페이지는 원격 통신 네트워크의 각 네트워크 구성요소에 대한 세부 상태 요약 페이지(detailed status summary page), 모든 다수의 네트워크 구성요소에서 비교적 주요한 시스템의 상태 요약(relatively high system status summary), 원격 통신 네트워크 내의 모든 액티브 알람의 리스트를 포함한다.

다수의 네트워크 구성요소 각각은 구성요소 관리 서버를 네트워크 구성요소에 인터페이스하는 관리 중개자 애플리케이션(management agent application)을 가진 관련 애플리케이션 프로세서를 구비한다. 애플리케이션 프로세서는 선택적으로 보존 태스크를 수행하기 위하여 구성요소 관리 서버로부터 관리 중개자 애플리케이션을 통해 보존 애플리케이션(maintenance application)으로 인터페이스되는 네트워크 구성요소 커맨드 요청(network element command request)의 보존을 수행하는 보존 애플리케이션을 포함한다. 구성요소 관리 서버는 애플리케이션 프로세서 특정 이벤트(application processor specific event)와 커맨드 승인(command acknowledgment)을 구비한다.

바람직하게, 컴퓨터 인터넷은 월드 와이드 웹이며, 인터넷, 커넥션, 통신은 관리 컴퓨터와 구성요소 관리 서버에서 월드 와이드 웹 기반 JAVA 애플리케이션의 작업을 통해 달성된다. 이와는 달리, 컴퓨터 인터넷은 근거리 네트워크일 수 있다. 이러한 방식으로, 상이한 원격지에 있는 다수의 관리 컴퓨터는 원격 통신 네트워크의 임의의 모든 네트워크 구성요소와 임의의 네트워크 구성요소를 액세스할 수 있다. 다수의 상이한 관리 컴퓨터로부터 동시에 수신된 다수의 커맨드는 큐잉(queueing)되고, 다수의 커맨드는 상이한 관리 컴퓨터 중 그 해당 커맨드를 발생시킨 적절한 하나로만 응답을 송신함으로써 다수의 커맨드에 대하여 응답된다. 관리 컴퓨터와 특정 구성요소 관리 서버 사이의 커넥션은 바람직하게 관리 컴퓨터에서의 올바른 패스워드(password) 입력에 응답하여 인에이블된다. 바람직하게, 패스워드는 암호화된 후 구성요소 관리 서버로 송신된다.

따라서, 본 발명은 또한 네트워크 구성요소의 커맨드, 제어, 고장 관리를 위해 다수의 상이한 워크스테이션에서 관리 애플리케이션을 선택적으로 실행하고, 컴퓨터 인터넷을 통하여 구성요소 관리 서버를 다수의 상이한 워크스테이션과 인터페이스하여 분산 네트워크 구성요소 관리 서비스를 다수의 워크스테이션 모두에 있는 관리 애플리케이션으로 제공하며, 네트워크 관리 서버와 네트워크 구성요소 사이의 컴퓨터 인터넷을 통한 커맨드 승인과 커맨드 요청을 통신하기 위해 네트워크 구성요소와 관련된 관리 중개자 애플리케이션을 통하여 네트워크 구성요소를 구성요소 관리 서버와 인터페이스하는 단계를 수행함으로써 다수의 상이한 원격 관리 컴퓨터로부터 다수의 네트워크 구성요소 모두를 관리하는 개념을 포함한다.

그러므로, 주지의 네트워크 구성요소 관리 시스템 및 방법의 결함을 극복하고, 원격 통신 시스템의 대규모 관리에 필요한 특징을 갖는 효율과 편의성을 향상시킨 분산 네트워크 관리 방법이 제공된다.

부록 A는 본 명세서에 포함된 용어의 정의와 머리 글자의 해설을 제공한다.

도 1a는 공중전화망(public switched telephone network : PSTN)을 통하여 원격 통신 네트워크의 다수의 네트워크 구성요소를 제어 또는 관리하기 위해 관리 컴퓨터 또는 워크스테이션을 채용한 네트워크 구성요소 관리 시스템의 실시예를 도시하는 기능적 블럭도,

도 1b는 컴퓨터 인터넷을 통하여 원격 통신 네트워크의 다수의 네트워크 구성요소를 제어 또는 관리하기 위해 관리 컴퓨터 또는 워크스테이션을 채용한 네트워크 구성요소 관리 시스템의 실시예를 도시하는 기능적 블럭도,

도 1c는 근거리 통신망을 통하여 원격 통신 네트워크의 다수의 네트워크 구성요소를 제어 또는 관리하기 위해 관리 컴퓨터 또는 워크스테이션을 채택한 네트워크 구성요소 관리 시스템의 실시예를 도시하는 기능적 블럭도,

도 2는 오프 더 셸프(off­the­shelf) 컴포넌트(component)와 전유 애플리케이션(proprietary application)을 갖는 웹 사용가능한 워크스테이션에서 네트워크 구성요소를 관리하는 구성요소 관리 시스템을 도시하는 기능적 블럭도,

도 3은 본 발명의 아키텍쳐의 주된 소프트웨어를 도시하는 기능적 블럭도,

도 4는 관련 네트워크 구성요소와 관련 단순 관리 프로토콜(simple management protocol : SNMP) 중개자를 구비하는 구성요소 관리 시스템 서버와 클라이언트 워크스테이션의 기능적 블럭도,

도 5는 구성요소 관리 시스템 클라이언트 구성(element management system client configuration)을 도시하는 기능적 블럭도,

도 6은 본 발명에 따른 관리 객체 모델(managed object model)과 관련된 용어의 테이블,

도 7은 애플리케이션 프로세스의 유도를 도시하는 기능적 블럭도,

도 8은 관리 객체 클래스와 애플리케이션 프로세스를 관리하는데 사용될 수 있는 컨테인먼트 관계(containment relationship)의 기능적 블럭도,

도 9는 통신을 위해 SNMP 이외의 프로토콜을 사용하는 네트워크 구성요소, AP, 서비스 객체 및 그에 포함된 데이터, ECP 관리 객체를 도시하는 블럭도,

도 10, 11, 12, 13은 본 발명에 따른 대표적 웹 페이지를 도시하는 도면,

도 14는 네트워크 구성요소, AP, 소프트웨어 아키텍쳐의 기능적 블럭도,

도 15는 구성요소 관리자 클라이언트 애플리케이션 프로그래밍 인터페이스를 도시하는 도면,

도 16은 클라이언트 애플리케이션과 상호작용하는 서버 상에 상주하는 서비스 객체를 도시하는 도면,

도 17은 EMAPI에서 정의된 콜백(callback) 인터페이스를 도시하는 도면,

도 18은 EMAPI에서 정의된 데이터 유형을 도시하는 도면,

도 19는 클라이언트, 애플리케이션, 특정 서비스 객체, 관리 객체 인스턴스(managed object instance)의 내부 서버 표시(internal server representation) 사이의 관계를 도시하는 도면,

도 20은 각각의 이벤트 범주에 유효한 필터 기준을 도시하는 도면,

도 21은 다수의 값 중 하나를 포함하는 EMAPI 예외 코드(exception code)를 이용하여 정의된 EMAPI 특정 예외(specific exception)를 도시하는 도면.

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

28 : 구성요소 관리 시스템 클라이언트

32 : 구성요소 관리 시스템 서버

44 : 자바 애플리케이션 동적 컨텐트 46 : 웹 서버

55 : EMAPI 58 : HTTP 웹 서버

60 : 오빅스 64 : 오빅스 명명 서비스

66 : 객체 서버 68 : 액티브 알람 관리자

70 : HPOV 프로세스 72 : ROP 포매터

76 : 커맨드 라인 해석기 78 : UX 프록시

79 : IDS 80 : 애플리케이션 프로세서

81 : SNMP 중개자 82 : ECP

86 : ECP 중개자 88 : 커맨드 처리기

90 : RAPs 92 : 텍스트 커맨드 해석기

94 : 이벤트 처리기 96 : NE 상태 테이블

98 : 기타 플랫폼 및 애플리케이션 소프트웨어

100 : RCC 104 : AP 상태 모니터

전술한 본 발명의 특징은 명확해질 것이고, 본 발명의 기타 특징은 몇몇 도면을 참조하여 주어지는 바람직한 실시예의 상세한 설명에서 설명될 것이다.

도 1a는 웹 사용가능한 워크스테이션(16)에서 네트워크 구성요소(14)를 관리하는 방법을 보여주는 시스템(10)을 도시한다. 구성요소 관리 시스템 클라이언트(28)와 관련된 관리 컴퓨터(26)는 공중전화망(public switched telephone network : PSTN)(33)을 통하여 네트워크 구성요소(14)와 구성요소 관리시스템 클라이언트(32)에 접속된다.

도 1b는 웹 사용가능한 워크스테이션(16)에서 전화 네트워크 내의 네트워크 구성요소(14)를 관리하는 방법을 보여주는 시스템(34)을 도시한다. 네트워크 구성요소(14)는 전화 컴퓨터 네트워크(35)를 통하여 컴퓨터 인터넷(36)에 접속된다. 구성요소 관리 시스템 클라이언트(28)와 관련된 관리 컴퓨터(26)는 전화 시스템 네트워크(37)를 거쳐 컴퓨터 인터넷(36)과 전화 링크(38)를 통하여 구성요소 시스템 관리 시스템 서버(32)에 접속된다.

도 1c는 근거리 네트워크(42)를 통해 구성요소 관리 시스템과 관련된 구성요소 관리 시스템 클라이언트(28)를 이용하여 관리 컴퓨터(26)에서 네트워크 구성요소(14)의 관리가 수행되는 시스템(40)을 도시한다.

본 발명에 따른 방법은 오프 더 셸프(off­the­shelf) 기법의 레버(leveraging)를 인에이블시켜서 상품의 비용을 거의 증가시키지 않거나 전혀 증가시키지 않고 후속 해제(release)와 기타 프로젝트(project)로 확장하면서, 추가적인 클라이언트 가시적 특징(additional client visible feature)을 인에이블시킨다.

도 2를 참조하면, 네트워크 구성요소(14)는 구성요소 관리 시스템 클라이언트(28)와 SNMP 기반 구성요소 관리 플랫폼을 통해 제공된다. 본 발명에 따른 방법은 오프 더 셸프 컴포넌트(44, 45, 46, 47, 48, 49)와 전유(propriety) 애플리케이션(50, 52, 54, 55, 56)을 이용하여 작업한다. 오프 더 셸프 기법은 HTML과 Java 애플리케이션(44), 웹 브라우저(45), 웹 서버(46), 전송 프로토콜[TCP/IPUDP/IP](47), 코바(CORBA)(48), SNMP 구성요소 관리 플랫폼(HP Open View Network Node Manager [HPOVNNM])(49) 또는 카네기 멜론 대학(Carnegie­Mellon University : CMU) SNMP 라이브러리, 전송 프로토콜(TCP/IP 프로토콜 모음(suite))을 포함한다.

클라이언트는 웹 페이지를 통해 클라이언트 인터페이스와 전유 애플리케이션을 실행한다. 마이크로소프트 인터넷 익스플로러(Microsoft Internet Explorer)와 넷스케이프 브라우저(Netscape browser)는 PC와 X 터미널(X­terminal)을 위한 웹 사용가능한 디바이스와 같이 지원된다. 웹 기반 그래픽 클라이언트 인터페이스를 통해, 클라이언트의 커맨드는 구성요소 관리 시스템 서버로 HTTP 요청을 생성한다. 서버는 정보를 수집하고, 웹 페이지를 동적으로 생성하며, 그 결과/출력을 웹 브라우저로 보내 디스플레이한다.

클라이언트 애플리케이션(JAVA Applets)은 액티브 알람 리스트 브라우저, 시스템 알람 요약, 네트워크 구성요소 세부 상태 디스플레이와 같은 전유 애플리케이션을 포함한다. 클라이언트 애플리케이션은 분산 객체 요청 아키텍쳐(CORBA)(48)를 통해 구성요소 관리자 API(element manager API : EMAPI)(55)와의 객체 지향 인터페이스(object oriented interface)에 의하여 서버와 통신한다. 이 인터페이스는 네트워크 내의 모든 관리 객체에 대한 지속적인 인터페이스를 제공하고 구성요소 관리 플랫폼과 관련된 구현 세부 사항을 은폐한다.

구성요소 관리 시스템 서버(32)는 애플리케이션을 실행하여 코바 미들웨어(middleware)를 통해 클라이언트에게 정보를 제공한다. 코바는 서버의 기능을 위하여 IPC로 작용하여 구현으로부터 임의의 플랫폼 특정(platform­specific) IPC를 제거하며, 장래에 작업을 위해 필요하다면 다수의 프로세서에 기능(functionality)이 분산되도록 한다. 구성요소 관리 시스템과 관리 구성요소 사이의 통신은 SNMP를 통해 이루어진다. 시스템 상태는 SNMP 폴링(polling)과 감사(audit)를 통해 얻어지고, SNMP 트랩은 실시간 통지를 위해 사용되며, SNMP 세트는 커맨드와 제어를 위해 사용된다. 구성요소 관리 시스템은 시스템 부팅(system boot) 동안 지속적으로 저장하지 못하고, 구성요소 관리 시스템이 초기화될 때 각각의 네트워크 구성요소와의 핸드쉐이크(handshake)를 필요로 하지만, 다수의 클라이언트에 의한 사용을 위해 정보를 저장하므로, 새로운 클라이언트로부터의 각 요청을 위해 이 정보를 가지고 있을 필요는 없다. 커맨드와 알람 출력은 실행 제어 프로세서 독출 전용 프린터(executive control processor read only printer)로 제공됨은 물론, 웹 브라우저 기반 디스플레이를 통해 디스플레이된다.

네트워크 구성요소(14)는 SNMP를 통해 이벤트와 알람을 구성요소 관리 시스템으로 통지하는 것을 처리하고, 애플리케이션으로부터 정보를 얻기 위해 커맨드를 발생시키는 역할을 한다. 관리 정보 기반(management information base : MIB)(56) 컨벤션(convention)은 시스템 내의 네트워크 구성요소를 관리하기 위해 정의된다. 이 MIB(56) 컨벤션은 커맨드 실행, 메시지 시퀀싱(message sequencing), 감사 공급(audit provision)을 정의하는데, 이들은 구성요소 관리 시스템 아키텍쳐 내에서 사용되며 SNMP를 위해 제공되지는 않는다.

도 3에 도시한 본 발명의 소프트웨어 컴포넌트의 기능적 블럭도의 설명은 다음과 같다.

구성요소 관리 서버 소프트웨어 컴포넌트(Element Management Server Software Components)

구성요소 관리 시스템 클라이언트(28)는 구성요소 관리 시스템 서버(32)에 대한 클라이언트의 인터페이스이다. 구성요소 관리 시스템 클라이언트(28)는 웹 브라우저(45)와 JAVA 애플릿(44)으로 이루어진다.

·웹 브라우저 : 웹 브라우저(45)는 최종 클라이언트, JAVA 애플릿(44)의 호스트, JAVA 실행을 위한 가상 머신에 대한 인터페이스이다. 넷스케이프와 MS 익스플로러가 모두 (이 브라우저를 지원하는 플랫폼에 대해) 지원된다.

·JAVA 애플릿 : JAVA 애플릿(44)은 다음과 같은 것을 포함하지만, 여기에 국한되지는 않는다.

⇒ 시스템 요약 애플리케이션 : 알람 상태에 대한 계층적 관찰, 패런트 노드(parent node)에 대한 요약 아이콘, 알람 상태에 대한 칼라 인코딩(color encoding), 네트워크 구성요소 세부 상태 스크린으로의 포인트/클릭(point/click) 네비게이션(navigation)을 제공한다.

⇒ 네트워크 구성요소 세부 상태 애플리케이션 : 각각의 네트워크 구성요소에 대한 커스텀 관찰(custom view)을 제공하고, 정적 구성 데이터(static configuration data)와 모든 관리 객체의 보존 상태를 디스플레이한다.

⇒ 액티브 알람 리스트 브라우저 애플리케이션 : 시스템 내의 현저한알람(outstanding alarm)의 현재 리스트를 디스플레이한다.

구성요소 관리 시스템 서버의 주된 소프트웨어 컴포넌트는 다음과 같은 것을 포함한다.

·HTTP 웹 서버(58) : (구성요소 관리 시스템 서버 하드 디스크로부터의) 구성요소 관리 시스템 클라이언트 애플리케이션과 관련된 (구성요소 관리 시스템 서버 하드 디스크로부터의) HTML 페이지와 JAVA 애플릿을 검색하고 다운로드하는 구성요소 관리 시스템 클라이언트로부터의 HTTP 요청을 처리한다.

·오빅스디(Orbixd)(60) : Iona 오빅스 데몬(daemon), 객체 요청 중개자

·오빅스 명명 서비스(64) : 객체 위치 요청(object locator request)을 서비스하는 오빅스 프로세스.

·객체 서버(66) : 구성요소 관리 시스템 서버 기능의 대부분을 제공하는 단일 유닉스(UNIX) 프로세스. 이는 본 명세서의 후반 섹션에서 상세히 설명한다.

·액티브 알람 관리자(68) : 클라이언트 액세스에 대하여 시스템 내에서 현재 액티브인 알람을 제공하고 클라이언트 알람 리스트 애플리케이션의 구성요소 관리 시스템 컴포넌트를 표시한다.

·HPOV 프로세스(70) : 네트워크 관리 시스템 인프라스트럭쳐(infrastructure)(SNMP API, 트랩(trapd), 포스트매스터 데몬(postmaster daemon))를 제공한다. 이와는 달리, 네트워크 구성요소 시스템은 CMU SNMP 라이브러리에 의해 수행된다.

·ROP 포매터(72) : 이진 메시지 코드를 ECP ROP 포매팅 관례(formattingpractice)에 따라 아스키(ASCII) 텍스트로 번역한다. 그런 다음 포매팅된 아스키 출력을 ROP 스트림으로 보낸다.

·커맨드 라인 해석기(command line interpreter)(76) : 아스키 커맨드 언어 인터페이스를 제공하여 기술자로 하여금 구성요소 관리 시스템에서 커맨드를 입력하고 결과를 관찰하도록 한다.

·UX 프록시(Proxy)(78) : 내부 데이터베이스 서브시스템(internal database subsystem : IDS)에 대한 UX 메시지 인터페이스(시스템 V 메시지 큐(queue)와 소켓(socket) 사이의 브리지(bridge)).

·내부 데이터베이스 서브시스템(IDS)(79) : ECP 링 데이터베이스 갱신은 AP가 시스템에 추가되면 (UX 프록시를 통하여) 객체 서버를 트리거한다.

애플리케이션 프로세서(AP) 컴포넌트(Application Processor Components)

아래 컴포넌트는 AP(80) 상에 상주한다.

·SNMP 중개자(81) : AP와 구성요소 관리 시스템 인프라스트럭쳐 사이에서 메시지를 송수신한다. 또한 트랩을 조절(throttling)하여 시스템의 과부하를 방지한다.

·내부 데이터베이스 서브시스템(IDS)(79) : ECP 링 데이터베이스 갱신은 AP 구성 데이터를 다운로드하고 ECP(82)로부터 갱신한다.

·ECP 중개자(86) : IDS 트리거를 처리하고, AP 애플리케이션으로 그들의 구성 데이터의 변경을 통지하며, 구성 변경(이벤트)을 이벤트 처리기로 보낸다.

·커맨드 처리기(88) : GUI 기반 또는 텍스트 기반 클라이언트 인터페이스로부터 발생된 AP 관리 커맨드 요청(AP administration command request)을 처리한다. RAP(90)를 실행하여 관리 요청을 완료한다_.완료 정보를 구성요소 관리 시스템 서버로 리턴한다. AP 커맨드 테이블 내에 액티브 커맨드 리스트를 보유한다.

·텍스트 커맨드 해석기(92) : 구성요소 관리 시스템 서버에 의해 나타난 GUI 기반 인터페이스를 클라이언트가 이용할 수 없는 특별한 경우를 위한 텍스트 기반 인터페이스.

·이벤트 처리기(94) : 이벤트 처리기는 이벤트(알람, 통지, 상태 변경, 구성 변경)를 필터링하고 구성요소 관리 시스템으로 보내는 역할을 한다. NEST 내의 상태와 알람 테이블을 갱신한다.

·NE 상태 테이블(96) : NEST로도 알려져 있으며, 액티브 커맨드 리스트는 물론 보존 객체 상태와 알람 정보를 저장한다.

·RAPs(90) : 자원 관리 프로세스(Resource Administration Process : RAP)는 프로세스를 분기 실행(fork-exec'ing)하고 프로세스 실행 결과를 얻기 위한 애플리케이션 프로세싱 인터페이스(application processing interface : API)이다.

·기타 플랫폼과 애플리케이션 소프트웨어(98) : 지나치게 세부적인 사항을 원하지 않는 경우에 다이어그램 상에 디스플레이되지 않은 커맨드 실행과 관련된 모든 실체(entity)를 포함한다. 이는 주어진 자원(예컨대, RCS, MMA, CCM, SS7)에 대해 특정한 소프트웨어 애플리케이션은 물론, RCC(100) 기반 구성요소 관리 시스템 커맨드가 실행(예컨대, 디지털 스위치 DS1을 제거)될 때 작동되는 RCC 자원 모니터와 자원 데몬을 포함한다.

·RCC(100) : 도시하였듯이, RCC(100) API로의 호출에 의해 서비스로부터 자원을 얻기 위한 RCC 이벤트를 생성한다. 이 버블(bubble)은 RCC 기반 구성요소 관리 시스템 커맨드가 실행될 때에 비로서 실행된다. 이것은 단지 개요이기 때문에 비 RCC 기반 구성요소 관리 시스템 커맨드(예를 들어, 진단 DS1)의 경우는 도시하지 않았다.

·AP 상태 모니터(104) : RCC(100) 이벤트를 국부적으로 이해된 AP(80) 이벤트로 브리지 매핑.

참고문헌(References)

다음은 구성요소 관리 시스템 서버와 분산 클라이언트 애플리케이션의 아키텍쳐를 설명한다.

다음은 배경 정보로 유용할 참고문헌과 본 명세서에서 참조로서 인용된 공개물을 제공한다.

객체 지향 기법(Object Oriented Technology)

·테일러, 데이비드 에이(Taylor, David A)의 "Object Oriented Technology : A Managers Guide", Addison­Wesley, 1993, ISBN 0­201­56358­4.

·부크, 그래디(Booch, Grady)의 "Object Oriented Analysis and Design with Application", Benjamin/Cummings, 1994, ISBN 0­8053­5340­2.

네트워크 관리(Network Management)

·스털링, 윌리엄(Stallings, William)의 "SNMP, SNMPv2, and CMIP. The Practical Guide to Network­Management Standards", Addison­Wesley, 1993, ISBN 0­201­63331­0.

·로즈, 마샬 티(Rose, Marshall T.)의 "The Simple Book­An Introduction To Internet Management", Prentice­Hall, 1994, ISBN 0­13­177254­6.

·"Hewlett­Packard Open View Network Node Manager 4.1 Technical Evaluation Guide", 휴렛 패커드 코퍼레이션(Hewlett Packard Corporation), 1996년 4월.

·"HP Open View Using Network Node Manager", 휴렛 패커드 코퍼레이션, 1996년 4월.

·카네기 멜론(Carnegie­Mellon) SNMP 라이브러리, http://www.net.cmu.edu/projects/SNMP.

웹 기법(Web Technology)

·월드 와이드 웹 콘소시엄 웹 사이트(The World Wide Web Consortium Web Site) <http://www.w3.org/>는 웹 기법에 관한 참고문헌, 백서, RFC를 포함한다.

코바(CORBA)

·오펄리, 로버트(Orfali, Robert) 등의 "The Essential Distributed Objects Survival Guide", John Wiley and Sons. 1996년, ISBN 0­471­12993­3.

·비노스키, 스티브(Vinoski, Steve)의 "Distributed Object Computing WithCORBA", 휴렛 패커드 컴퍼니, 1993년. (C++ 리포트 매거진의 1993년 7/8월 호에 개재된 기사)

·객체 관리 그룹 웹 사이트 <http://www.omg.org/>는 표준 문서와 백서를 포함하고 코바에 관한 정보에 링크시킨다.

도 4는 구성요소 관리 시스템 서버와 단일 클라이언트 워크스테이션에 대한 개략적인 주요 기능 컴포넌트를 도시한다. 단일 관리 네트워크 구성요소(14)는 그와 관련된 SNMP 중개자와 함께 도시되어 있다. 도 4의 테이블은 후속 설명에서 사용하는 용어의 정의를 제공한다.

구성요소 관리 시스템 클라이언트 컴포넌트(Element Management System Client Components)

구성요소 관리 시스템 클라이언트(28) 컴포넌트는 네트워크 구성요소 커맨드, 제어, 고장 관리를 제공하는 웹 브라우저에 의해 호스트되는 애플리케이션(web browser hosted application)으로 이루어진다. 이러한 웹 브라우저에 의해 호스트되는 애플리케이션은 크로스 플랫폼 환경(cross platform environment)에서 그래픽 클라이언트 인터페이스 기반 클라이언트 인터페이스를 제공한다. 서버 인프라스트럭쳐는 성능과 보안 관리를 위한 애플리케이션을 지원한다.

서버에 대한 클라이언트 인터페이스는 이미 본 명세서의 앞 부분에서 참조로서 인용된 계류 중인 특허 출원 명세서에서 설명한 EMAPI(55)에서 설명된다. EMAPI(55)는 산업 표준 객체 관리 그룹 인터페이스 묘사 언어(interfacedescription language : IDL)를 활용하여 구현된다. EMAPI(55)의 인터페이스 및 의미론(semantics)은 클라이언트 애플리케이션 프로세스로 하여금 이 인터페이스를 활용하여 시스템 관리를 제공하도록 한다. 이 인터페이스의 분산은 분산 객체 요청 아키텍쳐를 제공하는 코바(Common Object Request Broker Architecture : CORBA)의 사용을 통해 달성된다.

클라이언트 애플리케이션은 EMAPI(55)를 활용하여 관리 객체의 속성(attribute)에 대한 액세스를 제공하는 서버 상의 서비스 객체를 액세스하고, 이러한 관리 객체들에 대한 보존 작업을 제공하며, 클라이언트로 하여금 속성 변경의 통지와 이벤트 통지(전형적으로 커맨드 승인과 커맨드 결과인)를 등록하도록 한다.

클라이언트 애플리케이션의 개발은 EMAPI(55) 인터페이스 사양(specification)에만 의존한다. 코바를 사용하면, 클라이언트가 (C++로) 서버와는 상이한 (Java와 같은) 언어로 분산되고 구현되도록 할 수 있다.

구성요소 관리 시스템 서버(32)는 SNMP 네트워크 관리 프레임워크(framework)와 분산 네트워크 관리 서비스를 클라이언트 애플리케이션에 제공하는 소프트웨어 컴포넌트 세트로 이루어진다. 본 발명에 따른 방법은 오프 더 셸프 소프트웨어 컴포넌트를 사용한다. 구성요소 관리 시스템에 포함된 오프 더 셸프 소프트웨어 컴포넌트는 다음과 같다.

① HTTP 웹 서버

② 등록상표 넷스케이프 또는 마이크로소프트 인터넷 익스플로러 웹 브라우저

③ 오빅스 데몬

④ 오빅스 명명 서비스

⑤ HP 개방 관찰 네트워크 노드 관리자(HPOVNNM) 또는 이와는 달리 CMU SNMP 라이브러리 패키지

애플리컨트에 의해 제공되는 구성요소 관리 시스템 서버(32) 소프트웨어 컴포넌트는 다음과 같은 것을 포함한다.

① 객체 서버(66)

② 액티브 알람 관리자(120)

③ 유닉스 서브시스템 프록시

④ 독출 전용 프린터 포매터

⑤ 커맨드 라인 해석기

처음 두 컴포넌트인 객체 서버(66)와 액티브 알람 관리자(120)는 구성요소 관리 시스템 클라이언트 애플리케이션을 지원하는 데 필요한 서버 기능의 전부를 제공한다. 다른 세 컴포넌트는 중요한 지원 기능을 담당한다.

오프 더 셸프 구성요소 관리 시스템 서버 컴포넌트 HTTP 웹 서버(일반적으로 웹 서버라 지칭함)(Off the Shelf Element Management System ServerComponents HTTP Web Server(Generally called Web Server))

이 오프 더 셸프 기능은 클라이언트 브라우저에 정적 및 동적 웹 페이지를 제공한다. 웹 서버는 HTTP 1.0(혹은 그 이상), CGI 스크립트(script)에 대한 지원을 제공해야 하고, "진행 중인(on the fly)" 동적 웹 페이지의 생성을 위해 내장(built in) API를 제공해야 한다. 웹 서버는 다음과 같은 것을 지원한다.

·CGI 스크립트 실행

·시작(init)부터 자동 개시(서버를 시작하기 위하여 어떠한 인적 개입(human intervention)도 없음)

·페이지 액세스의 로깅(logging). IP 어드레스와 URL 참조(referenced)를 포함하는 로그 파일. 이는 액세스 패턴을 조사하고 미인증된 소스로부터의 액세스를 검출, 추적하기 위해 사용된다.

·클라이언트 이름과 패스워드에 기반한 웹 페이지 액세스 제어. 서버는 기본적인 서버 인증을 지원하고 브라우저에서 서버로의 커넥션의 암호화가 필요한 경우 SSL(Secure Socket Layer)을 지원하도록 향상될 수 있다.

·액세스 제어를 위해 클라이언트 이름과 패스워드를 관리하는 것을 포함하는 웹 서버의 보안 관리자 관리

오빅스 웹 서버(Orbix Web Server)

오빅스 제품의 일부분. 웹 브라우저 내에서 코바를 지원하기 위해 필요. JAVA 애플릿이 클라이언트에게 다운로드되어 코바를 통해 구성요소 관리 시스템서버와 통신하도록 함.

오빅스 데몬(코바 ORB)(Orbix Daemon(CORBA ORB))

코바 ORB는 코바의 서버 측을 나타내고, 오프 더 셸프 코바 구현에 의해 제공된다. 코바(Common Object Request Broker Architecture : CORBA)를 이 아키텍쳐 내에서 활용하고 EMAPI(55)를 사용하여 클라이언트 사이의 프로세스 간(inter­process) 및 프로세서 간(inter­processor) 통신을 제공한다.

·코바는 플랫폼에 무관하고(platform­independent) 언어에 무관한 프로그래밍과 분산 객체를 위한 실행 환경.

·코바는 많은 공통 네트워크 프로그래밍 작업을 자동화한다.

⇒ 객체 등록.

⇒ 위치 지정(location)과 활성화(activation)

⇒ 다중화/역다중화 요청

⇒ 프레이밍(framing)과 에러 처리

⇒ 파라미터 마샬링(marshaling)과 역마샬링(de­marchaling)

⇒ 작업 디스팻치(operation dispatch)

·원격 객체 서비스로의 액세스는 발신자(caller)에게 트랜스패런트(transparent)하다. 클라이언트는 다음과 같은 것을 알 필요가 없다.

⇒ 객체의 위치

⇒ 그의 프로그래밍 언어

⇒ 그의 운용 시스템

⇒ 객체 인터페이스의 일부분이 아닌 기타 시스템의 측면

오빅스 명명 서비스(Orbix Naming Service)

오빅스 명명 서비스 데몬은 네트워크 상의 서버들의 기호적 참조(lookup)를 제공하고 IIOP 프로토콜을 지원하는데 필요하다.

HP 개방 관찰 또는 이와는 달리 CMU SNMP 라이브러리(HP OPEN VIEW OR ALTERNATIVELY CMU SNMP LIBRARY)

기능적 설명(Functional Description)

HP 개방 관찰 네트워크 노드 관리자(HP Open View Network Node Manager : HPOVNNM) 또는 CMU SNMP 라이브러리 제품은 SNMP SET, GET 요청의 전달과 SNMP 트랩의 수신을 위한 최하 레벨 네트워크 관리 인프라스트럭쳐를 제공한다. 이 인프라스트럭쳐는 구성요소 관리 시스템 서버로부터 SNMP 중개자로 GET와 SET 요청을 전달하고 표준 트랩 UDP 포트 상의 트랩을 수신하여 이들을 SNMP 중재기(SNMP Mediator)로 보낸다.

HP 개방 관찰 네트워크 노드 관리자의 역할(Role of HP Open View Network Node Manager)

본 발명에서 사용될 때, HP 개방 관찰 네트워크 노드 관리자(HPOVNNM)는 구성요소 관리 시스템 서버(32) 인프라스트럭쳐의 일부분으로서 사용된다. HPOVNNM 실행시간 시스템의 서브세트만이 액티브인 동안, 전체 HPOVNNM 시스템은 구성요소 관리 시스템 서버 상에 인스톨될 것이다. 다음의 주된 컴포넌트가 인스톨될 것이다. 구성요소 관리 시스템 서버 인프라스트럭쳐의 일부분이 될 HPOVNNM의 이러한 컴포넌트들을 굵은 활자로 나타내었다.

·ovspmd(Open View System Process Management Daemon) : 이 프로세스는 작업의 ovstart와 같은 클라이언트 인터페이스 상태 검사 프로그램을 인에이블시키기 위해 실행되어야 한다. 이 모니터는 종료된 시스템 프로세스의 재시작을 지원하지 않으므로, EM 서버 프로세스 관리 방안에서 특별히 유용하지는 않을 것이다.

·OVLicenseMgr: 임계 HPOVNNM 실행시간 컴포넌트와 ovw 브라우저 애플리케이션의 시작(startup)을 제어하는 허가 관리자.

·ovtrpd(Open View Trap Daemon) : 표준 포트 상의 각 SNMP 중개자로부터 입력 SNMP 트랩을 수신하고 이들을 포스트매스터(postmaster) 데몬(아래 참조)으로 보낸다.

·pmd(Postmaster Daemon) : HPOVNNM 인프라스트럭쳐에서 일반적인 패킷 라우터로 작용. pmd 프로세스는 ovtrapd로부터 트랩을 수신하여 이들을 구성요소 관리 시스템 객체 서버로 보낸다. 이는 등록되어 있어 모든 트랩을 수신할 수 있다.

·ovaction: HP 개방 관찰 이벤트 관리 소프트웨어를 통해 정의된 대로 유닉스 레벨 액션에 대한 트랩의 연합(association)을 관리하는 개방 관찰 프로세스.

·ovtopmd: 개방 관찰 위상 관리자 데몬으로서, HPOVNNM 위상 데이터베이스를 위한 IP 발견과 레이아웃(layout)을 담당한다.

·netmon(Network Monitor) : 네트워크 상의 노드를 발견하고 모니터한다. 노드를 모니터하기 위하여 ICMP 핑(ping)을 처리하고, MIB­2 시스템 그룹을 이용하여 단순히 SNMP 주기적 폴링을 수행한다.

·snmpCollect: 클라이언트가 HP 개방 관찰 윈도우 X 기반 GUI 인터페이스를 통하여 주기적으로 수집될 SNMP MIB 값을 정의하도록 하는 SNMP 수집 데몬. 이는 문턱값과 연합 액션(유닉스 셸(shell) 커맨드)을 정의하는 방법을 제공한다.

·ovw(Open View Windows) : 개방 관찰 윈도우 X 기반 GUI는 맵 애플리케이션, 이벤트 브라우저, MIB 브라우저로의 액세스를 제공한다.

·ovwdb(Open View Windows Database) : 개방 관찰 윈도우 위상 데이터베이스 관리자.

이 실행시간 시스템에 대한 C 언어 인터페이스인 HPOV SNMP API는 HPOVNNM 개발자 키트의 일부분으로서 제공되며 다음과 같은 것을 위해 사용될 것이다.

·SNMP 패킷의 인코딩 및 디코딩

·SNMP 트랩 세션의 셋업과 철거(tear down)

설명한 바와 같이 전체 플랫폼은 HP 개방 관찰을 위해 특별히 작성된 제 3 부분 SNMP 관리 애플리케이션을 지원하기 위해 인스톨되고 활성화되며 ovw 맵 프레임워크(framework)를 이용한다. 오프 더 셸프 제 3 부분 애플리케이션이 코바 기반 객체 서버 메커니즘 대신에 ovwdb 기반 관리 객체 데이터베이스를 사용하므로, 이들 애플리케이션은 최소 노력으로도 구현된다.

관리(Administration)

CMU SNMP 라이브러리 패키지 대신 사용되는 경우 HPOVNNM 인프라스트럭쳐의 몇몇 관리가 필요하다.

·초기 구성(Initial configuration)

⇒ 어느 프로세스를 실행할 것인지를 결정하고 이러한 프로세스 각각의 특정 속성을 정의하기 위해 HPOVNNM에 의해 사용된 국부 등록 파일의 정의.

⇒ 트랩 구성 파일의 정의 : 이는 HPOVNNM 인프라스트럭쳐에 의해 수신된 각각의 트랩에 대해서 어떤 프로세싱(단순한 로깅 포함)이 수행되어야 할 지를 정의한다.

⇒ 인프라스트럭쳐의 자동 시작을 위해 적절한 RCC 초기화 파일 내에 HPOVNNM ovstart 커맨드 포함.

⇒ HPOVNNM 진행 보존(Ongoing maintenance)에 의해 사용되는 네트워크 허가 관리자의 구성.

·온고잉(ongoing) 작업

⇒ MIB 갱신

⇒ HPOVNNM에 의해 사용된 네트워크 허가 관리자에 대한 허가 갱신.

본 발명에 따른 구성요소 관리 시스템 서버 컴포넌트(ELEMENT MANAGEMENT SYSTEM SERVER COMPONENTS IN ACCORDANCE WITH THE INVENTION)

객체 서버(Object Server)

객체 서버는 클라이언트 애플리케이션이 네트워크 구성요소와 기타 관련된 관리 객체에 관한 정보를 수신하고 네트워크 구성요소 상에서 실행되는 커맨드를 발생시키는 방법을 제공한다. 이러한 기능을 수행하기 위해, 객체 서버는 다음의 서비스를 제공한다. (1) 클라이언트 세션 등록, (2) 이벤트 분산 및 스크리닝(screening), (3) 커맨드 관리, (4) SNMP 중재, (5) 각각의 관리 객체 클래스에 특유한 서비스.

객체 서버는 중앙 이벤트 큐를 이용하는 단일 쓰레드(single­threaded) 프로세스로서 구현된다. 그러나, 아키텍쳐는 이 구현을 명령하지는 않는다. 아키텍쳐는 그 구현이 플랫폼일 것과 작업 시스템(operating system)이 중립(neutral)일 것을 요구하고, 다중 쓰레드 접근이 작업 시스템 의존성을 가질 것인지가 관심사이다. 객체 서버를 구성하는 서브 컴포넌트는 별개의 프로세스로서 구현될 수 있다. 후자의 접근 방법의 예는 두 번째로 주된 서버 컴포넌트인, 액티브 알람 관리자를 별개의 프로세스로 구현하기 위한 결정에 관한 것이다. 구성요소 관리 시스템 인프라스트럭쳐가 개발됨에 따라, 현재 객체 서버의 일부분인 기타 컴포넌트는, 필요하고 실행할 수 있다면, 별개의 프로세스로 구현될 수 있을 것이다.

다양한 형태의 프로세스 간 통신이 이러한 컴포넌트 사이의 통신을 위해 사용될 수 있지만, 이 아키텍쳐에 의해 권고된 방법은 코바를 사용하여 구현으로부터 플랫폼 특유의 IPC를 제거하고 필요하다면 성능 최적화를 위해 다수의 프로세서에 기능을 분산시키는 것이다.

도 3에 도시한 바와 같이, 객체 서버는 다음의 컴포넌트 세트로 이루어져 있으며, 그 각각은 특정 서비스를 지원한다.

⇒ 클라이언트 세션 관리자(130)는 액티브 클라이언트 세션과, 관리자에게 통지하지 않고 종료한 세션에 대한 감사(audit) 리스트를 보유한다.

⇒ 이벤트 분산자(140)는 이벤트 라우팅과 분산을 제공한다. 이벤트는 네트워크 구성요소로부터 (SNMP 중재기를 통해 수신된) SNMP 트랩, 커맨드, 커맨드 승인, 커맨드 응답, 구성요소 관리 시스템 내에서 생성된 이벤트를 포함한다. 이벤트 분산자의 클라이언트는 이벤트 분산자를 이용하여 필터를 등록하여 그 필터에 부합하는 이벤트의 (콜백 함수를 경유한) 전달을 요청한다.

⇒ 이벤트 스크리너(150)는 객체 서버에 의해서만 사용되며, 양단 개방(open­ended) 이벤트 상관(event correlation)을 위해 이벤트 분산자에 의해 감지되기 전에 스크리닝 이벤트를 지원한다.

⇒ 구성요소 관리 시스템 커맨드 처리기(155)는 액티브 커맨드를 추적하고 그 커맨드가 완료되면 자원을 해제한다. 또한, 구성요소 관리 시스템 커맨드 처리기는 구성요소 관리 시스템 내에서 커맨드의 실행을 조정한다.

⇒ SNMP 중재기(160)는 NIB ASN.1 포맷과 이 아키텍쳐에서 사용되는 관리 객체 기호(notation) 사이의 번역을 제공한다. 또, SNMP 중재기는 SNMP 서비스 객체에 대한 폴링 서비스와 관리 객체 커맨드(예를 들어, 제거, 회복)에 대한 적절한 SNMP 세트 커맨드로의 변환을 제공한다.

⇒관리 객체 : 도 3에 도시한 바와 같이 그 자체의 프로토콜(예컨대, AP, DS1, EIN, LAN)에 대해 SNMP를 활용하여 네트워크 구성요소나 네트워크 구성요소 내의 보존 유닛을 나타내는 각각의 객체는 "SnmpMO" 클래스 객체(170)로써 표현된다. 한 객체의 단일 인스턴스는 시스템 내의 그 객체 클래스의 모든 인스턴스에 대해 사용된다. 예를 들어, AP 서비스 객체는 시스템 내의 AP 프로세서의 모든 인스턴스에 대한 속성 및 방법을 제공한다. SnmpMOs와 함께, 아키텍쳐는 네트워크 구성요소나 보존 유닛에 직접 연결되지 않은 관리 객체를 나타내는 "논리적 관리 객체"를 지원한다. 한 예로는 시스템 레벨 상태와 커맨드를 제공하는 "시스템" 관리 객체 클래스이다.

액티브 알람 관리자(ACTIVE ALARM MANAGER)

액티브 알람 관리자(120)는 클라이언트 액세스에 대해 시스템 내에서 현재 액티브 알람을 제공하고, 클라이언트 알람 리스트 애플리케이션의 구성요소 관리 시스템 컴포넌트를 나타낸다. 두 가지 통신 엔티티(entity)가 있는데, 객체 서버 내에 상주하는 (클래스 ApActiveAlarms의) AP 액티브 알람 테이블(Active Alarm Table : AAT) 관리 객체와, 클라이언트 애플리케이션에 (클래스 AlarmManager에 의해 정의된 대로) 액세스를 제공하는 구성요소 관리 시스템 상에 별개의 유닉스 시스템 프로세스인 액티브 알람 관리자(Active Alarm Manager : AAM)이다. AAM은 구성요소 관리 시스템 상의 별개의 시스템 프로세스로서 구현되어 잠재적으로 큰 부피의 알람 데이터가 AAM에 의해 전달되어야 할 때(예컨대, 클라이언트 애플리케이션 개시 시에), 객체 서버의 실행의 차단을 방지한다. AAT와 AAM이 프로세스 경계를 가로질러 통신하므로, 그들 사이의 모든 인터페이스는 IDL로 정의된다. 유사하게, AAM에 의해 클라이언트 애플리케이션으로 제공되는 모든 인터페이스는 IDL로 정의된다.

모든 AP를 위한 알람은 AAT 관리 객체 내에 표시되어, AP 내에서 현재 액티브 알람을 갖는 보존 유닛의 모든 클래스에 대한 알람 기록이 존재하게 된다. 추가적인 관리 객체가 객체 서버 내에 도입되어, AP(예를 들어, ApFrameActiveAlarms)와 연관된 기타 보존 유닛 또는 기타 네트워크 구성요소(14) 내의 알람을 추적한다. 그러나, AAT에서와 같이, 이들 관리 객체에 의해 추적된 알람은 AAM 프로세스를 통해 클라이언트 애플리케이션으로 보고된다.

AAM 시스템 프로세스는 AAT 관리 객체의 액티브 알람 기록 테이블을 반영하는 액티브 알람 기록 테이블을 보유한다. 초기화 시, AAM은 현재 알람 기록의 전달과 후속 갱신의 통지를 위해 AAT 관리 객체를 등록한다. 다수의 클라이언트는 알람 필터와, 특정 필터 기준과 부합되는 알람 기록의 전달을 위한 콜백을 등록할 수 있다. 클라이언트 애플리케이션은 그들의 특정 필터 기준을 변경시키거나 취소할 수 있다.

UX 프록시(UX PROXY)

IDS(79)로의 UX 메시지 인터페이스를 제공하여 IDS 트리거를 수신하고 처리한다. AP가 시스템으로부터 추가되거나 삭제될 때 구성요소 관리 시스템에 통지하는 데 트리거가 필요하다. 그런 다음, 구성요소 관리 시스템은 자신의 장비 데이터(equipage data)를 위해 AP를 폴링한다.

ROP 포매터(ROP Formatter)

ECP ROP 포매팅 조건과 일치하는 포맷으로 이벤트를 포맷하고 포맷된 이벤트를 ECP ROP에서 로깅하고 프린팅하기 위해 ECP로 보낸다.

이 컴포넌트는 구성요소 관리 시스템 서버 상에 상주하는 클라이언트로 다음 기능을 제공한다.

·모든 이벤트에 대해 이벤트 분산자를 등록한다.

·현장 텍스트 포매팅 서비스(locale text formatting service)를 활용하여 TI/OP 메시지와 같은 가공하지 않은 이벤트(raw event)를 포맷한다.

·ECP ROP 포매팅 조건과 일치하는 포맷으로 이벤트를 포맷한다.

·메시지 내에 적절한 알람을 표시하는 것을 포함한다.

·포맷된 이벤트를 ECP ROP에서 로깅하고 프린팅하기 위해 ECP로 보낸다.

·보고를 위해 ECP에서 새로운 메시지 클래스를 활용한다.

이러한 메커니즘은 모든 구성요소 관리 시스템에서 생성된(element management system­generated) TI/OP 메시지를 보내기 위해 단일 메시지 유형에 의존할 것이다. 이동 교환국(mobile switch center : MSC) ECP ROP로부터의 현재 인터페이스는 알람 레벨(MAN, INFO, CRIT, MAJ, MIN)을 특정하는 것을 지원한다.

커맨드 라인 해석기(Command Line Interpreter)

커맨드 라인 해석기는 아스키 커맨드 언어를 제공하여 기술자로 하여금 커맨드를 입력하고 커맨드 결과를 관찰하도록 한다. 입력 커맨드 신택스(syntax)는 전유 시스템에 의해 사용되는 것과 동일한 PDS 포맷이다. 또한, 커맨드 보고도 기존의 전유 시스템과 동일한 신택스로 포맷된다.

·구성요소 관리 시스템에 의해 지원되는 네트워크 구성요소(와 그 보존 유닛)를 위한 모든 커맨드에 아스키 기반 입력 언어 액세스를 제공한다.

·입력 커맨드에 대한 승인을 제공하여 커맨드의 처리를 나타낸다.

·다수의 커맨드가 동시에 눈에 띄도록(outstanding) 허가한다.

·커맨드 시퀀스 번호를 제공하여 승인과 응답을 커맨드와 상관시킨다.

·커맨드 응답에 대한 최종 보고를 표시하는 것을 제공한다.

인프라스트럭쳐와 애플리케이션 특정 컴포넌트(Infrastructure and Application Specific Components)

아키텍쳐는 네트워크 관리와 애플리케이션 특정 컴포넌트에 대한 일반적인 인프라스트럭쳐를 제공하는 컴포넌트를 보유한다. 이 섹션은 인프라스트럭쳐와 애플리케이션 특정 범주 내에 도 4의 컴포넌트를 기입한다. 몇몇 컴포넌트는 인프라스트럭쳐와 애플리케이션 특정 코드(예를 들어, 커맨드 라인 해석기)로 이루어지며 그렇게 기록된다.

다음 컴포넌트는 인프라스트럭쳐와 관련된 것으로 간주된다.

·객체 서버

⇒클라이언트 세션 관리자

⇒이벤트 분산자와 스크리너

⇒구성요소 관리 시스템 커맨드 처리기

⇒SNMP 중재기

⇒관리 객체 기반 클래스(ManagedObject, NEMO, SnmpMO, SnmpNE, 도 7 참조)

·UX 프록시

·액티브 알람 관리자

·클라이언트 액티브 알람 브라우저 애플리케이션

·클라이언트 시스템 알람 요약 애플리케이션

·클라이언트 네트워크 구성요소 세부 상태 애플리케이션

·ROP 포매터

·커맨드 라인 해석기. 이들 컴포넌트의 일부분은 애플리케이션에 대해 특정되는데, 예를 들어, 스크린 내용이나 레이아웃은 관리되는 애플리케이션의 특정 특성에 따라 변할 것이다.

다음 컴포넌트는 애플리케이션에 대해 특정한 것으로 간주된다.

·네트워크 구성요소에 대한 커맨드와 보고

·관리 객체, SnmpMO, SnmpNE 유형의 애플리케이션 특정 서비스 객체

관리 객체 모델(MANAGED OBJECT MODEL)

이 아키텍쳐에서는, 관리될 수 있는 모든 자원과 구성요소가 관리 객체로서 시스템 내에 표현된다. 각각의 관리 객체는 클라이언트 애플리케이션에 의해 사용되는 속성, 방법, 통지를 제공하여 객체를 관리한다. 이 아키텍쳐에 의해 사용되는 관리 객체 모델을 묘사하기 위해, 다음 용어가 정의되고 후속하는 설명에서 사용된다.

관리 객체 유형의 모든 인스턴스는 속성, 작업, 통지, 성향(behavior)의 정의를 공유하나, 관리 객체의 각 인스턴스에 고유한 속성 값을 가질 것이다. 이러한 접근 방식은 관리 객체에 대한 공통 성향이 베이스 클래스 내에서 정의되도록, 또 전문화된 성향이 그 특정 관리 객체의 유형(베이스 클래스의 공통 성향과 속성을 전수하면서)을 위해 관리 객체 클래스 내에 위치하도록 한다. 관리 객체 클래스의 보다 전문화된 구성은 기존의 관리 객체 클래스를 서브클래싱하여 기존 클래스의 재사용을 제공함으로써 개발될 수 있다. 서브클래스는 종종 기존 속성의 범위에 속성을 더하거나, 그 범위를 확장 또는 제한하고, 작업과 통지를 추가하거나 제한한다. 이 개념은 관리 객체 클래스 내에서의 관리 객체의 성향에 관한 규칙을 포괄하는데 도움을 준다. 이는 이러한 기능을 (종종 다양한 방식으로) 구성요소에 대한 관리를 제공하는 상이한 애플리케이션에 복제하는 공통 실행을 방지한다. 도 7은 이 접근 방식이 몇몇 관리 객체부를 정의하는 데 어떻게 사용되는지 한 예를 보여준다. 이는 또한 특정 유형의 AP 관리 객체를 얻는 데 어떻게 사용되는 지도 보여준다. 이것이 전술한 개념을 나타내기 위한 예에 불과하다는 것에 유의하여야 한다.

SNMP 기반 관리 객체에 대해, 관리 객체 및 대부분의 관리 객체의 속성의 정의는 (MIB를 분석하는 도구에 의해 생성된) MIB(55)의 정의로부터 유도될 수 있다. 또한, MIB ASN.1 포맷과 EMAPI(55) (SNMP 중재기 내에서 수행되는) 객체 기호사이의 번역을 위해 필요한 대부분의 코드도 MIB(55)의 정의로부터 유도될 수 있다. 이 번역의 자동화로 인해 시스템의 보존을 감축시키고, 새로운 네트워크 구성요소가 이 시스템에 추가될 때 새로운 관리 객체의 개발을 감축시킬 것이다.

서비스와 관리 객체 속성에 대한 클라이언트 인터페이스와 방법은 EMAPI(55)에서 설명된다. EMAPI(55)와 관리 객체 기호는 네트워크 내의 모든 관리 객체의 일관된 모델을 제공하여 클라이언트 애플리케이션으로부터의 구성요소 관리자 플랫폼과 연관된 구현의 세부 사항을 은폐한다(예를 들어, 클라이언트는 네트워크 구성요소로의 기본적인 프로토콜이 SNMP, CMIP 또는 전유 인터페이스인지를 알 필요가 없다). 관리 객체 특정 로직은 다양한 애플리케이션 전체에 걸쳐 분산되는 대신 관리 객체 내에 포함되어 클라이언트 애플리케이션 개발을 단순화한다.

관리 객체 기호(MANAGED OBJECT NOTATION)

이 모델에서는 서버 내에 존재하는 실재 객체들이 서로 구별되어, 관리 객체의 클래스와 이러한 관리 객체 (및 그 속성)의 특정 인스턴스를 위한 서비스를 제공한다. 네트워크 구성요소가 다수의 관리 객체를 보유하는 거대한 구성요소 관리 시스템 상에서 금지될 수 있는 시스템 내의 모든 관리 객체에 대해 객체 인스턴스를 생성하는 대신, 단일 서비스 객체가 생성되어 관리 객체의 클래스를 위한 서비스를 제공한다. 특정 관리 객체 인스턴스와 그들의 속성은 객체 클래스 식별자와 속성 코드 세트를 이용하여 참조된다. 이들 관리 객체 클래스 식별자와 속성 코드의 정의는 모든 서비스 객체와 그 클라이언트 사이의 인터페이스 정의의 일부분이다.

관리 객체 식별자(Managed Object Identifiers)

관리 객체의 특정 인스턴스는 객체 클래스 코드와 인스턴스 식별자로 이루어진 객체 식별자를 이용하여 참조된다. 객체 클래스 코드는 정적 계수(static enumeration) 또는 상수(constant)이고, 인스턴스 식별자는 (구성에 기초하여 실행시간에서 정의된) 정수값으로 객체 클래스에 특유한 것이다. 인스턴스 식별자가 관리 객체 클래스에 대해 고유함에도 불구하고, 그 인스턴스에 대한 논리적 번호(logical number)와 동일하지는 않다. 각각의 관리 객체 클래스는 인스턴스 ID와 적절한 네트워크 구성요소 및 유닛 식별자 세트 사이의 번역 방법을 제공한다.

예를 들어, AP 네트워크 구성요소는 시스템 내의 논리적 번호(예를 들어, 1 내지 n)에 의해 참조된다. 시스템 내의 애플리케이션의 개수는 (8과 같이) 특정한 번호로 고정된 것이 아니고, 데이터베이스 내에서 발견되는 장비 정보(equipage information)에 기초할 것이다. 또한 각각의 애플리케이션은 일정 수의 애플리케이션 가상 머신을 가지며, 각각은 논리적 번호(예를 들어, RCS 1)에 의해 식별된다.

애플리케이션 관리 객체의 특정 인스턴스는 애플리케이션의 서비스 객체 내에 있는 참조 함수를 호출함으로써 참조되어, AP 네트워크 구성요소 인스턴스 식별자와 애플리케이션 키를 그와 관련된 인스턴스 ID로 변환한다. 객체 식별자 내의 이들 두 값의 조합은 특정 관리 객체 인스턴스를 고유하게 식별한다.

많은 경우, 관리 객체 클래스를 위한 서비스 객체의 사용은 객체 클래스 코드를 대신하게 될 것이다. 예를 들어, AP 객체 클래스 코드는 요청이 AP 서비스 객체를 통해 이루어질 때는, 클라이언트에 의해 특정되지 않는다. 반대로, AP 객체 클래스 코드는 클라이언트로 보내진 임의의 이벤트 내에 존재하게 되어, 클라이언트가 그 이벤트를 생성한 특정 관리 객체 인스턴스를 식별할 수 있게 한다.

속성 코드(Attribute Codes)

각각의 관리 객체는 그 관리 객체 클래스의 그 인스턴스에 특정한 속성 세트를 보유한다. 이들 속성은 관리 객체에 대한 다양한 보존, 운영, 구성, 크기(measurement) 정보를 설명한다. 각각의 속성은 자신이 속한 관리 객체의 네임 스페이스(name space)에 대해 국부적인 속성 코드로 정의된다. 예를 들어, AP 관리 객체 클래스는 (RCS 관리 객체 클래스가 그러하듯이) 상태 속성을 가질 것이다. 각각의 속성 코드는 자신이 속한 관리 객체 클래스에 대해 고유하다.

속성 값 정의(Attribute Value Definitions)

(예를 들어, 쇼트(short) 또는 옥테트(octet)인) 기본 "원시(primitive)" 유형이 아니면서 클라이언트와 서버 사이에서 사용되는 임의의 속성 값에 대한 유형 정의는 IDL로 정의되어야 한다. 이들 정의의 범위는 그들을 사용하는 관리 객체로 한정되거나, 더 높은 시스템 레벨(예를 들어, 알람 레벨 정의가 시스템 레벨에 있을 것이다)에 있을 것이다.

새로운 관리 객체의 추가(ADDING NEW MANAGED OBJECTS)

시스템 내에 새로운 유형의 관리 객체를 추가할 때, 새로운 유형의 관리 객체 서비스 클래스를 생성하거나, 기존의 서비스 클래스를 사용하는 것 중 하나를 선택하여 그 클래스 내의 관리 객체의 상이한 버전들이나 유형들을 구별하는 능력을 제공해야 한다. 새로운 클래스를 사용하거나 기존의 클래스를 확장하도록 결정하는 것은 새로운 유형 또는 버전의 관리 객체가 기존의 관리 객체와 얼마나 유사한가에 달려 있다. 공통 서비스 클래스를 사용할 때, 그 클래스의 속성도 사용되어 동일한 관리 객체에 대해 다양한 버전/유형을 구별할 수 있다. 새로운 관리 객체 유형이 생성되면, 기타 유사한 관리 객체 클래스를 갖는 임의의 공통 속성과 기능이 공통 베이스 클래스 내에 위치하여 보존을 감소시킨다. 지침을 요약하면 다음과 같다.

·시스템에 대해 고유한 새로운 보존 유닛 유형에 대한 새로운 관리 객체를 생성한다.

·기존의 공통 속성을 제공하는 새로운 보존 유닛 유형에 대한 기존의 관리 객체를 서브클래싱한다(또는 그것이 존재하지 않으면 공통 기능을 베이스 클래스로 이동시킨다). 이것도 여전히 새로운 관리 객체 유형을 초래한다는 것에 주목하여야 한다. 그 한 예는 AP 상의 이더넷(Ethernet) 인터페이스이다. 그들은 모두 공통의 이더넷 기능을 제공하지만, 이더넷 인터페이스 노드(Ethernet interface node : EIN)와 LAN 관리 객체가 있다.

·동일한 관리 객체의 상이한 버전에 대한 버전 속성을 이용한다. 하드웨어 버전과 펌웨어 개정(firmware revision) 속성을 모두 지원할 필요가 있다.

추가적인 기능(그 예로는 IS-634 애플리케이션이 있다)을 지원하는 새로운 AP 프로세서를 추가할 때, 새로운 유형의 관리 객체가 정의되어 그 새로운 유형의 객체를 그 유형의 AP 내에서 관리할 것이다. 모든 AP 프로세서가 추가의 하드웨어와 소프트웨어 엔티티(예를 들어, 이후에 RCS 가상 머신을 호스팅하는 AP의 해제하는 것도 SS7 하드웨어를 갖고 IS-634 기능을 호스트할 수 있다)를 호스팅할 수 있으면, 가능한 관리 객체의 수퍼세트(superset)를 지원하는 MIB가 구성되어 구성요소 관리 시스템 실행시간 프로세스로의 편집을 위해 이용가능하게 된다. 이 접근 방식은 자동 코드 생성을 활용하고, 새로운 객체를 구성요소 관리 시스템에 추가할 때 시간을 절약할 것으로 의도된다. 구성요소 관리 시스템에서는, 추가 서비스 객체가 생성되어 관리 객체의 새로운 클래스의 인스턴스(예를 들어, MMA)의 관리를 지원해야 한다.

휴대성(PORTABILITY)

이 아키텍쳐의 개발은 클라이언트와 서버 컴포넌트의 휴대성을 보장하여야 한다. 이는 여러 가지 방식으로 달성될 수 있다. 머신과 작업 시스템(operating system : OS) 의존 코드는 (특히 서버 내에 다수의 인터페이스가 있을 때) 이를 래퍼 라이브러리(wrapper library)에 둠으로써 가능한 한 은폐되어야 한다. 예를 들어, 구성요소 관리 시스템 로거 클래스(Logger class)는 모든 기존의 적절한 UX 로깅 서비스(UX_ELOG, UX_DLOG, UX_PLOG, UX_ALOG)에 대하여 객체 지향 래퍼를 제공할 것이다. 이는 머신/OS 의존 라이브러리의 구현을 호출 함수나 객체에 영향을 미치지 않고 변경함으로써 플랫폼으로 하여금 새로운 목표를 향하게 한다. 프로세스 간 통신은 대부분의 머신과 OS 플랫폼에 이용가능한 코바와 같은 산업 표준 소프트웨어를 사용할 것이다.

객체 서버 컴포넌트(OBJECT SERVER COMPONENTS)

이 섹션은 객체 서버의 주된 컴포넌트를 상세히 설명한다. 컴포넌트 각각은 구성요소 관리 시스템, 프로세스 또는 클래스로써 나타내지나, 이 섹션에서는 일반적인 컴포넌트로 다루어진다. 대부분의 컴포넌트가 추가적인 애플리케이션을 위해 모든 OAM의 이동을 지원할 인프라스트럭쳐를 제공하기 때문에, 본 명세서의 많은 부분이 (AP에 특정하지 않고) 일반적인 예를 제공하고 있음에 유의하여야 한다.

클라이언트 세션 관리자(Client Session Manager)

클라이언트 세션 관리자는 액티브 클라이언트 세션과 애플리케이션의 리스트를 보유할 것이다. 이는 그 리스트를 주기적으로 감사하여 종료(예컨대, 접속의 실패)를 명시하지 않고 없어진((go away) 세션을 검출한다.

다음 기능이 제공될 것이다.

·세션을 개시하기 위한 클라이언트에 대한 인터페이스.

⇒고유한 세션 식별자 생성

⇒장래에, 클라이언트 보안과 허가를 유효화(보다 상세한 논의를 위해 이전 섹션의 "보안" 참조)

·수동으로 세션을 종료시키기 위한 클라이언트에 대한 인터페이스.

·주기적인 승인(check­in)(고동(heartbeat))을 위한 클라이언트에 대한 인터페이스.

·세션/애플리케이션 종료의 통지에 관심사(interest)를 등록하기 위한 기타 서버 컴포넌트에 대한 인터페이스. 이러한 관심사를 갖는 컴포넌트는 다음과 같다.

⇒그러한 종료 모두에 관심이 있는 이벤트 분산자.

⇒특정 클라이언트 세션/애플리케이션에만 관심이 있는 관리 객체 서비스 클래스.

·액티브 세션/애플리케이션을 주기적으로 감사하여 최근에 임의의 세션/애플리케이션이 승인하는 데 실패했는지를 검사. (설계 시 결정된) 합리적인 시간 내에 승인하는 데 실패한 세션/애플리케이션은 세션 관리자의 액티브 세션/애플리케이션 리스트로부터 삭제될 것이다.

·전술한 콜백 통지 인터페이스를 통해 세션/애플리케이션이 종료하면, 등록된 엔티티를 통지.

이벤트 분산자와 스크리너(Event Distributor and Screener)

이벤트 분산자는 시스템 내 모든 이벤트를 필터링하고 라우팅하는 역할을 한다. (속성 변경 통지가 아닌) 하나 이상의 이벤트의 발생 시 통지될 것을 원하는 클라이언트는 이벤트가 발생할 때마다 이에 부합되는 기준을 특정하는 이벤트 분산자를 이용하여 필터를 등록한다. 클라이언트의 예로는 요약 알람/상태 관리자, ROP 포매터, 관리 객체, 수동 보존 요청을 생성한 클라이언트가 있다. 이벤트의 포매팅은 이벤트 분산자 내에서 수행되지 않으며, 이는 애플리케이션에 남겨진다. 이벤트는 전형적으로 SNMP 중개자에 의한 트랩의 결과로 생성되지만, 동일한 머신 상의 구성요소 관리 시스템 컴포넌트에 의해, 심지어는 기타 상속(legacy)의 네트워크 구성요소에 의해서도 역시 생성될 수 있다. 이벤트 분산자는 객체 서버 내의 객체 세트로 구현될 수 있다. 이벤트 스크리너는 단순히 양단 개방 이벤트 상관(simple, open­ended event correlation)을 위해 이벤트 분산자가 감지하기 전에 이벤트의 스크리닝 지원한다. 이벤트 스크리너는 (클라이언트에 이용가능하지는 않더라도) 이벤트 분산자와 동일한 인터페이스를 지원하나, 객체 서버 내의 사용에 대해서만 지원한다.

다음 서브섹션은 이벤트 스크리너와 이벤트 분산자에 의해 제공되는 기능들이다.

클라이언트 등록 및 필터링(Client registration and filtering)

·다음에 기초하여 필터를 등록하기 위해 IDL 인터페이스(이벤트 분산자만)를 제공한다.

⇒세션 및 애플리케이션 ID

⇒이벤트를 관심 등록자(interested regiserant)로 전달하는 데 사용되는 콜백 객체

⇒클라이언트로 전달될 이벤트를 설명하는 사양을 포함하는 필터 객체. 이 필터는 조합되어 이벤트 세트를 제한할 이벤트 속성 세트의 사양을 제공하는 제한된 파라미터 세트를 허용한다. 이벤트 속성을 위한 특정 값이 주어지거나 속성을 무시하는 데 사용될 수 있는 특정 무정의(don't care) 값이 주어진다.

이 이벤트 필터는 아래 리스트 내에 필드를 보유할 것이다. 이 모든 필드가 세팅될 필요는 없다는 점에 유의하고, 중요하지 않은 것들은 전술한 대로 무정의로 표시될 수 있다.

⇒이벤트 범주

⇒네트워크 구성요소 인스턴스 ID 및 클래스 코드

⇒네트워크 구성요소 알람 레벨

⇒보존 유닛 인스턴스 ID 및 클래스 코드

⇒보존 유닛 알람 레벨

⇒커맨드 ID(클라이언트 ID 및 커맨드 시퀀스 번호)

·클라이언트(이벤트 분산자만)와 기타 객체 서버 컴포넌트를 위한 IDL 인터페이스를 제공하여 명시적으로 특정 필터를 취소한다.

·객체 서버 컴포넌트를 위한 수단을 제공하여 특정 세션 및 애플리케이션과 연관된 모든 필터를 제거한다.

·클라이언트 등록과 필터 기준을 저장할 효율적인 방법과 입력 트랩 상의 이들 필터 기준을 조사할 효율적인 방법을 제공한다.

이벤트 수신(Event Receipt)

·이벤트 스크리너는 (SNMP 중개자로부터 트랩을 수신하고 이들을 EMAPI(55)이벤트 헤더로 번역하는) SNMP 중재기로부터 이벤트를 수신한다.

·이벤트 분산자는 이벤트 스크리너와 기타 객체 서버 서비스 객체로부터 이벤트를 수신한다.

·각각의 저장된 이벤트 필터에 대해 입력 이벤트 헤더를 부합시킨다. 이벤트 헤더는 (위에서 주어진) 이벤트 필터의 필드와 부합되는 필드를 포함할 것이다. 또한, 이벤트 헤더는 다음과 같은 것을 포함할 것이다.

⇒이벤트가 생성된 때를 나타내는 타임 스탬프.

·(그들의 공급된 필터 기준과 부합되는 이벤트에 대한) 클라이언트 공급 콜백 함수를 사용하여 클라이언트에게 트랩의 전달을 제공한다.

·이벤트 분산자는 이벤트 조절(event throttling)에 있어 역할을 하지 않을 것이며, 이 조절은 SNMP 중개자에서 발생할 것이다.

감사(Auditing):

·기타 객체 서버 컴포넌트에 의해 수행되는 감사를 통해 필터 리스트의 클린업(cleanup)을 지원한다. 이러한 지원은 전술한 인터페이스를 통해 또는 내부 콜백 메커니즘을 통해 제공된다. 예를 들어, 클라이언트 세션 관리자가 세선 및/또는 애플리케이션을 그 내부 구조로부터 제거할 때, 클라이언트 세션 관리자는 이벤트 분산자가 그 세션 및/또는 애플리케이션과 연관된 모든 필터를 제거하는 시점에서 콜백을 통하여 이벤트 분산자에게 통지한다.

커맨드와 연관된 필터는 다음 몇몇 상황 하에서 클린업될 필요가 있다.

⇒최종 보고 지표가 커맨드 이벤트 내에서 감지될 때

⇒최종 보고 지표를 포함하는 트랩이 손실됐을 때

이벤트 분산자는 그 영향받은 커맨드와 부합되는 필터나 그 커맨드가 제거되는 시점에서, 위 상황 중 하나가 검출될 때 통지를 받을 것이다.

커맨드 처리기(Command Handler)

다양한 자원이 구성요소 관리 시스템 서버 내에서 활용되어 관리 객체 커맨드를 처리하므로, 커맨드 처리기는 액티브 커맨드를 추적하고 그 커맨드가 완료되면 자원을 해제해야 한다. 액티브 커맨드는 시스템 내의 다른 관리 객체 클래스와 같이 모델링되고, 커맨드 처리기는 액티브 커맨드의 모든 인스턴스에 대한 서비스 객체를 나타낸다. 커맨드 처리기는 이들 커맨드에 대해 중앙집중적으로 추적 및 관리하는 것을 제공한다. 커맨드 응답이 신뢰할 수 없는 SNMP 트랩을 경유하여 전달되므로, 네트워크 구성요소와 커맨드 처리기 사이의 커맨드 활동(activity)에 대한 감사가 수행되어야 한다.

커맨드 블럭(Command Block)

커맨드 블럭은 적어도 다음 필드를 포함할 것이다.

·커맨드 시퀀스 번호

·세션 식별자

·객체 인스턴스 식별자(예컨대, 어느 AP인지 또는 어느 DS1인지)

·커맨드 유형

·커맨드 한정자(Command Qualifier)(선택적)

어떤 커맨드는 추가적인 독립변수(argument)를 필요로 한다. 각각의 커맨드블럭이 별도로 정의되기 때문에, 추가적인 독립변수를 구현하는 것은 간단하다.

커맨드 응답/승인(Command Responses/Acknowledgments)

각각의 중개자는 커맨드 요청이 무효인지 또는 처리될 수 없는지, 더 이상의 응답 없이 요청된 대로 처리될 수 있는지 또는 펜딩된 추가적인 응답을 가지고 진행 중인지를 나타내는 승인 값과 함께 개시 세션 식별자(originating session identifier)와 커맨드 시퀀스 번호를 포함하는 각각의 커맨드 요청에 응답하여 승인 트랩을 생성해야 한다. 후자의 경우, 응답 시퀀스 번호와 최종 보고 지표와 함께 개시 세션 ID와 커맨드 시퀀스 번호도 포함하는 하나 이상의 커맨드 응답 트랩이 생성될 것이다. UDP 메시지가 순서와 상관없이 수신되므로, 응답 시퀀스 번호가 클라이언트 애플리케이션에 의해 사용되어 동일한 커맨드에 대한 다수의 응답을 재정렬(reorder)한다.

커맨드 필터 클린업(Command Filter Cleanup)

최종 보고 지표는 클라이언트 애플리케이션에 의해 사용되어 커맨드 개시 액션(command­initiated action)이 완료되는 때를 표시하고, 서버에 의해서도 사용되어 자동적으로 그 커맨드와 연관된 이벤트 필터를 등록 해제(de­register)시킨다. 각각의 중개자는 진행 중인 모든 커맨드의 세션 IDS와 커맨드 시퀀스 번호를 기재한 액티브 커맨드 테이블을 지원할 것이다. 이 테이블은 서버에 의해 주기적으로 감사되어 최종 보고 트랩이 손실되면 필터 제거를 개시한다.

SNMP 중재기(SNMP MEDIATOR)

이 기능은 EMAPI(55) 클래스 및 속성과, SNMP MIB의 IP 어드레스 및 객체 식별자 사이의 번역을 제공한다. 또한, 적절한 SNMP 요청(보존 요청을 위한 SNMP SET 요청, 폴링 및 감사를 위한 SNMP GET 요청)을 형성하고 응답을 요청자로 라우팅하여 돌려보내는 역할을 한다. 이는 SNMP 요청을 큐잉하고 어떤 단일 네트워크 구성요소 SNMP 중개자도 요청의 돌발에 의해 압도되지 않도록 보장한다. 이 컴포넌트에 대해 어떤 클라이언트도 액세스할 수 없으며, 객체 서버 내의 내부적 사용을 위해서만 존재한다는 점에 유의하여야 한다.

SNMP에서 EMAPI(55)로의 번역(SNMP to EMAPI 55 Translation)

이 기능은 EMAPI(55) 객체 클래스, 인스턴스 클래스, 속성 코드 기호와 SNMP IP 어드레스, SNMP MIB 객체 식별자(Object Identifier : OID), 0 이상의 SNMP 변수 제한(variable binding) 사이의 번역을 수행한다. 객체 서버 내의 객체 세트 및 방법으로 구현될 수 있다.

이 서비스가 수행해야 하는 번역의 유형은 다음과 같다.

·EMAPI(55) 커맨드 객체로부터 SNMP 커맨드 블럭으로

·EMAPI(55) 폴링 응답 객체로부터 SNMP GET로

·EMAPI(55) 인스턴스 ID/ 클래스 코드로부터 SNMP IP 어드레스로

·SNMP GET 응답으로부터 EMAPI(55) 폴링 요청 객체로

·SNMP 트랩으로부터 EMAPI(55) 이벤트 헤더로

·SNMP IP 어드레스로부터 EMAPI(55) 인스턴스 ID/클래스 코드로

객체 서버 인터페이스(Object Server Interface)

객체 서버 내의 관리 객체 클래스에 대한 인터페이스를 제공하여 다음을 지원한다.

·감사(Auditing) : 객체 서버가 서버 상에 항상 보유하려고 하는 (구성요소 관리 시스템 메모리 내에서 일관된) 구성 데이터와 일관된 속성(이들 속성은 다수의 클라이언트에 의해 사용되기 위해 메모리 내에 저장되지만 구성요소 관리 시스템의 재부팅 시 저장되지 않음)의 주기적인 폴링

·폴링(Polling) : 하나 이상의 EM 클라이언트에 의해 요청된 속성의 주기적인 폴링

·1회 상태 요청(One­Time Status Request) : 단일 속성 또는 속성들에 대한 단일 요청

·커맨드 실행 : SNMP SET 요청을 이용하여 커맨드를 발생시킴.

SNMP 인터페이스(SNMP Interface)

SNMP 중재기는 네트워크 구성요소 상의 SNMP 중개자와의 모든 인터페이스를 처리한다. SNMP 인터페이스는 속성 폴링, 구성 감사, 커맨드 실행, SNMP 재시도 메커니즘, 트랩 전달로 이루어진다.

속성 폴링

·HPOV SNMP API 또는 CMU SNMP 라이브러리를 사용하여 각각의 AP 중개자에 대한 SNMP 세션을 확립한다.

·EMAPI(55)로부터 SNMP로의 번역 컴포넌트를 사용하여 EMAPI(55) 기호와 적절한 SNMP GET 요청 사이를 번역한다.

·SNMP GET 요청에 대한 응답을 EMAPI(55) 기호로 번역하여 이를 그와 관련된 관리 객체로 라우팅하여 돌려보내고, 그런 다음, 실제로 변한 값들만을 승인하여 전달한다.

·눈에 띄는 GET와 SET 요청의 개수에 대한 제어를 중개자에게 제공한다. 이는 중개자에서 소켓의 과부화를 방지하게 위해 필요하다.

구성 감사(CONFIGURATION AUDITING)

AP 장비는 최근의 변경을 통해 보존된다. 서브 네트워크 구성요소 레벨 컴포넌트에 대한 구성 정보는 각각의 AP 중개자에 의해 보존된다. 하나 이상의 관리 객체 인스턴스가 AP(예를 들어, RCS)와 관련되면, 각각의 관리 객체는 하나 이상의 구성 속성(예컨대, 셀 번호)에 의해 색인을 단 MIB 테이블에 의해 정의된다. 각각의 테이블은 테이블 엔트리(테이블 카운트)의 현재 번호를 식별하는 다른 MIB 객체와 연관되어 있다. 임의의 테이블에 대한 구성 정보는 테이블 카운트를 위해 GET 요청을 테이블 카운트를 위한 중개자로 보내거나 하나 이상의 GET­BULK 요청을 보냄으로써, 테이블 내의 모든 유효한 행(row)에 대해 (키(key)라고도 알려진) 인덱스 정보를 검색한다. SNMP 중재기는 이러한 방식으로 각각의 테이블을 주기적으로 감사하여 각각의 연관된 관리 객체로 현재 구성 정보를 보고할 것이다.

커맨드 실행(COMMAND EXECUTION)

SNMP 중재기는 EMAPI(55)로부터 SNMP로의 번역 컴포넌트를 사용하여EMAPI(55) 커맨드로부터 적절한 MIB 커맨드 블럭 세팅으로 번역한다. SNMP 중재기는 EMAPI(55) 커맨드를 적절한 MIB 커맨드 블럭으로 번역하고 SNMP SET를 발생시킨다.

커맨드 큐잉(COMMAND QUEING)

SNMP 요청이 UDP를 통해 보내지고 순서없이 중개자에 의해 수신되므로, 관리자와 중개자 사이의 커맨드 요청/응답 컨벤션(convention)은 중개자가 생성될 재시도 회수에 관계없이 단일 커맨드(즉 SET 작업)에 대해 단 한 번만 응답하도록 보장하는 데 활용된다. 관리자는 각각의 네트워크 구성요소를 위해 별개의 커맨드 SET 큐를 유지할 것이다. 네트워크 구성요소 당 커맨드 SET 큐의 크기는 튜닝가능한(tunable) 것이 바람직하다. 임의의 주어진 네트워크 구성요소에 대해 단 하나의 SET 요청만이 한 번에 펜딩(pending)될 것이다. 즉, 커맨드 프로토콜 데이터 유닛(protocol data unit : PDU)은 이전 커맨드로부터의 SET 응답이 수신되기 전에는 그와 관련된 중개자로 보내지지 않을 것이다. 일단 SET 응답이 수신되면, 다른 커맨드가 개시되어 관련 중개자로 보내진다. 각각의 PDU는 단조 증가 요청 ID(monotonically increasing request id)를 보유하는데, 이는 모든 SET 요청마다 중개자에 의해 조사될 것이다. 이 ID가 최종 처리된 것보다 크면, PDU는 새로운 요청을 포함하는 것으로 추정되어 그에 따라 수행될 것이다. 요청 ID가 최종 처리된 것과 같으면, 중개자는 중복되는 패킷이 재시도의 결과라고 가정하고 최종 생성된 응답을 리턴할 것이다. ID가 최종 처리된 것보다 작으면, 이는 관리자가이미 그에 대한 응답(또는 타임아웃)을 수신했을 커맨드에 대한 중복되는 패킷으로 가정되어, 그 패킷은 무시된다.

장애 처리(FAILURE HANDLING)

SNMP 중재기가 응답하지 않은 것으로 알려진 네트워크 구성요소로의 전달을 위해 관리 객체로부터 SET 요청을 수신하면, 그 요청은 수신된 대로 여전히 처리될 것이다. 관련 PDU가 보내지지 않으면, 부정적인 승인이 국부적으로 생성될 것이며, 이벤트 분산자를 통해 원래 클라이언트로 리턴될 것이다.

SNMP 재시도 메커니즘(SNMP RETRY MECHANISM)

SNMP가 기본적인 전송 프로토콜과 마찬가지로 UDP에 의존하므로, SNMP GET, GET BULK, SET 작업이 실패할 수 있다. 실패로부터 회복하기 위해, SNMP 중재기는 모든 GET, GET BULK, SET 작업과 일치하며 HPOVNNM SNMP 라이브러리나 CMU SNMP 라이브러리에 의해 규정된 인터페이스를 따르는SNMP 트랜잭션을 재시도하는 메커니즘을 사용할 것이다. 보다 많은 정보를 얻으려면, 본 명세서의 앞부분에서 참조로써 인용된 HPOVNNM이나 CMU SNMP 라이브러리를 참조하라. 사전정의된 최대 재시도 회수만큼 각각의 요청에 대해 시도될 수 있다. 대수적으로 증가하는(logarithmically increasing) 튜닝가능한 타임아웃이 있다(요청 당 12 초의 최대 재시도 지연에 대한 디폴트(default)가 제안된다). 임의의 요청에 대한 응답이 최대 재시도 회수 이후에도 수신되지 않으면, 이 네트워크 구성요소와 관련된 각 관리 객체는 통신의 실패를 통지받고 국부적 이벤트가 생성되어, ECP ROP로 전달되는 알람 출력 메시지를 발생시킨다. 내부 상태 테이블 내의 상태 값은 그에 따라 세팅되며, 이들 변경은 콜백을 통해 등록된 클라이언트에게 전달될 것이다. 네트워크 구성요소에 대한 폴링 큐는 후속의 감사 또는 임의의 트랩이, 중개자가 온라인 상태로 돌아와 있다는 것을 나타낼 때까지 아이들 상태가 된다.

트랩 수신 및 전달(TRAP RECEIPT AND DELIVERY)

SNMP 중재기는 SNMP 중개자로부터 트랩을 수신할 것이다. 이 메커니즘의 개요는 다음과 같다.

·초기화 시, HPOV SNMP 인프라스트럭쳐로 트랩 세션을 개방한다.

·각각의 트랩에 대해, SNMP 트랩 PDU를 EMAPI(55) 이벤트 헤더로 번역한다.

·각각의 EMAPI(55) 이벤트를 필터링과 등록된 클라이언트로의 전달을 위해 이벤트 스크리너로 전달한다.

MIB로부터 IDL로의 매핑(MIB­to­Mapping)

MIB 변경과 해당 EMAPI(55) 관리 객체 기호의 보존을 자동화할 수단이 제공될 것이다. ASN1 MIB 분석자를 포함하는 엔진이 사용되어 IDL 및 그 MIB에 의존하는 기타 파일들을 생성할 것이다. 목표는 핸드 크래프트되고(hand­craft) 보존된 IDL의 양을 최소화하는 것이 될 것이다.

MIB 컨벤션(MIB Convention)

MIB 컨벤션은 AP 중재기의 개발에 따라 정의되고 기록될 것이다.

서비스 객체 묘사 및 인프라스트럭쳐(SERVICE OBJECT DESCRIPTION AND INFRASTRUCTURE)

서비스 객체는 시스템 내의 네트워크 구성요소, 보존 유닛 또는 논리적 객체의 각 클래스를 위해 존재한다. 도 4에 도시한 바와 같이, 이들은 SnmpNEMO와 SnmpMO 클래스 객체로 표시된다. 각각의 서비스 객체 인스턴스는 클라이언트 애플리케이션 액세스를 위해 서버를 제공하고, 그 클래스 내의 관리 객체의 모든 인스턴스에 대해 (요구되는 대로) 속성의 관찰을 보존한다. 서비스 객체의 예로는 AP, RCS, DS1이 있다. 논리적 서비스 객체의 예로는 System과 APSummary가 있다. 도 8은 관리 객체 클래스와 AP를 관리하는데 사용될 그들의 컨테인먼트 관계(containment relationship)를 도시한다. 또한 도 8은 가까운 장래에 추가되어 다른 원격 통신 네트워크 구성요소를 관리할 서비스 객체의 몇몇 예를 도시한다. 도시한 OAM은 구성요소 관리 시스템을 호스트할 수 있다.

속성 값을 보유하고 속성 변경에 대한 클라이언트 통지를 제공하기 위해, 각각의 서비스 객체는 현재 구성 데이터와 클라이언트 폴링 요구에 따라 동적인 크기를 갖는 상태 테이블을 보유한다. 이 테이블 내의 정보는 속성 코드와 유형 정보를 포함하는 클래스 딕셔너리(class dictionary)를 통해 식별될 것이며, 서버와 클라이언트 코드 모두에 대한 공통 인터페이스를 통해 이용가능할 것이다. 예를 들어, AP 객체는 보존 상태에 대한 속성을 포함할 수도 있다. 클라이언트 애플리케이션은 인스턴스 식별자와 속성 코드를 수용하는 클래스 방법을 통해 특정 AP에 대한 그 상태 정보를 액세스할 것이다. 서비스 객체는 네트워크 구성요소 상태가 기록된 중앙화된 장소를 제공한다. 각각의 애플리케이션이 필요한 속성에 대해 폴링하는 대신, 서비스 객체는 등록된 클라이언트와 그들이 등록된 속성의 리스트를 관리한다. 그런 다음 조합된 세트는 SNMP 중재기에 의해 폴링된다. 제거, 회복, 진단 등과 같은 유닛 유형에 특정한 작업을 수행하기 위해 추가적인 클래스 방법이 제공될 것이다. 네트워크 구성요소와의 통신을 위해 사용되는 특정 프로토콜은 서비스 객체에 의해 특정된다. SNMP 프로토콜은 AP와 연관된 서비스 객체와 AP 네트워크 구성요소 사이의 통신을 위해 사용된다. 상이한 프로토콜을 활용하고 관리 객체 클래스 내의 지식을 포함하는 기타 관리 객체 클래스가 추가될 수 있다. 도 9는 AP 서비스 객체와 그 자신이 포함하는 데이터를 도시한다. 또한, 통신을 위해 SNMP가 아닌 프로토콜을 사용할 수 있는 ECP 관리 객체의 예를 도시한다.

클라이언트 통지 및 요청/응답(CLIENT NOTIFICATION AND REQUEST/RESPONSE)

각각의 서비스 객체는 자신의 관리 객체 인스턴스의 속성에 대한 클라이언트 액세스를 위한 방법을 제공할 것이다. 속성의 현재 값을 요청하는 것 외에도, 클라이언트는 속성 값에 대한 임의의 변경을 통지하기 위해 등록할 수 있다. 속성과, 속성 통지를 위한 등록에 대한 클라이언트 액세스는 다음의 관점에서 특정된다.

·관리 객체의 특정 인스턴스에 대한 속성 세트

·초기 속성 값과 후속 변경의 전달을 위한 클라이언트 콜백 함수

모든 속성 값은 클라이언트가 제공한 콜백 객체 참조(client supplied callback object reference)에 의해 클라이언트로 전달된다. 속성 코드 및 값쌍의 시퀀스는 콜백 객체 참조의 독립 변수로써 보내진다. 초기 통지에서, 그 시퀀스는 요청된 모든 속성 값을 포함한다. 속성 변경의 후속 통지에서, 그 시퀀스는 변화된 속성만을 포함한다.

클라이언트 커맨드 요청/응답(CLIENT COMMAND REQUEST/RESPONSE)

네트워크 구성요소 클래스 또는 보존 유닛에 대한 각각의 서비스 객체는 멤버 함수를 제공하여 네트워크 구성요소 클래스 또는 보존 유닛의 특정 인스턴스에 대한 작업에 대한 요청을 구현한다. 예를 들어, AP 내에 있는 서비스로부터 DS1 유닛을 제거하기 위해, DS1 서비스 클래스의 제거 방법이 요청된다. 임의의 다른 클라이언트 요청과 같이, 클라이언트는 이 작업을 수행하기 전에 세션을 형성해야 한다. 보존 유닛의 특정 인스턴스와 임의의 커맨드 특정 파라미터가 특정되어야 한다. 작업은 클라이언트 세션에 대해 고유한 커맨드 시퀀스 식별자(commandSeq)를 리턴할 것이다. 커맨드 시퀀스 식별자는 그 커맨드에 대한 모든 후속 이벤트(승인 및 커맨드 응답)를 위해 헤더 내에 존재한다.

일단 작업이 서버에서 유효화되면, 클라이언트 세션과 커맨드와 관련된 그 커맨드 시퀀스 식별자와 부합되는 모든 이벤트에 대한 이벤트 분산자를 이용하여 클라이언트에 대해 필터가 등록된다. 이벤트 필터를 성공적으로 등록한 후, 인스턴스가 적절한 IP 어드레스와 MIB 커맨드 블럭 값으로 변환된 SNMP 중재기로 보내지고 적절한 SNMP SET 요청을 생성한다. 커맨드 승인과 커맨드 응답이 SNMP 중개자로부터 SNMP 트랩에 의해 전송된다. 서버에서, 이들은 이벤트로 변환되어 부합되는 이벤트 필터를 갖는 클라이언트로 라우팅된다. 구성요소 관리 시스템이 (SNMP 중재기 섹션에서 상세히 설명한) 관련 SETRSP를 수신하지 못한 경우 SET 요청에 대한 재시도 메커니즘이 있으나, 커맨드가 실패하면(오류(failover)가 진행 중인 경우와 같이) 재시도를 할 수 없음을 유의하여야 한다.

시스템이 개시한 커맨드와 응답은 고유의 시스템 세션 식별자와 콜백 함수를 사용하여 유사하게 라우팅될 것이다. 이러한 유형의 커맨드의 예로는 논리적 서비스 객체가 요청을 서비스하고 응답을 생성하는 역할을 하는 시스템 상태(OP)를 출력하는 요청을 포함한다. 이들 커맨드는 구성요소 관리 시스템 서버 내에서 처리되며 SNMP 인터페이스를 통해 네트워크 구성요소에 의해 처리되지 않는다. 구성요소 관리 시스템 서버가 커맨드에 내부적으로 응답하고 있으므로, 구성요소 관리 시스템 서버는 커맨드 승인과 커맨드 응답 이벤트 자체를 생성해야 한다.

네트워크 구성요소 중개자는 커맨드 요청이 수용되었는지를 나타내는 승인 트랩을 제공하는 역할을 한다. 그런 다음, 커맨드의 결과는 하나 이상의 일련의 커맨드 응답 트랩에 의해 네트워크 구성요소 중개자로부터 전달된다. 최종 커맨드 응답 트랩은 서버 내에서 사용되어 커맨드의 종료를 감지하고 그 커맨드와 관련된 서버 자원(이를테면 이벤트 필터)을 해제하는 최종 응답이나 최종 보고 지표를 포함한다. 커맨드 응답이 손실될 수도 있으므로, 커맨드 활동(activity)의 저 레벨감사가 관리자와 네트워크 구성요소 중개자 사이에서 수행되어야 한다. 감사는 중개자가 커맨드 응답 정보를 보유할 것을 요구하지 않는다. 감사는 커맨드가 중개자에서 여전히 실행되고 있는지를 조사할 뿐이다. 커맨드 응답이나 트랩이 손실된 경우, 손실된 응답을 재생할 회복 방법은 없다. 네트워크 구성요소가 커맨드 승인을 생성할 수 없거나 승인이 구성요소 관리 시스템 서버에 수신되지 않은 경우, 구성요소 관리 시스템 서버는 적절한 승인을 생성하여 클라이언트에게 보내는 역할을 한다. 다음은 구성요소 관리 시스템 서버가 승인 이벤트를 생성하여 클라이언트에게 되돌려 보내는 역할을 하는 경우를 요약한다.

1. 커맨드 블럭 SET PDU를 중개자로 전송할 수 없다.

2. (SET 요청의 반복된 재시도 후) 중개자로부터 SETRSP가 수신되지 않았다.

3. 중개자로부터의 SETRSP가 (무효 객체 식별자와 같은) 에러를 표시한다.

중개자가 SET 요청을 수신하고 그 내용을 "파악"할 수 있는 기타 모든 경우, 중개자가 승인을 생성하여 클라이언트에게 보내는 역할을 한다.

객체 속성(OBJECT ATTRIBUTES)

다음 유형의 속성은 각각의 관리 객체와 연관될 수 있다. 각 속성의 범주에 대해, 속성 데이터의 소스는 서로 다르다(예를 들어, 네트워크 구성요소 트랩, 네트워크 구성요소 폴링, 구성요소 관리 시스템 국부 데이터). 모든 관리 객체가 모든 범주의 속성을 지원할 필요는 없고, 대신 속성의 존재가 관리 객체의 필요에 기초한다(이를테면, 몇몇 관리 객체는 어떠한 상태 속성도 갖지 않으나, 알람 속성을 갖는다).

지속 속성(PERSISTENT ATTRIBUTES)

관리 객체를 위한 상태 및 알람 속성은 그 속성에 대해 어떤 클라이언트도 등록되어 있지 않은 경우에도 항상 보존된다. 이들 속성은 네트워크 구성요소로부터의 트랩 통지에 의해 갱신되고 (Snmp 중재기에 의해 제어되는 저 레벨 주기적 감사 폴링에 의해 감사된다). 보존 상태는 상태 변경 통지에 의해 전달되고, 알람 레벨 속성은 알람 세트/클리어 통지에 의해 전달된다.

구성 속성(CONFIGURATION ATTRIBUTES)

이들 속성은 구성과 관련된 정보로 이루어진다. 이들 속성은 관리 객체의 구성 변경에 대한 이벤트 통지의 결과로 갱신된다. 구성의 삽입 또는 갱신을 나타내는 구성 이벤트 통지가 수신되면, 관리 객체는 단일 요청을 수행하여 특정된 것에 대한 모든 속성의 현재 값을 얻는다(또한 이는 SNMP 내에서 트랩 지향 폴링(trap directed polling)으로 알려져 있다). 구성 이벤트가 구성 삭제를 표시하면, 관리 객체는 인스턴스와 관련된 것에 대한 삭제를 수행한다. 지속 속성에서와 같이, 컨피그(config) 속성은 Snmp 중재기에 의해 제어되는 저 레벨 주기적 폴링에 의해 감사된다(사실상, 동일한 감사이다). 이러한 유형의 속성의 예로는 apLogicalId가 있다. SNMP 중개자가 재부팅될 때 컨피그로 표시된 몇몇 속성만이 변한다는 점에 유의해야 한다. 따라서, 네트워크 구성요소는 이러한 속성에 대한 임의의 컨피그 변경 통지를 결코 발생시키지 않는다. 컨피그 통지가 관리 객체의 새로운 인스턴스를 위해 수신될 때, 관리 객체가 기타 컨피그 속성과 함께 그들의 값을 요구하므로, 이들은 컨피그로 분류되어야 한다.

감사 속성(AUDIT ATTRIBUTES)

이들 속성 값은 주기적인 저 레벨 감사를 통해서만 보존된다. 이러한 유형의 속성의 예로는 액티브 커맨드 테이블 커맨드 세션과 커맨드 시퀀스 번호가 있다.

폴링된 속성(POLLED ATTRIBUTES)

이들 속성의 현재 값은 클라이언트가 그 속성에 대한 변경의 통지를 위해 등록될 때만 보존된다. 이들 속성은 SNMP 중재기에 의해 15 초의 폴링 레이트로 폴링된다. 그 예로는 AP sysUpTime 속성이 있다.

내부 속성(INTERNAL ATTRIBUTES)

이들 속성은 내부 데이터에 기초하거나 다른 속성으로부터 얻어진다. 그 예로는 AP 네트워크 구성요소 내에서 고립된 속성이 있다. 그 값은 통신이 네트워크 구성요소에서 실패하였을 때 (또는 나중에 회복되었을 때), SNMP에 의해 검출된 고립 지표(isolation indication)에 기초한다. SNMP 기반 관리 객체에 있어서, 내부적이지 않은 모든 속성은 관련 MIB 속성을 직접 나타낸다.

서비스 객체 기반 클래스 기능(Service Object Base Class Functionality)

각 객체의 기본적 성향은 특정 관리자 기능을 포함하는 베이스 클래스의 상속(inheriting)에 의해 드러난다. 예를 들어, 클라이언트 등록과 폴링은 모든 서비스 객체를 통해 공유되는 베이스 클래스 내에 정의될 것이다. 다음 섹션은 모든 서비스 객체 클래스에 대해 이용가능한 이들의 공통적인 성향을 설명한다.

관리 객체 베이스 클래스(MANAGED OBJECT BASE CLASS)

이 클래스는 모든 관리 객체가 지원해야 하는 기본 인터페이스에 대한 정의를 제공한다. 이는 관리 객체 구성 통지와 속성 갱신 통지와 같은 것들에 대한 클라이언트 인터페이스를 제공하는 것을 포함한다. 특정 서비스 객체는 이들 베이스 클래스를 모두 상속할 것이다.

NE 관리 객체 베이스 클래스(NE MANAGED OBJECT BASE CLASS)

(관리 객체 베이스 클래스로부터 얻은) 이 클래스는 기본 관리 객체 클래스에 가까운 네트워크 구성요소 특정 기능을 제공한다. 이는 네트워크 구성요소 구성 통지를 위한 클라이언트 인터페이스를 제공하는 것을 포함한다. 이는 구성 데이터 서비스(AP 장비 변경)로부터의 네트워크 구성요소 관련 장비 통지를 처리하고, 이들 변경을 SNMP 중재기에게 통지하는 역할을 한다. 관리 객체와 네트워크 구성요소 사이의 적절한 라우팅과 번역을 제공하기 위해, SNMP 중재기는 이들 변경을 통지받아야 한다. 특정 네트워크 구성요소 서비스 객체는 이 베이스 클래스 모두를 상속할 것이다.

클라이언트 통지 등록(CLIENT NOTIFICATION REGISTRATION)

각각의 서비스 객체는 등록되어 있는 클라이언트와 속성의 리스트를 관리해야 한다. 이 리스트는 세션 처리, 속성 코드 리스트, 특정 관리 객체 인스턴스를 위한 인스턴스 식별자를 포함하여야 한다. 이 기능은 또한 등록된 클라이언트가 변경을 통지받을 수 있도록, 속성 코드와 인스턴스 식별자에 기초하여 이 리스트를 효율적으로 검색하는 방법을 제공하여야 한다. 클라이언트 등록은 클라이언트 세션 관리자의 조정을 받아 비정상적인 클라이언트 종료가 감지되면 순조로운 클린업(graceful cleanup)을 제공해야 한다.

클라이언트 등록 기능(The client registration functionality):

·다음 파라미터가 주어진 속성 등록을 위한 클라이언트에 대한 인터페이스를 제공한다.

·클라이언트 세션 id

·관리 객체 인스턴스 식별자(특정 id, 범위 또는 모두 클래스 내)

·속성 코드 세트

·변경의 전달을 위한 콜백 함수

·클라이언트 등록 리스트를 관리하기 위한 일반적인 컨테이너(container)와 데이터 구조를 제공한다.

·속성 코드/값을 갖는 클라이언트 콜백의 구축과 전달 방법을 제공한다.

·등록 해제를 위한 클라이언트와의 인터페이스를 제공한다.

·비정상적인 클라이언트 종료가 감사를 통해 감지되면 해제를 위한 클라이언트 세션 관리자와의 인터페이스를 제공한다.

폴링된 속성 관리(POLLED ATTRIBUTE MANAGEMENT)

속성 폴링은 구성요소 관리 시스템 초기화(예를 들어 구성요소 관리 시스템 초기화 시, 상태를 얻는 유일한 방법은 폴링을 통해서이다), 트랩 지향적이 아닌 속성 값, 감사(즉, UDP는 신뢰할 수 없는 전달이고, 따라서 트랩이 손실될 수도 있다)를 위해 필요하다. 트랩 지향적 속성은 다수의 클라이언트의 사용을 위해 메모리 내의 구성요소 관리 시스템 상에 저장된다. 또한, 그 값을 폴링을 통해서만 얻을 수 있어서, 클라이언트가 객체에게 그들 변수의 상태 변경 통지에 관심이 있다는 것을 통지할 때 비로소 폴링이 초기화되는 다른 속성이 존재할 수 있다. 그런 경우, 객체는 SNMP 중재기가 일정한 간격(15 초)마다 네트워크 구성요소를 폴링하도록 요청하여 관심 변수 중 어느 것이 변했는지를 판단하여야 한다. 변경이 검출되면, 등록된 클라이언트는 클라이언트 콜백에 의해 통지받아야 한다. 이들 폴링된 속성도 메모리에 저장된다. 이들 속성의 관리자는 다음과 같다.

·속성 테이블(속성 테이블의 할당, 인스턴스 식별자 관리, 구성 변경에 기초한 속성 테이블의 변경)을 보존한다.

·SNMP 중재기에게 폴링될 속성의 현재 세트를 통지한다. 클라이언트가 등록하면(또는 등록 해제하면), 폴링되어야 하는 속성 세트가 변하게 된다. 그러면, SNMP 중재기는 통지받아야 한다.

·SNMP 중재기로부터의 폴링 응답을 처리한다. 폴링된 데이터 세트가 (서버 콜백 함수를 통해) 전달되면, 속성 값은 속성 테이블 내의 현재 값과 비교되어야 한다. 값이 변했으면, 속성 테이블 내의 값은 갱신되고, 클라이언트는 그 변경을 통지받아야 한다. 하나 이상의 속성이 관리 객체 인스턴스에 대해서 변했으면, 그 변경은 그룹화되어 관리 객체 인스턴스 기반(basis) 상의 각각의 등록된 클라이언트에게 전달될 것이다.

트랩 지향 속성 폴링 관리(TRAP DIRECTED ATTRIBUTE POLLING MANAGEMENT)

SNMP를 활용하는 네트워크 구성요소에 대해, 모든 알람, 구성 변경, 기본 상태 변경(비 알람 보존 상태를 포함)이 중개자로부터 관리자로 기획 특정 SNMP 트랩(enterprise specific SNMP trap)을 통해 전달된다. 이들 트랩은 그들을 EMAPI(55) 이벤트로 번역하는 SNMP 중재기에 의해 수신되고 이벤트 분산자를 따라 전달된다. 이어서, 그들은 관련 이벤트 내의 데이터와 부합되는 필터를 등록한 모든 클라이언트에게 전달된다. 각 객체 클래스의 요약 알람/상태 기능은 필터를 이벤트 분산자를 이용하여 등록하여 그 클래스 내의 객체의 모든 인스턴스를 위한 모든 알람과 상태 변경 이벤트의 전달을 요청한다. 알람이나 상태 변경 이벤트가 요약 알람/상태 관리자에 의해 수신되면, 적절한 인스턴스에 대한 속성이 갱신되고, 그 클래스에 대한 요약 속성이 갱신되며, 영향을 받은 속성에 대한 상태 변경 통지의 객체를 이용하여 등록된 모든 클라이언트가 그들의 클라이언트 콜백 함수를 통해 통지받는다.

·이 관리 객체 클래스의 인스턴스에 대한 모든 이벤트(알람, 상태 변경, 구성 통지)를 위한 이벤트 분산자를 이용하여 적절한 필터를 등록한다.

·이벤트 분산자로부터의 이벤트를 처리한다. 트랩이 수신되면, 이벤트 내의 속성 값이 속성 테이블 내의 현재 값과 비교된다. 값이 변했으면, 속성 테이블 내의 값은 갱신되고 클라이언트는 변경을 통지받아야 한다.

·SNMP 중재기와 인터페이스하여 트랩과 관련된 관리 객체 클래스 내의 속성에 대해 덜 빈번히 (감사) 폴링을 수행한다.

·SNMP 중재기로부터의 덜 빈번히 감사 폴링한 응답을 처리한다.

클라이언트 인터페이스 컴포넌트(CLIENT INTERFACE COMPONENT)

다음 섹션은 구성요소 관리 시스템 서버의 클라이언트 상에 존재하여 NE 관리 특정 클라이언트 인터페이스 스타일에 대한 클라이언트 인터페이스를 제공하는 컴포넌트를 설명하며, 그 내용은 휴먼 팩터(human factor)로부터의 입력과 구성요소 관리 시스템 엔지니어링을 갖는 아키텍쳐 다음에 소개될 것이다. 클라이언트 인터페이스를 가능한 한 사용하기 쉽게 만드는 것 외에도, 클라이언트 인터페이스는 최종 클라이언트(기술자)의 재교육이 거의 필요하지 않도록 현재 보존 모델과 유사점을 갖고 있어야 한다. 샘플 웹 페이지가 이 명세서에 첨부되어 있다.

AP 또는 네트워크 구성요소 텔넷 액세스(AP OR NETWORK ELEMENT TELNET ACCESS)

시스템 관리와 몇몇 구성 기능을 수행하기 위해, 그리고 구성요소 관리 시스템이 작업하지 않는 경우 AP 커맨드 라인 해석기를 액세스하는 수단으로서, AP를 직접적으로 컷스루(cut­through) 액세스할 필요가 있다. 이러한 액세스를 제공하기 위해, 클라이언트 플랫폼은 텔넷(telnet) 애플리케이션과 적절한 터미널 에뮬레이션(terminal emulation)을 지원하여 vi와 같은 시각 편집기(visual editor)를 실행시켜야 한다. X 터미널 상에서는, xterm 터미널 에뮬레이터와 텔넷 애플리케이션의 사용으로 충분할 것이다. 마이크로소프트 윈도우즈 플랫폼 상에서는, X 터미널 에뮬레이터를 사용하여 X 터미널과 동일한 엑세스를 제공하거나, PC 상의 윈도우즈 텔넷 애플리케이션이 사용될 수 있다.

웹 브라우저(WEB BROWSER)

주된 클라이언트 인터페이스는 HTML 웹 브라우저에 의해 제공된다. 넷스케이프 네비게이터(Netscape navigator)와 마이크로소프트 인터넷익스플로러(Microsoft Internet Explorer) 모두 지원가능하다. 웹 브라우저는 Java 1.1 애플릿과 적어도 HTML 버전 3.2의 실행을 지원해야 한다. 다음의 클라이언트 터미널 구성이 지원되어야 한다.

·구성요소 관리 시스템 상에서 실행되는 넷스케이프 브라우저를 갖는 X 터미널

·워크스테이션 상에서 실행되는 넷스케이프 브라우저를 갖는 선(Sun) 워크스테이션

·PC 상에서 실행되는 넷스케이프나 마이크로소프트 IE 중 하나를 갖는 PC(윈도우즈 95 또는 NT 4.0)

웹 페이지(WEB PAGES)

AP를 위한 웹 기반 네트워크 관리 액세스를 제공하기 위해, 다음 기능을 제공하는 웹 페이지가 개발되어야 한다. 도 10, 11, 12, 13은 샘플 페이지 레이아웃(layout)을 도시한다.

1. 최상 레벨 페이지 : 시스템에 대한 초기 엔트리. 선택 메뉴와 잠재적인 고 레벨 시스템 상태 메뉴를 보여준다.

2. 네트워크 페이지 : AP 시스템 레벨 요약 애플리케이션을 호스트한다.

3. AP 페이지 : 단일 AP를 위한 AP 세부 NE 상태 페이지를 호스트한다. 이 페이지의 버전은 URL 내의 AP 논리적 번호에 기초하여 "진행 중(on the fly)"으로 구축된다. AP 논리적 번호와 기타 파라미터는 AP 상세 NE 상태 애플릿으로 전달된다.

4. 알람 페이지 : 알람 리스트 애플릿을 호스트한다.

페이지 레이아웃과 네비게이션은 휴먼 엔지니어링 팩터를 가지고 작업함으로써 결정된다는 것에 유의하여야 한다.

클라이언트는 다음을 할 수 있어야 한다.

1. 각각의 페이지를 직접 액세스한다. (웹 ID 유효화를 통한) 안전한 액세스가 이들 페이지로의 초기 액세스를 위해 제공되어야 하지만, 동일한 브라우저 세션이 사용되는 동안 후속 페이지로의 요청에 대해서는 제공되지 않는다.

자바 기반 GUI 인프라스트럭쳐(JAVA­BASED GUI INFRASTRUCTURE)

이 섹션은 AP 특정 GUI 애플릿을 구현하는데 필요한 기본 컴포넌트를 설명한다. 다수의 이들 컴포넌트(특히 GUI 컴포넌트)는 (예를 들어 로그 웨이브 제이위젯(Rogue Wave JWidgets)이나 미크롤린의 그리드 위젯(Microline's Grid widget)과 같은) 상업적인 3차 파티 제품(3rd party product)으로 만족할 것이다(또는 이에 기초할 것이다). 또한, 3차 파티 비 GUI 컨테이너와 알고리즘 클래스(예컨대, 로그 웨이브나 JGL 중 하나)는 Java 개발 키트와 함께 사용되는 세트를 향상시킬 것으로 간주되어야 한다.

다음 섹션들은 이 아키텍쳐를 사용하는 애플리케이션을 설명한다.

AP 요약 애플리케이션(AP Summary Application)

이 애플리케이션은 시스템 내의 모든 AP 프로세서에 대한 요약 정보를 제공한다. 요약 정보는 모든 AP 프로세서에 대한 최상위 알람 레벨, 관리 상태, 장비 상태로 이루어진다. 디스플레이된 요약 정보 구성에 대한 어떤 변경도 변경 후 30 초 이내에 디스플레이 상에서 갱신된다. 상태 변경은 AP 내의 상태 변경 후 15 초 이내에 디스플레이될 수 있다. 요약 및 장비 정보를 나타내는 것 외에도, 애플리케이션은 각각의 AP 프로세서에 대한 세부 상태 페이지로의 네비게이션을 지원한다. 또한, (예를 들어 RMV AP와 같은) AP 커맨드의 실행을 위해, 팝 업 메뉴(pop up menu) (와 필요한 임의의 다이얼로그 박스(dialog box))를 제공한다. 또, 커맨드 응답 영역이나 다이얼로그 박스가 커맨드 응답의 디스플레이를 위해 제공된다.

이 애플리케이션은 (클라이언트 세션 객체를 통해) 구성요소 관리 시스템 서버를 갖는 세션을 개시하고, AP 네트워크 구성요소 요약(예컨대, 최상위 알람 레벨과 상태 요약)의 디스플레이를 제공할 필요가 있는 구성 정보와 속성을 위해 네트워크 구성요소 서비스 객체(AP 객체)를 이용하여 등록한다. 속성 값의 초기 세트는 클라이언트로 전달되고, 이들 속성에 대한 임의의 후속 변경된 것도 (서비스 객체 내의 요약 알람/상태 관리자로부터) 전달된다. 클라이언트가 속성의 "재로드(reload)"를 요청하지 않는 한, 변경된 속성들만이 후속 콜백으로 전달됨에 유의하여야 한다.

샘플 네트워크 웹 페이지가 본 명세서에 첨부되어 있다.

네트워크 구성요소 세부 상태 애플리케이션(Network Element(NE) Detailed Status Application)

이 애플리케이션은 AP 네트워크 구성요소 내의 보존 유닛의 상태를 세부적으로 보여준다. 디스플레이된 요약 정보의 구성에 대한 변경은 변경 후 30 초 내에 디스플레이 상에서 갱신된다. 상태 변경은 AP 내의 상태 변경 후 15 초 내에 디스플레이될 수 있다. 이 애플리케이션은 (시스템 객체를 통해) 객체 서버로 세션을 개시하고 AP 구성요소 상태의 디스플레이를 제공할 필요가 있는 속성에 대한 AP 서비스 객체(특정 네트워크 구성요소 인스턴스와 보존 유닛)를 이용하여 등록한다. 속성 값의 초기 세트는 클라이언트에게 전달되고, 이들 속성의 임의의 후속 변경된 것은 (서비스 객체 내의 속성 관리자로부터) 전달된다. 클라이언트가 속성의 "재로드"를 요청하지 않는 한, 변경된 속성만이 후속의 콜백으로 전달된다. 세부 상태 애플리케이션도 풀다운(pull down) (또는 팝업) 메뉴를 사용하여 컨텍스트에 민감한 커맨드 실행(context sensitive command execution)을 제공할 것이다. 커맨드 실행과 커맨드 결과의 디스플레이를 위한 인터페이스는 앞서 "커맨드 처리기" 섹션에서 설명한 인터페이스와 동일하다.

샘플 AP 웹 페이지가 본 명세서에 첨부되어 있다.

알람 리스트(액티브 알람 브라우저) 애플리케이션(Alarm List(Active Alarm Browser) Application)

이 애플리케이션은 시스템 내의 액티브 알람에 대한 알람 브라우저 인터페이스를 제공한다. 클라이언트는 필터를 지정하여 (이를테면, 네트워크 구성요소, 알람 레벨 등에 의해) 알람의 세트를 제한한다. 이 애플리케이션은 EMAPI(55)를 통해 액티브 알람 관리자를 이용하여 자신의 필터와 콜백 함수를 등록한다. 필터 기준과 부합되는 액티브 알람의 초기 세트는 후속의 갱신과 함께 클라이언트에게 전달되어 알람을 세팅하거나 클리어한다. 순조로운 종료(graceful termination) 시, 클라이언트는 액티브 알람 관리자로부터 연결을 해제한다(또는 액티브 알람 관리자 내의 내부 감사가 이를 감지하고 클린업(clean up)한다).

샘플 알람 웹 페이지가 본 명세서에 첨부되어 있다.

위치 텍스트 포매팅 서비스(LOCALE TEXT FORMATTING SERVICES)

이 서비스는 다수의 인간의 언어를 지원하기 위한 인프라스트럭쳐를 제공한다. 이 서비스는 텍스트의 디스플레이를 통해 최종 클라이언트와 상호작용하는 임의의 애플리케이션 의해 사용되며, ROP 포매팅 프로세스, 웹 기반 클라이언트 애플리케이션, 구성요소 관리 시스템 상의 임의의 위치 로깅을 포함한다.

다음 기능이 제공될 것이다.

·포매팅을 위해 클라이언트에 의해 사용되는 텍스트 포매팅 스트링의 데이터베이스를 액세스한다.

·참조(lookup)는 통합 키에 기초하며, 해당 아스키 스트링(ASCII string)이 리턴된다.

·데이터베이스는 키와 아스키 값을 포함하며 디스크 상에 상주할 것이다. 이 저장 포맷과 저장 메커니즘(caching mechanism)은 참조 속도를 최소화하도록 설계될 것이다.

·지역 및 원격 클라이언트 모두 서비스될 수 있다.

·X/Open CAE(XPG4) 소스 메시지 파일 포맷에의 부착(adherence)

커맨드와 보고(COMMANDS AND REPORTS)

각각의 관리 객체 클래스는 관리 객체 베이스 클래스에 의해 특정되는 인터페이스에 부착될 것이고 (클라이언트 속성 등록, 통지, 구성 등록, 통지를 제공), 그 클래스 내의 관리 객체의 모든 인스턴스를 위한 장비, 알람, 상태를 관리할 것이다. 또한, 각각의 클래스는 관리 객체 특정 커맨드를 구현하는 방법을 제공할 것이다. 이들 방법은 적절한 독립 변수 유효화(예를 들어, 범위 확인, 커맨드가 실행되기 전에, 목표 네트워크 구성요소가 구비된다)를 구현할 것이다.

AP가 생성한 보고 외에도, 구성요소 관리 시스템은 다음과 같은 상황에 대한 보고를 생성한다. 통신이 AP에서 실패하고, 통신이 AP에서 확립되며(콜드 개시 트랩(cld strart trap)), 모든 AP가 서비스를 제공하지 못한다.

과부하 제어(OVERLOAD CONTROL)

구성요소 관리 시스템 서버 내에서 과부하 제어는 (본 명세서에서와는 반대로) 설계에 있어서 가장 중요하게 간주된다. 특히, 상태 요청(폴링, 감사, 1회 GET 요청(one­time GET request))은 구성요소 관리 시스템에 의해 동시에 지원되는 HPOV 세션의 개수와 각각의 AP에 대해 관리되는 튜닝가능한 슬라이딩 윈도우(tunable sliding window)의 크기에 의해 제한된다. 또한, 이벤트 스트림은 각각의 SNMP 중개자에 의해 구현되는 조절(throttling) 메커니즘에 의해 제한된다. 클라이언트 측에서 볼 때, 구성요소 관리 시스템은 제한된 수의 액티브 클라이언트 세션을 지원할 것이고, 각각의 액티브 클라이언트 세션은 제한된 수의 애플리케이션을 실행할 것이다. 가장 중요한 사항은, 제 1 단계를 위한 추가적인 과부하 제어의 개발을 보장하기 위한 충분한 네트워크나 클라이언트 생성 트래픽이 없을 것이라는 것이다.

추가적인 개발은 과부하 제어하는 것을 제어되지 않은 이벤트 스트림에 대하여 보호 수단으로 확장하며, 각각의 애플리케이션과 관련된 클라이언트 요청의 개수와 범위를 모니터하고 제한해야 한다.

다음 관심 영역은 과부하 제어를 조사하는 시작점으로서 식별되고 사용될 것이다.

·클라이언트 과부하 :

⇒ 너무 큰 부피의 데이터를 등록

⇒ 너무 많은 세션을 생성 : 적절한 자원이 내부 서버 세션을 위해 현재 할당됨에 유의하라.

⇒ 고빈도(high frequency) 콜백(예컨대, 트랩)

·서버 과부하 :

⇒ SNMP 중재기로부터 NE 중개자로의 너무 많은 폴링 양

⇒ 트랩 범람 : 단기간 동안 NE 중개자로부터 수신된 너무 많은 트랩

소프트웨어 버전 관리(SOFTWARE VERSION MANAGEMENT)

전체적인 AP/구성요소 관리 시스템/ECP 소프트웨어 버전 관리를 위한 기록 계획은 다음과 같다.

·다른 애플리케이션에 대한 소프트웨어 갱신을 위해, 구성요소 관리 시스템 서버와 AP가 구성요소 관리 시스템 소프트웨어의 새로운 버전과 동일하게 갱신된다.

·구성요소 관리 시스템 소프트웨어 갱신에서 :

⇒ 구성요소 관리 시스템 서버가 먼저 갱신된다.

⇒ AP들이 한번에 하나씩 갱신된다.

⇒ 구성요소 관리 시스템 클라이언트는 구성요소 관리 시스템 서버가 다운된 것을 감지할 것이며, 구성요소 관리 시스템 서버가 다시 온라인 상태가 되면 재초기화(reinitialize)할 필요가 있을 것이다.

구성요소 관리 시스템 SUs에 대해, 구성요소 관리 시스템 서버 상의 구성요소 관리 시스템 소프트웨어는 AP 상의 소프트웨어의 옛 버전 및 새 버전과 호환성이 있어야 한다. 이러한 호환성을 지원하기 위해, 구성요소 관리 시스템 서버는 동시에 MIB 버전 j와 j+1을 지원할 필요가 있다. 구성요소 관리 시스템 버전 관리는 구성요소 관리 시스템 클라이언트 애플리케이션으로도 확장되는데, 이는 주어진 AP 상의 MIB 버전을 알아야 하고 그에 따라 작동할 수 있어야 한다.

소프트웨어 갱신 애플리케이션과 구성요소 관리 시스템 서버 SU 중에, 구성요소 관리 시스템 클라이언트는 다운될 것이고 구성요소 관리 시스템 서버가 백업(back up)되면 재초기화될 필요가 있을 것이다. 구성요소 관리 시스템 GUI 클라이언트 버전 관리를 위한 제한 요건은 구성요소 관리 시스템 GUI 클라이언트 능력(capability) 요건/높은 수준의 설계 문서에 설명될 것이다.

MIB의 설계는 구성요소 관리 시스템/AP 인터페이스의 매우 상세한 설명을 포함한다. MIB는 단일 구성요소 관리 시스템/AP 인터페이스 정의를 가능한 한 많이 서비스하여야 한다. 따라서, 그 세부 사항은 각각의 일반적인 갱신(Generic Retrofit)보다 자주 갱신될 필요가 있을 것이다. SU 접근 방식은 해당 AP SNMP 중개자와는 상이한 MIB 버전을 실행하고 있는 구성요소 관리 시스템 서버가 무오류(error­free) 작업이 가능하도록 보장하지는 못할 것이고, MIB가 하나의 해제로부터 다른 것으로 변경할 수 있는 가능한 방법을 열거할 것이며, 각각의 경우에 버전이 부합되지 않은 것들이 처리되는 방법과 필요한 에러 처리의 유형을 특정할 것이다. 우선적인 목표는, AP가 구성요소 관리 시스템 서버와 동일한 MIB 버전을 실행하지 않더라도, 임의의 이용가능한 AP 상에서 본 발명에 따른 방법을 수행하기 위한 기술자의 능력을 극대화하는 것이다.

보안(SECURITY)

이 기능은 네트워크 구성요소, 보존 유닛, 네트워크 구성요소/보존 유닛 상의 작업에 대하여 클라이언트 기반 액세스를 제어하는 방법을 제공한다. 개시 시에, 클라이언트 애플리케이션은 클라이언트 호스트, 포트, 클라이언트, 패스워드의 식별을 제공함으로써 서버에 등록해야 한다. 서버는 국부 데이터 서비스로부터 클라이언트 기록을 검색하고 세션 객체를 클라이언트 액세스 허가를 표시하는 클라이언트에게 리턴한다. 이 정보는 클라이언트 애플리케이션 내의 일정 레벨의 액세스 제어(예컨대, 허가되지 않은 보존 작업을 위한 메뉴 구성요소 관리 시스템의 해제)를 제공하는 데 사용될 수 있을 것이다. 어떤 경우에도, 모든 클라이언트 요청은 서버에서 유효화된다. 각각의 관리 객체 클래스는 각각의 주지의 방법(public method)에 대한 파라미터로서 세션 식별자를 요청한다. 세션과 관련된 액세스 허가는 클라이언트 실행(예를 들어, 제거 작업)을 인증하기 전에 조사된다. 동일한 인터페이스 정의를 이용하는 인프라스트럭쳐 컴포넌트에 의한 사용을 위해 전역(global) 액세스 허가를 갖는 사전결정된 "시스템 세션"이 존재함에 유의하여야 한다.

이 아키텍쳐에 의해 사용될 SNMP의 버전은 SNMP V2c이다. 이 SNMP 버전은 SNMP V1 내의 커뮤니티 이름 기반(community name based) 보안에 대한 더 이상의 보안 향상을 제공하지는 않는다. 관리 메시지의 소스를 인증하거나, 네트워크 상의 메시지의 도청(eavesdropping)을 방지하는 메커니즘을 제공하지는 않는다. 이 때문에, AP SNMP 트래픽에 대해 구성요소 관리 시스템을 위해 사용되는 네트워크가, 폐쇄 네트워크(closed network)이며 서비스 제공자 공공 LAN이나 인트라넷의 일부가 아닐 것이 강력히 요청된다.

(구성요소 관리 시스템 서버 상에서만 상주하는) 커맨드 라인 해석기 애플리케이션은 구성요소 관리 시스템 서버 상의 로그인(login)을 갖는 임의의 클라이언트에게 사용가능하다. 따라서, 위에서 설명한 클라이언트 기반 액세스 제어는 커맨드/클라이언트 별로 액세스를 제한하는 수단을 제공한다.

AP의 주된 서브컴포넌트(MAJOR SUB­COMPONENTS OF THE AP)

AP의 기능적 블럭도가 도 14에 도시되어 있다.

·SNMP 중개자 : SNMP 프로토콜과 AP를 위해 특별히 정의된 MIB를 이용하여 구성요소 관리 시스템 서버에 대한 인터페이스를 제공한다. AP 이벤트와 커맨드 승인/응답을 SNMP 트랩으로서 구성요소 관리 시스템 서버로 보내고, 관리 객체 데이터에 대한 요청(SNMP GET)에 응답하며, 커맨드 요청(SNMP SET)을 커맨드 처리기로 전달한다.

·AP MIB : AP를 위해 특별히 정의된 SNMP MIB. 구성요소 관리 시스템 서버로 보내질 모든 AP 트랩의 정의는 물론, 구성요소 관리 시스템 서버로부터 관리될 모든 AP 객체의 정의를 포함한다.

·중개자 구성 파일 : 관리자와 통신하기 위해 중개자에 의해 요구되는 값을 포함하며, 이 관리자는 구성요소 관리 시스템 서버 상에 상주한다.

·이벤트 처리기 : 이벤트를 필터링하고 SNMP 중개자로 보내는 역할을 한다. 생성된 이벤트에 응답하여, (구성요소 관리 시스템 서버가 나중에 요청하거나 폴링할 수 있도록) 네트워크 구성요소 상태 테이블을 AP에 의해 "기억"될 데이터로 갱신한다.

·이벤트 API : AP 애플리케이션은 이 API를 사용하여 이벤트(상태 변경, 알람, 정보 메시지, 구성)를 생성한다. 이벤트는 이벤트 처리기로 전달된다.

·네트워크 구성요소 상태 테이블(Network Element Status Table : NEST) : 구성요소 관리 시스템 서버가 요청할 수도 있는 모든 상태에 대한 저장. 상태 변수와 눈에 띄는 알람 리스트를 포함하여 각각의 관리 객체를 위한 현재 상태가 이 테이블에 보존될 것이다. 또한, 눈에 띄는 커맨드 리스트가 이 테이블에 보존될것이다.

·NE 상태 API : 네트워크 구성요소 상태 테이블로의 기록과 그로부터의 독출에 대한 인터페이스

·이벤트 구성 파일(Event Configuration File : ECF) : (기술자에 의해 편집될 수 있는) 텍스트 파일로, 어느 이벤트가 구성요소 관리 시스템 서버로의 전송을 위해, AP 상에 국부적으로 로그(log)될 지 및/또는 SNMP 중개자로 전달될 지를 정의한다. 요청에 따라, 구성요소 관리 시스템 서버로 항상 로그되거나 보내질 이벤트 세트가 있을 것이며, 기술자는 이를 변경할 수 없을 것이다. (개발 상태의 진행에 따라) 정의되어 기술자에 의해 편집될 수 있는 다른 이벤트가 있을 수 있다. 또한, ECF는 알람 및 정보 메시지와 관련된 X.733 값(예컨대, 엄격(severity))을 정의한다.

·관리 로그(Admin Log) : AP 상에 생성되고, 사용자가 관찰가능한 이벤트의 로그를 포함하는 파일로, 로그된 이벤트는 ECF에 의해 제어된다.

다음 서브컴포넌트는 AP 인프라스트럭쳐 소프트웨어의 일부분으로 간주된다.

·커맨드 처리기 : AP 상에서 실행될 모든 커맨드를 관리한다. SNMP 중개자, AP 텍스트 클라이언트, 또는 커맨드/응답 API를 통한 ECP 중개자와 같은 (커맨드 처리기 액세스 포인트 또는 CHAP로도 알려진) 커맨드 소스에 대한 인터페이스. RAP API를 통해 실행될 커맨드를 트리거하고 모니터하는 역할을 한다. 커맨드 승인을 생성한다. 커맨드 승인과 커맨드 응답을 커맨드 소스로 돌려보내도록 라우팅한다. NE 상태 테이블 내의 액티브 커맨드 리스트를 보존한다.

·커맨드/응답 API : 커맨드를 발생시키고 커맨드 승인 및 응답을 얻기 위한, 커맨드 소스와 커맨드 처리기 사이의 인터페이스

·RAP API : 프로세스를 생성하고 프로세스 실행 결과를 얻기 위한 일반적인 API. 일반적으로, AP 자원 상의 보존 커맨드를 실행하기 위해 RAP가 사용된다. 필요한 경우, RAP는 다른 프로세스를 생성할 수 있다.

·텍스트 커맨드 해석기 : AP 상에 국부적으로 커맨드를 생성하고 응답을 수신하기 위한 텍스트 기반 커맨드 클라이언트. 구성요소 관리 시스템 서버가 이용가능하지 않을 때 사용됨.

·IDS­AP : AP 상의 IDS의 데이터 테이블을 보존하고, ECP 상의 IDS로부터 데이터의 변경을 나타내는 트리거를 수신한다.

·IDS(구성) 데이터 : IDS­AP를 통해 ECP로부터 얻은 AP 구성 데이터를 저장

·IDS API : IDS­AP에 의해 제공되는 구성 데이터를 얻기 위한 API

·ECP 중개자 : ECP 상의 상태 디스플레이에 대한 인터페이스. 데이터 내의 변경을 나타내는 트리거를 처리하기 위한 IDS­AP에 대한 인터페이스. 관심 애플리케이션 프로세스로 트리거를 전달한다.

·감사 제어기 : RCC, NEST, 자원 관리자(예컨대, CCM) 중에서 상태와 알람을 감사한다.

·AP 상태 모니터 : RCC 관련 상태 변경과 알람을 감지하고 보고한다. 이는 소프트웨어를 모니터하는 자원 모니터 RCC 프로세스에 의해 보고되는 상태 변경과알람을 포함한다.

SNMP 중개자

구성요소 관리 시스템은 SNMP 중개자를 통해 AP에 인터페이스한다. MIB는 구성요소 관리 시스템 서버와 중개자 사이의 인터페이스를 정의하는 데 사용되고, 구성요소 관리 시스템 서버와 중개자 모두에 공통된다. 중개자는 이 섹션에서 설명되고, MIB는 다음 섹션에서 설명된다. 중개자는 인터넷 표준 단순 네트워크 관리 프로토콜(SNMP)(인터넷 문서 RFC­1157 참조)을 사용하여 표준 UDP/IP 포트를 통해 구성요소 관리 시스템 서버와 통신한다. 이 아키텍쳐에서는, GETBULK 작업과 같이 SNMPv1에 비해 향상된 능력을 제공하는 SNMPv2c를 사용한다.

SNMP는 세 가지 기본 관리 기능을 제공한다.

·GET(또한 GETNEXT, GETBULK) : 관리 시스템으로부터 데이터를 얻는다(MIB에서 정의된 대로, 관리 객체와 관련된 속성을 검색한다). 관리 시스템은 GET­RESPONSE를 이용하여 GET에 응답하여야 한다.

·SET : 보통 관리 시스템을 수정하기 위해 사용된다. 관리 시스템은 SET­RESPONSE를 이용하여 SET에 응답하여야 한다. 이 아키텍쳐에서, SET은 AP 상에서 실행될 커맨드를 트리거하는 데 사용된다.

·트랩 : 관리 시스템이 관리자로 비동기 통지(asynchronous notification)를 보내는 방법.

SNMP 중개자 기능

SNMP 중개자는 다음의 기본 기능을 수행할 것이다.

I. SNMP 관리자에 의해 보내진 SNMP 패킷을 구성요소 관리 시스템 서버에서 수신하고 각각을 다음과 같이 처리한다.

A. GET/GET­NEXT/GETBULK 패킷 : 네트워크 구성요소 상태 테이블이나 구성(IDS) 데이터 중 적절한 하나를 액세스함으로써 패킷 내에서 요청되는 관리 객체 속성의 현재 값을 얻는다. 요청된 속성과 그 값은 GET­RESPONSE 패킷에 저장되고 관리자로 리턴된다.

B. SET 패킷 : 공통 커맨드/응답 API에 의해 정의된 대로, SNMP SET 요청을 커맨드 요청 메시지로 매핑한다. 커맨드 속성은 SNMP 패킷 내에서 지정되고 MIB 내에서 정의된 대로, 해당 메시지 구성요소로 매핑될 것이다. 이 메시지는 커맨드/응답 API를 통해 커맨드 처리기로 전달될 것이다.

중개자는 SET­RESPONSE를 관리자로 되돌려 보낼 것이다. 커맨드 처리기가 커맨드를 실행할 것을 결정할 수 없도록 SET 요청이 무효화되거나, 커맨드가 커맨드 처리기로 전달될 수 없으면, SET­RESPONSE는 에러를 나타낼 것이다. 관리자는 SET RESPONSE 에러를 해석하고 에러 발생을 나타내는 커맨드 승인을 생성해야 한다.

관리자는 관리자가 동일한 SET 요청을 보내는 경우를 허용해야 한다. 이는 관리자가 SET­RESPONSE를 수신하지 못하면(실패) 발생한다. 중개자는 주어진 클라이언트 세션(클라이언트 세션 정보는 모든 커맨드에 대한 공통 속성으로서 MIB 내에서 정의된다)에 대해 처리되는 최종 SET 요청을 기억하고, 새로운 요청인 경우에 그 커맨드를 커맨드 처리기로 전달하기만 할 것이다. 새로운 요청이 아닌 경우, 중개자는 다른 SET­RESPONSE를 관리자로 단순히 보내기만 할 것이다.

II. 커맨드 처리기로부터 메시지를 수신하여 각각을 다음과 같이 처리한다.

A. 메시지가 커맨드 승인이면, 이를 커맨드 승인 트랩 패킷으로 매핑한다. MIB는 모든 커맨드에 대해 사용될 커맨드 승인 트랩을 정의할 것이다. 커맨드 승인은 단순한 값의 형태를 취하여, 커맨드가 거부되거나, 타임 아웃되거나, 완료되거나, 진행 중인 것과 같은 커맨드의 상태를 이어질 커맨드 응답에서 표시해 준다.

B. 메시지가 커맨드 응답이면, 이를 커맨드 응답 트랩 패킷에 매핑한다. MIB는 되돌려 보내질 공통 커맨드 응답 트랩 블럭을 모든 커맨드 응답에서 정의할 것이다. 공통 커맨드 응답 트랩 블럭 외에도, 생성될 각각의 커맨드 응답의 유형에 대한 특정 정의가 MIB 내에 있을 것이다. 실패할 경우(구성요소 관리 시스템 서버에서 처리하는 커맨드 응답은 실패한 응답 상에서 보고할 수 있을 것이다) 커맨드 응답을 저장하기 위해 어떠한 준비도 되어 있지 않는다는 점에 유의하여야 한다. 또한, 응답이 올바른 순서로 리턴되도록 보장하는 준비도 없을 것이다.

III. 이벤트 처리기로부터 메시지를 수신하여 각각을 다음과 같이 처리한다.

A. 특정 이벤트를 해당 트랩 패킷으로 매핑한다. 중개자에 의해 수신될 수 있는 이벤트의 가능한 유형은 4 가지가 있고, 각각의 이벤트 유형은 AP MIB에서 정의된 대로, 특정 트랩으로 매핑될 것이다.

1. 상태 변경 : 관리 객체와 관련된 하나 이상의 변수의 값의 변경을 나타낸다. 관리 객체 상태는 NE 상태 테이블 내에 보존될 것이고, 관리자는 관리 객체와 연관된 임의의 또는 모든 상태를 중개자에게 요청할 것이다. 중개자는 이벤트 메시지 내에 있는 변수와 새로운 상태 값을 그들의 해당 MIB 객체 식별자와 트랩 패킷 내의 값으로 매핑하고, 그 패킷을 관리자로 보낸다.

2. 알람 : 특정하고 지속적인 기술자 통지를 요구하는 예측되지 않은 성질의 상태(condition of an unexpected nature)를 나타낸다. 또한 그러한 상태의 클리어를 나타내는 데 사용될 것이다. 각각의 알람은 관리 객체와 관련되어 있고 MIB 내의 관리 객체에 대해 특정한 정의를 갖는다. 모든 알람에 공통인 MIB 내에는 알람 블럭이 정의되어 있다. 관리 객체 상태와 같은 알람은 NE 상태 테이블 내에 보존될 것이고, 관리자는 액티브 알람을 요청할 것이다. 중개자는 알람 이벤트를 공통 MIB 알람 블럭과 관리 객체에 대해 정의된 특정 속성의 합으로 매핑할 것이다.

3. 정보 메시지 : 실질적으로는 알람과 유사하나, 알람의 지속을 요구하지 않는 상태이다. 정보 메시지는 (말하자면, 구성요소 관리 시스템 서버 및/또는 ROP 상에서) 로깅을 요구하는 조건이지만, 알람으로써 보존될 정도로 중요하게 여겨지지는 않으며(기술자에 대한 지속적인 관찰), 조건이 없어지면 자동적으로 해제될 수 없는 조건이다. 알람은 자동적으로든 아니면 어떤 기술적인 조작의 결과이든, 해제될 수 있어야 하는 조건을 정의한다. 중개자는 정보 메시지 이벤트를 공통 MIB 정보 메시지 블럭과 관리 객체에 대해 정의된 특정 속성의 합으로 매핑하고, 이를 관리자로 보낸다.

4. 구성 변경 : 주어진 관리 객체에 대한 구성 데이터가 어떤 방식으로 변경했음(즉, 관리 객체가 생성 또는 삭제되거나, 관리 객체와 관련된 구성 데이터가 갱신됨)을 나타낸다. 중개자는 구성 변경 이벤트를 공통 MIB 구성 변경 블럭으로 매핑하고, 이를 관리자로 보내다. 이어서, 관리자는 AP에 문의하여 새로운/갱신된 구성 데이터를 얻는 역할을 한다.

IV. 중개자는 구성요소 관리 시스템 서버로 가는 트랩을 조절하여 관리자를 압도하지 않도록 할 것이다. 조절은 AP로부터 오는 고정된 최대 레이트에 기초할 것이다. 중개자에 의해 수행되는 조절은 커맨드 승인과 응답이 구성 변경보다 우선하도록 우선순위(priority)에 기초하는데, 구성 변경은 알람보다 우선하고, 알람은 정보 메시지보다 우선할 것이다. 트랩 조절의 세부 사항은 설계 단계에서 특정될 것이다.

SNMP 중개자 초기화

구성요소 관리 시스템 서버 상의 SNMP 관리자와 통신하기 위해, 중개자는 다음과 같은 소정의 정보를 요구한다.

1. SNMP 트랩을 보내기 위해, SNMP 관리자의 IP 어드레스가 필요하다. 표준 호스트네임(hostname)은 AP 상의 /etc/hosts 파일 내에 존재하는 것으로 추정될 것이며, 중개자는 개시 시에 이 호스트의 IP 어드레스를 얻을 것이다. 디폴트 IP 어드레스는 AP의 단(stage)에서 셋업될 것이다.

2. SNMP 독출 및 기록 커뮤니티 스트링(community string). 커뮤니티 스트링은 SNMP 보안의 한 형태이다. 관리자가 보낼 스트링은, 관리자가 GET(독출)/SET(기록)을 허용하도록 관리자의 예상과 부합되어야 한다. 이들 스트링은 중개자가 시작될 때 커맨드 라인 선택사양으로부터 얻어질 것이다. 커맨드 라인 파라미터는 RCC 구성 파일 내에서 특정된다.

SNMP 중개자는 AP 상의 구성요소 관리 인프라스트럭쳐 플랫폼 가상 머신(Platform Virtual Machine : PVM)의 일부로써 존재하며, 따라서 신뢰성 있는 클러스터 컴퓨팅 인프라스트럭쳐(Reliable Cluster Computing infrastructure)에 의해 시작될 것이다.

개시 시, SNMP 중개자는 NE 상태 테이블과 구성 데이터를 액세스하는 데 필요한 단계들을 수행할 것이고, (전술한 바대로) 관리자 IP 어드레스를 결정할 것이며, 관리자로 SNMP 콜드 개시 트랩(SNMP Cold Start TRAP)을 보낼 것이다.

중개자는 표준 인터넷 "시스템" 그룹 객체 상의 SNMP GET에 응답할 것이다. 이는 구성요소 관리 시스템 서버 상에서 사용되는 HP 개방 관찰(HP OpenView) 패키지에 의해 요구된다.

AP MIB

AP MIB는 구성요소 관리 시스템 서버 상의 SNMP 관리자와 AP 상의 SNMP 중개자 사이에서 공유되는 데이터 정의이다. 이는 다음 정의를 포함한다.

·커맨드, 커맨드 승인, 알람 등에 대해 정의된 것들과 같은 공통 속성 블럭("헤더") (아래의 "MIB 컨벤션" 참조).

·모든 상태 변수, 커맨드, 커맨드 응답, 알람, 구성요소 관리 시스템 서버로부터 관리될 객체와 연관된 정보 메시지. 관리 객체는 AP 자신, RCS 가상 머신, 이더넷 등을 포함하여야 한다.

·(구성요소 관리 시스템 서버가 AP 관찰과 함께 눈에 띄는 커맨드의 관찰을 감사할 수 있도록) 액티브 커맨드 리스트와 같이 감사에 필요한 객체.

MIB 컨벤션

앞서 언급하였듯이, 몇몇 컨벤션이 MIB에 적용되어 이 아키텍쳐를 지원할 것이다. 이들은 다음 섹션에 리스트 된다.

"바이너리(binary)" 대 "아스키(ASCII)" 속성

MIB 내에 정의된 속성은 일반적으로 아스키 스트링과는 대조적으로 바이너리 값으로 정의될 것이다. 이는 (구성요소 관리 시스템 서버에서) 속성 값의 텍스트 포매팅이 (적절한 인간 언어로 텍스트가 드러나도록) 위치 텍스트 포매팅을 사용하도록 한다.

SNMP 중개자는 상기 변수를 지원하는 것이 바람직하다. 이는 관리자에 의해, 이것이 (이 섹션에서 설명된 다른 인터페이스 컨벤션을 지원하는) MIB인지를 결정하는 데 사용되며, 또한 버저닝(versioning) 메커니즘을 제공하여 MIB 변경을 지원하는 데 사용된다. 초기화 시, 관리자는 이 변수에 대한 GET 작업을 수행하려 시도할 것이다. 그것이 존재하지 않으면, 중개자는 이 아키텍쳐에 의해 요구되는 향상을 지원하지 못한다.

공통 커맨드 블럭

커맨드 요청을 지원하기 위해, MIB는 특정 변수 세트를 지원하여 커맨드 실행을 위하여 모든 파라미터가 아토믹 작업(atomic operation)에서 특정되도록 한다. 이 변수 세트는 공통 블럭이라 지칭한다. 공통 블럭은 (트랩에 의해 전달되는) 최종 응답을 개시 요청자(originating requester)로 라우팅하는 데 사용되는 식별 태그(tag)를 이용하여 커맨드 요청을 "등록"하는 방법을 제공한다. 커맨드 블럭은 다음 파라미터를 포함할 것이다.

·커맨드를 특정 클라이언트 세션에 연관시키는 세션 ID

·커맨드를 특정 클라이언트 세션 내에서 고유하게 만드는 커맨드 시퀀스

·그 커맨드가 수행될 객체의 특정 인스턴스를 식별시키기 위한 객체 인스턴스 식별자(예를 들어, "RCS" 관리 객체에 대해서는 "7")

·커맨드 작업(예컨대, 제거(REMOVE))

커맨드에 특정한 추가 파라미터는 공통 커맨드 블럭의 일부분이 아니다.

공통 커맨드 승인 및 커맨드 응답 블럭

커맨드 승인 및 커맨드 응답을 개시 클라이언트(originating client)로 되돌려 보내기 위해, 승인과 응답을 생성하기 위해 만들어진 트랩은 초기 커맨드 요청부터 공통 커맨드 블럭 속성(위를 참조)을 포함하여야 한다. 또한, 커맨드 응답은 응답 시퀀스와 최종 응답을 나타내는 플래그(flag)를 포함해야 한다. 공통 커맨드 블럭 속성은 SNMP 중개자에 의해 커맨드 처리기로 전달될 것이며, 커맨드 처리기로부터 중개자로 리턴되어서(즉, 이는 커맨드/응답 API 의 일부분이어야 한다), 중개자가 이들을 커맨드 응답 트랩으로 돌려보낼 수 있다.

공통 알람 및 정보 메시지 블럭(Common Alarm and Informational message Block)

알람과 정보 메시지는 정의된 공통 속성 블럭을 가질 것이다. 알람 레벨, 알람 원인, 알람 ID(눈에 띄는 알람마다 하나의 고유한 값)와 같은 속성이 정의될 것이다.

공통 구성 변경 이벤트 블럭(Common Configuration Ch

모든 구성 이벤트 트랩에 대해 정의된 공통 속성 블럭이 존재할 것이다. 관리 객체 인스턴스 식별자와 구성 작업(삽입, 갱신, 삭제)과 같은 속성이 정의될 것이다.

MIB 내의 유닛 계층 어드레싱(Unit Hierarchy Addressing within the MIB)

SNMP MIB는 현재 단 하나의 데이터 구조화 방법만을 제공하는데, 이는 스칼라 값 엔트리(scalar­valued entry)를 갖는 단순한 2차원 테이블이다. 이렇게 MIB 변수를 구조화하는 제한된 방법은 셀 사이트(cell site)와 같이 보다 복잡한 구조의 네트워크 구성요소를 직접 지원하지 못한다. 셀 사이트는 많은 유닛을 가지며, 각각의 유닛은 그 유닛에 대해 특정한 변수 세트를 갖는다. 이들 유닛은 계층적으로 구조화된다.

그 계층에서의 더 낮은 서브 유닛의 특정 속성(또는 속성 세트)을 지칭하기 위해, 계층 내의 각 유닛에 대한 식별자로 이루어진 다중열(multi­column) 키가 사용될 것이다(예를 들어, CCC2, CCC1과 같은 서브 유닛을 지칭하기 위한 SNMP 객체 식별자의 마지막 두 디짓(digit)은 "2.1"일 것이다). SNMP GETNEXT 작업은 (중개자에 의해 지원되어야 하는) 컨벤션을 지원하여 다중열 키를 객체 식별자로 특정함으로써 속성을 요청한다.

주의 : 현재, AP 관리 객체에 필요하다고 판단되는 그러한 유닛 계층은 없다.

이벤트 생성 및 처리(Event Generation and Processing)

AP 상의 애플리케이션은 다음과 같은 것을 반영할 이벤트를 생성하는 역할을 한다.

·AP 관리 객체와 연관된 현재 상태와 알람

·AP 관리 객체와 연관된 구성 데이터의 변경

·네트워크 관리 애플리케이션에 중요한 정보 메시지

불일치(inconsistencies)를 피하기 위해, 특정 관리 객체 인스턴스의 상태와 알람을 처리하는 역할을 하고, 따라서 이벤트 API를 사용하여 항상 관리 객체의 정밀한 관찰을 유지하는 유일한 애플리케이션이 있는 것으로 가정된다.

다음 섹션은 이벤트 생성 및 처리와 관련된 주된 컴포넌트를 설명한다.

이벤트 API(Event API)

이벤트 API는 AP 상의 애플리케이션을 위한 메커니즘을 제공하여 이벤트를 생성하고, 이들 이벤트를 가능한 기록, 로깅 및 또는 구성요소 관리 시스템 서버로의 전송을 위한 이벤트 처리기로 전달한다. API는 다음을 포함한다.

·시스템 내의 모든 가능한 이벤트의 정의. 각각의 이벤트는 본 명세서에서 먼저 논의한 바와 같이 가능한 4 가지 유형의 이벤트인 상태 변경, 알람, 정보 메시지, 구성 변경 중 하나로 분류될 것이다.

·API를 초기화하는 수단. 내부적으로, API는 UX 프로세스 간 통신 라이브러리를 사용하여 메시지를 이벤트 처리기로 보낼 것이다.

·주어진 알람 발생과 관련된 알람 텍스트를 전달하는 수단. 텍스트는 기계 및 언어와 무관한 형태로 구성요소 관리 시스템으로의 전송을 위해 인코딩될 것이다. 텍스트를 인코딩하는 수단은 국가 언어 지원(National Language Support : NLS) 라이브러리를 제공받을 것이다.

·이 애플리케이션에 의해 이전에 생성된 모든 알람을 클리어하는 수단. 이는 애플리케이션이 재초기화될 때 사용되고, 자신이 담당하는 모든 관리 객체와 관련된 모든 눈에 띄는 알람을 클리어해야 한다.

·특정 관리 객체 인스턴스와 연관된 모든 알람을 클리어하는 수단. 이는 특정 관리 객체가 초기화되거나 서비스될 때 사용된다. 예를 들어, 서비스 중인 작업과 관련된 DS1 객체 상의 몇몇 눈에 띄는 알람이 있을 것이다. DS1이 서비스할 수 없는 상태가 될 때, DS1을 관리하는 애플리케이션은 그 DS1 상의 모든 눈에 띄는 알람을 클리어하기를 원할 것이다.

이벤트 처리기(Event Handler)

이벤트 처리기는 AP 상의 플랫폼 가상 머신의 일부로써 존재할 것이며, 따라서 신뢰성있는 클러스터 계산(Reliable Cluster Computing) 인프라스트럭쳐에 의해 시작될 것이다.

이벤트 처리기의 주된 기능은 다음과 같다.

I. 이벤트 구성 파일을 독출하여 어느 이벤트가 구성요소 관리 시스템 서버로의 전송을 위해 기록되고(속성 변경과 알람), 로그되고, 및/또는 SNMP 중개자로 전달될 지를 결정한다. 또한, ECF는 이벤트가 알람 또는 정보 메시지, 알람 및 정보 메시지와 연관된 X.773 값인지를 정의한다.

II. 정규적으로 ECF(예를 들어, UNIX state 시스템 호출)를 모니터하여 ECF 내의 변경을 검출한다.

III. AP 상의 애플리케이션으로부터 메시지를 수신하여 각각을 다음과 같이 처리한다.

A. 이벤트가 로그될 예정이면, 그렇게 한다.

B. 이벤트가 기록(속성 변경이나 알람)을 필요로 하는 것이면, NE 상태 API를 이용하여 NE 상태 테이블을 갱신한다.

C. 이벤트가 구성요소 관리 시스템 서버 상으로 전달될 예정이면(디폴트로, 모든 이벤트가 전달될 것이다), UX 프로세스간 통신 라이브러리를 이용하여 SNMP 중개자로 이를 보낸다.

네트워크 구성요소 상태 테이블(NETWORK ELEMENT STATUS TABLE)

구성요소 관리 시스템 서버가 요청할 모든 비구성 데이터에 대한 저장. 이는 다음을 포함한다.

·관리 객체 인스턴스(per­managed­object­instance) 당 현재 관리 객체 상태

·관리 객체 인스턴스 당 눈에 띄는 알람 리스트

·SNMP 중개자가 구성요소 관리 시스템 서버로부터의 현재 눈에 띄는 커맨드 리스트로의 액세스를 갖도록, 감사를 위한 액티브 커맨드 테이블

네트워크 구성요소 상태 API(NETWORK ELEMENT STATUS API)

네트워크 구성요소 상태 테이블을 독출하고 기록하는 메커니즘을 제공한다. API는 데이터가 일관되게 보존되도록(예컨대, 세마포(semaphore)를 이용하여) 테이블이 갱신되는 동안 독자(reader)를 막는다. 위의 "이벤트 API" 섹션에서 설명된 대로 알람의 "와일드카드(wildcard)" 클리어를 지원한다. ECP 중개자 및 SNMP 중개자와 같은 다른 애플리케이션이 독출 API를 사용하는 반면, 이벤트 처리기는 기록 API를 사용할 유일한 애플리케이션이 될 것이다.

이벤트 구성 파일(EVENT CONFIGURATION FILE : ECF)

구성요소 관리 시스템 서버로의 전송을 위해 어느 이벤트가 AP 상에서 국부적으로 로그될지 및/또는 SNMP 중개자로 전달될 지를 정의하는 (기술자에 의해 편집 가능한) 텍스트 파일. 시스템의 요건에 의해 정의된 대로, 구성요소 관리 시스템 서버로 로그되거나 전달될 필요가 있는 이벤트는 변경되지 않을 것이다. 또한, ECF는 기술자로 하여금 알람 및 정보 메시지와 관련된 X.733 값을 세팅하도록 한다. ECF 확인자 애플리케이션(ECF­checker application) (이를테면, shell/awk)은 파일의 유효하지 못한 변경을 막도록 기록될 것이다.

ADMIN LOG

이벤트 처리기에 의해 기록되고, ECF에 의해 정의된 대로 로그되는 이벤트를 포함하며 고정된 포맷의 공통 필드를 갖는 아스키 파일. 이 파일은 기존의 OMP Admin 로깅 메커니즘에 기초할 것이다. 알람 엔트리를 위한 필드는 구성요소 관리 시스템 서버 알람 리스트 애플리케이션 상에 나타난 필드의 내용 및 순서와 부합될 것이고 탭에 의해 윤곽 모사될 것이다. 이벤트 로그 내에 포함된 데이터의 양은 표준 로그파일(logfile) 메커니즘을 통해 유지될 것이다. 이벤트 로그로의 액세스는 표준 메커니즘(AP로의 컷스루, 표준 편집기의 사용)을 통할 것이다.

EMAPI

개관(Overview)

구성요소 관리 시스템(Element Management System : EMS)은 네트워크 구성요소의 모니터와 제어를 위한 프레임워크(framework)를 제공한다. 네트워크 내의 각각의 물리적 및 논리적 컴포넌트는 관리 객체로써 모델링되는데, 서버는 공통 객체 요청 브로커 아키텍쳐(Common Object Request Broker Architecture : CORBA)의 설비(facility)가 분산 클라이언트 애플리케이션에 사용될 수 있도록 한다. EM 클라이언트는 각각의 애플리케이션 관리 객체에 대해 정의된 속성과 작업에만 관여하면 되고, 객체 서비스를 지원하는데 필요한 네트워크 레벨 프로토콜과 서버 인프라스트럭쳐의 세부 사항에는 관여하지 않는다. 다음은 EM 클라이언트에 의해 활용되는 본 발명에 따르는 구성요소 관리 애플리케이션 프로그래밍 인터페이스(Element Management Application Programming Interface : EMAPI)(55)이다.

EMAPI 객체 정의(EMAPI OBJECT DEFINITIONS)

도 15는 클라이언트 애플리케이션에 사용될 수 있는 모든 인터페이스를 도시한다.

도 15는 클라이언트 및 서버 객체 요청 브로커(Object Request Broker : ORB)에 의해 명백한(transparent) 프로세스나 프로세서 영역을 도시하지 않는다. 애플리케이션 서비스는 CORBA 인터페이스 정의 언어(Interface Definition Language : IDL)에 의해 형식적으로 정의된 객체 인터페이스를 통해 제공된다.

클라이언트 애플리케이션과 상호작용하는 서버 상에 상주하는 서비스 객체가 도 16의 테이블에 도시되어 있다.

실시간 상태 갱신이나 이벤트, 알람, 또는 구성 변경의 통지를 등록하는 클라이언트 애플리케이션은 서버가 비동기 적으로 정보를 전달하는 데 사용할 국부 콜백 객체에 대한 참조를 제공해야 한다. EMAPI 내에서 정의된 콜백 인터페이스는 도 17의 테이블 2에 도시되어 있다. 이들 인터페이스를 구현하는 클래스들은 클라이언트 코드로 정의되고 예증되어야 한다.

데이터 표시(DATA REPRESENTATION)

EMAPI 내에서 정의된 몇몇 기본 데이터 유형이 있는데, 이들은 도 18에 도시한 두 범주 중 하나에 해당한다.

세션 관리(SESSION MANAGEMENT)

각각의 EM 클라이언트 세션은 로그인과 논리적으로 연관되어 있다. 세션 식별자는 초기화 시 클라이언트가 사용자 세션 관리자를 이용하여 등록할 때, EM 서버에 의해 할당된다. 각각의 클라이언트 애플리케이션은 세션과 논리적으로 연관되어 있다. 애플리케이션 식별자는 클라이언트에 의해 할당된다. 구성요소 관리 그래픽 사용자 인터페이스(Element Manager Graphical User Interface)를 위해, 각각의 "윈도우"는 고유의 애플리케이션 id를 할당받을 것이다. 각각의 클라이언트는 주기적인 고동(heartbeat)을 등록하여, 관련 세션이 여전히 액티브한 서버에 대해 유효화할 필요가 있다는 점에 유의하여야 한다.

사용자 세션 서비스 객체는 다음과 같은 인터페이스를 제공한다.

·start

이 방법은 초기화 시 클라이언트에 의해 불러내져서 새로운 세션을 등록해야 한다.

·stop

클라이언트는 이 방법을 불러내서, 관련 세션이 종료되고 그 세션과 관련된 임의의 애플리케이션에 의해 활용되는 모든 자원이 해제되어야 함을 서버에게 통지한다.

·stopApplication

클라이언트는 이 방법을 사용하여 사용자 세션 관리자에게 단일 애플리케이션의 종료를 통지한다.

·heartbeat

이 방법은 적어도 모든 UserSession::HeartbeatPeriod 초마다 불러내져서, 서버 감사에 의해 감지될 때 각 세션과 관련된 임의의 애플리케이션에 의해 활용되는 모든 자원의 해제를 초래할 타임아웃(timeout) 상태를 방지한다.

관리 객체(MANAGED OBJECTS)

관리 객체(Managed Object : MO)는 네트워크 구성요소, 보존 유닛 또는 데이터 링크와 같이, EMS에 의해 관리될 수 있는 물리적 또는 논리적 자원의 추상적인 표시이다. EM 서버는 관리될 각각의 유형의 물리적 또는 논리적 자원에 대해 하나의 애플리케이션 특정 서비스 객체를 구현할 것이다. 이들 서비스 객체 각각은 특정 관리 객체 인스턴스 상에서 수행될 작업은 물론, 관리 객체 특성을 식별하는 속성 세트를 정의한다(단일 "서비스 객체"를 통해 인스턴스 정보로의 액세스를 제공하도록 하는 결정은 많은 수의 원격 참조를 관리할 때, 현재 ORB 구현이 불안정해진다는 사실로부터 비롯된다). 도 19에 도시한 다이어그램은 클라이언트, 애플리케이션 특정 서비스 객체 및 관리 객체 인스턴스의 내부 서버 표시 사이의 관계를 도시한다.

각각의 관리 객체 서비스 클래스는 ClassCode에 의해 고유하게 식별된다. 각각의 관리 객체 인스턴스는 InstId에 의해 고유하게 식별된다. 시스템 내의 임의의 객체 인스턴스는 관리 객체 식별자(Object Identifier : Oid)에 의해 고유하게 참조되는데, 이는 ClassCode와 InstId의 조합이다.

관리 객체 상태 정보는 서비스 객체에 의해 속성 코드값 쌍의 시퀀스로서 보고된다. 각각의 속성 값은 데이터 표시와 관련된 본 섹션에서 설명된 모든 EMAPI 기본 데이터 유형의 결합으로 정의된다.

구성 정보는 ConfigData 구조의 시퀀스로 보고되는데, 이들 구조들은 다음과 같은 것을 포함하도록 정의된다.

·네트워크 구성요소 인스턴스 id

·관리 객체 인스턴스 id

·속성 값 쌍의 시퀀스로 보고된 관리 객체 키 리스트(길이가 0보다 크면, 키 리스트는 보통 하나 이상의 LogicalId를 특정한다.)

각각의 관리 객체 서비스 클래스는 MO 인터페이스를 구현해야 하는데, 이는 다음과 같은 구성과 상태 서비스를 정의한다.

·viewConfig

클라이언트는 이 방법을 사용하여 특정 네트워크 구성요소 인스턴스에 대한 관리 객체 구성의 현재 EMS 관찰을 얻는다. 예비 인스턴스 식별자 AnyInstance가 모든 네트워크 구성요소에 대한 구성 정보를 얻는 데 사용될 수 있다는 것에 유의하여야 한다.

·notifyConfig

클라이언트는 또한 콜백을 경유하여 관리 객체 구성 정보를 등록할 수도 있다. 이런 경우, 초기 관찰은 통지 유형 CONFIG_INIT과 함께 리턴된다. 후속 변경은 CONFIG_CREATE나 CONFIG_DELETE 유형과 함께 보고된다.

·cancelNotify

클라이언트는 이 방법을 사용하여 특정 클라이언트 애플리케이션과 관련된 관리 객체 구성 통지에 대한 등록을 취소한다.

·getPersistent

클라이언트는 이 방법을 사용하여 이 서비스 객체에 의해 보존되는 모든 "지속" 데이터를 식별하는 속성 코드 세트(SeqAttrCode)를 검색한다. 각각의 관리 객체 인스턴스에 대한 관련 속성 값은 임의의 클라이언트 요청과는 무관하게 현재값으로 저장되고 보존된다.

·viewStatus

클라이언트는 이 방법을 불러내어 특정 관리 객체 인스턴스에 대한 지속적인 속성의 특정 세트에 대한 현재값의 EMS 관찰을 획득한다.

·getStatus

클라이언트는 이 방법을 사용하여 현재 상태 정보의 스냅샷(snapshot)을 등록할 수 있다. 이 인터페이스는 요청된 속성 리스트가 지속 데이터와 연관된 것들만이 아니라 임의의 관리 객체 속성 코드를 특정할 수 있고, 정보가 클라이언트 상태 콜백(StatusCB)을 경유하여 리턴된다는 점에서 이전 것과는 다르다.

·startUpdate

클라이언트는 또한 특정 관리 객체 인스턴스에 대해 선택된 속성의 리스트에 대한 초기 관찰과 임의의 갱신 통지를 등록할 수 있다. 이러한 경우, 초기 관찰은 통지 유형 STATUS_INIT을 이용해 클라이언트 콜백을 통해 보고된다. 후속 변경은 STATUS_CHANGE를 이용해 보고된다. 관리 객체 인스턴스 삭제는 구성 변경 통지를 통해서만 보고된다(네트워크 구성요소가 구비되지 않은 경우 클라이언트 콜백의 잠재적인 동요를 방지한다)는 점에 유의하여야 한다.

·stopUpdate

클라이언트는 이 방법을 사용하여 관리 객체 상태 갱신에 대한 등록을 취소한다.

·getInst

클라이언트는 이 방법을 사용하여 특정 네트워크 구성요소 인스턴스 id와 관리 객체 키 리스트에 대한 관리 객체 인스턴스를 획득한다.

각각의 방법은 사용자 액세스를 유효화하기 위해 클라이언트 세션 애플리케이션 식별자(Session AppId)를 필요로 함에 유의하여야 한다. 이 경우의 구성 또는 상태 변경 통지 등록에 있어서, 이 식별자는 또한 클라이언트 애플리케이션이 액티브인 동안 사용되는 추가 서버 자원을 추적하는 데 사용된다.

네트워크 구성요소 레벨 관리 객체(NETWORK ELEMENT LEVEL MANAGED OBJECTS)

각각의 네트워크 구성요소 레벨 관리 객체는 또한 추가적인 네트워크 구성요소 레벨 구성 서비스를 정의하는 NEMO 인터페이스를 구현하여야 한다.

·viewNEconfig

클라이언트는 이 방법을 불러내어 네트워크 구성요소 구성의 현재 EMS 관찰을 획득할 수 있다.

·notifyNEconfig

클라이언트는 또한 콜백을 통해 네트워크 구성요소 레벨 관리 객체 구성 정보를 등록할 수 있다. 이 경우, 초기 관찰은 통지 유형 CONFG_INIT과 함께 리턴된다. 후속 변경은 CONFIG_CREATE 또는 CONFIG_DELETE 유형과 함께 보고된다.

·cancelNEnotify

클라이언트는 이 방법을 사용하여 네트워크 구성요소 관리 객체 구성 갱신의 등록을 취소해야 한다.

각각의 방법이 사용자 액세스를 유효화하기 위해 클라이언트 세션 애플리케이션 식별자를 필요로 한다는 점에 유의하여야 한다. 이 경우의 구성 변경 통지 등록에 있어서, 이 식별자는 또한 클라이언트 애플리케이션이 액티브인 동안 사용되는 추가 서버 자원을 추적하는 데 사용된다.

기술 엔티티 객체(DESCRIPTIVE ENTITY OBJECTS)

이 유형의 애플리케이션 객체는 EMS와 관리 객체 기술(예를 들어, SNMP 트랩(TRAP) 정의와 커맨드 그룹)의 일부가 아닌 네트워크 구성요소 사이에서 통신되는 데이터와 같은 추상적인 엔티티를 위한 유형과 속성 정보를 제공하기 위해 정의된다. 기술 엔티티 객체는 구현을 제공하지 않고, 컴파일(compile) 시에 클라이언트 애플리케이션에 의해 정의되고 알려진다.

이벤트 분산자(EVENT DISTRIBUTOR)

이벤트는 다음과 같은 것들의 조합으로 보고된다.

1. 대부분의 일반적인 관심 정보를 포함하는 헤더

·이벤트의 시간

·다음 중 하나로 정의되는 이벤트 범주

*알람 세트

*알람 클리어

*커맨드 승인

*커맨드 응답

*구성 변경

*정보 메시지

*초기화

*상태 변경

·네트워크 구성요소 객체 식별자

·네트워크 구성요소 알람 레벨(알람 세트에 대해서만 의미있는)

·보존 유닛 객체 식별자(적용가능하다면)

·보존 유닛 알람 레벨(알람 세트에 대해서만 의미있는)

·사용자 세션 id 및 커맨드 시퀀스 번호로 정의된 커맨드 식별자(CmdId)(커맨드 승인 및 응답에 대해서만 의미있는)

2. 다음과 같은 것을 포함하는 구조의 시퀀스로 정의되는 이벤트 데이터

·관리 객체, 네트워크 구성요소 또는 기술 엔티티의 ClassCode

·속성 코드 값 쌍의 시퀀스

클라이언트 애플리케이션은 이벤트 분산자에 의해 처리된 대로, 이벤트 헤더 내에서 특정된 정보에 대해 필터링된 이벤트 스트림의 복제를 요청할 수 있다. 필터 와일드카드는 "아웃 어브 밴드(out­of­band)"를 이용하여 구현된다.

·임의의 범주

·임의의 클래스

·임의의 인스턴스

·임의의 알람

·임의의 Cmd

도 20에 도시한 테이블 3은 어느 필터 기준이 각 이벤트 범주에 대해 유효한지를 요약한다.

이벤트 분산자는 특정 범주를 조사하고 유효한 기준을 함께 논리곱(AND)함으로써 필터를 처리한다. 클라이언트는 다수의 필터를 등록함으로써 OR 작업을 시뮬레이션할 수 있다.

EvtDist 서비스 객체는 다음 클라이언트 인터페이스를 구현한다.

·registerFilter

클라이언트는 이 방법을 사용하여 이벤트 필터를 등록한다. 필터 식별자가 리턴된다.

·cancelFilter

클라이언트는 이 방법을 불러내고, 관련 등록으로부터 리턴된 필터 id를 사용하여 특정 이벤트 필터를 제거한다.

각각의 방법이 사용자 액세스를 유효화하기 위해 클라이언트 세션 애플리케이션 식별자를 필요로 함에 유의하여야 한다.

알람 관리자(ALARM MANAGER)

알람 정보는 다음과 같은 것을 포함하는 AlarmData 구조의 시퀀스로 보고된다.

·네트워크 구성요소 특정 알람 기록을 정의하는 관리 객체의 ClassCode. 처음의 EMS 해제 시, 하나의 네트워크 구성요소 액티브 알람 테이블(ApActive Alarms)만이 정의됨에 유의하여야 한다.

·각각이 알람 인스턴스 식별자와 속성 코드 값 쌍의 시퀀스를 포함하는 알람 기록의 시퀀스

클라이언트 애플리케이션은 다음의 임의의 조합에 대해 필터링된 모든 액티브 알람의 복제를 요청할 것이다.

·네트워크 구성요소

·보존 유닛

·알람 레벨

이벤트 분산자에 의해 제공되는 인터페이스와 유사하게, 아웃 어브 밴드 값은 와일드카드를 표시하기 위해 사용될 수 있다.

관리 객체 인스턴스 정보가 알람이 보고되는 때에는 이용가능하지 않을 수도 있으므로, 실제 알람 필터 기준은 논리적 식별자에 의하여 특정된다. 논리적 IDS는 디바이스와 인터페이스의 논리적 번호를 표시하는 정수 값(예컨대, AP 4)이다. 논리적 id와 관리 객체 인스턴스 식별자 사이의 연관은 각각의 관리 객체 서비스 객체에 의해 이용가능하게 된 구성 정보 내에 제공되고, 유용(utility) 방법getInst를 통해 제공된다. 추가적인 세부 사항을 위해서는 관리 객체에 관한 섹션을 참조하라.

AlarmManager 클라이언트 인터페이스는 액티브 알람 리스트 애플리케이션에 대해 특정하게 기록된다.

·requestAlarms

클라이언트는 이 방법을 불러내어 액티브 알람에 대한 필터를 등록한다.

·changeFilter

클라이언트는 이 방법을 불러내어 필터 기준을 변경시킨다.

·refreshAlarms

클라이언트는 이 방법을 불러내어 액티브 알람 리스트를 리프레쉬(refresh)할 수 있다.

·cancelAlarms

클라이언트는 이 방법을 불러내어 필터 등록을 해제하여야 한다.

등록 해제를 제외한 모든 작업은 특정 기준에 대하여 필터링된 모든 액티브 알람을 리턴한다. 또한, 이들 방법 각각은 사용자 액세스를 유효화하고, 각각의 클라이언트가 액티브인 동안 활용될 추가 서버 자원을 추적하기 위해 유효한 클라이언트 세션 애플리케이션 식별자를 필요로 한다.

예외(EXCEPTIONS)

EM 서버와 클라이언트 모두에서 일관되고 구조화된 에러 처리를 위해 예외적인 것이 사용된다.

CORBA 사양은 많은 시스템 예외적인 것을 정의한다.

·BAD_PARAM

·INV_OBJREF

·NO_PERMISSION

·BAD_OPERATION

·NO_RESPONSE

·OBJ_ADAPTER

·…

기호 고갈 리스트(exhaustive list of mnemonics)와 관련 예외 기술(exception description)을 위해서는 "The Common Object Request Broker : Architecture and Specification"을 참조하라.

판매업자(vendor) 특정 객체 요청 브로커 예외도 (SystemException의 부(minor) 식별자를 이용하여) 정의된다.

·NO_IT_DAEMON_PORT

·LICENCE_EXPIRED

·…

현재, EMS는 이오나(Iona)의 오빅스 제품을 사용한다. 기호 고갈 리스트와 관련 예외 기술을 위해서는 "Orbix 2.1 Reference Guide"를 참조하라.

도 21에서는 EMAPI 특정 예외가 정의되는데, 이는 다수의 값 중 하나를 포함하는 EmapiExceptionCode를 이용하여 정의된다.

대부분의 경우, 예외적인 것은 모든 관련 애플리케이션의 종료를 초래하는 클라이언트에 의해 치명적인 오류로 취급될 것이다.

현재 본 개시물의 혜택을 받는 당업자는 본 발명이 많은 형태와 실시예를 취할 수 있다는 것을 이해할 것이다. 몇몇 실시예는 본 발명의 이해를 돕기 위해 제시되고 설명되었다. 이들 실시예는 예시적인 것이며 본 발명을 제한하는 것이 아님을 이해하여야 한다. 오히려, 본 발명이 첨부한 청구범위에 의해 정의된 본 발명의 사상과 범주 내에 있는 모든 변형, 상당 등가 및 대체를 포함하는 것임을 이해해야 한다.

본 발명은 근거리 통신망(local area network), 월드 와이드 웹(world wide web) 또는 인터넷과 같은 컴퓨터 인터넷을 포함하는 특정 통신 링크를 통하여 원격 통신 네트워크의 다수의 네트워크 구성요소를 원격 관리하는 방법에 관한 것으로서, 관리 컴퓨터는 컴퓨터 인터넷을 포함하는 통신 링크를 통하여 구성요소 관리 시스템 서버에 접속되고, 다수의 네트워크 구성요소 중 적어도 하나는 컴퓨터 인터넷을 통해 구성요소 관리 서버에 접속되고, 다수의 네트워크 구성요소 중 적어도 하나는 관리 컴퓨터와 적어도 하나의 네트워크 구성요소 사이의 구성요소 관리 서버를 통해 통신함으로써 관리된다.

부록 A(APPENDIX A)

용어 정의(DEFINITION OF TERMS)

알람(Alarm) : 일반적으로 예측되지 않는 성질의 상태로, 특별하고 지속적인 기술자 통지(technician notification)를 필요로 한다.

액티브 알람 리스트 브라우저 애플릿(Active Alarm List Browser Applet) : 모든 관리 객체에 대해 시스템 내에서 현재 액티브 알람을 디스플레이하는 자바(JAVA) 애플릿. 샘플 액티브 알람 리스트 브라우저 애플릿은 알람 웹 페이지 상의 부속물(Attachment) 2에서 발견될 수 있다.

ASN.1(Abstract Syntax Notation One) : 신택스(syntax)를 정의하는 데 사용하는 형식적인 언어. SNMP의 경우, ASN.1 기호가 SNMP 프로토콜 데이터 유닛과 객체의 포맷을 정의하는 데 사용된다.

AP : 애플리케이션 프로세서는 일반적인 계산 기능을 제공하는 상업적 계산 시스템을 지칭한다.

APCC(Application Processor Cluster Complex) : 클러스터 내의 AP가 장애를 일으켰을 경우, 그 AP가 그 클러스터 내의 다른 AP의 애플리케이션 서비스를 실행할 수 있는 고도의 사용가능한 플랫폼이나 클러스터 계산 환경.

AP EMS 인프라스트럭쳐 : AP 상에 상주하여 APCC OAM 아키텍쳐를 지원하는 OAM 소프트웨어 아키텍쳐 컴포넌트. 이들은 AP 상의 MIB, AP 상의 SNMP 중개자, 이벤트 처리기 및 이 명세서의 섹션 4에서 설명한 기타 컴포넌트를 포함한다.

API(Application Programming Interface) : 일반적으로 인터페이스의 클라이언트로부터 기본적인 구현의 세부 사항을 발췌하는 잘 정의된 소프트웨어 인터페이스.

애플릿(Applet) : 웹 브라우저에 의해 동적으로 다운로드되고 그 가상 머신에 의해 실행되는 소규모 자바 프로그램. 자바 애플릿이 브라우저 실행 환경에 의해 제공되는 많은 서비스(예를 들어, 오디오, 네트워크 액세스)에 대한 액세스를 갖더라고, 또한 브라우저 보안 관리자에 의해 제한 받는다(예컨대, 국부 파일 시스템으로의 액세스 금지).

속성(Attribute) : 관리 객체의 특성. 하나의 속성은 하나의 값을 갖는다.

속성 코드(Attribute Code) : 관리 객체 클래스의 특정 속성을 식별하는 코드.

클래스 코드(Class Code) : 관리 객체 클래스를 고유하게 식별하는 정수 값.

클라이언트 콜백 함수(Client Callback Function) : 서버에 의해 사용되어 속성 변경, 구성 변경 또는 이벤트 통지의 비동기적인 통지를 전달하며, 클라이언트에 의해 서버로 전달되는 함수.

클라이언트/서버(Client/Server) : 분산 계산 아키텍쳐의 유형.

클라이언트 터미널(Client Terminal) : EMS 클라이언트 애플리케이션을 호스트할 수 있는 X 터미널/워크스테이션 또는 윈도우 95 PC. 이들 클라이언트 터미널은 보편적으로 클라이언트 애플리케이션 워크스테이션으로 지칭된다.

CMU SNMP 라이브러리(CMU SNMP Library) : SNMP 관리자와 SNMP 중개자를 생성하는 데 사용될 수 있는 카네기 멜론 대한 SNMP 라이브러리.

커맨드 승인(Command Acknowledgment) : 커맨드가 거절되었는지, 실행되었는지, 또는 진행 중인지를 나타내기 위한, 커맨드에 대한 "짧은" 응답.

커맨드 응답(Command Response) : 커맨드 실행의 결과를 제공하는, 커맨드에 대한 "보다 긴" 응답. 커맨드는 다수의 응답을 가질 수도 있다.

구성 데이터(Configuration Data) : 비일시(non­transient) 특성을 갖는 데이터. 이는 관리 객체의 작업/실행과 연관된 데이터와는 반대로, 기술자에 의해 (예를 들어, ECP에서의 최근 변경(Recent Change)과 인증(Verify)을 통해) 준비되는 데이터이다.

구성 정보(Configuration Information) : 그 문맥에 따라 두 의미 중 하나를 갖는 일반적인 용어.

·관리 객체 클래스에 대해, 이 용어는 시스템 내의 특정 네트워크 구성요소나 모든 네트워크 구성요소에 대해, 그 클래스의 모든 인스턴스의 식별에 적용된다.

·관리 객체 인스턴스에 대해, 이 용어는 이중(duplex) 컴포넌트의 주된/대체적인 역할과 같이 데이터베이스 값과 연관된 하나 이상의 속성에 적용될 수 있다.

컨테인먼트(Containment) : 관리 객체 인스턴스의 존재가, 포함하는(containing) 관리 객체 인스턴스의 존재에 달려있는 관리 객체 인스턴스에 대한 구조화 관계(structuring relationship). 그 예로는 AP 객체 내에 포함된RCS 객체가 있다.

코바(Common Object Request Broker Architecture : CORBA) : 객체 관리 그룹에 의해 인증된 사양으로 분산, 상호작업 객체에 기초하는 상호작업가능한 애플리케이션을 생성하는, 600 개 이상의 컴퍼니(company)의 콘소시엄(consortium).

구성요소 관리 시스템(Element Management System) : 네트워크 구성요소를 관리한다. PlanR의 초기 해제 시, 관리는 고장 관리로 제한된다.

구성요소 관리 시스템 서버(Element Management System Server) : 관리 구성요소 상에 상주하지 않는 OAM 인프라스트럭쳐 컴포넌트를 포괄하는 데 사용되는 용어(AP EMS 인프라스트럭쳐 참조).

EMAPI 이벤트(Element Management Application Programming Interface Event) : 일반적으로 자율적인 통지. AP가 생성할 수 있는 4 가지 유형의 이벤트가 정의되는데, 이는 알람(alarm), 보고(report), 상태 변경(state change), 구성 변경(configuration change)이다.

IS­634 : 기지국(base station)을 한 판매업자(vendor)로부터 다른 판매업자의 MSC로 부착시키는 데 필요한 인터페이스를 정의하는 국제 표준 모음.

IDL(Interface Definition Language) : CORBA 객체 인터페이스를 기술하는 C++과 유사한 기호. IDL은 구현 언어나 작업 시스템에 관계없이 임의의 자원을 기술하거나 클라이언트에게 노출(expose)하기 원하는 서버 컴포넌트를 서비스하는 데 사용된다.

상속(Inheritance) : 속성, 통지, 작업, 성향(behavior)이 그 수퍼클래스(superclass)로부터 서브클래스(subclass)에 의해 획득되는 개념적인 메커니즘.

인스턴스 식별자(Instance Identifier) : 관리 객체의 특정 인스턴스를 식별하고 그 관리 객체 클래스 내에서 고유한 정수 값.

자바(JAVA) : 애플리케이션이 변경 없이 많은 플랫폼 상에서 실행될 수 있도록 하면서 해석되는, 선 마이크로시스템(Sun Microsystem)으로부터의 객체 지향 프로그래밍 언어.

논리적 식별자(Logical Identifier) : 디바이스나 인터페이스(예컨대, AP4)의 논리적 번호를 표시하는 정수 값. 논리적 id와 인스턴스 id 사이에 직접적인 연관은 없다는 점에 유의하여야 한다.

관리 객체(Managed Object) : 네트워크 관리 플랫폼에 의해 관리될 수 있는 자원의 추상적인 표시. 그 예로는 네트워크 구성요소, 보존 유닛(maintenance unit), 네트워크 구성요소 요약(network element summary), 데이터 링크가 있다.

관리 객체 클래스(Managed Object Class) : 동일한 속성, 통지, 관리 작업의 세트를 공유하는 명명된 관리 객체 세트. 그 예로는 AP 관리 객체 클래스가 있다.

관리 객체 클래스 코드(Managed Object Class Code) : (시스템에 대해 고유한) 특정 관리 객체 클래스를 식별하는 코드. 이 코드는 상수(계수 또는 정수 정의).

관리 객체 식별자(Managed Object Identifier) : 관리 객체 클래스 코드와인스턴스 식별자의 조합이 관리 객체 식별자를 정의한다. 또한 MOID로 줄여 쓰기도 한다.

방법 또는 작업(Method or Operation) : 관리 객체에 대한 작업 또는 방법은 액션(action)을 수행한다.

MIB(Management Information Base) : 인터넷 표준 언어로 기록되고 SNMP 프로토콜에 특정하며, 구성요소 관리자에 의해 관리될 네트워크 구성요소 객체의 데이터 정의.

MMA(Message Mapping Application) : 오토플렉스 기지국 인터페이스(Autoplex Base Station Interface : ABI) 호 상태(call state)와 메시지 시퀀스 및 IS­634 호 상태와 메시지 시퀀스 사이를 매핑하는 애플리케이션. MMA는 때때로 개방 A 인터페이스(Open A Interface : OAI)로 지칭된다.

네트워크 구성요소(Network Element) : 셀 사이트(cell site), 애플리케이션 프로세서(Application Processor : AP), 호 처리 데이터 노드(Call Processing Data Node : CDN), 실행 셀룰러 프로세서(Executive Cellular Processor : ECP)와 같은 오토플렉스 시스템의 기능적 컴포넌트.

네트워크 구성요소 세부 상태 애플릿(Network Element Detailed Status Applet) : 네트워크 구성요소에 속하는 관리 객체에 대한 세부 상태를 묘사하는 자바 애플릿. 네트워크 구성요소 세부 상태 애플릿의 샘플 관찰은 AP 웹 페이지 상의 부착물(attachment) 2에서 찾을 수 있다.

네트워크 구성요소 상태(Network Element Status) : NE의 상태를 표시하는 관리 객체 속성과 해당 값. PlanR APCC NE 상태는 RCS­AP와 IS­634­AP 관리 객체, 액티브 알람 리스트 및 눈에 띄는 커맨드(outstanding command)의 테이블로 이루어진다.

통지(Notification) : 이벤트가 관련 네트워크 구성요소에서 발생하면 중개자에 의해 관리자로 보내지는 정보. 이는 기술자 입력 커맨드에의 승인을 물론, 알람 및 정보 메시지, 네트워크 구성요소 내의 구성 변경의 통지를 포함한다.

OAI AP : OAI 애플리케이션을 실행하는 AP.

ORB(Object Request Broker) : 객체 요청 브로커

객체 식별자(Object Identifier) : 관리 객체 클래스 코드와 시스템 내의 임의의 관리 객체 인스턴스를 고유하게 식별하는 인스턴스 식별자의 조합.

지속 속성(Persistent Attribute) : 임의의 클라이언트 요청(예컨대, 보존 상태)과 관계없이 저장되고 현재 보존되는 정보.

RAP API : 프로세스를 발생시키고(spawn) 프로세스 실행의 결과를 얻는 일반적인 API. 일반적으로, RAP는 AP 자원에 대한 보존 커맨드를 수행하는 데 사용될 것이다. RAP는 필요한 경우, 다른 프로세스를 발생시킬 수 있다.

RCC(Reliable Cluster Computing) : 소프트웨어와 하드웨어 컴포넌트를 제공하여 HA 또는 클러스터 시스템(clustered system)의 신뢰도, 이용가능도, 보존도를 향상시키는 루슨트 테크놀로지(Lucent Technologies)의 고도로 이용가능한(Highly­Available : HA) 제품.

RCS(Radio Cluster Server) : 이 애플리케이션은 AP 상에서 실행되어 PlanR마이크로셀(microcell)을 위한 호처리와 OAM 기능을 제공한다. 이 애플리케이션을 위한 소프트웨어는 시리즈 II 셀의 라디오 클러스터 제어기로부터 온다.

RCS AP : RCS 애플리케이션을 호스트하는 AP.

서비스 객체(Service Object) : 관리 객체 클래스를 위한 서비스를 제공하는 객체. 클라이언트 애플리케이션은 이 객체(CORBA에서 이들은 객체에 속박됨)에 대한 참조를 획득한다.

세션(Session) : 각각의 클라이언트는 액세스 허가를 유효화하고 통지의 후속 라우팅을 위해 사용되는 고유한 세션을 확립하여야 한다.

SNMP(Simple Network Management Protocol) : 네트워크 관리자로부터의 네트워크 구성요소를 관리하기 위한 인터넷 표준 프로토콜로서, 세 가지 기본 작업 GET, SET, 트랩(TRAP)(자율 통지)을 제공한다.

SNMP 중개자(SNMP Agent) : 네트워크 구성요소 상에 상주하는 소프트웨어 엔티티와 SNMP 프로토콜을 통한 네트워크 관리자로의 인터페이스. 이 프로세스는 관리자로부터 SNMP 요청을 수신하기 위해 특정 UDP 포트 상에서 경청(listen)하고. 트랩(TRAP)을 NE로부터 관리자로 보낸다.

SNMP 트랩(SNMP Trap) : 네트워크 구성요소로부터 네트워크 관리자로의 자율적인 통지.

상태 변경(State Change) : 관리 객체와 연관된 하나 이상의 속성 변경.

상태 정보(Status Information) : 관리 객체 인스턴스에 대한 현재 속성 값.

시스템 요약 애플릿(System Summary Applet) : 시스템 내의 모든 네트워크 구성요소의 상태의 요약을 디스플레이하는 자바 애플릿. 부착물(Attachment) 2에서, 시스템 요약 애플릿의 예는 네트워크 웹 페이지 상에서 발견할 수 있다.

TI/OP : 기술자 인터페이스 및 출력 프로세서. 입력 커맨드와 출력 보고가 처리되는 오토플렉스 서브시스템.

X 터미널(X Terminal) : X 프로토콜만을 디스플레이하고 EMS 클라이언트 애플리케이션을 호스트하지 못하는 클라이언트 터미널의 유형. 대신, 클라이언트 애플리케이션은 서버 상에서 실행되고 (X 프로토콜을 통해) X 터미널 상에서 디스플레이된다.

머리 글자의 해설(GLOSSARY OF ACRONYMS)

1. 용어 해설(GLOSSARY)

ACF : Agent Configuration File

AP : Application Processor

APCC : Application Processor Cluster Complex

API : Application Programming Notation One

ASN.1 : Abstract Syntax Notation One

C/S : Client/Server

CDPD : Cellular Digital Packet Data

CD­ROM : Compact Disk­Read Only Memory

CHAP : Command Handler Access Point

CMIP : Common Management Information Protocol

COGS : Cost of Goods

CORBA : Common Object Request Broker Architecture

DAT : Digital Audio Tape

DCI : Digital Computer Interface

DELPHI : Desktop Windows Visual Development Tool from Borland

EAI : Emergency Action Interface

EI : Emergency Interface

ECF : Event Configuration File

ECP : Executive Control Processor

ECPC : Executive Control Processor Complex

EIN : Ethernet Interface Node

EMAPI : Element Management Application Programming Interface

EMS : Element Management System

FTP : File Transfer Protocol

GUI : Graphical User Interface

HA : High Availability

HA­OMP : High Availability Operations and Management Platform

HP : Hewlett Packard

HPOV : HP OpenView

HPOVNNM : HP OpenView Network Node Manager

HTML : HyperText Markup Language

HTTP : HyperText Transfer Protocol

ICMP : Internet Control Message Protocol

IDL : Interface Definition Language

IDS : Internal Database Subsystem

IP : Internet Protocol

ipmap : 네트워크 구성요소의 업/다운(up/down) 상태를 모니터하는 데 사용되는 HPOVNNM 컴포넌트

JAR : JAVA Archive

LAN : Local Area Network

LMT : Local Maintenance Terminal

Mbytes : Megabytes

MIB : Management Information Base

MMA : Message Mapping Application

MO : Managed Object

MOID : Managed Object Identifier

NE : Network Element

NEST : Network Element Status Table

NLS : Network Language Support

NMS : Network Management System­EMS로 대체되어 쓰이지 않는 용어

OAI : Open A Interface

OAM : Operations and Administration and Maintenance Platform

OMG : Object Management Group

OMP : Operations and Management Platform

ORB : Object Request Broker

ovspmd : OpenView System Process Management Daemon

ovstart : HPOVNNM startup script, HP OpenView 실행시간을 개시하는 데 사용됨

ovtrapd : OpenView Trap Daemon

ovw : OpenView Windows

ovwdb : HPOVNNM map database manager

pmd : PostMaster Daemon(HPOVNNM의 일부분)

PVM : Platform Virtual Machine

RAP : Resource Administration Process

RCC : Reliable Cluster Computing

RCS : Radio Control System

ROP : Read Only Printer

SCANS : Software Change Administration and Notification System

SDP : Status Display Pages

SLIQ : Qmodem'의 정의된 스크립팅(scripting) 언어

SNMP : Simple Network Management Protocol

SSL : Secure Socket Layer

SU : Software Update

TCP : Transmission Control Protocol

TI/OP : Technician Interface and Output Processor

UDP : User Datagram Protocol

UX : UNIX subsystem

WAN : Wide Area Network

xnmevents : X Network Management Events Browser(HPOVNNM의 일부분)

Claims (33)

1. 다수의 네트워크 구성요소(network element)를 구비하는 원격 통신 네트워크에서 적어도 하나의 네트워크 구성요소를 관리하는 방법에 있어서:

   컴퓨터 인터넷을 포함하는 통신 링크를 통하여 관리 컴퓨터를 구성요소 관리 서버에 접속시키는 단계와;

   상기 컴퓨터 인터넷을 통하여 상기 다수의 네트워크 구성요소 중 적어도 하나를 상기 구성요소 관리 서버에 연결하는 단계로서, 상기 컴퓨터 인터넷은 상기 구성 요소 관리 서버와 상기 네트워크 구성 요소를 인터페이스하는 관리 중개자 애플리케이션을 가진 관련 애플리케이션 프로세서에 다수의 네트워크 구성 요소 중 적어도 하나를 연결하는 것을 포함하는 상기 연결 단계; 및

   상기 관리 컴퓨터와 상기 적어도 하나의 네트워크 구성요소 사이의 상기 구성요소 관리 서버를 통하여 전달되는 통신을 통하여 상기 다수의 네트워크 구성요소 중 적어도 하나를 관리하는 단계로서,

   동일한 네트워크 구성요소 속성에 대한 폴링을 위해 상기 네트워크 구성요소에서 다수의 상이한 관리 컴퓨터로부터의 요청을 수신하는 단계와,

   상기 동일한 속성의 폴링을 위해 단 하나의 요청만이 존재하는 경우에만 동일한 속성에 대해 폴링하는 단계와,

   상기 동일한 속성 폴링 결과를 상기 동일한 속성의 폴링을 요청한 상기 상이한 관리 컴퓨터 모두로 제공하는 단계를 포함하는 상기 관리 단계

   를 포함하는 네트워크 구성요소 관리 방법.
2. 제 1 항에 있어서,

   상기 관리 단계는,

   상기 적어도 하나의 네트워크 구성요소의 관리와 관련된 객체(object)를 갖는 대화형 웹 페이지(interactive web page)를 상기 관리 서버로부터 생성하는 단계와,

   상기 대화형 웹 페이지를 상기 관리 서버로부터 상기 컴퓨터 인터넷을 통하여 상기 관리 컴퓨터로 송신하는 단계와,

   상기 관리 컴퓨터와 상기 적어도 하나의 네트워크 구성요소 사이의 관리 통신을 위해 상기 관리 컴퓨터에서 상기 대화형 웹 페이지를 디스플레이하는 단계

   를 포함하는 네트워크 구성요소 관리 방법.
3. 제 2 항에 있어서,

   상기 대화형 웹 페이지의 객체는 상기 적어도 하나의 네트워크 구성요소의 작업(operation), 관리(administration), 보존(maintenance) 중 적어도 하나와 관련된 객체를 포함하는 네트워크 구성요소 관리 방법.
4. 제 3 항에 있어서,

   상기 웹 페이지는 상기 적어도 하나의 네트워크 구성요소의 작업, 관리, 보존의 모두와 관련된 객체를 포함하는 네트워크 구성요소 관리 방법.
5. 제 2 항에 있어서,

   상기 관리 컴퓨터에서 상기 대화형 웹 페이지와의 상호작용을 통하여 신호를 생성하여 상기 네트워크 구성요소의 커맨드(command), 제어, 고장 관리(fault management) 중 적어도 하나를 달성하는 단계를 더 포함하는 네트워크 구성요소 관리 방법.
6. 제 5 항에 있어서,

   상기 신호를 생성하는 단계는 상기 관리 컴퓨터에서 상기 대화형 웹 페이지와의 상호작용을 통하여 신호를 생성하여, 상기 네트워크 구성요소의 커맨드, 제어, 고장 관리의 모두를 달성하는 단계를 포함하는 네트워크 구성요소 관리 방법.
7. 제 2 항에 있어서,

   상기 대화형 웹 페이지는, 개개의 보존 단위 커맨드 선택(maintenance unit command options) 메뉴를 포함하는 네트워크 구성요소 관리 방법.
8. 제 2 항에 있어서,

   상기 대화형 웹 페이지는, 상기 적어도 하나의 개개의 네트워크 구성요소를 위한 세부 상태 요약 페이지(detailed status summary page)를 포함하는 네트워크 구성요소 관리 방법.
9. 제 2 항에 있어서,

   상기 대화형 웹 페이지는, 상기 다수의 네트워크 구성요소의 모두를 위한 상위 레벨 시스템 상태 요약(high level system status summary)을 포함하는 네트워크 구성요소 관리 방법.
10. 제 2 항에 있어서,

    상기 대화형 웹 페이지는, 상기 원격 통신 네트워크 내부에 모두 액티브 알람(all active alarm)인 리스트를 포함하는 네트워크 구성요소 관리 방법.
11. 삭제
12. 제 1 항에 있어서,

    상기 애플리케이션 프로세서는, 상기 네트워크 구성요소의 보존을 수행하기 위한 보존 애플리케이션(maintenance application)을 포함하며,

    상기 연결 단계는, 상기 구성요소 관리 서버로부터의 커맨드 요청(command request)을 상기 관리 중개자 애플리케이션을 통해 상기 보존 애플리케이션에 인터페이스하여 선택적으로 보존 작업을 수행하는 단계를 포함하는 네트워크 구성요소 관리 방법.
13. 제 1 항에 있어서,

    상기 네트워크 구성요소에 의한 상기 인터페이스 단계는, 상기 구성요소 관리 서버에 애플리케이션 프로세서 특정 이벤트(specific events)와 커맨드 승인(command acknowledgment)을 제공하는 단계를 포함하는 네트워크 구성요소 관리 방법.
14. 제 1 항에 있어서,

    상기 컴퓨터 인터넷은, 월드 와이드 웹(world wide web)이고,

    상기 접속 단계와 연결 단계는, 상기 관리 컴퓨터와 상기 구성요소 관리 서버에서 월드 와이드 웹 기반 JAVA 애플리케이션을 작업하는 작업 단계를 포함하는 네트워크 구성요소 관리 방법.
15. 제 1 항에 있어서,

    상기 관리 중개자 애플리케이션은, 다양한 액션(action)에 응답하고,

    상기 관리 단계는, 상기 관리 중개자 애플리케이션으로부터의 응답을 그 액션을 발생시킨 액션과 상관(correlating)시키는 단계를 포함하는 네트워크 구성요소 관리 방법.
16. 제 1 항에 있어서,

    상기 관리 단계는, 자동적으로 커맨드 응답(command response), 폴링 결과(polling result), 트랩(TRAP)을 상기 관리 컴퓨터로 라우팅(routing)하여 되돌려 보내는 단계를 포함하는 네트워크 구성요소 관리 방법.
17. 다수의 네트워크 구성요소(network element)를 구비하는 원격 통신 네트워크에서 적어도 하나의 네트워크 구성요소를 관리하는 방법에 있어서:

    컴퓨터 인터넷을 포함하는 통신 링크를 통하여 관리 컴퓨터를 구성요소 관리 서버에 접속시키는 단계와;

    상기 컴퓨터 인터넷을 통하여 상기 다수의 네트워크 구성요소 중 적어도 하나를 상기 구성요소 관리 서버에 연결하는 단계―상기 네트워크 구성 요소는 관리 중개자 애플리케이션을 가짐―와,

    상기 관리 컴퓨터와 상기 적어도 하나의 네트워크 구성요소 사이의 상기 구성요소 관리 서버를 통하여 전달되는 통신을 통하여 상기 다수의 네트워크 구성요소 중 적어도 하나를 관리하는 단계와,

    상기 하나의 관리 컴퓨터를 포함하는 다수의 상이한 관리 컴퓨터들로부터 동시에 수신된 다수의 커맨드를 큐잉하는 단계와,

    상기 커맨드를 발생시킨 상기 상이한 관리 컴퓨터 중 적절한 곳으로 응답을 보냄으로써 상기 다수의 커맨드 각각에 연속적으로 응답하는 단계

    를 포함하는 네트워크 구성요소 관리 방법.
18. 제 1 항에 있어서,

    상기 접속 단계는, 상기 관리 컴퓨터에서의 올바른 패스워드 입력에 응답하여 상기 접속(connection)을 인에이블시키는 인에이블 단계를 포함하는 네트워크 구성요소 관리 방법.
19. 제 18 항에 있어서,

    상기 패스워드를 상기 관리 서버로 전송하기 전에 패스워드를 암호화(encrypting)하는 단계를 포함하는 네트워크 구성요소 관리 방법.
20. 제 1 항에 있어서,

    상기 관리 단계는,

    폴링에 이용가능한 다수의 네트워크 구성요소 속성(attribute)으로부터 네트워크 구성요소 속성을 선택하는 단계와,

    상기 선택된 네트워크 구성요소 속성에 대해서만 폴링하는 단계를 포함하는 네트워크 구성요소 관리 방법.
21. 삭제
22. 제 1 항에 있어서,

    새로운 알람의 구동(actuation)과 이전 알람의 클리어(clearing) 중 하나가 발생 시에 상기 네트워크 구성요소의 액티브 알람 리스트를 자동적으로 갱신하는 단계를 포함하는 네트워크 구성요소 관리 방법.
23. 다수의 네트워크 구성요소를 구비하는 통신 네트워크에서, 네트워크 구성요소를 관리하는 방법에 있어서,

    상기 네트워크 구성요소의 커맨드, 제어, 고장 관리를 위해 다수의 상이한 워크스테이션(work station)에서 관리 애플리케이션을 선택적으로 실행하는 단계와,

    컴퓨터 인터넷을 통하여 구성요소 관리 서버를 상기 다수의 상이한 워크스테이션에 인터페이스하여, 상기 다수의 워크스테이션 모두에서 상기 관리 애플리케이션으로 분산 네트워크 구성요소 관리 서비스를 제공하는 단계와,

    단일 노드 관리 프로토콜을 이용하여 상기 구성요소 관리 서버와 상기 네트워크 구성 요소사이에서 상기 컴퓨터 인터넷을 통해 커맨드 승인과 커맨드 요청을 통신하기 위해, 상기 네트워크 구성요소와 관련된 관리 중개자 애플리케이션을 통하여 상기 네트워크 구성요소를 상기 구성요소 관리 서버와 인터페이스하는 인터페이스 단계로서,

    SNMP 네트워크 구성요소와 통신하는 SNMP 서비스 객체 세트를 확립하는 단계와,

    상기 SNMP 서비스와 통신하는 SNMP 중재기 프로세스(SNMP mediator process)를 확립하는 단계와,

    상기 SNMP 서비스 객체에 대해 폴링하는 단계와,

    상기 관리 객체의 커맨드를 SNMP 세트 커맨드로 변환하는 단계와,

    상기 통신 네트워크 내의 이벤트의 작업을 모니터링하는 단계와,

    상기 이벤트의 작업을 감축시켜 상기 통신 시스템의 과부하(overloading)를 방지하는 단계를 포함하는 상기 인터페이스 단계

    를 포함하는 네트워크 구성요소 관리 방법.
24. 제 23 항에 있어서,

    상기 구성요소 관리 서버는, 상기 네트워크 구성요소와 상기 시스템의 다른 자원을 나타내는 관리 객체를 구비하는 객체 서버를 포함하는 네트워크 구성요소 관리 방법.
25. 삭제
26. 삭제
27. 제 23 항에 있어서,

    상기 네트워크 구성요소의 이벤트를 필터링하는 단계를 더 포함하는 네트워크 구성요소 관리 방법.
28. 제 27 항에 있어서,

    상기 이벤트를 필터링하는 단계의 이벤트는, 상기 구성요소 네트워크 시스템 서버(element network system server)에 대한 알람 통지(alarm notification), 상태 변경, 구성 변경(configuration change) 중 적어도 하나를 포함하는 네트워크 구성요소 관리 방법.
29. 제 23 항에 있어서,

    상기 네트워크 구성요소를 인터페이스하는 단계는, 상기 구성요소 관리 서버 내에서 상기 네트워크 내의 현재 알람의 리스트를 보존하는 단계를 포함하는 네트워크 구성요소 관리 방법.
30. 삭제
31. 제 23 항에 있어서,

    상기 관리 애플리케이션은 JAVA로 쓰여지며,

    상기 구성요소 관리 서버와 상기 워크 스테이션을 인터페이스하는 단계는, 커맨드, 제어, 고장 관리 선택 메뉴를 시각적으로 디스플레이하는 대화형 웹 페이지를 통해 수행되는 네트워크 구성요소 관리 방법.
32. 제 31 항에 있어서,

    상기 웹 페이지는, 커맨드, 제어, 고장 관리 선택의 각각에 대한 개별적인 상태 요약 디스플레이(separate status summary display)를 포함하는 네트워크 구성요소 관리 방법.
33. 제 31 항에 있어서,

    상기 웹 페이지는, 상기 통신 네트워크 내의 모든 네트워크 구성요소에 대한 액티브 알람 리스트의 디스플레이를 포함하는 네트워크 구성요소 관리 방법.