0

네트워크관리(NMS)

Chapter 11Chapter 11

1

1. NMS 개요

인터넷과 인트라넷의 활성으로 많은 업무가 네트워크를 통하여 이루어지게 된다.

의사 전달을 위한 E-Mail이나 그룹웨어, 클라이언트/서버 업무 처리 등 네트워크의

중요성은 날로 높아지고있다.

네트워크 환경이 대형화 되고 복잡해짐에따라 네트워크의 관리 또한 중요한 비중을

차지하게 되었다. 네트워크의 다운이나 속도의 저하로 인해 업무처리가 늦어진다면

이것은 이제 단순한 문제가 아니다.

NMS를 사용하여 네트워크상의 장비를 Monitoring하고 장애에 대한 신속한 대처를

할 수 있도록 구성한다. 네트워크 구성상의 문제를 발견할 수 있으며 이러한

자료들이 네트워크 구성을 효율적으로 구성하게 하고 향후 네트워크 설계의 자료가

될 수 있다.

네트워크 관리 시스템에서 사용중인 프로토콜인 SNMP, CMIP 그리고 RMON등에

대하여 알아보고자 한다.

Chapter 11. 네트워크 관리 (Network Management System)

2

2. SNMP (Simple Network Management Protocol)

2.1 SNMP 배경

관리 표준 프로토콜이 정착되기 이전에 업체들은 자기 고유의 관리 프로토콜을

지원하고 있었다.

따라서 각 업체들은 중앙 명령콘솔에 대한 고객 소프트웨어는 물론 네트워크화한

장비를 위한 펌웨어도 제공해야만 했다. 몇몇의 큰 회사들은 서로 비밀을

보장한다는 조건으로 인터페이스 정보를 교환함으로써 자신들 고유의 중앙

네트워크 관리 제품을 일반적인 네트워크 관리 플랫폼으로 성장시키려고 애썼다.

그러나 호환성 있는 에이전트의 그룹이 제한돼있고 네트워크 관리 시스템 업체의

고유 정보를 공유하는 그룹 이외의 장비를 관리하기 힘들기 때문에 이것은 대체로

성공적이지 못했다.

그러던중 SNMP(Simple Network Management Protocol)는 88-89년에 선두로

부상했으며 현재 거의 모든 네트워크 관리 제품에서 지원하고 있다. SNMP가

급속히 표준으로 채택된 이유는 기업 네트워크에서 증명된 능력, 타당한 가격대

성능, 그리고 보다 중요한 것은 다른 표준 프로토콜을 지원하는 제품이 거의 없다는

점이다.

Internet Activitise Board 에서 개발한 Network 관리 프로토콜인 SNMP는 처음에는

TCP/IP 네트워크를 관리 하기위해 설계되었다. 비록 SNMP가 IP 스택에 존재하지만

비 TCP/IP장비를 포함한 어떤 형태의 네트웍 트래픽도 관리하고 모니터 할 수 있다.

SNMP 패킷은 모든 표준 IP 라우터를 이용해 경로배정이 가능하므로 브리지와

라우터로 연결된 네트워크와 같은 네트워킹 환경관리에 이상적이다.

SNMP는 여러 업체의 장비로 구성된 네트워크 관리의 표준이 되어버렸다. 자신들의

네트워크 장비에 SNMP 에이전트를 지원하는 제조업자가 많을 뿐만 아니라

윈도우나 유닉스 시스템용의 다양한 중앙관리 소프트웨어 패키지가 존재한다.

3

2.2 SNMP의 구성

TCP/IP 네트워크를 관리하기 위한 4가지 모델은 관리 시스템, 관리대상 에이전트, MIB, 네트워크관리 프로토콜로 구성된다.

관리 시스템은 네트워크 관리자에게 전 네트워크 상황을 볼 수 있는 인테페이스를제공하며 관리 데이타의 분석, 장애관리 등의 기능수행을 위한 데이타베이스를구축하고 있다. SNMP 에이전트는 피관리대상장비, 즉 호스트, 라우터, 브릿지, 허브와 같은네트워크 장비에 설치되어 관리 시스템의 요구에 따라 관리 정보를 송달하거나 관리시스템의 액션 요구를 수행하며 문제 발생시 자동적으로 장애 상황을 관리 시스템에통보한다.네트워크 관리 프로토콜로서 현재 가장 널리 사용되는 SNMP는 OSI에서 정의된CMIP와 공존하며 일정기간 계속 사용되리라 예상되고 있다. MIB(Management Information Base) 란 TCP/IP를 기초로한 관리 모델에서 각피관리 대상장비의 관리 되어질 요소들에 대한 정보를 포함하고 있는 데이터베이스이다. 이때 관리되어지고 있는 각 정보들을 오브젝트라고 하며 MIB은 이러한오브젝트들의 계층적 트리구조로 이루어져 있다. MIB은 SMI 규칙에 따라 5가지기능분야로 분류된다.

▶ 구성관리 (Configuration Management)- 네트웍상의 장비와 전반적인 물리구조를 Maping 하는 기능을 말한다.

▶ 성능관리 (Performance Management)- 가용성, 응답시간, 사용량, 에러량, 처리속도 등 성능 분석에 필요한

통계 데이타를 제공하는 기능

▶ 고장관리 (Fault Management)- 문제의 검색, 추출 및 해결을 제공하는 기능

▶ 보안관리 (Security Management)- 정보의 제어 및 보호 기능

▶ 계정관리 (Accounting)- 각 노드별로 사용현황을 측정하는 기능

4

[그림] SNMP 프로토콜 아키텍처

2.3 SMNP의 동작

SNMP는 매니저와 에이젼트 사이에 관리정보를 주고 받기위한 프로토콜이다. 이들정보의 교환은 메시지 단위로 이루어지며 SNMP 메시지는 GetRequest PDU,GetNextRequest PDU, SetRequest PDU, GetResponse PDU, Trap PDU의 다섯가지 형태를 갖는다.

•GetRequest PDU는 매니저가 하나 또는 그 이상의 에이젼트에게 오브젝트값을 요청하기 위해 사용한다.

•GetNextRequest PDU는 GetRequest PDU와 같지만 이 경우, 돌려받는오브젝트 값은 MIB상에 정의된 어휘적인 순서로서의 다음 오브젝트 값이다.

•SetRequest PDU는 값을 요청하기 위한 것이 아니라 값을 설정(변경)하기위해 매니저가 에이젼트에게로 보내는 메시지이다.

위의 세가지 메시지에 대한 응답은 GetResponse PDU로 돌려진다. Trap PDU는에이젼트가 자신에게 일어나 사건들에 대한 정보를 매니저에게 알리는 메시지이다.

SNMP는 비연결 지향형인 UDP(user datagram protocol) 상에서에 동작하지만앞으로는 전송-레벨의 여러 다양한 프로토콜 상에서 동작하도록 향상될 것이다.

5

[그림] SNMP Manager와 Agent간의 통신

[그림] SNMP Message Format

6

2.3 SNMP v1의 문제점 및 SNMP v2

SNMP v2는 다음에 나타난 것처럼 SNMP v1의 불충분한 기능을 강화하기 위해

표준화되었다.

처리 효율 시 기능상 한계

처리 효율의 저하는 SNMP v1이 커넥션리스 프로토콜상에서 실장되는 점과 복수

동시 요구 및 응답을 행하는 명령이 지원되지 않는 등에서 기인한다.

SNMP v2에서는 GetBulkRequest-PDU를 도입하여 한번의 요청으로 여러 테이블

값들을 읽어오는 것이 가능해져서 불 불요한 대역폭을 줄일 수 있다.

데이터 기밀 보호에 있어서의 한계

정보 보호에 관해서는 ‘Secure SNMP’가 먼저 표준화되어 있는데, 기능강화에

따라 네트워크의 부하가 증대되는 단점 때문에 현재 널리 보급되지 못하고 있다.

SNMP v2에서는 DES(Data Encryption Standard) 알고리즘과 MD5(Message

Digest 5) 알고리즘을 사용하여 데이터 보안 기능과 인증절차에 대한 보안 기능을

추가하였다. 또한 Party MIB을 사용하여 특정한 사용자에게만 특정 객체를

이용하게하는 Access Control기능을 추가했다.

관리 시스템간(매니져간) 연대 기능상의 한계

매니져간 연대기능이 없는것은 SNMP의 아키텍처에 피어 투 피어 기능의 개념이

포함되지 않기 때문이다. 또, 하나의 매니저 에이전트형 관리시스템을 포함하는

논리공간의 개념이 없어서 기능상 발전성을 가지고 있지 않다.

SNMP v2에서는 매니져간 통신을 위한 InformRequest-PDU가 정의되었고 이를

위한 Manager To Manager MIB을 정의해 놓았다.

7

3. MIB (Management Information Base)

3.1 MIB의 개요

네트워크나 인터네트워크에서 각 시스템(워크스테이션, 서버, 라우터, 브릿지

등)등은 관리 대상의 상태를 보여주는 MIB을 가지고 있다. 네트워크 관리는

MIB에서 오브젝트의 값를 읽음으로 자원을 모니터할 수 있으며, 그 값을

수정함으로 자원을 조정할 수 있게 한다.

MIB이 네트워크 관리 시스템에서 역할을 다하기 위해서는 확실한 관리대상이

있어야 한다.

각 시스템에서 특별한 자원을 나타내기 위한 오브젝트들은 같아야 한다.

시스템에서 TCP에 관하여 저장된 정보의 예를 들어보자. 일정 시간동안 열리는

모든 접속은 액티브 오픈(active open)과 패시브 오픈(passive open)으로

되어있다. 시스템에서 MIB은 관련된 3개(액티브 오픈의 수, 패시브 오픈의 수, 전체

오픈의 수) 중에서 2개를 저장하고 있으며, 나머지 한 개는 필요로 할 때 계산해낼

수 있다. 게다가 다른 시스템에서 저장을 위해 다른 쪽을 선택한다면, 요구하는

정보에 접근하기 위해 하나의 프로토콜로는 어려울 것이다. 그러한 상황에서,

TCP/IP 에 관 한 MIB 정 의 는 저 장 된 액 티 브 오 픈 ( active open) 과

패시브오픈(passive open) 숫자를 나타난다.

공통 기준을 나타내기 위해서는 반드시 공유 가능한 환경이 되어야 한다. 공유

가능한 환경이 되어야 한다는 것은 SMI(관리정보 구조)의 정의에서 다루고 있는데,

관리대상이라는 의미로 다루고 있는 특별한 이슈와 함께 이 장에서 살펴보고 있다.

오브젝트가 같아야 한다는 것은 MIB에서 오브젝트와 오브젝트의 체계화를

정의하는 것을 통해 나타난다.

8

3.2 MIB 구조

SNMP 환경에서 운영되는 오브젝트는 계층적인 구조나 트리 구조로 정돈되어있다. 트리의 잎(leaf)에 해당하는 것이 실제로 운영되고 있는 오브젝트이며, 각오브젝트는 자원, 행동 또는 운영되는 관련된 정보를 나타낸다. 트리 구조 자체는논리적으로 이해관계를 가지고 있는 체제의 그룹화를 말한다.

MIB 안에 있는 각 오브젝트형과 관련된 것 중 ASN.1타입 OBJECT IDENTIFIER의ID가 있다. 이 ID가 오브젝트의 이름이 된다. 그 외에도 OBJECT IDENTIFIER와관련된 값은 계층 구조이기 때문에, 이름을 붙이는 규정이 오브젝트형의 구조를명시한다. 오브젝트 ID는 고유한 값이며, 그 값은 연속적인 번호로 되어 있다.

정의된 오브젝트의 세트는 뿌리에 해당하는 부분이 ASN.1 표준을 의미하는 트리구조로 되어 있다. 각 오브젝트의 ID는 트리의 뿌리 부분부터 가지까지 구성한다. 뿌리에서 시작해서, 첫번째 레벨에는 iso, ccitt, joint-iso-ccitt의 3가지 노드가있다.

iso, ccitt, joint-iso-ccitt의 iso 노드에서, 하나의 서브트리는 조직집단(org)을위해서 사용된다. org의 하위트리 중 한 개는 미국방성(dod)이다. RFC1155는아래와 같이 dod의 서브트리중 1개가 IAB( Internet Activities Board)에 의한관리를 위하여 할당된 것으로 처리한다.

internet OBJECT IDENTIFIER ::= { iso(1) org(3) dod(6) 1 }

인터넷 노드는 1.3.6.1이라는 오브젝트 ID를 가지고 있다.(뒷 장 그림 참조) 이것은트리구조의 experimental 노드 앞에 붙은 타이틀이다. 아래와 같이, SMI 다큐먼트는 internet 노드에서 4개의 노드를 정의하고 있다.

- directory : 추후 OSI 디렉토리 사용을 위하여 예약됨- mgmt : IAB가 승인한 문서에 의해 정의된 오브젝트를 위하여 사용됨- experimental : 인터넷 실험에서 각 오브젝트를 식별하기 위해 쓰인다.- private : 일방적으로 정의된 오브젝트를 정의하는 데 쓰인다.

9

iso (1)

org (3)

dod (6)

internet (1)

derectory (1)

mgmt (2)

mib-2 (1)

System (1)

interfaces (2)

At (3)

ip (4)

icmp (5)

tcp (6)

udp (7)

egp (8)

transmission (10)

snmp (11)

exeperimental (3)

private (4)

enterprise (1)

[그림] MIB의 오브젝트 그룹

10

mgmt 서브트리는 IAB로 인증된 MIB 정의를 포함하고 있다. 현재 mib-1과 mib-2의 두 가지 버전의 MIB이 개발되어 있다. mib-2는 mib-1에서 확장된 것이다. 어떤 구성도에서는 두 MIB 중 하나만 있기 때문에, 서브트리에서 둘의 오브젝트ID는 같다.

그 외의 오브젝트들은 다음 세 가지로 구분된다.

1. mib-2 서브트리는 확장되거나 완전히 새로운 리비젼(mib-3과 같은)으로교체될 수 있다. mib-2를 확장시키기 위해 새 서브트리가 정의된다. 예를 들면, 원격 네트워크 감시(RMON : Remote Network Monitoring) MIB은 mib-2에서는16번째 서브트리로 정의된다. (mib-2 (16))

2. 시험적인 MIB은 특별한 어플리케이션으로 구성될 수 있다. 그러한오브젝트들은 후에 mgmt 서브트리로 옮겨질 수도 있다. 이러한 예는 IEEE802.5 토큰링 (RFC 1231)과 같이 다양한 전송매체에 관리정보를 포함한다.

3. private 확장은 private 서브트리에서 추가될 수 있다. RFC에서 문서화된 것 중한 개가 MUX(mulyiplexer) 관리정보이다. (RFC1227)

현재 private 서브트리에는 enterprise 노드라고 정의된 차일드(child) 노드가 있다. 서브 트리의 이 부분은 벤더의 장비운영 향상을 위해 사용되며, 시스템 내의공유환경을 필요로 하는 다른 사용자와 벤더들의 정보공유에 사용된다. enterprise 서브 트리내의 가지(branch)는 각 enterprise 오브젝트 ID를 등록한 각벤더(vander)에 할당된다.

4개의 서브트리로 나뉘는 internet 노드는 MIB 변화에 기반을 구축한다. 벤더나다른 사용자들이 이 오브젝트들의 사양이 표준화되기 전에 새로운 오브젝트를시험 사용하므로 실용적인 노하우를 얻을 수 있다. 그러므로 MIB은 오브젝트 MIB 내에 표준화되어 있는 오브젝트 운영에 즉각사용될 수 있으며, 기술이나 상품의 변화에 유연성있게 대처할 수 있다. 이러한변화는 TCP/IP 안에 있는 프로토콜과 같은 이치이다. 위의 모든 프로토콜들은광범위한 시험과 디버깅을 거쳐서 표준화 프로토콜이 된다.

11

4. RMON (Remote network Monitoring)

4.1 RMON 개요

네트웍의 효율적 이용을 위해서 현재의 네트웍 상태를 측정하고 과거의 기록을

토대로 향후 네트웍 문제를 사전에 예견, 유용하게 이용되는 것이 RMON(Remote

network Monitoring)이다.

기존의 SNMP MIB들이 보유하고 있는 대리인(Agent)이 탑재된 장비 자신의 처리

결과만을 보유하고 있는 데 반해서 RMON 대리인은 한 세그먼트 전체에서 발생하는

트래픽을 파악하게 해준다.

즉, 전체 발생 트래픽, 세그먼트에 연결된 각 호스트의 트래픽, 호스트들간의

트래픽 발생 현황을 알려준다.

이런 처리를 위해서 RMON 대리인은 전체 통계 데이터,이력(history) 데이터,

호스트 관련 데이터, 호스트 매트릭스와 사전에 문제 예측 및 제거를 위해서 특정

패킷을 필터링하는 기능과 임계치를 설정, 이에 도달하면 자동으로 알려주는 경보

기능, 및 사건 발생 기능을 보유하고 있어야 한다.

네트웍에서 발생한 트래픽 모두를 관찰하고자 나온 것이 네트웍 모니터링이다.

또는 분석기(Analayzer),프로브(probe)라고 부른다. 실제로는 프로브라는 말을

많이 쓴다.

네트웍 데이터를 수집하는 대리인은 보통 단독 장비로 또는 웍스테이션 ,

PC,허브,스위치 등의 장비에 탑재하는 경우가 있다.

단독 장비는 모든 트래픽을 분석할 수 있으나 별도로 구입함으로써 비용이

고가이고 기존장비에 탑재된 경우는 비용절감 효과는 있으나 장비 고유의 업무처리

때문에 트래픽을 정확하게 분석할 수 없다는 단점이 있다.

12

4.2 RMON의 기본 기능

RMON이 정의되어 있는 RFC1757(RFC1271)은 주로 RMON MIB에 집중되어있다. 이 문서는 기본적으로 SNMP를 기반으로 한 RMON 대리인과 RMON 관리자간의 각종 절차를 담고 있다. 즉 대리인과 관리자의 요청에 의해서 어떻게 데이터를 채집하고 그리고 그데이터를 보관하고 어떻게 삭제하는가에 관한 것이다.

RMON이 갖추어야할 기본적인 목표를 다음과 같이 제시하고 있다.

Offline 동작대리인은 관리자와 RMON 대리인간의 통신에 영향을 받지 않고 해당 세그먼트의성능, 구성 정보 등을 축적하고 관리할 수 있어야 한다.

Proactive Monitoring대리인에 주어진 자원에 따라 네트웍을 진단하고 성능 자료의 이력 관리를통해서 장애 및 장애에 대한 기록을 관리자에게 보고할 수 있어야 한다.

문제 타지 및 보고관리자가 특정 상태(오류,특정패킷)에 대한 보고를 명령하면 이를 계속감시하다가 탐지되면 이 사건을 기록하고 관리자에게 통보할 수 있어야 한다.

부가 가치 자료수집한 자료에 의미있는 가치를 부여할 수 있어야 한다. 즉 가장 많은 트래픽과오류를 발생시키는 호스트들을 집중 관찰함으로써 문제 해결에 대한 세밀한정보를 관리자에게 줄 수 있다.

복수의 관리자여러 관리자가 보내는 명령을 모두 수용해야 한다. 이때 대리인의 시스템 용량에따라서 메모리 부족등으로 관리자 명령대로 수행을 못하거나 거역하는 경우가발생할 수도 있다.

13

4.3 RMON MIB

통계한 세그먼트내에서 발생한 패킷/바이트 수, 브로트캐스트/멀티캐스트 수,충돌(collision)수 및 패킷 길이별 수 그리고 각종오류(프래그먼트,CRCAlinment,jabber,길이 미달,길이 초과)에 대한 통계를제공한다.

이력관리자가 설정한 시간 간격내에 발생한 각종 트래픽 및 오류에 대한 정보를제공한다. 기본적으로 단기/장기적으로 간격을 설정가능하고 1-3.600초를간격으로 제한한다. 이 자료를 통해 시간대별 이용 현황 및 다른 세그먼트와 비교가가능하다.

경보주기적으로 특정한 값을 체크해 기준치(임계치)에 도달하면 관리자에 보고하고대리인이 자신이 기록을 보유하고 있다.기준치는 절대값 및 상대값으로 정할 수 있고 계속적인 경보 발생을 막기 위해서상/하한치를 설정해서 넘나드는 경우에만 경보가 발생한다.

호스트세그먼트에 연결된 각 장비가 발생시킨 트래픽,오류수를 호스트별로 관리한다.

상위 N개의 호스트위 호스트 테이블에 발견된 호스트 중에서 일정시간 동안 가장 많은 트래픽을발생시킨 호스트를 찾는다.관리자는 원하는 종류의 자료(입/출 패킷,바이트,외부오류,브로트캐스트/멀티캐스트 패킷)와 시간 간격 및 원하는 호스트의 갯수를설정해서 정보를 얻을 수 있다.

트래픽 메트릭스데이터 링트 계층, 즉 MAC 어드레스를 기준으로 두 호스트간에 발생한 트래픽 및오류에 대한 정보를 수집한다. 이 정보를 이용해서 특정 호스트에 가장 많은이용자가 누구인지를 어느 정도는 알 수 있다.다른 세그먼트에 있는 호스트가 가장 많이 이용했다면 이것은 주로 라우터를통과함으로써 실제이용자는 알 수 없다.

14

필터관리자가 특정한 패킷의 동향을 감시하기 위해서 이용한다.이를 이용해서 특정패킷의 발생여부를 알 수 있고 경보와 사건 기능을 이용해서한계치 이상 발생시에 알 수가 있다.

패킷 수집세그먼트에 발생한 패킷을 수집해서 관리자가 분석할 수 있도록 한다.관리자는 패킷의 전부 또는 일정한 길이만 보관하고 읽을 수 있도록 설정이가능하다.

사건일정한 사건이 발생하면 그 기록을 보관하고 관리자에게 경고(trap) 메시지를보낸다. 트랩 발생 및 기록 보관은 선택적이다. 경보와 연관되어서 사건이발생하면 사건 기록 및 트랩 발생은 관리자가 사전에 설정 가능하다.

15

4.4 RMON2

기존에 발표된 RMON은 한 세그먼트에 대한 트래픽을 감시하는 데는 적합했다.

그러나 RMON은 MAC 계층까지만 분석이 가능하므로 어떤 프로토콜이 사용되는지

그리고 어떤 어플리케이션이 네트웍에 영향을 주는지는 거의 알 수 가 없었다.

결국 이런 점을 보완하기 위해서 등장한 것이 RMON2이다

RMON2에 추가된 것은 프로토콜별 분포현황, 네트웍 계층 즉 IP

,IPX,DECnet,애플톡 등의 호스트별 트래픽을 수집한다.

네트웍 계층의 호스트간의 트래픽을 수집함으로써 애플리케이션,웹서버와 같은

호스트에 가장 많은 트래픽을 발생시키는 호스트를 찾을 수도 있다.

그리고 애플리케이션 계층 차원에서 호스트별 트래픽의 감시 및 호스트간

트래픽을 관찰 할 수 있다.

RMON2의 발표로 네트웍 관리자는 이제 OSI 7계층 모두를 관찰할 수 있게됐다.

그러나 이 모두를 구현하자면 대리인의 시스템 자원이 충분해야 하고 성능이

우수해야 한다.

이 모든 기능을 갖추려면 단독 장비로 구성해야 한다.

그러나 요즘 네트웍 구성이 스위치를 이용해서 세그먼트를 분리하는 방향으로

나아가고 있다.

이때 스위치의 각 포트당 하나의 세그먼트가 되는데 여기에 하나씩 RMON

대리인을 장착하기에는 비용이 문제다 이를 해결하기 위해서 대부분의 스위치

장비가 RMON을 탑재하고 있으나 RMON과 RMON2의 모든 기능을 지원하기에는

본래의 스위치 기능에 악영향을 줄 수 있다.

현재 대안으로 나온 것이 스위치의 각 포트에 연결된 허브에 RMON을 탑재하는

방법이다.

16

5. CMIP / CMIS

CMIS(Common Management Information Service)/CMIP는 잘 정리되고 훌륭한개념임에도 불구하고 지나치게 방대하게 규정됨으로써 구현하기가 쉽지 않고시스템도 SNMP에 비해서 방대하다.

따라서 쉽게 SNMP를 대체하지 못하고 있다. 그러나 최근 TMN(TelecomunicationManagement Network)이라는 개념이 도입되면서 CMIP/CMIS가 주목을 받고 있다.

5.1 CMISE(Common Management Information Service Element)

OSI 시스템 관리자에서 기본적인 기능이 두 시스템(manager,agent)간의 정보를교환하는 것이다. 이 시스템 관리를 목적으로 정보와 명령을 교환하기 위해서이용하는 기능이 CMISE이다.

CMISE는 사용자와의 인터페이스 서비스를 담당하는 CMIS와 PDU 및 관련 절차를규정한 CMIP로 이루어진다.

CMISE 서비스는 기본적으로 요청받은 서비스에 대해서 실패, 성공이나 요청을받았다는 응답을 해주는 확인 서비스들과 응답을 하지 않는 비확인 서비스로 나눌 수있다. 이들 서비스는 3가지 범주로 나뉜다.

Association Service이 서비스는 통신을 하기 위해서 해당 시스템의 어플리케이션간의 연결 및 해제를하기 위해서 필요하다. 이는 ACSE(Association Control Service)를 이용한다.

Management-notification Service이 서비스는 관리 객체들에 대한 특정 사건을 보고하는데 이용하는 것으로 필요한속성,행동 및 작동 절차 등에 대한 것은 각 관리객체들에 정의되어 있다.

Management-operation Service이 6가지 서비스는 시스템 관리를 위해서 정보를 주고 받는데 이용된다

17

5.2 CMIS(Common Management Information Service)

시스템간 연결 및 해제를 위한 서비스인 A-Associate, A-Reases, A-Abort가있고,대리인에서 관리자에게 관리 객체에 발생한 특정 상황을 통지하는 M 이벤트리포트 서비스가 있다

M 이벤트 리포트는 SNMP의 트랩과 같은 기능을 수행하나 이 메시지를 받은관리자가 받았다는 확인을 해주어야 한다는 차이가 있다.

실제로 관리 객체들에 대한 정보를 주고 받는 서비스인 MOS(Management Operation Service)에는 다음과 같은 6가지가 있다.

M-GET대리인에게 관리 정보를 요청한다.

M-SET대리인의 관리 정보를 수정하도록 요청한다. 관리 객체의 속성값을 바꾸기 위해서대체(replace), 기존값에 추가(Add Value), 기존값의 제거 (Remove Value), 기본값설정 등의 하나를 명시해야 하고 기본동작은 대체로 가정한다.

M-ACTION관리 객체에 사전에 정의된 특정한 동작을 실행한다. 요청시는 동작 종류를 반드시명시해야 한다.

M-CREATE객체 클래스의 새로운 실체를 만들기 위해서 사용되는 서비스이다.

M-DELETE대리인의 하나 이상의 관리 객체를 삭제시에 이용된다.

M-CANCEL-GET이미 요청된 M-GET을 중지시킬 때 이용되는데 이를 사용하는 이유는 MIB가수정도중에 문제가 발생하면 MIB의 일관성을 보증하기가 어렵게 때문이다. 이 서비스가 대리인에 도달하면 대리인은 실행중인 M-GET에 대한 응답으로"취소 오류"를 보내고 M-CANCEL-GET에 대한 응답을 보낸다. M 이벤트 리포트를 포함한 7가지 서비스중에서 M-GET, M-CREATE,M-DELETE, M-CANCEL-GET 은 반드시 응답을 받아야하는 확인 서비스이고나머지는 서비스 요청시에 확인/비확인을 위한 패러미터를 주어야 한다.

18

5.3 CMIP

CMIP는 관리정보를 전송하는 절차 즉 CMISE사이에 CMIS 서비스를 완성시키기

위해서 교환하는 CMIP PDU를 만들고 전송하는 것에 대해 정의해 놓은 것이다.

양단의 CMISE 사용자(관리자와 대리인 또는 양단의 CMISE 어플리케이션)들이

정보교환을 위해서 시스템을 연결하기 위해 ACSE를 이용하는데, 이때는 CMIP이

이용되지 않는다.

관리 서비스를 위해서 CMISE는 PDU를 교환하기 위해서 CMIP를 채용한다. 그리고

CMIP는 CMIP PDU 전송을 위해서 ROSE(Remote Operations Service Element)를

이용한다.

CMIP는 CMIS 서비스를 처리하기 위해서 11개의 PDU를 정의해 놓았다.

CMIP는 항상 ROSE 3를 이용한다. 그리고 확인 서비스를 위해서는 집합 2 또는 3을

이용하고 비확인 서비스를 위해서 집합 5를 이용한다.

19

5.4 OSI MIB

OSI MIB의 가장 큰 특징은 객체지향적인 개념을 수용하고 있다는 점이다.OSI MIB는 X.720, X.721, X.722에 잘 정의되어 있다.

특히, X.722에 정의된 GDMO(Guidelines for the Definition of Managed Objects)는 객체들의 클래스, 객체의 행동, 속성,등을 명시하는방법을 제공하는구조화된 기술 언어이다.

X.720 시리즈인 관리 정보 모델은 관리 객체에 대한 개념이 세밀하게 기술돼 있다.또한 관리 객체의 이름을 만드는 방법도 정의되어 있다.

OSI에서 정의한 객체는 행동 및 속성, 통지,작동 등을 캡슐화하며 그 객체를 상속해새로운 객체를 만들 수 있다. 또한 동질성을 이용하여 과거의 객체등을 손쉽게관리할 수 있다.

알로모피즘은 객체지향의 다향성의 특별한 경우이다.SNMP가 테이블의 개념으로 객체를 관리하는데 반해서 OSI MIB는"Containment"개념을 이용한다. 즉 한 객체가 하나 이상의 다른 객체를 포함할 수있다. 물론 객체를 포함하고 있는 객체도 다른 객체의 하위 객체가 될 수 있다.

그러나 한 객체는 하나의 상위 객체에만 포함돼야 한다.관리 뼈대로 객체지향적인 GDMO와 그렇지 않은 SMI에서 거의 모든 차이가발생한다.현재 대부분의 장비가 SNMP를 이용하고 있으나 모든 장비의 통합관리라는 개념의TMN하에서는 CMIP가 채택되고 많은 개발 도구들이 등장하고 있다.

광섬유망에서 셀룰러와 위성을 기반으로 한 무선 통신시스템이 등장하면서 관리의필요성 때문에 TMN이 각광 받으면서 CMIP도 관심의 대상이 되고 있다.