KR100560743B1

KR100560743B1 - 엑스엠엘을 이용한 티엘원과 에스엔엠피의 프로토콜 변환방법 및 변환장치

Info

Publication number: KR100560743B1
Application number: KR1020030066388A
Authority: KR
Inventors: 양원종; 이지연
Original assignee: 삼성전자주식회사
Priority date: 2003-09-24
Filing date: 2003-09-24
Publication date: 2006-03-13
Also published as: KR20050030071A

Abstract

본 발명은 본 발명은 네트웍 장비(Network Element, 이하 NE)를 관리하기 위한 프로토콜로서 인터넷에서 가장 널리 사용되는 SNMP 와 통신 장비의 유지/관리 프로토콜인 TL1 과의 변환 알고리즘에 대한 것이다. 본 발명은 네트웍 장비와의 인터페이스에서 실제로는 SNMP가 사용됨에도 사용자 친화적 차원에서 TL1을 지원하는 경우 TL1 입력 스트링이 SNMP 요청 PDU(Packet Data Unit)로 자동 변환되고, SNMP 응답 PDU(Packet Data Unit)가 TL1 출력 스트링으로 자동 변환되게 하는 알고리즘을 특징으로 한다. 본 발명에 의하면 네트웍 장비의 특성 및 기능변경으로 인해 MIB 이나 모델링 데이터 변경시 별도의 소스코드 수정이나 별도의 재 컴파일 작업없이 XML 데이터 변경만으로 새로 추가되는 명령어나 변경되는 명령어를 구현할 수 있다. 따라서 개발기간 단축과 시험, 유지보수에 드는 노력과 시간 절약이 가능하도록 하고 있다.

빌더 팩토리, 빌더, XML 데이터

Description

엑스엠엘을 이용한 티엘원과 에스엔엠피의 프로토콜 변환 방법 {The method of protocol converting between TL1 and SNMP using XML}

도 1은 TL1 입력 메시지를 SNMP 요청 PDU 로 변환하는 과정을 나타낸 블럭도

도 2는 TL1 입력 메시지를 SNMP 요청 PDU 로 변환하는 과정을 나타낸 흐름도

도 3은 SNMP 응답 PDU에서 TL1 출력 메시지(Output Message)로 변환하는 과정을 나타낸 블록도

도 4는 SNMP 응답 PDU에서 TL1 출력 메시지(Output Message)로 변환하는 과정을 나타낸 흐름도

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

100 : TL1 커맨드 101 : 파싱(parsing)

102 : SNMP 빌더 팩토리(SNMP Builder Factory)

103 : SNMP 빌더 (SNMP Builder) 104 : XML 데이터

105 : 밉네임 별 OID 서치 106 : NE(Network Element)

200 : SNMP PDU(package data unit) 201 : 내부 처리 변환부

202 : TL1 빌더 팩토리(TL 1 Builder Factory)

203 : TL1 빌더 (TL 1 Builder) 204 : XML 데이터

205 : TL1 출력 메시지별 실제 데이터 값 표시

206 : TL1 출력 메시지

본 발명은 네트웍 장비(Network Element, 이하 NE)를 관리하기 위한 프로토콜로서 인터넷에서 가장 널리 사용되는 SNMP 와 통신 장비의 유지/관리 프로토콜인 TL1과의 변환 알고리즘에 대한 것이다. 실제 네트웍 장비와의 인터페이스는 SNMP를 사용하지만 사용자 친화적 차원에서 TL1을 지원할 경우, 본 발명은 TL1 입력 스트링이 SNMP 요청 Pdu(package data unit)로 자동 변환되고 SNMP 응답 Pdu(package data unit)가 TL1 출력 스트링으로 자동 변환되게 하는 알고리즘에 관한 것이다. 아울러 그 역방향의 동작 역시 가능하도록 하고 있다.

SNMP라 함은 라우터(router)나 허브(hub)등 망 기기(network agent)의 망 관리 정보를 망 관리 시스템에 보내는 데 사용되는 표준 통신 규약으로 채용된 TCP/IP의 망 관리 프로토콜(RFC 1157)을 말한다. TCP/IP의 게이트웨이 관리 프로토콜 (SGMP: simple gateway management protocol)을 바탕으로 개발되었으며, 개방형 시스템 간 상호 접속(OSI)의 망 공통 관리 정보 프로토콜 (CMIP)에 대응한다. SNMP는 요구와 응답의 2가지 기능을 사용하여 망 관리 정보를 수집, 관리한다. SNMP를 이용한 망관리가 가능하기 위해서는 크게 관리자(Manager), 대리인(Agent), 시스템(System) 이렇게 3가지가 필요하다.

관리자(Manager)는 SNMP 명령을 대리인(Agent) 에게 요청(Request)하여 그 응답(Response)를 처리하고 또 대리인(Agent)으로부터 온 트랩(Trap)을 분석하여 적당한 처리를 하는 시스템을 말한다.

대리인(Agent)은 관리자(Manager)로부터 온 SNMP 요청(Request)을 분석하여 시스템으로부터 그에 상응하는 결과를 요청하거나 자체적으로 처리하여 그 응답(Response)을 관리자(Manager)로 보내고 또 시스템으로부터 어떤 상태 변화가 감지되었을 때 트랩(Trap)을 발생시켜 관리자(Manager)에게 보고하는 시스템이다.

시스템(System)은 실제 관리되는 시스템을 말한다.

SNMP는 MIB(Management Information Base)라는 정보모델을 사용하여 관리자(Manager)와 대리인(Agent)간의 정보를 주고받으며, MIB상의 각 엔티티(Entity)는 OID(Object Identifier)를 이용하여 지정하게 되어있다.

MIB (management information base)이라 함은 SNMP를 이용하여 관리될 수 있는 일련의 네트웍 객체들에 대한 형식적인 설명이다. MIB의 형식은 SNMP의 일부로서 정의되어 있다. 즉 MIB (management information base)은 망 기기를 감시, 제어 하기 위해 사용되는 체계화된 관리 정보 항목들로서 망에서 관리되는 장치가 정적 또는 동적 정보로서 유지되며, 관리 장치가 그 내용을 얻고 변경한다. 따라서 장치 상호(Machine-to-Machine)간에 사용되는 프로토콜로는 적합하나 사람이 직접 OID를 이용해서 장비를 관리하는 것은 불가능하다.

TL1 (Transaction Language 1)은 80년대 초에 미국의 벨 코어에서 제정한 통신 장비의 유지/관리 프로토콜로, ITU-T Z.3XX 시리즈의 MML (Man-Machine Language)을 기반으로 하여 작성된 오퍼레이션시스템(Operations System; OS)와 네트웍 장치(Network Element; NE) 간의 메시지 전달 체계이다.

TL1은 현재 북미를 비롯한 전 세계에서 가장 많이 사용되는 통신장치/망의 유지/관리 명령어이다. TL1은 다음과 같은 장점을 가진다.

첫째, 이해하기 쉽다. 장치상호간 관리규약(Machine-to-Machine Management Protocol)인 SNMP나 CMIP과는 달리 TL1은 ASCII 문자열로 명령어와 메시지가 구성된다. SNMP와 CMIP은 ASN.1 이라는 이진 부호 형태(Binary encoded format)을 사용하기 때문에 사람이 읽을 수도 없고, 읽는다 하더라도 그 뜻을 알 수가 없지만 TL1은 ASCII 문자를 사용하기 때문에 TL1 문법에 대한 특별한 지식이 없어도 메시지의 의미를 읽을 수 있다.

둘째, 명령어 및 메시지의 기계적인 생성 및 해석이 쉽다.각 명령어와 메시지는 블록단위로 구분된 구조로 이루어져 있다. 각 블록은 그 기능과 문법이 명확히 정의되어 있어, 메시지의 기계적인 생성이나 해석이 쉽고, 장치 상호간(Machine-to-Machine) 통신을 위한 이진(Binary)형식으로의 전환도 간편하 다.

셋째, 자동보고 및 운용명령어의 관리가 가능하다. 모든 자동보고 메시지와 명령어 및 응답 메시지는, 관리를 위하여 TAG 필드를 포함한다. 자동보고 메시지의 경우, 메시지의 종류(장애, 성능 등의 구분)에 따라 구분되는, 순차적 증가 카운터인 ATAG (Autonomously correlation TAG)을 이용하여 자동보고 추적(Tracking) 기능을 구현할 수 있고, 운용명령어의 경우에는 명령어와 응답 메시지간의 상호연관성을 부여하기 위하여 CTAG (Correlation TAG)을 사용한다.

넷째, 거의 모든 운용명령어와 메시지가 정의되어 있다. 운용명령어와 메시지는 각 기능별(장애, 구성, 성능, 보안 등)로 거의 모든 경우에 대해 정의되어 있으며, 파라미터와 에러코드에 대해서도 자세히 정의되어 있다. 따라서 TL1 규격을 적용하게 되면, 장비에 관계없이 동일한 기능에 대하여 동일한 메시지를 사용할 수 있으므로, 장비간의 상호 호환성을 부여할 수도 있다.

전술한 바와 같이 TL1은 운용자가 기억할 수 있는 명령어 형태로 되어 있으며 수행결과도 사람이 읽을 수 있는 형태의 텍스트로 표현되므로 관리상 많은 잇점을 갖는다. 따라서 많은 인터넷 장비들이 SNMP 프로토콜을 지원하고 있지만, TL1 프로토콜을 지원해달라는 통신사업자의 요구사항이 발생할 경우에는 중간에 게이트웨이(Gateway)를 두어 변환작업을 수행하게 된다.

그러나 종래의 경우, 운용자가 TL1 명령을 입력할 경우 표준화된 절차없이 하나 하나의 명령어를 SNMP 프로토콜로 변환하는 작업을 구현해야 하는데, 명령어나 MIB이 변경될 경우 일일이 소스 코드를 수정한 후, 반드시 재컴파일 작업을 거 쳐야 하므로 많은 작업과 시간이 소요된다는 문제점이 있었다.

본 발명은 이러한 낭비를 줄이고 쉽게 구현 가능하며 변화에 유연하게 대처할 수 있도록 XML(Extensible Markup Language. 이하 XML )에 모든 정보를 기록한 후, 다이나믹하게 프로토콜간의 변환을 처리할 수 있게 하는 방법을 제공하고자 하였다.

상기한 기술적 과제를 달성하기 위하여 본 발명은 XML 데이터를 비롯하여 SNMP(또는 TL1) 빌더 팩토리(Builder Factory), SNMP(또는 TL1) 빌더(Builder)를 포함하여 이루어진다.

XML 이라 함은 하이퍼텍스트 생성 언어(HTML)를 대체할 목적으로 월드 와이드 웹 컨소시엄(WWW Consorsium)이라는 단체가 표준화 작업을 진행하고 있는 페이지 기술 언어로서 웹 상에서 구조화된 문서를 전송 가능하도록 설계된 표준화된 텍스트 형식이다. HTML에서 사용되는 연결(link) 기능 등을 확장함과 동시에 표준 범용 문서 생성 언어(SGML)를 인터넷용으로 최적화한 것으로 HTML과 SGML의 장점을 모두 가지도록 규정하고 있다. 즉 이는 인터넷에서 기존에 사용하던 HTML의 한계를 극복하고 SGML의 복잡함을 해결하는 방안으로써 HTML에 사용자가 새로운 태그(tag)를 정의할 수 있는 기능이 추가되었다고 이해하면 쉽다. 또한, XML은 SGML의 실용 적인 기능만을 모은 부분집합 (subset)이라 할 수 있으며, 인터넷상에서 뿐 만 아니라 전자 출판, 의학, 경영, 법률, 판매 자동화, 디지털 도서관, 전자상거래 등 매우 광범위하게 이용될 전망이다. 다시 말해 XML은 월드와이드웹, 인트라넷 등에서 데이터와 포맷 두가지 모두를 공유하려고 할 때 유용한 방법이라 할 수 있다.

본 발명은 TL1 입력 메시지(Input Message)에서 SNMP 요청(Request) PDU 로의 변환시 및 그 역방향인 SNMP 응답 PDU에서 TL1 출력 메시지(Output Message)로의 변환시 양자 모두를 포함하여 각각의 변환을 제공하고 있다.

먼저 TL1 입력 메시지(Input Message)에서 SNMP 요청(Request) PDU 로의 변환시 본 발명의 구성은 SNMP 빌더 팩토리(Builder Factory)(102)와 SNMP 빌더 (Builder)(103), XML 데이터(104)를 포함하여 이루어진다.

SNMP 빌더 팩토리(Builder Factory)(102)는 커맨드 코드(Command Code)를 입력받아 XML 데이터중 해당하는 커맨드 코드(Command Code)에 해당하는 것을 찾아 XML 데이터정보를 파싱(Parsing)한 후, 해당 데이터 정보에 대한 SNMP 빌더 (Builder)(103)를 생성한다. SNMP 빌더(Builder)(103)는 입력된 TL1 입력 스트링에 대해서 각 파라미터별로 해당하는 밉네임(mibname)을 매핑(mapping)한다. XML 데이터(104)는 각 커맨드 코드(Command Code)별로 파라미터별 밉 네임 (mibname), 변수 타입(variable type)을 지정한 XML 형식의 데이터 파일을 말한다.

SNMP 응답 PDU에서 TL1 출력 메시지(Output Message)로의 변환시 본 발명의 구성은 TL1 빌더 팩토리(Builder Factory)(202)와 TL1 빌더(Builder)(203), XML 데이터(204)를 포함하여 이루어진다.

TL1 빌더 팩토리(Builder Factory)(202)는 커맨드 코드(Command Code)를 입력받아 XML 데이터 중 해당하는 커맨드 코드(Command Code)에 해당하는 것을 찾아 XML 데이터 정보를 파싱(Parsing)한 후, 해당 데이터 정보에 대한 TL1 빌더(Builder)(203)를 생성한다. TL1 빌더(Builder)(203)는 XML에 정의된 정보를 이용하여 각 밉네임(mib name)별로 운용자에게 보여줄 디스플레이(Display) 스트링과 NE 로부터 받은 값 (value)을 매핑(mapping)하여 TL1출력(Output) 스트링 을 만든다. XML 데이터(204)는 각 커맨드 코드(Command Code)별로 밉네임 (mibname)별 디스플레이(Display)스트링, 변수 타입(variable type)을 지정한 XML 형식의 데이터 파일을 말한다.

본 발명에 있어서 운용자에 의한 TL1 입력은 클라이언트(Client)에서 이루어지며, TL1 또는 SNMP 로의 변환이 이루어지는 변환부인 빌더 팩토리 및 빌더는 서버(Server)에서 수행되어 진다.

이하, 첨부된 도면을 참조하여 본 발명을 상세히 설명한다.

도 1은 TL 1 입력 메시지를 SNMP 요청 PDU 로 변환하는 과정을 나타낸 블럭도이다.

전술한 바와 같이 운용자(operator)에 의한 TL 1 명령어 입력은 클라이언트에서 이루어진다. TL 1 명령어에 대한 파싱이 이루어진 후 TL 1 커맨드 코드에 대한 밉 네임으로의 변환은 서버에서 이루어지며, 최종적으로는 OID(Object Identifier) 형태로 NE(Network Element)에 전달된다. 따라서 서버에서는 SNMP 빌더 팩토리(102)와 SNMP 빌더(103), 그리고 XML 데이터파일(104)이 구동된다.

SNMP 빌더 팩토리(102)는 서버에서 구동되는 프로그램의 라이브러리로 사용되며 XML 데이터파일에 의하여 입력된 TL 1 명령어에 대한 모든 변환이 가능하도록 만들어진다. SNMP 빌더(103)는 클라이언트에 의하여 입력된 각각의 TL 1 명령어에 대한 변환을 담당하며, 파라미터별로 각 파라미터를 밉 네임으로 변환하는 개별적인 매핑을 수행한다. 이는 로딩된 XML에서 TL1 입력 스트링에 포함된 커맨드 코드부분을 찾아 정보를 얻어냄으로써 이루어진다.

간단히 말하면, SNMP 빌더 팩토리(102)는 모든 입력 명령어에 대한 변환이 가능하도록 만들어지는 반면에 SNMP 빌더(103)는 해당 개별 입력 명령어에 대한 변환을 담당한다. 따라서 운용자에 의하여 명령어가 입력되면 입력된 명령어는 SNMP 빌더 팩토리(102)내의 명령어 관련 항목을 검색함으로써 상기 입력 명령어에 대한 변환을 수행하는 SNMP 빌더(103)를 형성하게 된다. SNMP 빌더(103)에 의해 변환된 밉 네임은 예를 들어 1.3.6.1.2.1.1.0 과 같은 OID 형태로 NE(Network Element)(106)에 전달된다.

클라이언트는 윈도우즈 2000등을 이용하는 일반 PC 가 사용될 수 있으며, 서버의 경우 솔라리스(Solaris)가 설치된 유닉스 서버(Unix Server)가 사용될 수 있다. NE(Network Element)의 경우는 ADSL 모뎀(Modem), 허브(Hub), 라우터 (Router)같은 통신장비가 그 대상이 될 수 있다. NE(Network Element)에서는 SNMP 대리인(Agent)가 실행된다.

도 2 는 TL 1 입력 메시지를 SNMP 요청 PDU 로 변환하는 과정을 나타낸 흐름도이다.

먼저 운용자(operator)가 TL1 입력 메시지 스트링을 클라이언트에서 입력한다(s1). 이때 이들 명령어들에 대한 파싱(parsing)이 이루어지게 된다.

한편 파싱(parsing)이라 함은 문장의 분석을 말한다. 즉 컴언어 해석기인 파일러 또는 번역기가 프로그램을 이해하여 기계어로 번역하는 과정의 한 단계로, 각 문장의 문법적인 구성 또는 구문을 분석하는 과정을 말한다. 즉 원시 프로그램에서 나타난 토큰(token)의 열을 받아들여 이를 그 언어의 문법에 맞게 구문 분석 트리(parse tree)로 구성해 내는 일로서 크게 하향식 문장 분석과 상향식 문장 분석으로 나눌 수 있다.

TL1 명령어들에 대한 파싱(parsing)이 이루어지게 되면 SNMP 빌더 팩토리 (Builder Factory)는 TL1 입력 메시지에서 지정한 타겟 정보(tid)에 따라 장비 유형별로 구분된 XML 화일을 로딩하여 장비 종류에 맞는 XML 데이터를 읽어들인다 (s2). SNMP 빌더 팩토리는 서버에서 구동되는 프로그램의 라이브러리로 사용되는 일종의 모듈로서 설계자에 의하여 미리 작성된다. 따라서 이때 SNMP 빌더 팩토리(Builder Factory)의 구동은 하드 디스크에 저장된 SNMP Builder Factory.class 파일과 XML 데이터가 조합해서 하나의 SNMP 빌더 팩토리가 만들어짐으로써 이루어진다. 즉 이때 SNMP 빌더 팩토리는 클래스(Class)가 인스턴스(Instance)화 됨을 의미한다.

한편 인스턴스(Instance)화라 함은 하드 디스크에 저장되어 있던 클래스 (Class)화일이 주기억장치(메모리)상에 공간을 차지하게 된다는 것으로서 어떤 객체가 인스턴스(Instance)화 될 때는 HDD에 저장된 클래스(Class)화일과, 클래스(Class)에 포함된 정보를 초기화하기 위한 데이터가 필요하게 되며 똑같은 클래스라고 해도 안에 들어가는 데이터가 다르게 인스턴스(Instance)화 될 수 있다.

XML 화일 로딩에 따라 구동된 SNMP 빌더 팩토리(Builder Factory)는 SNMP 빌더(Builder)를 생성한다(s3). SNMP 빌더(103)는 전술한 바와 같이 로딩된 XML 에서 TL1 입력 스트링에 포함된 커맨드 코드부분을 찾아 정보를 얻어냄으로써 이루어지는 것으로서 해당 개별 입력 명령어에 대한 변환을 담당한다. 운용자에 의하여 명령어가 입력되면, 입력된 명령어는 SNMP 빌더 팩토리(102)내의 명령어 관련 항목을 검색함으로써 상기 입력 명령어에 대한 변환을 수행하는 SNMP 빌더 (103)를 형성하게 된다.

전술한 바와 같이 XML 데이터(204)는 각 커맨드 코드(Command Code)별로 밉네임(mibname)별 디스플레이 (Display)스트링, 변수 타입(variable type)을 지정한 XML 형식의 데이터 파일을 말한다.

SNMP 빌더(Builder)는 각 커맨드(command)별로 정의된 밉네임(mib name) 을 이용하여 파라미터(parameter)별로 밉네임(mib name)정보를 매핑(mapping) 시킨다 (s4). SNMP 빌더(Builder)에 의한 매핑에 따라 실질적인 프로토콜의 변환이 이루어 지게된다.

입력된 TL1 입력 메시지와 XML에서 얻은 정보를 조합하여 SNMP 패킷이 만들어지며(s5), 이는 매핑(mapping)된 밉네임(mib name)으로 각각의 OID를 찾아 SNMP 패킷 즉 SNMP 응답(Request)PDU를 생성하여 NE로 전송하게 되는 것으로 이에 따른 과정은 본 발명의 범주를 넘기 때문에 이에 관한 자세한 설명은 생략하기로 한다

아래는 get, set 오퍼레이션을 수행하는 2개 명령에 대한 XML 데이터의 예이다.

***** get 오퍼레이션 XML 데이터 파일의 예 *****

</cmd>

***** set 오퍼레이션 XML 데이터 파일의 예 *****

</cmd>

다음은 EMS 에서 NE로 요청하는 커맨드 메시지인 TL1 입력 메시지에 대한

포맷(Format)을 나타낸다.

<command_code>:<staging_parameter_blocks>:<message_payload_block(s)> ;

dis-system-info: ne0: ;

: 메시지를 수신한 NE가 수행할 액션(Action)을 결정한다

(verb-modifier-modifier)

: 타겟(Target) NE와 액션(Action)의 대상을 결정한다 (a:b:c:d)

: 액션(Action)에 필요한 parameter를 전달한다 (e:f)

Semicolon(;)

: 메시지의 끝을 나타낸다.

도 3 은 SNMP 응답 PDU에서 TL1 출력 메시지(Output Message)로 변환하는 과정을 나타낸 블록도이다. 도 3 에서는 SNMP 의 패킷 데이타를 받아 이를 TL 1 출력 메시지(Output Message)로 변환하는 과정에서 동작하게 되는 TL 1 빌더 팩토리(202)와 TL 1 빌더(203), XML 데이터 파일(204)이 나타나 있다.

이때 TL 1 빌더 팩토리(202)와 TL 1 빌더(203), XML 데이터 파일(204)은 전술한 SNMP 빌더 팩토리(102)와 SNMP 빌더(103), XML 데이터 파일(204)과 동일한 개념으로서 그 역방향의 과정을 실현한다. 따라서 TL 1 빌더 팩토리(202)와 TL 1 빌더(203), XML 데이터 파일(204)은 서버내에서 동작되며 NE 의 SNMP 응답 패킷 데이터를 TL 1 출력 메시지(Output Message)로 변환함으로써 운용자에게 친숙한 환경에서 작업할 수 있도록 돕는다.

NE 에서 생성된 SNMP 패킷 데이터(200)는 내부 처리 변환부(201)에 의하여 내부 처리 가능한 형식으로 전환된 다음 커맨드 코드가 TL 1 빌더 팩토리(202)에 전달된다. TL 1 빌더 팩토리(202)는 XML 데이터 파일(204)을 읽어들인 다음 TL 1 빌더(203)를 생성하게 된다. 생성된 TL 1 빌더(203)에서는 각 밉 네임 별로 TL 1 출력 메시지(Output Message)와 매핑이 이루어진다. 매핑된 TL 1 출력 메시지 (Output Message)는 개별적으로 실제 데이터 값을 표시하게 되며(205) 운용자에 친숙한 TL 1 출력 메시지(Output Message)(206)를 통하여 운용자는 NE 에 관한 관리 정보를 얻을 수 있게 된다.

도 4 는 SNMP 응답 PDU에서 TL1 출력 메시지(Output Message)로 변환하는 과정을 나타낸 흐름도이다. NE 로 부터의 SNMP 응답(Request)PDU가 서버로 전달되면(S10) 우선 내부 IPC 메시지 포맷으로 변환된 다음 해당하는 응답에 대한 커맨드 코드가 TL 1 빌더 팩토리에 넘겨진다(S20). TL 1 빌더 팩토리는 SNMP 빌더 팩토리와 동일한 개념으로 이해 될 수 있으며 SNMP 빌더 팩토리와 같이 서버에서 구동되는 프로그램의 라이브러리로 사용되는 일종의 모듈이라 할 수 있다.

응답에 대한 커맨드 코드를 넘겨받은 TL 1 빌더 팩토리(Builder Factory)는 XML 데이터 파일을 읽어들임으로써 실질적인 구동이 이루어진다(S30). 이때 XML 데이터 파일은 커맨드 별로 파라미터에 대한 밉 정보가 정의되어 있다. TL 1 빌더 팩토리(Builder Factory)는 SNMP 빌더 팩토리(Builder Factory)와는 별개의 프로그램으로서 XML 데이터 파일에서 해당하는 커맨드 코드(Command Code)에 대한 것을 찾아 파싱(parsing)한 데이터 가진 TL 1 빌더(Builder)를 생성한다(S40).

TL 1 빌더(Builder)는 밉네임(mibname)별로 정의된 운용자에게 보여질 출력 포맷(PrintOut Format)과 데이터를 매핑(mapping)함으로써(S50) 밉 네임이 TL 1 네임으로 전환될 수 있도록 한다. 이때 실질적인 프로토콜간의 전환이 이루어지게 된 다. 매핑이 이루어진 다음에는 개별적으로 실제 데이터 값이 표시되어 생성된 TL 1 출력메시지(Output Message)가 운용자에게 제공된다(S60).

다음은 위에서 보낸 요청(Request)에 해당하는 XML 문서의 예이다.

</cmd>

</cmd>

</TL1Builder>

이상에서 본 발명에 대한 기술사상을 첨부도면과 함께 서술하였지만 이는 본 발명의 바람직한 실시예를 예시적으로 설명한 것이지 본 발명을 한정하는 것은 아니다. 또한, 이 기술분야의 통상의 지식을 가진 자라면 누구나 본 발명의 기술사상의 범주를 이탈하지 않는 범위 내에서 다양한 변형 및 모방이 가능함은 명백한 사실이다.

본 발명에 의하면 네트웍 장비의 특성 및 기능변경으로 인해 MIB 이나 모델링 데이터 변경시 별도의 소스코드 수정이나 별도의 재 컴파일 작업없이 XML 데이터 변경만으로 새로 추가되는 명령어나 변경되는 명령어를 구현할 수 있도록 함으로써 개발기간 단축과 시험, 유지보수에 드는 노력과 시간 절약이 가능하도록 하고 있다.

Claims

TL1 프로토콜 명령어를 네트워크 장치부의 프로토콜 명령어로 변환하는 방법에 있어서,

TL1 프로토콜 명령을 입력받는 단계;

상기 TL1 프로토콜 명령어 정보와 네트워크 장치부의 프로토콜 명령어 정보를 포함하는 장비별 데이터베이스를 읽는 단계;

상기 입력받은 TL1 프로토콜 명령을 상기 장비별 데이터베이스에 매핑하여, 상응하는 네트워크 장치부의 프로토콜 명령을 출력하는 단계를 포함하는 프로토콜 변환 방법.
제1항에 있어서,

상기 네트워크 장치부의 프로토콜은 SNMP인 것을 특징으로 하는 프로토콜 변환 방법.
제1항에 있어서,

상기 장비별 데이터베이스는 XML(eXtensible Markup Language)로 이루어지는 것을 특징으로 하는 프로토콜 변환 방법.
제1항에 있어서,

상기 매핑은 파라미터별 밉네임 정보의 매핑을 포함하는 것을 특징으로 하는 프로토콜 변환 방법.
네트워크 장치부의 프로토콜 명령어를 TL1 프로토콜 명령어로 변환하기 위한 방법에 있어서,

네트워크 장치부의 프로토콜 명령을 입력받는 단계;

상기 TL1 프로토콜 명령어 정보와 네트워크 장치부의 프로토콜 명령어 정보를 포함하는 장비별 데이터베이스를 읽는 단계;

상기 입력받은 네트워크 장치부의 프로토콜 명령을 상기 장비별 데이터베이스에 매핑하여, 상응하는 TL1 프로토콜 명령을 출력하는 단계를 포함하는 프로토콜 변환 방법.
제5항에 있어서,

상기 네트워크 장치부의 프로토콜은 SNMP인 것을 특징으로 하는 프로토콜 변환 방법.
제5항에 있어서,

상기 장비별 데이터베이스는 XML로 이루어지는 것을 특징으로 하는 프로토콜 변환 방법.
제5항에 있어서,

상기 매핑은 각 밉네임별 TL 1 출력 메시지의 매핑을 포함하는 것을 특징으로 하는 프로토콜 변환 방법.
프로토콜 변환 장치에 있어서,

적어도 하나의 TL1 프로토콜 명령어와 그에 상응하는 네트워크 장치부의 프로토콜 명령어의 정보를 포함하는 장비별 데이터베이스;

입력받은 TL1 프로토콜 명령에 따른 네트워크 장치부의 프로토콜 명령을 상기 장비별 데이터베이스에서 검색하여 파싱하는 빌더 팩토리; 및

상기 입력받은 TL1 프로토콜 명령어의 파라미터를 상기 장비별 데이터베이스에 매핑하여 네트워크 장치부의 프로토콜 메시지로 변환하는 빌더를 포함하는 프로토콜 변환 장치.
제9항에 있어서,

상기 네트워크 장치부의 프로토콜은 SNMP인 것을 특징으로 하는 프로토콜 변환 장치.
제9항에 있어서,

상기 장비별 데이터베이스는 XML로 이루어지는 것을 특징으로 하는 프로토콜 변환 장치.
프로토콜 변환 장치에 있어서,

적어도 하나의 TL1 프로토콜 명령어와 그에 상응하는 네트워크 장치부의 프로토콜 명령어 정보를 포함하는 장비별 데이터베이스;

입력받은 네트워크 장치부의 프로토콜 명령어에 따른 TL1 프로토콜 명령어를 상기 장비별 데이터베이스에서 검색하여 파싱하는 빌더 팩토리; 및

상기 입력받은 네트워크 장치부의 프로토콜 명령어의 파라미터를 상기 장비별 데이터베이스에 매핑하여 TL1 프로토콜 메시지로 빌더를 포함하는 프로토콜 변환 장치.
제12항에 있어서,

상기 네트워크 장치부의 프로토콜은 SNMP인 것을 특징으로 하는 프로토콜 변환 장치.
제12항에 있어서,

상기 장비별 데이터베이스는 XML로 이루어지는 것을 특징으로 하는 프로토콜 변환 장치.