KR100452504B1 - 이엠에스 에이전트에서 에스엔엠피 프로토콜처리방법 - Google Patents

Abstract

본 발명은 EMS 에이전트에서 SNMP 프로토콜 처리방법을 제공하기 위한 것으로, SNMP 데몬을 변경한 약속된 특정 OID를 가진 패킷을 입력받는 제 1 단계와; 상기 제 1 단계 수행 후 SNMP SET REQUEST를 수행하는 제 2 단계와; 상기 제 2 단계 수행 후 SNMP GET RESPONSE를 수행하여 특정 OID에 대한 아웃풋을 문자열이나 숫자로 출력하는 제 3 단계를 포함하여 구성함으로써, SNMP 프로토콜에서 작은 길이의 인풋에 대해 상대적으로 큰 아웃풋 데이터 전송을 위해 기존의 SNMP의 셋 요구 패킷 위에 실린 인풋 메시지를 받아들이고, 그에 대한 응답은 SNMP 겟 응답 패킷 위에 인풋에 대한 아웃풋 메시지를 실어서 보내줌으로써 SNMP 프로토콜을 사용함과 동시에 스트링이나 바이너리 데이터를 주고받을 수 있게 하고, MML와 같이 비교적 짧은 인풋에 비해 큰 아웃풋이 나오는 구조에서 용이하게 적용할 수 있게 되는 것이다.

Description

이엠에스 에이전트에서 에스엔엠피 프로토콜 처리방법{Method for processing SNMP protocol in EMS agent}

본 발명은 EMS(Element Management System) 에이전트에서 SNMP(Simple Network Management Protocol, 간이 통신망 관리 프로토콜) 프로토콜 처리방법에 관한 것으로, 특히 SNMP 프로토콜에서 작은 길이의 인풋(Input)에 대해 상대적으로 큰 아웃풋(Output) 데이터 전송을 위해 기존의 SNMP의 셋 요구 패킷(SET REQUEST Packet) 위에 실린 인풋 메시지(Input Message)를 받아들이고, 그에 대한 응답(Acknowledge)은 SNMP 겟 응답 패킷(GET Acknowledge Packet) 위에인풋(Input)에 대한 아웃풋 메시지(Output Message)를 실어서 보내줌으로써 SNMP 프로토콜을 사용함과 동시에 스트링(String)이나 바이너리(Binary) 데이터를 주고받을 수 있게 하고, MML(Man-machine Language)와 같이 비교적 짧은 인풋(input)에 비해 큰 아웃풋(Output)이 나오는 구조에서 용이하게 적용하기에 적당하도록 한 EMS 에이전트에서 SNMP 프로토콜 처리방법에 관한 것이다.

일반적으로 망 관리란 국제 통신망의 상태를 상시 감시하고 어떠한 상황하에서도 최대한의 트래픽 소통을 가능하도록 하기 위해 필요에 따라 그 유입을 제어하기 위한 조치를 취하는 기능을 말한다.

그리고 NMS(Network Management System, 망관리 시스템)는 이러한 망 관리 업무를 지원하기 위한 컴퓨터 시스템이며, 다음과 같은 기능을 수행한다. 즉, 교환기로부터 망의 상태, 경보, 트래픽 데이터 등을 수집하고 축적한다. 망 관리 파라미터나 통계 데이터를 계산한다. 명령어에 의해 교환기의 트래픽 유입을 제어한다. 망관리 센터의 망 감시반, 망 제어 단말을 제어한다.

또한 EMS(Element Management System)는 망을 구성하는 각각의 장비를 개별적으로 관리하는 장치이다.

도 1은 종래 EMS 에이전트의 블록구성도이다.

여기서 참조번호 10은 SNMP 매니저(Manager)이고, 20은 SNMP 에이전트(Agent)이다.

그래서 원래의 SNMP는 MIB(Management Information Base, 관리 정보 베이스)와 OID(Object Identifier)를 사용하여 관리 객체(주로 네트워크 관련 장비)의 상태를 세팅하고 재시도(Retrieve)할 때 사용하는 프로토콜로서, 장비의 에이전트에는 관리 객체의 OID에 따라서 각종 세팅 값들이 저장되어 있다.

따라서 SNMP는 이 OID를 바꾸고 읽는 데에 사용되는 프로토콜이다.

OID 값을 읽어오는 데에는 SNMP GET을 쓰고, OID 값을 쓰는 데에는 SNMP SET을 쓴다.

그래서 종래에는 다음과 같이 SNMP를 사용하였다.

즉, SNMP는 MIB와 OID를 사용하여 관리 객체(주로 네트워크 관련 장비)의 상태를 세팅하고, 재 시도할 때 사용하는 프로토콜인데, MIB에 할당되는 OID는 각 회사 별로 고유한 넘버(Number)가 있으며, IANA(Internet Assigned Number Authority)에서 할당한다.

ATM(Asynchronous Transfer Mode, 비동기 전송 방식), ADSL(Asynchronous Digital Subscriber Line, 비동기 디지털 가입자선), DS3(Digital Signal - level 3), STML 등 각종 관리 객체에 대한 OID와 그 정의는 RFC(Request For Comments) 문서에 나와 있다.

그래서 종래의 SNMP 프로토콜을 쓰면 장비의 에이전트에서 기대할 수 있는 아웃풋은 정해진 포맷으로 아웃풋 스트링(Output String)을 받거나, 숫자로 밖에 받을 수 없게 된다.

인풋은 OID를 꼭 써야 하며, 그 OID 형식에 맞는 인풋을 주어야 한다.

그러므로 이 SNMP 프로토콜은 원래 설계되기를, 에이전트에 있는 데이터를 읽어올 때는 OID를 써서 읽어 오고(SNMP GET), 이 때에는 응답되는 패킷이 문자열을 포함할 수 있다.

에이전트에 있는 값을 변경할 때는 문자열이나 숫자를 다 쓸 수 있다(SNMP SET).

그러나 이 때에는 보낸 값으로 세팅했다는 응답 메시지만 온다.

만일 에이전트와 EMS 간의 통신으로 MML(Man-machine Language)을 쓴다고 할 때는, EMS가 어떤 인풋 데이터를 에이전트에 보내서, 정해지지 않은 길이의 가공된 아웃풋이 에이전트로부터 나오기를 기대하게 된다.

이럴 때는 종래의 SNMP 프로토콜은 MML 메시지의 통신 프로토콜을 사용하지 못하게 되는 문제점이 있었다.

이에 본 발명은 상기와 같은 종래의 제반 문제점을 해소하기 위해 제안된 것으로, 본 발명의 목적은 SNMP 프로토콜에서 작은 길이의 인풋에 대해 상대적으로 큰 아웃풋 데이터 전송을 위해 기존의 SNMP의 셋 요구 패킷 위에 실린 인풋 메시지를 받아들이고, 그에 대한 응답은 SNMP 겟 응답 패킷 위에 인풋에 대한 아웃풋 메시지를 실어서 보내줌으로써 SNMP 프로토콜을 사용함과 동시에 스트링이나 바이너리 데이터를 주고받을 수 있게 하고, MML와 같이 비교적 짧은 인풋에 비해 큰 아웃풋이 나오는 구조에서 용이하게 적용할 수 있는 EMS 에이전트에서 SNMP 프로토콜 처리방법을 제공하는데 있다.

상기와 같은 목적을 달성하기 위하여 본 발명의 일 실시예에 의한 EMS 에이전트에서 SNMP 프로토콜 처리방법은,

SNMP 데몬을 변경한 약속된 특정 OID를 가진 패킷을 입력받는 제 1 단계와; 상기 제 1 단계 수행 후 SNMP SET REQUEST를 수행하는 제 2 단계와; 상기 제 2 단계 수행 후 SNMP GET RESPONSE를 수행하여 특정 OID에 대한 아웃풋을 문자열이나 숫자로 출력하는 제 3 단계를 포함하여 수행함을 그 기술적 구성상의 특징으로 한다.

도 1은 종래 EMS 에이전트의 블록구성도이고,

도 2는 본 발명에 의한 EMS 에이전트에서 SNMP 프로토콜 처리방법을 보인 흐름도 이다.

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

10 : SNMP 매니저

20 : SNMP 에이전트

이하, 상기와 같은 본 발명, EMS 에이전트에서 SNMP 프로토콜 처리방법의 기술적 사상에 따른 일 실시예를 도면을 참조하여 설명하면 다음과 같다.

도 2는 본 발명에 의한 EMS 에이전트에서 SNMP 프로토콜 처리방법을 보인 흐름도 이다.

이에 도시된 바와 같이, SNMP 데몬(Daemon)을 변경한 약속된 특정 OID를 가진 패킷을 입력받는 제 1 단계(ST10)와; 상기 제 1 단계 수행 후 SNMP SET REQUEST를 수행하는 제 2 단계(ST20)와; 상기 제 2 단계 수행 후 SNMP GET RESPONSE를 수행하여 상기 특정 OID에 대응되는 응답메시지의 아웃풋(Output)을 문자열이나 숫자로 출력하는 제 3 단계(ST30)(ST40)를 포함하여 수행한다.

이와 같이 구성된 본 발명에 의한 EMS 에이전트에서 SNMP 프로토콜 처리방법의 동작을 첨부한 도면에 의거 상세히 설명하면 다음과 같다.

먼저 본 발명에서는 종래의 SNMP 프로토콜을 쓰되, OID는 지정된 하나만 사용한다. 즉, TMO(Transparent Mib Object)가 되는 것이다.

지정된 OID에 SNMP SET으로 어떠한 인풋(Input)을 써넣으면, 에이전트는 인풋(Input)을 가지고 그 장비만의 데이터로 가공한 다음 SNMP GET RESPONSE로 아웃풋(Output)을 내 보낸다.

여기서 본 발명에서 사용하는 SNMP SET REQUEST 패킷의 구조는 다음과 같다.

① 30 82 00 3b

② 02 01 00

③ 04 09 6c 67 64 73 6c 6d 75 78 21

④ a3 82 00 29

⑤ 02 04 5f 62 ce 5e

⑥ 02 01 00

⑦ 02 01 00

⑧ 30 82 00 19

⑨ 30 82 00 15 06 08 2b 06 01 02 01 01 05 00

⑩ 04 09 49 6e 70 75 74 44 61 74 61

1. "0x30" : SNMP 패킷,

"82 00 3b" : 바로 뒷부분부터 끝까지의 길이는 3b이다.

2. "02 01 00" : "02"는 다음에 올 데이터는 정수형(integer) 형이고, "01"은 데이터가 1 바이트란 뜻이며, 버전은 SNMP v1이다.

3. "04 09 6c 67 64 73 6c 6d 75 78 21" : 여기서 "04"는 뒤에 올 데이터가 문자형(char)이고, 09개의 community name이 뒤에 온다는 뜻이다. community name -> lgdslmux!

4. "a3 82 00 29" : SNMP 패킷 타입은 SNMP SET TYPE 이고, 끝까지 길이는 0x29이다.

5. "02 04 5f 62 ce 5e" : 데이터 형태는 integer이고, 4바이트이며, "5f 62 ce 5e"는 REQUEST ID로써 SNMP 패킷마다 서로를 구분하기 위해 다르게 전달된다. 물론 RESPONSE와 REQUEST의 ID는 서로 같아야 한다.

6. "02 01 00" : 에러 상태(Error State) -> No Error

7. "02 01 00" : 에러 인덱스(Error Index) -> 0

8. "30 82 00 19" : 이 뒤로는 0x19 바이트가 있다.

9. "30 82 00 15 06 08 2b 06 01 02 01 01 05 00" : 이 뒤로는 0X15 바이트가 있고, "06"은 OID를 나타내며, "08"은 OID의 길이가 8 바이트라는 것을 나타낸다. 그리고 "OID : 2b 06 01 02 01 01 05 00"은 1.3.6.1.2.1.1.5이다.

10. "04 09 49 6e 70 75 74 44 61 74 61" : 이는 인풋 데이터이다. 즉, "04"(char) "09"(길이) "49 6e 70 75 74 44 61 74 61"(인풋 데이터)이다.

한편 본 발명에서 변형된 SNMP RESPONSE 패킷의 구조는 다음과 같다.

① 30 82 00 3b

② 02 01 00

③ 04 09 6c 67 64 73 6c 6d 75 78 21

④ a3 82 00 29

⑤ 02 04 5f 62 ce 5e

⑥ 02 01 00

⑦ 02 01 00

⑧ 30 82 00 19

⑨ 30 82 00 15 06 08 2b 06 01 02 01 01 05 00

⑩ 04 09 49 6e 70 75 74 44 61 74 61

여기서 ④번의 위치에 0x03 대신 0xa2가 오고, 각각 길이 체크 바이트가 수신된 데이터의 길이에 따라 변한다.

순수 데이터의 바로 앞에는 인풋과는 달리 4바이트의 헤더가 붙어서 온다.

SNMP 헤더 + 30 39 30 31 aa bb aa bb aa bb ...... -> 09/01 : 모두 9개의 패킷 중 첫 번째란 뜻이다.

이러한 RESPONSE는 원래의 SNMP SET에 대한 RESPONSE와는 다르다.

상기한 두 가지 패킷이 변형된 SNMP SET REQUEST와 RESPONSE 패킷이다.

이와 같이 쓰게 되면, 어떤 메시지라도 SNMP 에이전트에 보낼 수 있으며, 그 메시지에 대한 답을 변형된 RESPONSE 패킷에 실어서 보낼 수가 있게 된다.

또한 RESPONSE를 보낼 때, 한번에 다 보내는 것이 아니라, 한 패킷 당 2Kbyte가 되도록 원래의 RESPONSE를 쪼개어서 보냄으로써 UDP(User Datagram Protocol, 사용자 데이터그램 프로토콜)에서 큰 데이터를 보낼 때 약간이나마 안정성을 줄 수 있다.

그래서 도 2를 보면 다음과 같이 수행하게 된다.

즉, 일반적인 SNMP GET이나 SNMP SET REQUEST(메시지 전송을 위한 OID 외의 다른 OID를 가진 SNMP 패킷)을 수신하고, 메시지 전송을 SNMP SET(특정한 OID 사용) REQUEST 패킷을 수신하면, 종래의 SNMP 데몬을 변형시켜서 약속된 특정한 OID를 가진 패킷이 입력되면 SNMP SET REQUEST에 대하여 SNMP GET RESPONSE로 응답한다. 나머지 일반적인 인풋 패킷에 대해서는 종래와 동일하게 응답한다.

이를 수행결과 다음과 같이 된다.

일반적인 SET REQUEST에 대한 응답 : 성공, 실패에 관한 응답 패킷 출력

일반적인 GET REQUEST에 대한 응답 : 요청한 정보가 GET REQUEST 시에 지정한 OID에 있으면 그 정보를 출력한다. (문자열 또는 숫자)

본 발명에 따른 SNMP SET REQUEST에 대한 응답 : 사용자가 미리 지정해 둔 OID로 어떠한 인풋이 들어왔을 때, 인풋에 대한 처리를 해서 그 아웃풋을 문자열이나 숫자로 출력한다. 따라서 특정한 OID에 대해서는 SNMP SET REQUEST에 대해서 SNMP GET RESPONSE를 출력하게 되는 것이다.

이러한 본 발명의 동작을 하나의 가정을 두어 설명하면 다음과 같다.

(가정)

1. 만일 TMO(Transparent Mib Object)로는 1.3.6.1.2.1.5.1.0 OID를 사용한다고 하고,

2. community name(SNMP 프로토콜에서 정의된 최소한의 보안 장치)으로는 약속된 스트링을 쓴다고 할 때(여기서는 'private'를 쓰기로 한다.),

3. 사용자 'myinput'이란 데이터를 에이전트에 입력하여 'my output is very long'이란 아웃풋을 받고 싶다고 하면,

(과정)

1. 'myinput'이란 메시지를 SNMP 매니저 툴(UNIX의 경우 snmpset)이라든지 기타 SNMP 패킷 생성기를 이용하여 에이전트로 보낸다.

UNIX의 경우에는 다음과 같다.

snmpset AGENT_IP private 1.5.0 s "myinput"

2. 그럼 에이전트에서는 OID 1.3.6.1.2.1.5.1.0에 myinput이란 데이터를 기록하겠다는 뜻으로 해석한다. 그냥 쓰기만 쓰고, 그에 대한 OK acknowledge 만 response 하면 종래의 SNMP와 다를 바가 없지만,

3. 변형된 SNMP 에이전트는 input data message인 'myinput'을 해석한 뒤 그에 맞는 아웃풋 메시지를 만든다.

4. 에이전트는 Acknowledge를 가로채어서, 아웃풋 메시지인 'my output is very long'을 넣어서 되돌려 준다.

5. 만일 아웃풋 포함 전체 패킷의 길이가 2Kbyte를 넘는다면, 2Kbyte 씩 패킷을 쪼개어서 보낸다.

6. 이런 경우, 아웃풋 메시지의 앞에 nnNN을 붙여서 보낸다.

7. NN은 전체 패킷의 개수, NN은 그 중 몇 번째인가를 나타내게 된다. 예를 들어, 아웃풋 메시지 처음 부분에 (0x01 0x01 ...)이 있다면, 총 1개의 패킷 중 첫 번째란 말이 된다.

8. 기타 correlation tag 나 패킷의 형태는 SNMP 원래 패킷의 모양을 따른다.

9. 물론 이런 변형된 패킷을 해석하기 위해서는 SNMP 매니저 부분에서 지원을 해야 한다.

이처럼 본 발명은 SNMP 프로토콜에서 작은 길이의 인풋에 대해 상대적으로 큰 아웃풋 데이터 전송을 위해 기존의 SNMP의 셋 요구 패킷 위에 실린 인풋 메시지를 받아들이고, 그에 대한 응답은 SNMP 겟 응답 패킷 위에 인풋에 대한 아웃풋 메시지를 실어서 보내줌으로써 SNMP 프로토콜을 사용함과 동시에 스트링이나 바이너리 데이터를 주고받을 수 있게 하고, MML와 같이 비교적 짧은 인풋에 비해 큰 아웃풋이 나오는 구조에서 용이하게 적용하게 되는 것이다.

이상에서 본 발명의 바람직한 실시예를 설명하였으나, 본 발명은 다양한 변화와 변경 및 균등물을 사용할 수 있다. 본 발명은 상기 실시예를 적절히 변형하여 동일하게 응용할 수 있음이 명확하다. 따라서 상기 기재 내용은 하기 특허청구범위의 한계에 의해 정해지는 본 발명의 범위를 한정하는 것이 아니다.

이상에서 살펴본 바와 같이, 본 발명에 의한 EMS 에이전트에서 SNMP 프로토콜 처리방법은 SNMP 프로토콜에서 작은 길이의 인풋에 대해 상대적으로 큰 아웃풋 데이터 전송을 위해 기존의 SNMP의 셋 요구 패킷 위에 실린 인풋 메시지를 받아들이고, 그에 대한 응답은 SNMP 겟 응답 패킷 위에 인풋에 대한 아웃풋 메시지를 실어서 보내줌으로써 SNMP 프로토콜을 사용함과 동시에 스트링이나 바이너리 데이터를 주고받을 수 있게 하고, MML와 같이 비교적 짧은 인풋에 비해 큰 아웃풋이 나오는 구조에서 용이하게 적용할 수 있는 효과가 있게 된다.

Claims (1)

1. SNMP 데몬을 변경한 약속된 특정 OID를 가진 패킷을 입력받는 제 1 단계와;

   상기 제 1 단계 수행 후 SNMP SET REQUEST를 수행하는 제 2 단계와;

   상기 제 2 단계 수행 후 SNMP GET RESPONSE를 수행하여 상기 특정 OID에 대응되는 응답메시지의 아웃풋을 문자열이나 숫자로 출력하는 제 3 단계를 포함하여 수행하는 것을 특징으로 하는 EMS 에이전트에서 SNMP 프로토콜 처리방법.