2010/02/01 11:10

How to write a shell script

How to write a shell script

Introduction

A shell is a command line interpretor. It takes commands and executes them. As such, it implements a programming language. The Bourne shell is used to create shell scripts -- ie. programs that are interpreted/executed by the shell. You can write shell scripts with the C-shell; however, this is not covered here.

Creating a Script

Suppose you often type the command

find . -name file -print

and you'd rather type a simple command, say

sfind file

Create a shell script

% cd ~/bin

% emacs sfind

% page sfind

find . -name $1 -print

% chmod a+x sfind

% rehash

% cd /usr/local/bin

% sfind tcsh

./shells/tcsh

Observations

This quick example is far from adequate but some observations:

Shell scripts are simple text files created with an editor.
Shell scripts are marked as executeable

3. %chmod a+x sfind

Should be located in your search path and ~/bin should be in your search path.
You likely need to rehash if you're a Csh (tcsh) user (but not again when you login).
Arguments are passed from the command line and referenced. For example, as $1.

#!/bin/sh

All Bourne Shell scripts should begin with the sequence

#!/bin/sh

From the man page for exec(2):

"On the first line of an interpreter script, following the "#!", is the name of a program which should be used to interpret the contents of the file. For instance, if the first line contains "#! /bin/sh", then the con- tents of the file are executed as a shell script."

You can get away without this, but you shouldn't. All good scripts state the interpretor explicitly. Long ago there was just one (the Bourne Shell) but these days there are many interpretors -- Csh, Ksh, Bash, and others.

Comments

Comments are any text beginning with the pound (#) sign. A comment can start anywhere on a line and continue until the end of the line.

Search Path

All shell scripts should include a search path specifica- tion:

PATH=/usr/ucb:/usr/bin:/bin; export PATH

A PATH specification is recommended -- often times a script will fail for some people because they have a different or incomplete search path.

The Bourne Shell does not export environment variables to children unless explicitly instructed to do so by using the export command.

Argument Checking

A good shell script should verify that the arguments sup- plied (if any) are correct.

if [ $# -ne 3 ]; then

echo 1>&2 Usage: $0 19 Oct 91

exit 127

This script requires three arguments and gripes accordingly.

Exit status

All Unix utilities should return an exit status.

# is the year out of range for me?

if [ $year -lt 1901 -o $year -gt 2099 ]; then

echo 1>&2 Year \"$year\" out of range

exit 127

etc...

# All done, exit ok

exit 0

A non-zero exit status indicates an error condition of some sort while a zero exit status indicates things worked as expected.

On BSD systems there's been an attempt to categorize some of the more common exit status codes. See /usr/include/sysexits.h.

Using exit status

Exit codes are important for those who use your code. Many constructs test on the exit status of a command.

The conditional construct is:

if command; then

command

For example,

if tty -s; then

echo Enter text end with \^D

Your code should be written with the expectation that others will use it. Making sure you return a meaningful exit status will help.

Stdin, Stdout, Stderr

Standard input, output, and error are file descriptors 0, 1, and 2. Each has a particular role and should be used accordingly:

# is the year out of range for me?

if [ $year -lt 1901 -o $year -gt 2099 ]; then

echo 1>&2 Year \"$year\" out of my range

exit 127

etc...

# ok, you have the number of days since Jan 1, ...

case `expr $days % 7` in

echo Mon;;

echo Tue;;

etc...

Error messages should appear on stderr not on stdout! Output should appear on stdout. As for input/output dialogue:

# give the fellow a chance to quit

if tty -s ; then

echo This will remove all files in $* since ...

echo $n Ok to procede? $c; read ans

case "$ans" in

n*|N*)

echo File purge abandoned;

exit 0 ;;

esac

RM="rm -rfi"

else

RM="rm -rf"

Note: this code behaves differently if there's a user to communicate with (ie. if the standard input is a tty rather than a pipe, or file, or etc. See tty(1)).

Language Constructs

For loop iteration

Substitute values for variable and perform task:

for variable in word ...

command

done

For example:

for i in `cat $LOGS`

mv $i $i.$TODAY

cp /dev/null $i

chmod 664 $i

done

Alternatively you may see:

for variable in word ...; do command; done

Case

Switch to statements depending on pattern match

case word in

[ pattern [ | pattern ... ] )

command ;; ] ...

esac

For example:

case "$year" in

[0-9][0-9])

year=19${year}

years=`expr $year - 1901`

;;

[0-9][0-9][0-9][0-9])

years=`expr $year - 1901`

;;

echo 1>&2 Year \"$year\" out of range ...

exit 127

;;

esac

Conditional Execution

Test exit status of command and branch

if command

then

command

[ else

command ]

For example:

if [ $# -ne 3 ]; then

echo 1>&2 Usage: $0 19 Oct 91

exit 127

Alternatively you may see:

if command; then command; [ else command; ] fi

While/Until Iteration

Repeat task while command returns good exit status.

{while | until} command

command

done

For example:

# for each argument mentioned, purge that directory

while [ $# -ge 1 ]; do

_purge $1

shift

done

Alternatively you may see:

while command; do command; done

Variables

Variables are sequences of letters, digits, or underscores beginning with a letter or underscore. To get the contents of a variable you must prepend the name with a $.

Numeric variables (eg. like $1, etc.) are positional vari- ables for argument communication.

Variable Assignment

Assign a value to a variable by variable=value. For example:

PATH=/usr/ucb:/usr/bin:/bin; export PATH

TODAY=`(set \`date\`; echo $1)`

Exporting Variables

Variables are not exported to children unless explicitly marked.

# We MUST have a DISPLAY environment variable

if [ "$DISPLAY" = "" ]; then

if tty -s ; then

echo "DISPLAY (`hostname`:0.0)? \c";

read DISPLAY

if [ "$DISPLAY" = "" ]; then

DISPLAY=`hostname`:0.0

export DISPLAY

Likewise, for variables like the PRINTER which you want hon- ored by lpr(1). From a user's .profile:

PRINTER=PostScript; export PRINTER

Note: that the Cshell exports all environment variables.

Referencing Variables

Use $variable (or, if necessary, ${variable}) to reference the value.

# Most user's have a /bin of their own

if [ "$USER" != "root" ]; then

PATH=$HOME/bin:$PATH

else

PATH=/etc:/usr/etc:$PATH

The braces are required for concatenation constructs.

$p_01

The value of the variable "p_01".

${p}_01

The value of the variable "p" with "_01" pasted onto the end.

Conditional Reference

o ${variable-word}

If the variable has been set, use it's value, else use word.

POSTSCRIPT=${POSTSCRIPT-PostScript};

export POSTSCRIPT

${variable:-word}

If the variable has been set and is not null, use it's value, else use word.

These are useful constructions for honoring the user envi- ronment. Ie. the user of the script can override variable assignments. Cf. programs like lpr(1) honor the PRINTER environment variable, you can do the same trick with your shell scripts.

${variable:?word}

If variable is set use it's value, else print out word and exit. Useful for bailing out.

Arguments

Command line arguments to shell scripts are positional vari- ables:

$0, $1, ...

The command and arguments. With $0 the command and the rest the arguments.

The number of arguments.

$*, $@

All the arguments as a blank separated string. Watch out for "$*" vs. "$@".
And, some commands:

shift

Shift the postional variables down one and decrement number of arguments.

set arg arg ...

Set the positional variables to the argument list.

Command line parsing uses shift:

# parse argument list

while [ $# -ge 1 ]; do

case $1 in

process arguments...

esac

shift

done

A use of the set command:

# figure out what day it is

TODAY=`(set \`date\`; echo $1)`

cd $SPOOL

for i in `cat $LOGS`

mv $i $i.$TODAY

cp /dev/null $i

chmod 664 $i

done

Special Variables

o $$

Current process id. This is very useful for constructing temporary files.

tmp=/tmp/cal0$$

trap "rm -f $tmp /tmp/cal1$$ /tmp/cal2$$"

trap exit 1 2 13 15

/usr/lib/calprog >$tmp

The exit status of the last command.

$command

# Run target file if no errors and ...

if [ $? -eq 0 ]

then

etc...

Quotes/Special Characters

Special characters to terminate words:

; & ( ) | ^ < > new-line space tab

These are for command sequences, background jobs, etc. To quote any of these use a backslash (\) or bracket with quote marks ("" or '').

Single Quotes

Within single quotes all characters are quoted -- including the backslash. The result is one word.

grep :${gid}: /etc/group | awk -F: '{print $1}'

Double Quotes

Within double quotes you have variable subsitution (ie. the dollar sign is interpreted) but no file name generation (ie. * and ? are quoted). The result is one word.

if [ ! "${parent}" ]; then

parent=${people}/${group}/${user}

Back Quotes

Back quotes mean run the command and substitute the output.

if [ "`echo -n`" = "-n" ]; then

n=""

c="\c"

else

n="-n"

c=""

and

TODAY=`(set \`date\`; echo $1)`

Functions

Functions are a powerful feature that aren't used often enough. Syntax is

name ()

{

commands

}

For example:

# Purge a directory

_purge()

{

# there had better be a directory

if [ ! -d $1 ]; then

echo $1: No such directory 1>&2

return

etc...

}

Within a function the positional parmeters $0, $1, etc. are the arguments to the function (not the arguments to the script).

Within a function use return instead of exit.

Functions are good for encapsulations. You can pipe, redi- rect input, etc. to functions. For example:

# deal with a file, add people one at a time

do_file()

{

while parse_one

etc...

}

etc...

# take standard input (or a specified file) and do it.

if [ "$1" != "" ]; then

cat $1 | do_file

else

do_file

Sourcing commands

You can execute shell scripts from within shell scripts. A couple of choices:

sh command

This runs the shell script as a separate shell. For example, on Sun machines in /etc/rc:

sh /etc/rc.local

. command

This runs the shell script from within the current shell script. For example:

# Read in configuration information

. /etc/hostconfig

What are the virtues of each? What's the difference? The second form is useful for configuration files where environment variable are set for the script. For example:

for HOST in $HOSTS; do

# is there a config file for this host?

if [ -r ${BACKUPHOME}/${HOST} ]; then

. ${BACKUPHOME}/${HOST}

etc...

Using configuration files in this manner makes it possible to write scripts that are automatically tailored for differ- ent situations.

Some Tricks

Test

The most powerful command is test(1).

if test expression; then

etc...

and (note the matching bracket argument)

if [ expression ]; then

etc...

On System V machines this is a builtin (check out the com- mand /bin/test).

On BSD systems (like the Suns) compare the command /usr/bin/test with /usr/bin/[.

Useful expressions are:

test { -w, -r, -x, -s, ... } filename

is file writeable, readable, executeable, empty, etc?

test n1 { -eq, -ne, -gt, ... } n2

are numbers equal, not equal, greater than, etc.?

test s1 { =, != } s2

Are strings the same or different?

test cond1 { -o, -a } cond2

Binary or; binary and; use ! for unary negation.

For example

if [ $year -lt 1901 -o $year -gt 2099 ]; then

echo 1>&2 Year \"$year\" out of range

exit 127

Learn this command inside out! It does a lot for you.

String matching

The test command provides limited string matching tests. A more powerful trick is to match strings with the case switch.

# parse argument list

while [ $# -ge 1 ]; do

case $1 in

-c*) rate=`echo $1 | cut -c3-`;;

-c) shift; rate=$1 ;;

-p*) prefix=`echo $1 | cut -c3-`;;

-p) shift; prefix=$1 ;;

-*) echo $Usage; exit 1 ;;

*) disks=$*; break ;;

esac

shift

done

Of course getopt would work much better.

SysV vs BSD echo

On BSD systems to get a prompt you'd say:

echo -n Ok to procede?; read ans

On SysV systems you'd say:

echo Ok to procede? \c; read ans

In an effort to produce portable code we've been using:

# figure out what kind of echo to use

if [ "`echo -n`" = "-n" ]; then

n=""; c="\c"

else

n="-n"; c=""

etc...

echo $n Ok to procede? $c; read ans

Is there a person?

The Unix tradition is that programs should execute as qui- etly as possible. Especially for pipelines, cron jobs, etc.

User prompts aren't required if there's no user.

# If there's a person out there, prod him a bit.

if tty -s; then

echo Enter text end with \^D

The tradition also extends to output.

# If the output is to a terminal, be verbose

if tty -s <&1; then

verbose=true

else

verbose=false

Beware: just because stdin is a tty that doesn't mean that stdout is too. User prompts should be directed to the user terminal.

# If there's a person out there, prod him a bit.

if tty -s; then

echo Enter text end with \^D >&0

Have you ever had a program stop waiting for keyboard input when the output is directed elsewhere?

Creating Input

We're familiar with redirecting input. For example:

# take standard input (or a specified file) and do it.

if [ "$1" != "" ]; then

cat $1 | do_file

else

do_file

alternatively, redirection from a file:

# take standard input (or a specified file) and do it.

if [ "$1" != "" ]; then

do_file < $1

else

do_file

You can also construct files on the fly.

rmail bsmtp <<$1@newshost.uwo.ca>

rcpt to:

data

from: <$1@newshost.uwo.ca>

to:

Subject: Signon $2

subscribe $2 Usenet Feeder at UWO

quit

EOF

Note: that variables are expanded in the input.

String Manipulations

One of the more common things you'll need to do is parse strings. Some tricks

TIME=`date | cut -c12-19`

TIME=`date | sed 's/.* .* .* $.*$ .* .*/\1/'`

TIME=`date | awk '{print $4}'`

TIME=`set \`date\`; echo $4`

TIME=`date | (read u v w x y z; echo $x)`

With some care, redefining the input field separators can help.

#!/bin/sh

# convert IP number to in-addr.arpa name

name()

{ set `IFS=".";echo $1`

echo $4.$3.$2.$1.in-addr.arpa

}

if [ $# -ne 1 ]; then

echo 1>&2 Usage: bynum IP-address

exit 127

add=`name $1`

nslookup < < EOF | grep "$add" | sed 's/.*= //'

set type=any

$add

EOF

Debugging

The shell has a number of flags that make debugging easier:

sh -n command

Read the shell script but don't execute the commands. IE. check syntax.

sh -x command

Display commands and arguments as they're executed. In a lot of my shell scripts you'll see

# Uncomment the next line for testing

# set -x

Based on An Introduction to Shell Programing by:

Reg Quinton

Computing and Communications Services

The University of Western Ontario

London, Ontario N6A 5B7

Canada

Press here to return to the General Unix Software Menu.

Posted by 두장

TAG Linux, script, shell, 리눅스, 쉘, 스크립트

트랙백0 댓글0

2010/01/21 01:59

etc

[퍼옴 ] (운하) 독일 교포를 위한 강의 - 사대강 사업

원본 Link
http://www.hanamana.de/hana/index.php?option=com_content&view=article&id=248:2010-01-06-12-20-14&catid=8&Itemid=15

(운하) 독일 교포를 위한 강의 - 사대강 사업

2010년 1월 06일 수요일

독일에 사는 한인 여러분, 안녕하세요?

조국에서 멀리 떨어져 사는 해외동포들도 지난 2년간 한반도 대운하, 사대강 사업이란 단어를 많이 들으셨을 겁니다. 특히 저희 독일 교포들은 한국에 사는 가족이나 친지들로부터 "너는 독일에 사니까 잘 알 것 아니냐?"며 질문을 받는 일도 있었겠지요? 한반도 대운하나 사대강 사업이 대체 무엇인지, 그게 어째서 독일과 관련이 있는지를 지금부터 설명해드리겠습니다. 한국 소식에 늘 밝을 수 없는 교포들의 입장을 살펴서 쉽고 간단하게 얘기해드리겠습니다만 학술적으로 증명할 수 있고, 신빙성 있는 보도를 통해 알려진 사실만을 말씀드릴 것을 약속합니다.

먼저 한반도 대운하가 탄생하게된 과정을 말씀드리겠습니다. 2006년에 이명박 대통령후보가 독일에 다녀가면서 독일 운하에 깊은 감명을 받고 "내가 대통령에 당선된다면 한국에도 이런 운하를 만들겠다"고 공언했습니다. 대통령에 취임한지 며칠 안 되어 2008년 초부터 한국에선 대규모의 촛불시위가 매일 열렸습니다. 그 이유는 대통령이 미국에 가서 체결하고 온 쇠고기 수입조약에서 광우병 예방조치가 충분하지 않다는 것이었는데 이때 한반도 대운하도 뜨거운 이슈로 함께 떠올랐습니다. 한국 국민은 이명박 대통령을 압도적인 표차로 선출했지만 대운하 건설에 대해서는 국민의 70% 이상이 반대하는 의견을 가졌기 때문입니다. 대규모 군중시위가 좀체로 사그러지지 않던 2009년 6월에 이명박 대통령은 국민이 원하지 않는다면 대운하를 건설하지 않겠다고 약속했습니다.

한반도 대운하란 무엇일까요? 한국의 주요강인 한강, 낙동강, 금강, 영산강을 서로 연결해서 우리나라 방방곡곡을 배로 돌아다닐 수 있도록 수로망을 건설하는 것입니다. 날이 갈수록 길도 막히고 기름값도 비싸지는데 연료비가 저렴한 배를 이용해서 교통문제를 해소하자는 것이 그 목적입니다.

그런데 왜 대다수의 국민들이 반대했을까요? 경제성이 없어서 그랬습니다. 배는 속도가 느리거든요. 독일 운하의 경우 시속 10km로 배가 다니는데 이런 속도로 다니자면 서울에서 부산까지 가는데 사흘 이상이 걸립니다. (참고로 말씀드리자면 자전거는 시속 15km이고, 사람이 걸어가면 시속 4km 입니다.) 배는 연료비가 싸지만 요즘은 시간도 돈으로 계산되는 시대이기 때문에 경쟁력이 떨어집니다. 그리고 집앞까지 배가 들어오는 게 아니라서 물건을 부치려면 트럭에 실었다가 배에 실었다가 다시 트럭으로 옮겨 실어야 합니다. 그래서 800km 이하의 거리에서는 그냥 트럭으로 직접 보내는 게 중간에 배로 갈아타는 것보다 더 싸게 먹힙니다. 우리나라는 서울에서 부산까지의 거리가 400km 밖에 되지 않는 작은 나라이기 때문에 선박운송은 어떤 경우에도 수지가 맞지 않지요. 여론조사를 해봤더니 대부분의 사업체에서 느리고 비싸다는 이유로 나중에 운하를 이용하지 않을 거라고 했습니다.

또 하나의 문제는 우리나라는 전국토의 70%가 산으로 이루어진 산악국가라는 점입니다. 강을 서로 연결하는 물길을 만들려면 산을 뚫어야 합니다. 그리고 산골짜기를 따라 구불구불 흐르던 강에 배를 띄우려면 물길을 반듯하게 고쳐서 강바닥을 깊게 파고 콘크리트로 둑을 쌓아야 합니다. 뿐만 아니라 경사가 가파른 강에서는 배가 다닐 수 없기 때문에 중간중간에 보(Staustufe)를 세워서 물을 막아 경사를 완만하게 만들어줘야 하는데, 그러다보면 보가 있는 곳마다 층이 생기는 층층계 강이 됩니다. 배가 층계를 오르내릴 수 있도록 하는 장치가 갑문(Schleuse)입니다. 보를 이중으로 만들고 문을 달아서 물을 빼거나 채우는 방식으로 그 위에 뜬 배를 아랫층으로 내리거나 윗층으로 올리는 것입니다. 이 모든 대공사는 자연환경을 엄청나게 변화시킵니다. 그래서 우리와 비슷한 지형의 산악국가인 스위스에도 운하가 없습니다.

보와 갑문을 이용한 수로

게다가 장마철이란 특성을 가진 우리나라의 기후도 문제가 됩니다. 장마철에는 강물이 넘치고 가물 때는 강바닥이 드러납니다. 우리나라의 낙동강과 독일의 라인강을 비교해보면 일년 중 강물이 가장 많을 때와 적을 때의 비율이 라인강은 14배인데 비해 낙동강은 260배나 됩니다. 그런 조건에서 전천후로 배가 다니려면 가뭄에 대비해서 강물을 많이 저장해야 하므로 물을 막는 보의 높이와 크기가 완전히 댐 수준으로 거대하게 됩니다. 그로 인해 우리의 강산이 시각적으로 어떻게 변한다는 것은 상상할 수 있겠습니다만 그 강과 산에 서식하던 동식물의 세계가 과연 어떻게 변화할지, 그 변화의 후유증이 과연 어떻게 나타날지 지금 우리의 능력으로 전혀 가늠할 수조차 없습니다.

범국민적인 반대에 부딪치자 정부에서는 한반도 대운하를 관광사업에 활용하겠다고 했지만 국민들은 성질 급한 한국인들이 자전거보다 느린 배를 타고 며칠씩 걸리는 운하 유람을 할 것인지에 대해 의문을 품었습니다. 또한 외국인들이 운하를 보러 한국까지 올 것인가에도 회의적이었습니다. 그러자 정부에서는 한반도 대운하는 홍수를 막고 깨끗한 수도물을 공급하는 방편으로 꼭 필요하다고 주장했습니다. 이에 많은 학자들은 자연 하천을 배가 다니는 뱃길로 개량하는 공사를 하면 도리어 홍수를 초래할 수 있다고 경고하고, 사람이 마시는 식수에 배를 띄우는데 어떻게 물이 더 깨끗해지느냐고 반문했습니다. 참고로 말씀드리자면 지하수를 수도물로 쓰는 독일과는 달리 우리나라에선 강물을 정화해서 수도물로 씁니다.

그러던 와중에 한국 건설기술연구원에서 정부의 이론을 뒷받침하는 연구를 해온 학자가 양심선언을 한 사건이 일어났습니다. 한반도 대운하를 건설하면 홍수를 방지하고 식수를 확보할 수 있다는 증거를 만들라는 상부의 압박에 시달리고 있다고 폭로하고, 하지만 암만 머리를 짜내어도 그런 이론을 만들어낼 수 없다고 고백했습니다. 곧이어 한반도 대운하의 모델이 된 독일의 라인-마인-도나우 운하가 한국에 알려진 것과는 달리 실지로는 어떤 경제적인 부작용과 환경적 후유증을 초래했는지를 보여주는 TV 방송들이 전파를 탔습니다. 그 방송에서 독일의 운하 전문가들은 오늘날 운하를 건설하는 것은 시대에 맞지 않는다고 경고했습니다. 국민들의 반대가 점점 거세어지자 대통령은 국민의 뜻을 받아들여 대운하의 포기를 선언했습니다. 이것이 아까 말씀드린 대로 작년 2009년 6월에 일어난 일입니다.

그로부터 석 달 후인 11월에 사대강 사업이 시작되어 지금 현재 공사가 한창 진행 중입니다. 사대강 사업은 또 무엇일까요? 예전에 운하로 연결하려고 했던 한강, 낙동강, 금강, 영산강에 홍수를 막고 물을 깨끗하게 할 목적으로 강을 정비하는 공사를 하는 것입니다. 민간기업의 자본으로 지으려고 했던 대운하와는 달리 사대강 사업은 국민의 안전과 건강을 위하는 일이기 때문에 100% 국민의 세금으로 합니다. 그런데 공사의 내용을 보니 물을 가두는 대형 보가 16개나 되고 강의 수심을 6m로 깊게 판다고 합니다. 학계에서는 '보를 세워 물길을 막고 강바닥을 파는 것은 홍수를 방지하는 것과는 거리가 멀고, 수질을 개선시키는 것과는 아예 반대 방향'이라고 이의를 제기했습니다. 한반도 대운하 계획에 나왔던, 강을 뱃길로 만드는 공사와 뭐가 다르냐는 질문이 쇄도하고 있습니다. 대통령은 '사대강 공사를 했다가 나중에 국민이 원할 때 서로 연결시켜서 한반도 대운하를 만들면 된다'라고 했다가 최근에는 '사대강을 우선 살리고 대운하가 필요하다면 다음 대통령이 하면 된다'고 했습니다.

대운하 건설공사는 두 가지 공정으로 이루어집니다. 하나는 자연하천의 바닥을 곧고 깊게 파서 배가 뜰 수 있는 뱃길로 개조하는 것이고, 다른 하나는 그렇게 개조한 강들을 서로 연결하는 것입니다. 그런 이유에서 '지금 사대강 공사를 했다가 나중에 국민이 원할 때 서로 연결시켜서 한반도 대운하를 만들 수 있다'라는 말은 '지금 대운하 공사를 하고 있다'는 말과 학술적으로 동일합니다. 그리고 환경적인 측면으로 봤을 때, 자연하천을 뱃길로 개조하는 공사의 후유증은 강을 연결하는 공사의 후유증보다 훨씬 큽니다. 강을 연결하는 공사는 비록 바위산을 뚫는 난공사라 할지라도 고작 몇십 킬로미터에 해당되지 않지만, 강 자체를 건드리는 공사는 전 국토에 걸쳐 몇백 킬로미터에 달하기 때문입니다. 현재 진행되고 있는 사대강 사업의 총 공사구간은 634㎞ 입니다. 환경적 후유증이 온 국토에서 일어난다는 뜻입니다.

이름이야 뭐라고 붙이던 간에 강에 보를 세워 물길을 막고 강바닥을 깊게 파는 공사에는 대체 어떤 후유증이 따를까요? 그 대답은 독일에 있습니다. 독일에 사는 사람들은 일상을 통해 알 수 있습니다. 독일의 라인-마인-도나우 운하가 한반도 대운하의 모델이 되었듯이 독일에서 운하의 역사를 살펴보면 결과까지 알 수 있습니다. 독일 운하의 역사와 과정을 설명해드리겠습니다.

유럽에서 라인강은 북해로 흐르는 강 중에 가장 긴 강이고, 도나우강은 반대쪽 흑해로 흐르는 강 중에 가장 긴 강입니다. 이 두 강을 연결할 수 있는 지점이 독일에 있지요. 라인강으로 흘러들어가는 마인강과 도나우강을 연결하면 장장 3500km의 뱃길이 형성되고, 독일이 그 중심에 서게 됩니다. 이 꿈은 이미 8세기때부터 시도되어온 독일의 오랜 로망인데, 이것이 19년 전에야 이루어졌습니다. 이게 바로 이명박 대통령이 한반도 대운하의 모델로 삼은 라인-마인-도나우 운하입니다. 이 운하는 순수 공사기간이 20년, 기술을 개발하는 준비기간까지 합치면 도합 100년 걸린 대사업입니다.

그렇지만 짓는 도중에 반대가 심해서 공사가 12년 동안이나 중단되기까지 했습니다. 예상했던 것보다 환경파괴가 심각했고, 또한 그 사이에 도로와 철로가 발달하여 이젠 운하가 별로 필요 없게된 것입니다. 세상이 변한 겁니다. 운하로 인한 환경 파괴와 운하를 통한 경제적인 효과를 비교해 보니 수지가 맞지 않았습니다. 치열한 공방 끝에 공사가 벌써 많이 진행되었다는 이유로 결국 완공을 강행했는데, 이때 학계와 환경단체가 요구하는 최신 지식과 기술을 동원해서 친환경적으로 설계를 변경했습니다.

완공 후에 경제적인 효과를 보았을까요? 운하를 통과하는 화물운송의 양이 설계할 당시 예상치의 3분의 1밖에 안 되고, 지금 적자를 보고 있습니다. 현재 운하 유지비의 7%를 통행료로 벌어들이고 나머지는 세금으로 충당하고 있습니다. 앞으로도 나아질 전망이 별로 없어 보이는데, 여론조사를 보면 시간이 너무 많이 걸린다는 이유로 고객들이 이용을 기피하고 있습니다. 이제는 신속한 운송이 중요한 시대가 되었기 때문이지요.

친환경적 설계의 결과는 어땠을까요? 유명한 알트뮐 골짜기의 습지가 사라지고 동식물의 종이 반으로 줄었습니다. 지금도 계속 줄고 있어서 앞으로 예전의 5분의 1 수준으로 줄 것으로 예상됩니다. 그 지역에만 존재했던 특별한 동식물이 사라지고, 이제는 어디서나 볼 수 있는 평범한 종으로 대체되고 있습니다. 또 옛날에 도나우강에만 서식했던 생선과 라인강에만 서식하던 물고기가 운하를 통해서 섞이면서 생태계의 균형이 깨지고 있습니다.

그러나 라인-마인-도나우 운하보다 환경에 더욱 심각한 영향을 미치는 건 라인강 그 자체입니다. 라인-마인-도나우 운하는 길이가 171 km밖에 안 되지만, 라인강은 독일을 최남단에서 최북단까지 쭉 관통하며 880km를 흐르거든요. 이 라인강을 뱃길로 이용하기 위하여 독일인들은 이미 19세기부터 물길을 직선화하고 강바닥을 파는 준설공사를 했고, 20세기에는 몇 개의 갑문을 세웠습니다. 그 결과 후유증이 지금 만만찮습니다.

첫째 후유증은 홍수입니다. 독일에 사는 여러분들께서는 라인강변의 도시가 물에 잠기는 모습을 해마다 뉴스를 통해 보셨을 것입니다. 물이 상류에서 구불구불 흐르면서 적당한 범람으로 기세를 잃지 못하면 중류, 하류에 가서 무서운 위력을 가집니다. 예전에 구불구불 돌아오느라고 상류에서 중류까지 사흘 걸려 내려오던 홍수물이 이제는 반듯하게 다듬은 물길을 타고 단 하루만에 내려오고 있습니다. 그 여파로 시달리는 곳이 라인강과 샛강이 만나는 지역들입니다. 모젤강, 마인강, 네카강 등의 샛강에서 불어난 물이 라인강을 통해 빠져나가기도 전에 라인강 상류에서 고속으로 오는 홍수가 덮치게 되었습니다. 옛날에 백년에 한번 일어나던 규모의 홍수가 요즘은 몇 년 간격으로 일어나는 이유가 바로 여기 있습니다.

둘째 후유증은 라인강 유역의 토지가 말라가고 지하수가 고갈되는 현상입니다. 구불구불하던 물길을 직선으로 만드니까 자연히 강의 길이가 짧아지면서 경사가 급한 꼴이 되었습니다. 너르게 흐르던 물길을 좁은 통로에 가둔데다가 경사도 급해지니까 물살이 세졌습니다. 이때 물 밑의 자갈들이 강바닥에서 통통 튈 정도로 물의 속도가 빨라지면 강바닥이 패이는 현상이 일어납니다. 바닥이 패여서 깊어지니까 따라서 강의 수면도 낮아집니다. 강의 수면이 낮아지면 강변의 흙으로 스며들어가 고이는 지하수의 수면도 따라서 낮아집니다. 지하수의 수면이 낮아지면 나무들이 뿌리를 암만 깊이 뻗어도 수분을 섭취할 수 없게 되어서 숲이 말라죽습니다. 우물을 아주 깊게 파야 물이 나오니 농사를 짓기에도 나쁩니다. 라인강 유역의 지하수면은 평균 8m 낮아졌습니다.

강바닥이 패이는 현상이 특히 심한 곳이 갑문이 있는 곳인데, 막아놓은 물이 폭포처럼 떨어지니 당연한 일이지요. 그곳에서는 30년 전부터 매일같이 엄청난 양의 자갈을 강바닥에 쏟아붓는 방법으로 해결하고 있습니다. 해마다 몇백만 유로를 들이는 극약처방인 셈이죠. Geschiebezugabe an der Staustufe Iffezheim에 가시면 이 광경을 보실 수 있습니다. 강바닥에 콘크리트를 치면 강바닥이 패이는 현상을 막을 수 있겠지요? 그러나 그렇게 되면 강물이 지하수로 스며들지 못해서 더 악영향을 미칩니다. 라인강을 보면 바닥과 벽을 콘크리트로 마감한 구간에선 그렇지 않은 구간보다 지하수면이 2-3m 더 낮습니다.

위에 말씀드린 두 가지 환경 재앙, 홍수와 지하수 고갈에서 벗어나기 위해서 지금 독일에선 어떤 일을 하고 있을까요? 강의 둑을 헐고 범람지와 습지를 되살리는 재자연화 공사가 한창입니다. 자연으로 되돌린다는 뜻의 Renaturierung이란 단어를 가끔 들어보셨을 것입니다. 특히 라인강 상류를 자연으로 되돌리는 공사가 지금 한창 진행중인데 벌써 여러 곳에 Polder라고 불리는 범람숲이 완성되었으니 라인강변에 사는 분들은 한번 가보셔요.

라인강 상류에 재생된 범람숲

그리고 뮌헨에 사는 분들은 근래에 재자연화공사를 마친 이자강변이 얼마나 아름다운지 아실 것입니다. 둑을 헐고 범람지와 습지를 다시 재생시켜 150년 전의 모습을 되찾은 이자강변은 주민들의 사랑을 받는 휴식공간이기도 하지만 완공되자마자 들이닥친 역사적인 대홍수를 훌륭하게 막아냈습니다.

재자연화 공사를 마친 뮌헨의 이자강변

이런 공사는 엄청나게 큰 돈이 들기는 하지만 홍수와 지하수 감소의 피해를 돈으로 환산하면 더 큰 액수이기에 독일에선 자연으로의 복구를 감행하고 있는 것입니다. 오늘날 홍수와 지하수 고갈의 원인이 과거에 강바닥을 파고 둑을 쌓은 공사에 있다는 것을 독일에선 중고등학교에서 가르칩니다.

150년 전의 모습을 되찾은 뮌헨의 이자강변

사대강 사업을 하는 우리나라에서도 독일에서와 같은 피해가 일어날 수 있을까요? 물론입니다. 자연법칙은 나라를 가리지 않으니까 우리나라에서 라인강 같은 공사를 하면 당연히 라인강의 피해가 일어나겠지요. 그렇지 않다고 주장하려면 우리나라 자연조건의 어떤 점이 독일과 다르고, 그래서 결과가 어떻게 다르게 나타날지를 과학적으로 증명해야 할 것입니다. 우리나라 정부에서는 사대강 공사를 시작하기 전에 그것을 증명했을까요? 증명하지 않았습니다. 다만 환경조사를 해봤더니 전혀 문제가 없다고만 했습니다. 그런데 634㎞ 구간의 환경조사를 하는 데 넉 달밖에 안 걸렸습니다. 사대강 공사도 2년 안에 끝낸다고 합니다. 뮌헨에선 8㎞ 구간의 이자강 재자연화 공사를 조사하고 준비하는데 10년 걸렸고 공사하는 데도 10년 걸렸습니다.

지금까지 저는 제 의견을 말씀드린 게 아니라 한국에서 일어난 일과 독일에서 일어난 일을 있는 그대로 전해드렸을 뿐입니다. 이제부터 저의 의견을 말씀드리는 것을 허락해주시기 바랍니다.

저는 독일에 사는 외국인답게 독일 흉을 잘 봅니다. 누가 저보고 성질 급한 한국사람 아니랄까봐 독일 사람들 꼼꼼하게 일하는 거 보면 제 속이 다 터져요. 그렇지만 독일의 기술은 신뢰합니다. 저는 구두쇠지만 꼭 필요한 물건은 암만 비싸도 '메이드 인 저머니'를 삽니다. 품질이 틀림 없고 돈값을 하기 때문이죠. 저는 독일사람들이 실력이 없고 게을러서 8㎞ 구간의 이자강 공사를 준비하는 데 10년, 공사하는 데 10년씩이나 걸렸다고 생각하지 않습니다. 따라서 한국에서 전국에 걸친 634㎞ 구간의 환경조사를 4개월 안에, 문화재 조사를 2개월 안에 끝내고, 사대강 공사를 2년 안에 할 수 있다는 소리를 들으면 자랑스러운 생각이 들기는커녕 불안한 마음이 듭니다. 조사를 정말로 한 것인지, 공사를 제대로 하는 것인지, 한국에 사는 우리 조카, 조카 손주들이 자자손손 그 댓가를 치르는 것은 아닌지 겁이 더럭 납니다.

어떤 분들은 제가 독일에서 건축을 공부한 공학도니까 운하에 일가견이 있어서 이런 글도 쓴다고 생각하실는지 모르겠습니다. 사실은 그렇지 않습니다. 독일의 선례에 비추어 한국의 사대강 사업을 불안하게 생각하는 데는 독일에 사는 평범한 사람이 가지는 상식 이상의 어떤 실력도 요구되지 않습니다. 자연법칙은 만국공통이라는 걸 말하는 데는 상식 하나만 있으면 됩니다.

그럼 우리나라 국민들은 상식도 없는 사람들일까요? 아닙니다. 우리나라 국민의 70% 이상이 저처럼 사대강 사업을 불안해하고 의심하고 있습니다. 운하반대 전국교수모임에는 현재 3000여명의 교수들이 참여하고 있습니다.

그럼 국민의 뜻을 이렇게 거스를 수 있는 정부를 가진 우리나라는 법치국가일까요? 예, 그렇습니다. 국회의 예산심의도 받지 않은 채 세금으로 사대강 사업을 진행하는 우리 정부가 국가재정법, 하천법, 환경영향평가법, 문화재보호법을 위반했다고 국민이 정부를 상대로 소송을 걸었습니다. 이것이 바로 우리나라가 법치국가라는 증거입니다. 국민소송에 들어가는 비용은 국민들이 십시일반 모금해서 충당하고 있습니다. 국민소송을 진행하는 사람들은 교수, 변호사 등 명망 있는 인사들이고 각 종교계의 지도자들이 공개적으로 이름 석 자 내걸어 뒤를 받쳐주고 있습니다. 천주교에서는 교단 차원에서 국민소송을 지지하고 있으며 다른 종교에서도 그런 움직임이 일고 있습니다.

독일에 살면서도 마음은 늘 한국을 향하는 저도 모금에 동참했습니다. 저는 이것을 반정부 운동이라고 생각하지 않습니다. 저는 우리 국민이 민주적으로 뽑은 이명박 대통령의 정부를 반대하는 것이 아닙니다. 단지 우리나라 법에 어긋하는 정책을 반대하는 것이고, 반대 의사를 합법적인 방법으로 표시하고 관철하려는 것입니다. 외국에 사는 제가 저의 신상에 아무런 손익도 없는 일에 돈을 내는 이유는 법치국가를 모국으로 둔 국제시민으로서 자존심을 지키기 위해서입니다.

북한 공산당에 대한 우호적인 마음에서 우리 정부의 정책을 반대하는 건 아닐까하고 의심하는 어르신들이 독일에도 혹시 계실는지요? 육이오를 직접 겪으신 분들의 우려를 이해합니다. 하지만 동독 공산당이 비밀경찰(Stasi)을 이용해서 어떤 공포정치를 폈는지가 가욱 관청(Gauck-Behörde, 동독의 과거청산을 위해서 자료를 관리하고 공개하는 관청)을 통해 낱낱히 밝혀지는 것을 매일같이 보며 살아온 사람으로서 어떻게 일당독재 공산체제에 우호적인 마음을 가질 수 있겠습니까? 사대강 사업에 대한 찬성이나 반대는 이데올로기의 문제가 아니라 과학의 문제입니다.

'잘못되었다 하더라도 공사를 이미 시작했으니 어떡하겠나? 기왕에 쓴 돈이 아까우니 그냥 완공하는 게 낫지 않을까?'라고 생각하는 분들이 계실는지요? 잘못된 공사는 설령 99%까지 진행되었다 하더라도 나머지 1%를 막는 것이 이익입니다. 나중에 되돌리는 공사를 하려면 그 1%라도 건지는 게 엄청난 행운이기 때문입니다. 잘못된 공사라면 단 1m라도 막을 수 있을 때 막아야지요. 솔직히 말씀드려서 저는 지금 이 시간에도 강바닥을 파헤치고 있을 중장비를 생각하면 몸에 피가 마를 지경입니다.

우리나라 정부에 대한 확고한 믿음으로 사대강 사업을 지지하시는 분들께 부탁드립니다. 사대강 사업으로 인해 우리나라에도 독일의 라인강 같은 후유증이 일어나지 않는다는 과학적인 논증을 먼저 마친 후에 공사를 계속하라고 정부에 건의해주십시오. 지금 우리가 어느 나라에 살고 있건 그 정도의 수고를 바치는 것이 대한민국에서 살아갈 후손에 대한 최소한의 예의가 아니겠습니까?

긴 글을 끝까지 읽어주셔서 감사합니다.

2010년 새해를 맞으면서 뮌헨에서 임혜지 드림

많은 돈을 들여 자연으로 되돌린 이자강변의 오늘의 모습

PS 1. 오는 1월 20일 (수요일) 오후 2시 30분에 뮌헨의 사랑방 도서실에서 '한반도 대운하와 사대강 공사'에 대한 강의를 합니다. 뮌헨 사랑방도서실은 Dachauer Str. 23번지의 3층에 있는 한인 천주교회 안에 있습니다. (문의: 089 - 93 15 13) 지난번 강의를 놓치신 분들께선 부디 많이 참석하셔서 지난번과 같이 뜨거운 관심을 보여주시기 바랍니다.

PS 2. 국민소송의 모금에 참여하고 싶은 분들을 위하여 제가 은행 구좌를 따로 만들었습니다. 5유로도 좋고 10유로도 좋습니다. 보내주시는 성금은 제가 한푼도 흘리지 않고 알뜰하게 관리해서 한국으로 보내드리겠습니다.

Kt.Nr. 4 212 514 01
Commerzbank Muenchen
BLZ. 700 800 00
Name: Hea-Jee Im

PS 3. 천주교 정의평화위원회에서 신자들에게 사대강 사업을 쉽게 설명하기 위하여 만화를 제작하여 전국의 성당에 배포하고 있습니다. 천주교 정의평화위원회는 한국천주교 주교회의 아래에 있는 공식 조직으로, 위원회가 발표하는 성명은 한국 가톨릭의 공식 입장이 됩니다. 여기를 누르면 첫 페이지가 뜨고, 잠시 기다리시면 오른쪽 아래에 책 넘기는 표시가 나타납니다. 마우스로 거기를 누르시면 다음 장으로 넘어갑니다.

PS 4. 국민소송단의 취지와 집행단의 명단을 보시려면 여기 누름

Posted by 두장

TAG 4대강, 문제점

트랙백0 댓글0

2009/11/11 15:00

Computer/Network

SNMP

단순 망 관리 규약(SNMP) 표준

------------------------------------------------------------------------------------------------------------------------------

대한민국 전산망표준
KIS―3I―0016('93)
단순 망 관리 규약(SNMP) 표준
1993. 12

체 신 부

전 문

본 규약은 이기종으로 구성된 전산망의 효율적인 관리를 목표로, TCP/IP를 기반으로 하는 전산망을 관리하기 위해 간단히 운용할 수 있는 구조와 시스템을 제공한다. 본 규약은 국내전산 망이 개방시스템 상호접속(OSI)으로 완전히 전환되기 전까지는 전산망관리 잠정표준으로서 전산 망에 적용된다.

본 규약은 전산망내에 있는 노드들을 관리하기 위해 사용되는 단순 네트워크 관리 프로토콜 (SNMP: Simple Network Management Protocol)을 규정한다. 그리고 관리정보의 정의를 위한 공통구조와 식별기법을 기술한 관리정보구조(SMI: Structure of Management Information)를 규정하고, TCP/IP를 기반으로 하는 전산망에서, 피관리 대상들의 집합체인 관리정보베이스의 두 번째 버전(MIB-II: Management Information Base)을 정의한다.

본 규약은 미국 IETF(Internet Engineering Task Force)에서 발간된 RFC(Request For Comments) 1155 -- SMI, RFC 1213 -- MIB-II, RFC 1157 -- SNMP 를 번역하여 국내 전문가의 기술적인 검토를 토대로 작성되었다.

* 주요단어 : 단순전산망관리(SNMP), 관리정보구조(SMI), 관리정보베이스(MIB)

--------------------------------------------------------------------------------------------------------------------------------

목 차

제 1 장 총 칙

1.1 목적
1.2 필요성
1.3 적용대상 및 범위
1.4 주요내용

제 2 장 근거 및 관련표준
2.1 근거
2.2 관련표준

제 3 장 용어의 정의
3.1 주요 용어 정의

제 4 장단순 전산망관리 프로토콜(SNMP)
  4.1 개요
  4.2 SNMP 구조
  4.2.1 구조의 목적
  4.2.2 구조의 구성 요소
  4.3 프로토콜 명시
  4.3.1 절차 요소
  4.4 정의
  4.5 참고 문헌

제 5 장 TCP/IP기반 연결망(internets)을 위한 관리정보의 구조(SMI)
  5.1 개요
  5.2 관리 정보의 구조와 식별
  5.2.1 이름
  5.2.2 구문
  5.2.3 부호화
  5.3 관리 객체
  5.3.1 객체 이름에 대한 지침
  5.3.2 객체 유형과 실체
  5.3.3 관리 객체를 위한 매크로
  5.4 MIB 확장
  5.5 정의
  5.6 참고 문헌

제 6 장 TCP/IP기반 연결망의 네트워크관리를 위한 관리정보베이스(MIB-II)
  6.1 개요
  6.2 RFC 1156으로부터의 변화
  6.2.1 삭제 대상 객체
  6.2.2 출력 문자열
  6.2.3 물리적 주소
  6.2.4 시스템 그룹
  6.2.5 인터페이스 그룹
  6.2.6 주소 해석 그룹
  6.2.7 IP 그룹
  6.2.8 ICMP 그룹
  6.2.9 TCP 그룹
  6.2.10 UDP 그룹
  6.2.11 EGP 그룹
  6.2.12 전송 그룹
  6.2.13 SNMP 그룹
  6.2.14 RFC 1158로부터의 변화
  6.3 관리 객체
  6.3.1 정의 형식
  6.4. 정의
  6.4.1 본문의 관례적 표기
  6.4.2 MIB-II에서의 그룹
  6.4.3 시스템 그룹
  6.4.4 인터페이스 그룹
  6.4.5 주소 변환 그룹
  6.4.6 IP 그룹
  6.4.7 ICMP 그룹
  6.4.8 TCP 그룹
  6.4.9 UDP 그룹
  6.4.10 EGP 그룹
  6.4.11 전송 그룹
  6.4.12 SNMP 그룹
  6.5 참고 문헌

보칙

부칙

제 1 장 총 칙

1.1 목적

이 표준은 TCP/IP 기반 전산망을 관리하기 위해 사용되는 단순전산망관리 규약(SNMP : Simple Network Management Protocol)을 규정하여 효과적인 전산망관리를 도모하고자 한다.

1.2 필요성

전산망은 관련기술의 급속한 발달로 다양한 기능 및 서비스를 제공하고 있으며 과거의 중앙 집중방식에서 분산환경으로 바뀌고 있다. 또한 다수공급자에 의해 제공되며 다양한 장비로 구성되는 전산망은 본질적으로 복잡성 및 이질성을 내포하고 있다.

따라서 이러한 전산망 구성요소를 효과적으로 감시·통제하기 위한 전산망관리는 그 중요성이 점증되고 있다. 이질적인 전산망을 효과적으로 관리하기 위한 개방적이고 표준화된 괸리시스템이 존재하지 않는다면 호환성 및 상호운용성을 보장하는 개방시스템은 통제불능으로 인해 그의미가 상실될 것이다.

효과적인 전산망관리를 수행하려면 기본적으로 전산망관리 시스템과 피관리노드간의 관리정보를 주고 받기위해 관리정보 통신프로토콜, 관리정보구조, 관리정보의 정의 등의 전산망관리 매카니즘이 표준화되어야 한다.

1.3 적용대상 및 범위

이 표준의 적용범위는 전산망관리 표준 프로토콜의 제정에 필요한 단순 전산망관리 규약(SNMP: Simple Network Management Protocol) 표준, 관리정보구조(SMI: Structure of Management Information)에 관한 표준, 관리정보베이스(MIB: Management Information Base) 표준을 포함하고 있다.

국가기간전산망 또는 정부기관 전산망의 관리자와 전산망관리 제품의 구매자가 이 표준에서 언급하는 전산망관리 잠정표준 프로토콜과 동등한 기능을 제공하는 전산망관리 제품이나 서비스가 조달되어질 때 적용된다.

1.4 주요내용

이 표준의 내용은 다음과 같다.

첫째, TCP/IP를 갑으로 하는 전산망에 있는 노드들을 관리하기 위해 간단하고 운영가능한 구조와 시스템을 제공하는 단순 전산망관리 프로토콜(SNMP: Simple Network Management Protocol)을 규정한다.

둘째, 관리정보는 TCP/IP를 기반으로 하는 전산망을 관리하는데 사용되는 것으로 이 관리정보의 정의에 대한 공통구조와 식별기법을 기술한 관리정보구조(SMI: Structure of Management Information)를 제공한다.

셋째, TCP/IP를 기반으로 하는 전산망의 관리 프로토콜을 이용한 관리정보베이스의 두번째 버전(MIB-II: Management Information Base)을 정의한다.

제 2 장 근거 및 관련표준

2.1 근거

전산망 기술기준에 관한 규칙 제 4 조 (기능표준등의 고시)

2.2 관련표준

○ "Structure and Identification of Management Information for TCP/IP-based internets" RFC 1155, IETF.

○ "The Simple Network Management Protocol (SNMP)", RFC 1157, IETF.

○ "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", RFC 1213, IETF.

제 3 장 용어의 정의

3.1 주요 용어 정의

⊙ CMIP over TCP(CMOT): OSI 전산망관리 프로토콜을 TCP/IP를 사용하는 전산망에 적용하는 전산망관리 방법

⊙ High-level Entity Management System(HEMS): 인터네트에서 초기에 고안한 전산 망관리 시스템

⊙ IP 계층(internet layer): 인터네트 프로토콜 중 상이한 물리적 전산망 사이의 상호 통신을 담당하는 계층

⊙ Internet Assigned Numbers Authority(IANA): 인터네트 프로토콜에서 사용하는 할당 번호를 관리하는 기구

⊙ Internet Control Message Protocol(ICMP): IP의 간단한 보고용 프로토콜

⊙ Internet Engineering Steering Group(IESG): IETF의 활동을 조정하는 그룹

⊙ Internet Engineering Task Force(IETF): 인터네트의 단기적 문제를 해결하기 위한 IAB의 소위원회

⊙ Request for Comments(RFC): 인터네트 프로토콜 또는 그와 관련된 실험을 기술 하는 문서

⊙ Simple Gateway Monitoring Protocol(SGMP): SNMP의 원형인 관리 프로토콜 참고

⊙ 개방시스템상호접속(Open Systems Interconnection : OSI): IOS의 개방형 전산망 시스템

⊙ 게이트웨이(gateway): 인터네트에서 라우터를 지칭하는 용어로 둘 또는 그 이상의 종속망을 상호접속하여 한 종속망에서 다른 쪽으로의 데이타의 통로를 가능케하는 장비 또는 장비의 쌍

⊙ 경량 표현 프로토콜(light weight presentation protocol): OSI의 표현 서비스중 일부 만을 지원하는 프로토콜

⊙ 공개 키(public key): 이중 암호 시스템에서 공개시키는 키

⊙ 공통관리 정보규약(Common Management Information Protocol : CMIP): 전산망 관리를 위해 OSI에서 제정한 프로토콜

⊙ 공통관리 정보서비스(Common Management Information Service : CMIS): CMIP 에서 제공하는 전산망관리 서비스, OSI 시스템관리 소프트웨어 프로세스간에 관리정보 의 상호교환을 성취시켜주는 통신 메카니즘

⊙ 관리 대상(managed object): 전산망관리에 필요한 정보

⊙ 관리 대상군(managed object group): 같은 전산망 기능을 관리하는 관리 대상의 집합

⊙ 관리 대상점(managed node): 전산망관리 대리인을 가지고 있는 전산망 장비

⊙ 관리 정보 기반(Management Information Base : MIB): 관리 대상의 집합

⊙ 구성 관리(configuration management): 전산망관리 기능중 전산망을 형성하는 전산망 요소들의
연결성, 동작 상태, 관리 상태등을 감시하고 제어하는 기능

⊙ 국제표준화기구(International Organization for Standardization : ISO): 국제 표준을 제정하는 기관

⊙ 군체(community): 전산망관리 대리인과 전산망 관리소와의 행정적 관계

⊙ 군체 단면(community profile): 군체의 소속원이 조작할 수 있는 전산망관리 대리인이 보유하고 있는 관리 대상의 일부

⊙ 군체 이름(community name): 군체를 나타내는 문자 스트링

⊙ 기본 부호화 법칙(Basic Encoding Rules): 전송 구문을 기술하는 OSI에서 정의한 언어

⊙ 단순 네트워크 관리 프로토콜(Simple Network Management Protocol : SNMP):
1988년 초, Internet Activities Board(IAB)가 가진 ad-hoc 모임 즉, 국가 전체의 TCP/IP에 기초를 둔 Internet를 관리하는데 있어 전략을 결정하기 위한 이 모임에서 표준화에 대한 단기해결책으로 제시한 방안.

⊙ 단편(fragment): 큰 IP 데이타그램이 분할된 조각

⊙ 데이터 그램(datagram): 다른 데이터그램 등과 독립적으로 전송되는 독립 데이터 단위

⊙ 무결성(integtity): 현한을 부여 받지 않은 개체로 부터의 영향으로는 시스템이나 데이터가 변경되거나 파괴되지 않고 원래대로 보존되는 특성

⊙ 무연결형(connection-less mode): 한 단계에서 데이터 전송과 주소 지정과 같은 제어를 같이하는 서비스

⊙ 물리적 주소(hardware address): 물리적 인터페이스의 주소

⊙ 분할(fragmentation): 큰 IP 데이터그램을 여러개의 단편으로 나누는 것

⊙ 성능 관리(performance management): 전산망관리 기능중 전산망의 부하나 제반 성능을 감시하는 기능

⊙ 세그먼트(segment): TCP의 통신 단위

⊙ 실험적 MIB(experimental MIB): 인터네트 관리 공간중 experimental 트리에 등록되어 있는 관리 대상의 집합

⊙ 연결형(connection-oriented mode): 경로 연결, 데이터 전송, 경로 해제의 세 단계로 구성된 서비스

⊙ 외부 게이트웨이 프로토콜(Exterior Gateway Protocol : EGP): 인터네트의 외부 게이트웨이 사이에서 라우팅을 위해 제정한 프로토콜

⊙ 응용 계층(application layer): 응용 프로세스 사이의 통신을 관리하는 OSI 시스템의 최상층 구조

⊙ 인스턴스 인식표(instance-identifier): 관리 대상 인스턴스를 인식하는 방법

⊙ 인증(Authentication): 통신 상대방의 신분을 확인하여 접근이 허용된 실체인지 확인하는 것

⊙ 인터네트(Internet): 인터네트 프로토콜에 의해 상호 연결된 거대한 전산망의 집합

⊙ 인터네트 전산망 관리 기초구조(Internet-standard Network Management Framework): REC 1155, 1156, 1157에 정의된 인터네트에서 제정한 전산망관리 시스템의 기본 구조

⊙ 인터네트 초안(Internet Drafts): IETF의 작업결과를 기술하는 문서

⊙ 인터네트 표준개발 위원회(Internet Activities Board : IAB): 인터네트 프로토 콜의 발달을 총괄하는 기술적 기구

⊙ 인터네트 프로토콜(Internet Protocol : IP): IP 계층에서 사용하는 프로토콜

⊙ 인터네트 프로토콜 주소(IP address): 인터네트에 접속된 점을 나타내는 32bit로 된 주소

⊙ 인터페이트 계층(interface layer): 한 물리적 전산망안에서의 전송을 하는 인터네트 프로토콜의 최하계층

⊙ 장애 관리(fault management): 전산망관리 기능 중 전산망 장비의 장애 발견 및 원인 구분, 그리고 비정상적인 동작이나 장애 상태를 수리하는 기능

⊙ 전산망 관리소(network management station): 전산망의 관리를 관장하는 시스템

⊙ 전산망 인식표(network-identifier): IP 주소중 전산망을 지칭하는 부분

⊙ 전산망관리(network management): 전산망이 본연의 목적을 달성하도록 감시 제어 하는 행위

⊙ 전산망관리 대리인(network management agent): 전산망 관리소의 감시, 제어하에 관리 대상을 관리하는 관리 대상점에 있는 전산망관리 프로토콜의 구현

⊙ 전산망관리 프로토콜(network management protocol): 관리 정보를 전송하기 위한 프로토콜

⊙ 전송 제어 규약(Transmission Control Protocol : TCP): 미국 국방성의 ARPANET 에서 처음 사용되었으며 ISO의 트랜스포트 계층에 해당하는 ordered, connection-oriented, reliable, full-duplex 프로토콜

⊙ 접근 권한(Authorization): 통신 상대방이 접근할 수 있는 데이터의 범위와 접근 형태를 정의하는 것

⊙ 접근 제어(access control): 불법적으로 시스템이나 레이더에 접근하는 것을 방지함

⊙ 접근 형태(access mode): SNMP 군체가 보유하고 있는 관리 대상에 대한 접근 권한

⊙ 추상 구문(abstract syntax): 하드웨어의 구조 및 한계와 독립적인 데이터 유형의 기술

⊙ 추상 구문 표기법 1(Abstract Syntax Notation One : ASN.1): 추상 구문을 기술하기 위해 OSI에서 제정한 언어 ⊙ 포트 번호(port number): 인터네트 프로토콜의 전송 계층에서 응용 프로세스를 구별하는 번호

⊙ 프로토콜 데이타 단위(protocol data unit:PDU) : 프로토콜 제어 정보와 사용자 데이터를 포함하는 프로토콜 실체간의 전송 단위

⊙ 프로토콜 제어 정보(protocol control information): 상대편과의 통신을 제어하는 정보

⊙ 행정 구조(administrative framework): 인증과 접근 권한 방침을 정의하기 위한 방법

⊙ 호스트(host): 응용 계층 서비스를 하는 전산망 설비를 지칭하는 인터네트 용어

제 4 장 단순 망관리 프로토콜(SNMP)

4.1 개요

단순 망관리 프로토콜(SNMP) 표준은 전산망 구성 요소에 관한 관리 정보가 논리적으로 원격 지사용자들에 의해 조사되거나 변경될 수 있게 지원하는 간단한 프로토콜을 정의한다. 특히, 관리정보 베이스(MIB)와 함께 관리 정보의 구조(SMI)를 기술하는 관련 표준들과 같이 본 표준은 TCP/IP를 기반으로 하는 연결망들(internets)을 관리하기 위해 간단하고 운영가능한 구조와 시스템을 제공한다.

인터네트 전산망 관리 표준안(Internet Network Management Standards)[1] 개발을 위한 인터네트 표준개발 위원회(Internet Activities Board:IAB) 권고안인 RFC 1052에 보고된 것처럼,TCP/IP를 기반으로 하는 연결망의 전산망관리 표준을 위한 두가지 전략이 착수되었다. 단기적으로, 단순 전산망관리 프로토콜(SNMP)은 인터네트 공동체에 있는 노드들을 관리하기 위해 사용하고 장기적으로, OSI 전산망관리 체계로의 전환이 이루어지는 것이다.

전략은 단기적으로 성공했다. 즉, 인터네트를 기반으로 하는 전산망관리 기술은 몇 달 내에 연구소와 기업체들에 의해 실제 상황에서 실험되었다. 이런 결과로, 인터네트 공동체의 일부분들은 적절한 방식으로 전산망관리가 용이해졌다.

IAB는 "권고" 상태를 갖는 완전한 "표준 프로토콜"이 되기 위해 SNMP, SMI 그리고 초기 인터네트 MIB를 지정했다. 이런 행동에 의해, IAB는 모든 IP와 TCP 구현에 전산망 관리가 가능하며 전산망관리가 가능한 구현실상(instance)은 SMI, MIB, 그리고 SNMP를 채택하고 구현하도록 권고하고 있다.

이와같이, TCP/IP를 기반으로 하는 연결망을 위한 현재의 전산망관리 체계는 다음과 같이 구성된다. TCP/IP를 기반으로 하는 인터네트를 위한 관리 정보의 구조와 식별은 MIB에 포함된 관리객체가 RFC 1155[5]에서 제안된 것처럼 정의되는 방법을 기술한다. TCP/IP를 기반으로 하는 인터네트의 전산망 관리를 위한 관리 정보 베이스는 RFC 1156[6]에 제안된 것처럼 MIB에 포함된 관리객체를 기술한다.

그리고, 단순 전산망 관리 프로토콜은 이 표준에 제안된 것처럼 이런 객체들을관리하기 위해 사용되는 프로토콜을 정의한다.

4.2 SNMP 구조

SNMP의 구조적인 모델은 전산망 관리 스테이션들과 전산망 요소들로 이루어진다. 전산망 관리스테이션들은 전산망 요소들을 감시하고 통제하는 관리 응용들을 수행한다. 전산망 요소들은
호스트, 게이트웨이, 단말기 서버등과 같은 장비이며, 이 장비에는 전산망 관리 스테이션들로 부터요청된 전산망 관리 기능들을 수행하는데 책임이 있는 관리 수행자가 있다.

단순 전산망 관리 프로토콜(SNMP)은 전산망 관리 스테이션들과 전산망 요소들에 있는 수행자들사이의 관리 정보를 교환하기 위해 사용된다.

4.2.1 구조의 목적

SNMP는 관리 수행자 자체에 의해 실현되는 관리 기능의 수와 복잡성을 최소화한다. 이런 목적은 적어도 네가지 점에서 호소력이 있다.

(1) 프로토콜을 지원하기 위해 필요한 관리 수행자 소프트웨어의 개발 비용이 그에 맞추어 감소 된다.
(2) 원격지에서 지원되는 관리 기능의 정도가 높아지면서 관리 업무에 있어서 연결망자원의 충분 한 이용을 가능하게 한다.
(3) 원격지에서 지원되는 관리 기능의 정도가 높아지면서 관리 도구들의 형식과 정교함에 대해 가능한한 최소의 제한사항이 부과된다.
(4) 관리 기능의 단순화된 집합은 전산망 관리 도구의 개발자들에 의해 쉽게 이해되고 사용된다.

이 프로토콜의 두번째 목적은 감시와 제어를 위한 기능적인 형태 활용이 전산망 운영과 관리의 추가적이고 예측치 못한 측면을 조절할 정도로 충분히 확장가능하다는 것이다.
세번째 목적은, 그 구조가 특정 호스트 또는 게이트웨이의 구조와 메카니즘과는 가능한 한 독립적이라는 것이다.

4.2.2 구조의 구성 요소

SNMP 구조는 다음 사항에 의해 전산망 관리 문제의 해결책을 명확히 표명한다.

(1) 프로토콜에 의해 교환되는 관리 정보의 영역,
(2) 프로토콜에 의해 교환되는 관리 정보의 표현,
(3) 프로토콜에 의해 지원되는 관리 정보에 관한 동작,
(4) 관리 실체들 사이의 교환의 형식과 의미,
(5) 관리 실체들 사이의 관리적인 관계의 정의,
(6) 관리 정보 참조의 형식과 의미.

4.2.2.1 관리 정보의 영역

SNMP의 운영에 의해 교환되는 관리 정보의 영역은 인터네트 표준 MIB에 정의된, 또는 인터네트표준 SMI[5]에 의해 제안된 규정에 따라 정의된 모든 단순 객체 유형의 실상(instance)에 의해 표현된다.
MIB 내에서 집합 객체 유형에 대한 지원은 SMI를 따를 필요도 없고 SNMP에 의해 구현 되지도 않는다.

4.2.2.2 관리 정보의 표현

SNMP 운영에 의해 교환되는 관리 정보는 SMI에 있는 단일 유형 정의로 명시된 ASN.1 언어 [9]의 부분 집합에 따라 표현된다.

SGMP는 ASN.1 언어[9]의 잘 정의된 부분집합을 사용한 규정을 채택했다. SNMP는 계속해서 이런 방식을 확장하여 관리 객체를 기술하고 그런 객체를 관리하는데 사용되는 프로토콜 데이타 단위(PDU)를 기술하는데 ASN.1의 좀 더 복잡한 부분집합을 사용한다.

더우기, OSI를 기반으로하는 전산망 관리 프로토콜로의 궁극적인 전이를 용이하게 하려는 경향이 인터네트 표준 관리 정보의 구조와 관리 정보 베이스를 ASN.1 언어로 정의하게 하였다. 부분적으로, ASN.1 언어의 사용은 이전의 노력 특히, SGMP에서 ASN.1의 성공적인 사용에 의해 장려되었다.

SMI의 부분인 ASN.1의 사용에 관한 제약사항은 SGMP의 경험에 의해 지지를 받고 타당성을 인정받은 단순성에 공헌했다. 또한 단순성을 위해, SNMP는 ASN.1의 BER[10]의 부분집합만을 사용한다. 다시 말해서, 모든 부호화는 한정된 길이의 형식을 사용한다.

가능하다면, 조립형 부호화보다는 비조립형 부호화가 사용된다. 이런 제한은 그들이 포함하는 자료 객체와 상위 계층 프로토콜 데이타 단위(PDU)를 위해 ASN.1 인코딩의 모든 측면에 적용된다.

4.2.2.3 관리 정보에 지원되는 동작

SNMP는 변수의 변환 또는 조사로써 모든 관리 수행자의 기능을 모델화한다. 논리적으로 원격 지호스트 상의 프로토콜 엔티티(전산망 요소 자체)는 변수들을 바꾸거나 검색하기위해 전산망 요소상에 주둔하는 관리 수행자와 상호작용한다. 이런 방법은 적어도 두가지 긍정적인 결과를 갖는다.

(1) 관리 수행자에 의해 실현되는 필수적인 관리 기능의 수를 둘로 제한하는 결과를 가져온다.
즉, 명시된 구성이나 다른 매개변수에 값을 할당하는 동작이고 다른 하나는 그런 값을 검색하는 동작이다.

(2) 이런 결정의 두번째 결과는 필수적인 관리 명령어를 위해서 프로토콜 정의에 대한 지원이 있어야 한다는 것을 피하게 해준다. 그런 명령어의 수는 실제로 계속 증가하고, 일반적으로 그런 명령어의 의미는 복잡하다.

SNMP에서 암시하고 있는 전략은 세부적으로 중요한 수준에 있는 전산망 상태의 감시는 주로 감시 센타 부분의 해당 정보를 폴링하여 이뤄진다는 것이다. 제한된 수의 비요구 메세지(traps) 는폴링의 시기와 중요성을 지시한다. 요구되지 않은 메세지 수를 제한하는 것은 전산망 관리 기능에 의해 발생된 교통량을 최소화하고 단순성의 목적과 일관된다.

가시적으로 지원되는 관리 기능의 집합에서 지시 명령어의 배제는 바람직한 관리 수행자 운영을 방해하지는 않을 것이다. 현재, 대부분의 명령어는 어떤 매개변수 값을 설정하거나 그런 값을 검색하기 위해 요청된다. 그리고 현재 지원되는 몇가지 지시 명령어의 기능은 이런 관리 모델에 의해 비동기모드로 쉽게 조절된다.

이런 방법에서, 지시 명령어는 원하는 행동을 개시시키는 매개변수 값의 설정으로 구현되어야 한다. 예를 들면, "재시동 명령어"의 구현 보다는 이런 동작이 시스템 재시동될때까지의 초를 나타내는 매개변수를 설정하는 것에 의해 실행되어야 한다.

4.2.2.4 프로토콜 교환의 형태와 의미

관리 실체들 사이의 관리 정보 교환은 프로토콜 메세지의 교환을 통해 SNMP 내에서 실현된다.
그런 메세지의 형태와 의미는 3절에서 정의된다.

관리 수행자의 복잡성을 최소화하는 목적과 일관되도록 하기 위해, SNMP 메세지 교환은 비신 뢰적 데이타그램 서비스만을 요구하고, 모든 메세지는 하나의 수송계층 데이타그램에 의해 완전히독립적으로 표현된다. SNMP 메카니즘은 일반적으로 다양한 수송계층 서비스를 이용하기에 적합하다.

4.2.2.5 행정적 관계의 정의

SNMP 구조는 프로토콜에 참여하는 실체들 사이의 다양한 행정적 관계를 인정한다. SNMP를 이용하여 서로 통신하는 전산망 요소와 관리 스테이션에 주둔하는 실체들은 SNMP 응용 엔티티라 한다. SNMP를 구현하여 SNMP 응용 실체들을 지원하는 동위 프로세스들은 프로토콜 엔티티라 한다.

SNMP 응용 엔티티의 임의의 집합으로 된 SNMP 수행자의 쌍을 SNMP 공동체라 한다. 각 SNMP 공동체는 옥테트 스트링으로 명명되는데, 그것은 공동체 이름으로 불리운다.

공동체 구성요소에 의해 명명되어 실제로 SNMP 공동체에 속하는 SNMP 응용 엔티티에 의해 발생한 SNMP 메세지를 인증된 SNMP 메세지라 한다. SNMP 메세지가 특정 SNMP 공동체를 위한 인증된 SNMP 메세지로 식별되는 법칙들의 집합을 인증 기법이라 한다. 여러 인증 기법에 따라 인증된 SNMP 메세지를 식별하는 기능의 구현은 인증 서비스라 한다.

SNMP 응용 실체들 사이의 행정적 관계의 확실하면서도 효과적인 관리는 고도의 확실성으로 인증된 SNMP 메세지를 식별할 수 있는 인증 서비스(암호화 또는 다른 기술을 이용한)를 요구한다. 몇가지 SNMP 구현은 모든 SNMP 메세지를 믿을만한 SNMP 메세지로 식별하는 단순한 인증 기법만을지원할 수 있다.

전산망 구성요소를 위해, 그 요소에 속한 MIB 내의 객체들의 부분집합을 SNMP MIB 영역이라 한다. SNMP MIB 영역에 표현된 객체 유형의 이름은 객체 유형 이름 공간의 하나의 서브트리에 속할필요는 없다.

집합 { 읽기전용, 읽기쓰기 }의 요소는 SNMP 접근 방식이라 한다.

SNMP MIB 영역을 갖는 SNMP 접근 방식의 쌍은 SNMP 공동체 프로화일이라 한다. SNMP 공동체 프로화일은 명시된 MIB 영역에 있는 변수들에 명시된 접근 권한을 나타낸다. 주어진 SNMP 공동체프로화일에 있는 MIB 영역 내의 모든 변수들에 대해, 변수 접근은 다음 규정에 따르는 프로화일로 나타낸다.

(1) 언급된 변수가 MIB 내에 "접근:"이 "금지"로 정의된다면, 어떤 연산자에 대한 피연산자로이용불가능하다.

(2) 언급된 변수가 MIB 내에 "접근:"이 "읽기쓰기" 또는 "쓰기전용" 그리고 주어진 프로화일의 접근 모드가 "읽기쓰기"라면, 그 변수는 GET, SET, TRAP 동작의 피 연산자로 이용가능하다.

(3) 그밖의 경우, 변수는 GET 그리고 TRAP 동작의 피연산자로 이용가능하다.

(4) "쓰기전용" 변수가 GET 또는 TRAP 동작에 사용되는 피연산자인 경우에, 그 변수 에 주어진 값은 구현시 결정할 수 있다.

SNMP 공동체 프로화일을 갖는 SNMP 공동체의 쌍은 SNMP 접근 정책이라 불린다. 그 공동 체의 다른 구성원들에게 접근 정책이라는 것은 명시된 SNMP 공동체의 SNMP 수행자에 의해 제공되는 명시된 공동체 프로화일을 의미한다. SNMP 응용 실체들 사이의 모든 관리적인 관계 는 구조적으로 SNMP 접근 정책에 의해 정의된다.

모든 SNMP 접근 정책에 대해, 명시된 SNMP 공동체에 대한 SNMP 수행자가 상주하는 전산 망 요소가 명시된 프로화일에 대한 MIB 영역에 속한 곳이 아니라면, 그 정책은 SNMP 대리 접근 정책이라 불리운다. 대리 접근 정책에 연관된 SNMP 수행자는 SNMP 대리 수행자로 불리운다.

대리 접근 정책의 부주의한 정의가 관리 루프를 초래할 수 있는 반면, 대리 정책의 신중한 정의는 적어도 두가지면에서 유용하다.

(1) 관리 프로토콜과 수송계층 프로토콜을 사용하여 주소를 지정할 수 없는 전산망 요소의 제어와 감시를 허락한다. 다시 말해서, 대리 수행자는 상이한 관리 체계를 지원하는 모뎀, 멀티플렉서와 같은 장치를 포함하는 모든 전산망 요소에 일관된 관리 체계를 적용할 수 있도록 하는 프로토콜 변환 기능을 제공할 수 있다.

(2) 잠재적으로 정교한 접근 제어 방식으로 부터 전산망 요소를 보호한다. 예를 들면, 대리 수행자는 MIB 내의 변수들의 다양한 부분집합이 전산망 요소의 복잡도를 증가시키지 않고 다른 관리 스테이션에 접근할 수 있게 한다.

범위 : 구성요소의 관리 범위
PCommunity : 대리 수행자를 이용하는 공동체의 이름
DCommunity : 직접 공동체의 이름

4.2.2.6 관리 객체에 대한 참조의 형식과 의미

SMI는 이를 준수하는 관리 프로토콜의 정의가 다음을 설명한 것을 요구한다.

(1) 모호한 MIB 참조의 해결
(2) 현존하는 MIB 버젼에 있어서 MIB 참조의 해결, 그리고
(3) MIB에 정의된 객체 유형의 특정 실상(instance) 식별

4.2.2.6.1 모호한 MIB 참조의 해결

SNMP 동작 영역은 개념적으로 하나의 네크워크 요소와 관계된 객체로 제한되고, MIB 객체 로의 모든 SNMP 참조는 (암시적 또는 표면적으로) 유일한 변수 이름으로 이루어지므로, MIB에 정의된 어떤 객체 유형에 대한 SNMP 참조가 그 유형의 여러 실상(instance)을 참조할 가능성은 없다.

4.2.2.6.2 MIB 버젼에 따른 참조의 해결

어떤 SNMP 동작에 의해 참조되는 객체 실상(instance)은 전체 MIB 내에서 get-next 동작의 경우에 그의 직접적인 계승자 또는 동작 요청의 부분으로 명시된 것이다. 특히, 인터네트 표준 MIB버젼의 부분으로 객체에 대한 참조는 언급된 인터네트 표준 MIB 버젼의 부분이 아닌 객체를 해결하지 못한다.

다만, 요청된 동작이 get-next이고 명시된 객체 명이 언급된 인터네트 표준 MIB 버젼의 부분으로 나타난 모든 객체들의 이름 중에서 사전순으로 마지막인 경우는 예외이다.

4.2.2.6.3 객체 실상(instance)의 식별

MIB에 있는 모든 객체 유형의 이름은 인터네트 표준 MIB 또는 SMI의 이름 설정 규정에 따르는 다른 문서에 명확히 정의된다. 이를 준수하는 관리 프로토콜이 특정 전산망 요소를 위한 객체 유형 각각의 실상(instance)을 식별하기 위한 메카니즘을 정의하는 것을 SMI는 요구한다.

MIB에 정의된 어떤 객체 유형의 각 실상(instance)은 그것의 "변수 명"으로 불리는 유일한 이름에 의해 SNMP 동작에서 식별된다. 일반적으로, SNMP 변수의 이름은 x.y 형식의 OBJECT IDENTIFIER로, x는 MIB에 정의된 단순 객체 유형의 이름이고 y는 명명된 객체 유형에 정해진 방법으로서, 원하는 실상(instance)을 식별하는 OBJECT IDENTIFIER 부분이다.

이러한 명명 방법은 GetNextRequest-PDU 의미의 충분한 개발을 보장한다(3절 참조). 그 이유는MIB에 알려진 모든 변수 명이 사전편집 순서로 연속하도록 관련된 변수를 위한 이름을 할당하기 때문이다.

객체 실상(instance)의 유형에 정해진 명명은 많은 객체 유형의 등급을 위해 다음과 같이 정의 된다. 다음 명명 원칙 중에 응용할 수 없는 객체 유형의 실상(instance)은 x.0 형식의 OBJECT IDENTIFIER에 의해 명명된다. x는 MIB 정의에 있는 객체 유형으로 불리는 이름이다.

예를 들면, 변수 sysDescr의 실상(instance)을 식별하길 원한다고 가정하자. sysDescr을 위한 객체 등급은 다음과 같다.

iso org dod internet mgmt mib system sysDescr 1 3 6 1 2 1 1 1

그러므로, 객체 유형 x는 1.3.6.1.2.1.1.1이고 이것에 실상(instance) 서브 식별자로 0 이 추가된다. 다시 말해서, 1.3.6.1.2.1.1.1.0는 sysDescr의 실상(instance) 하나만을 식별한다.

4.2.2.6.3.1 ifTable 객체 유형 이름

서브네트(Subnet) 인터페이스 s의 이름은 i 형식의 OBJECT IDENTIFIER 값이다. 이때 i는 s에 연관된 ifIndex 객체 유형의 실상(instance)의 값을 갖는다. 정의된 이름 n이 ifEntry의 접두사를 갖는 각 객체 유형 t에 대해, t의 실상(instance) i는 n.s형식의 OBJECT IDENTIFIER로 명명되며, 이때 s는 i가 서브네트 인터페이스 정보를 나타내는 이름이다.

예를 들면, 인터페이스 2에 연관된 변수 ifType의 실상(instance)을 식별하길 원한다고 가정해보자. 이 경우 ifType.2는 원하는 실상(instance)을 식별한다.

4.2.2.6.3.2 atTable 객체 유형 이름

AT-cached 전산망 주소의 이름 x는 1.a.b.c.d 형식의 OBJECT IDENTIFIER이다.
이때 a.b.c.d("dot" 표기법)는 x에 연관된 atNetAddress 객체 유형의 값이다.
주소 해석 동치 e의 이름은 s.w 형식의 OBJECT IDENTIFIER로, s는 e에 연관된 atIndex 객체 유형의 실상(instance) 값이고, w는 e에 연관된 AT-cached 전산망 주소의 이름이다.

정의된 이름 n이 atEntry의 접두사를 갖는 각 객체 유형 t에 대해, t의 실상(instance) i는 n.y 형식의 OBJECT IDENTIFIER에 의해 명명된다. y는 i가 주소 해석 동치 정보를 나타내는 이름이다.
예를 들면, 인터페이스 3과 89.1.1.42 IP 주소에 연관된 주소 해석 테이블(ARP cache)에 있는 엔트리의 물리적 주소를 찾기를 원한다고 가정하자. 이 경우, atPhysAddress. 3.1.89.1.1.42는 원하는 실상(instance)을 식별한다.

4.2.2.6.3.3 ipAddrTable 객체 유형 이름

IP 주소를 부여할 수 있는 전산망 요소 x의 이름은 a.b.c.d 형식의 OBJECT IDENTIFIER이다.
이때, a.b.c.d("dot" 표기법)는 x에 연관된 ipAdEntAddr 객체 유형의 실상(instance) 값이다.

정의된 이름 n이 ipAddrEntry의 접두사를 갖는 각 객체 유형 t에 대해, t의 실상(instance) i 는 n.y 형식의 OBJECT IDENTIFIER에 의해 명명된다. y는 i가 IP 주소를 부여할 수 있는 전산망요소의 정보를 나타내는 이름이다.

예를 들면, 89.1.1.42 IP 주소에 연관된 IP 인터페이스 테이블에 있는 엔트리의 네크워크 마스크를 찾기를 원한다고 가정하자. 이 경우, ipAdEntNetMask.89.1.1.42는 원하는 실상(instance)을 식별한다.

4.2.2.6.3.4 ipRoutingTable 객체 유형 이름

IP 경로 x의 이름은 a.b.c.d 형식의 OBJECT IDENTIFIER이다. 이때 a.b.c.d("dot" 표기법)는 x에 연관된 ipRouteDest 객체 유형의 실상(instance) 값이다.
정의된 이름 n이 ipRoutingEntry의 접두사를 갖는 각 객체 유형 t에 대해, t의 실상(instance) i는 n.y 형식의 OBJECT IDENTIFIER에 의해 명명된다. y는 i가 IP 경로 정보를 나타내는 이름이다.

예를 들면, 89.1.1.42의 목적지에 연관된 IP 경로설정 테이블에 있는 엔트리의 다음 홉을 찾기를 원한다고 가정하자. 이 경우, ipRouteNextHop.89.1.1.42는 원하는 실상(instance)을 식별한다.

4.2.2.6.3.5 tcpConnTable 객체 유형 이름

TCP 연결 x의 이름은 a.b.c.d.e.f.g.h.i.j 형식의 OBJECT IDENTIFIER이다. 이때 a.b.c.d("do t" 표기법)는 x에 연관된 tcpConnLocalAddress 객체 유형의 실상(instance) 값이다. f.g.h.i는 x 에 연관된 tcpConnRemoteAddress 객체 유형의 실상(instance) 값이다. e는 x에 연관된 tcpConnLocalPort 객체 유형의 실상(instance) 값이다. j는 x에 연관된 tcpConnRemotePort 객체 유형의 실상(instance) 값이다.

정의된 이름 n이 tcpConnEntry의 접두사를 갖는 각 객체 유형 t에 대해, t의 실상(instance) i 는 n.y 형식의 OBJECT IDENTIFIER에 의해 명명된다. y는 i가 TCP 연결 정보를 나타내는 이름이다.

예를 들면, TCP 포트 21 상의 89.1.1.42 지역 주소와 TCP 포트 2059 상의 10.0.0.51 원격 주소 사이의 TCP 연결의 상태를 찾기를 원한다고 가정하자. 이 경우, tcpConnState.89.1.1.42.21.10.0.0.51.2059는 원하는 실상(instance)을 식별한다.

4.2.2.6.3.6 egpNeighTable 객체 유형 이름

EGP 이웃 노드 x의 이름은 a.b.c.d 형식의 OBJECT IDENTIFIER이다. 이때 a.b.c.d("dot" 표기법)는 x에 연관된 egpNeighAddr 객체 유형의 실상(instance) 값이다.
정의된 이름 n이 egpNeighEntry의 접두사를 갖는 각 객체 유형 t에 대해, t의 실상(instance) i는 n.y 형식의 OBJECT IDENTIFIER에 의해 명명된다. y는 i가 EGP 이웃 노드의 정보를 나타내는 이름이다.

예를 들면, 89.1.1.42의 IP 주소의 이웃 노드 상태를 찾기를 원한다고 가정하자.

이 경우,egpNeighState.89.1.1.42는 원하는 실상(instance)을 식별한다.

4.3 프로토콜 명시

전산망관리 프로토콜은 관리대리인 MIB의 변수가 관찰되거나 변경될 수 있는 응용 프로토콜 이다.
프로토콜 실체들 사이의 통신은 메세지의 교환에 의해 이뤄진다. 메세지 각각은 ASN.1의 BER 을 이용하는 하나의 UDP 데이타그램 내에서 완전히 그리고 독립적으로(2.2.2절에서 논의된 것처럼)표현된다.

메세지는 버젼 식별자, SNMP 공동체 이름, 그리고 프로토콜 데이타 단위(PDU)로 구성된다. 프로토콜 엔티티는 트랩을 보고하는 것을 제외하고(즉, Trap-PDU를 포함하는 것을 제외한 모든 메세지) 모든 메세지들에 연관된 그 호스트의 UDP 포트 161에서 메세지를 받는다.

트랩을 보고하는 메세지는 그 이상의 처리를 위해 UDP 포트 162 상에서 받아야한다. 이 프로토콜의 구현은 길이가 484 옥테트 이상인 메세지를 받을 필요는 없다. 그러나, 실행이 가능하다면 좀더 큰 데이타그램을 지원할 수 있도록 구현되는 것을 권고한다.

SNMP의 모든 구현은 다섯가지의 PDU 즉, GetRequest-PDU, GetNextRequest-P여, GetResponse-PDU, SetRequest-PDU, Trap-PDU 를 지원하는 것이 필수 사항이다.

RFC1157-SNMP 정의 ::= 시작

IMPORTS RFC1155-SMI로부터 ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks 를 가져온다.

-- 상위-레벨 메세지

Message ::=
SEQUENCE {
version
INTEGER {
version-1(0)
},
community -- 공동체 이름
OCTET STRING,
data -- 예를 들면, 단순한 인증이
ANY -- 사용될 경우 PDU

-- 프로토콜 데이타 단위

PDUs ::=
CHOICE {
get-request
GetRequest-PDU,
get-next-request
GetNextRequest-PDU,
get-response
GetResponse-PDU,
set-request
SetRequest-PDU,
trap
Trap-PDU
}

-- 데이타 유형에 사용되는 각각의 PDU와 공통적인 PDU는 후에 정의될 것이다.

4.3.1 절차 요소

이 절은 SNMP를 구현하는 프로토콜 엔티티의 행동을 기술한다. 그러나, 이에 준하는 구현의 내부 구조를 제약하지는 않는다.
다음의 원문에서, 수송계층 주소가 사용된다. UDP의 경우에, 수송계층 주소는 UDP 포트와 함께 IP 주소로 구성된다. 다른 수송계층 서비스는 SNMP를 지원하기 위해 사용될 수 있다. 이런 경우에, 수송계층 주소의 정의가 그것에 준하여 구성되어야 한다.
메세지를 만들어 내는 프로토콜 엔티티의 상위-레벨 행동은 다음과 같다.

(1) 먼저, ASN.1 객체로 해당 PDU(즉, GetRequest-PDU)를 구성한다.

(2) 다음에, 그의 근원지 주소와 목적지 주소인 공동체 이름과 함께 이 ASN.1 객체 를 원하는 인증 기법을 구현하는 서비스에게 넘겨준다. 이 인증 서비스는 또 다른 ASN.1 객체를 반환한다.

(3) 그 다음에, 프로토콜 엔티티는 공동체 이름과 생성된 ASN.1 객체를 이용하여 ASN.1 메세지 객체를 구성한다.

(4) 이런 새로운 ASN.1 객체는 ASN.1의 BER을 이용하여 연속적으로 나열되어서, 수송계층 서비스를 이용하여 상대방 프로토콜 엔티티로 보내진다.

유사하게, 메세지를 받는 프로토콜 엔티티의 상위-레벨 행동은 다음과 같다.

(1) ASN.1 메세지 객체에 대응하는 ASN.1 객체를 만들기 위해 유입되는 데이타그램의 기본적인 분석을 수행한다. 분석이 실패한다면, 데이타그램을 버리고 그 이상의 행동을 수행하지 않는다.

(2) 그 다음, SNMP 메세지의 버젼 번호를 확인한다. 불일치가 있다면, 데이타그램을 버리고 그 이상의 행동을 수행하지 않는다.

(3) 그 다음으로, 프로토콜 엔티티가 동일한 인증 기법을 사용하는 서비스에게 사용자 데이타와 공동체 이름을 넘겨주는데 이는 데이타그램의 근원지와 목적지 수송계층 주소를 포함하고 있는 ASN.1 메세지 객체에 존재하고 있다.

이 엔티티는 다른 ASN.1 객체를 반환하거나, 인증 실패를 알린다. 후자의 경우에, 프로토콜 엔티티는 트랩을 발생하여 이런 실패를 알리고, 데이타그램을 버린다. 그리고 그 이상의 행동을 수행하지 않는다.

(4) 그리고, 프로토콜 엔티티는 ASN.1 PDU 객체에 대응하는 ASN.1 객체를 만들기 위해 인증 서비스로 부터 반환된 ASN.1 객체에 관한 기본적인 분석을 행한다.

분석이 실패하면, 데이타그램을 버리고 그 이상의 행동을 수행하지 않는다. 그렇지 않으면, 명명된 SNMP 공동체를 이용하여, 해당 프로화일이 선택되고, PDU가 그것에 따라서 처리된다. 이 처리의 결과로, 메세지가 반환된다면, 응답 메세지의 근원지 수송게층 주소가 원래 요청 메세지가 보내진 목적지 수송계층 주소와 동일해야 한다.

4.3.1.1 공통 구문

프로토콜의 여섯가지 PDU 유형을 소개하기 전에, 자주 사용되는 ASN.1 구문들을 살펴보는 것이 좋다.

-- 요청/응답 정보

RequestID ::=
INTEGER

ErrorStatus ::=
INTEGER {
noError(0),
tooBig(1),
noSuchName(2),
badValue(3),
readOnly(4),
genErr(5)
}

ErrorIndex ::=
INTEGER

-- 변수 결합

VarBind ::=
SEQUENCE {
name
ObjectName,
value
ObjectSyntax
}

VarBindList ::=
SEQUENCE OF
VarBind

RequestID는 응답을 받지않은 요청들을 구분하기 위해 사용된다. RequestID를 이용하여, SNMP 응용 엔티티는 요청들과 유입되는 응답을 서로 연관시킬 수 있다. 신뢰할 수 없는 데이타 그램 서비스가 사용되고 있는 경우에, RequestID는 또한 전산망에 의해 중복되는 메세지를 식별하는 간단한 수단을 제공한다.

ErrorStatus의 0이 아닌 실상(instance)은 요청이 처리되는 동안 발생된 예외 상황을 알리기 위해 사용된다. 이런 경우에, ErrorIndex는 예외 상황이 발생된 목록에 있는 변수를 알리므로써 추가 정보를 제공할 수 있다.

변수는 관리 객체의 실상(instance)을 언급한다. 변수 결합 VarBind는 변수와 해당변수 값의 쌍을 언급한다. VarBindList는 변수 명과 대응하는 값의 단순한 목록이다.

몇몇 PDU는 값이 아닌 변수 명에만 관계된다( 예를 들면, GetRequest-PDU ). 이런 경우에, 결합의 값 부분은 프로토콜 엔티티에 의해 무시된다. 그러나, 값 부분은 올바른 ASN.1 구문과 인코딩을 준수해야 한다.
ASN.1 값 NULL이 그런 결합의 값 부분을 위해 사용되도록 권고된다.

4.3.1.2 GetRequest-PDU

GetRequest-PDU의 형식은 다음과 같다.

GetRequest-PDU ::=
[0]
IMPLICIT SEQUENCE {
request-id
RequestID,

error-status -- 항상 0
ErrorStatus,

error-index -- 항상 0
ErrorIndex,

variable-bindings
VarBindList
}

GetRequest-PDU는 해당 SNMP 응용 엔티티의 요청시에만 프로토콜 엔티티에 의해 만들어진다. GetRequest-PDU를 받자마자, 수신 프로토콜 엔티티는 아래의 목록에 있는 적용가능한 법칙에 따라 응답한다.

(1) variable-bindings 필드에서 명명된 임의의 객체에 대해, 객체의 이름이 관련 MIB 영역에 있는 get 동작에 이용가능한 객체의 이름과 정확히 맞지 않는다면, 수신 엔티티는 error-status 필드의 값이 noSuchName이고 error-index 필드의 값이 수신 메세지에 있는 언급된 객체 이름 요소의 색인으로 할당되는 것을 제외하고는, 동일한 형식의 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

(2) variable-bindings 필드에서 명명된 임의의 객체에 대해, 객체가 복합적인 유형 (SMI에 정의된것처럼)이라면, 수신 엔티티는 error-status 필드의 값이 noSuchName이고 error-index 필드의 값이 수신 메세지에 있는 언급된 객체 이름 요소의 색인으로 할당되었다는 것을 제외하고는, 동일한 형식의
GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

(3) 아래와 같이 기술되므로써 만들어진 GetResponse-PDU의 크기가 국부적인 제한을 초과한다면, 수신 엔티티는 error-status 필드의 값이 tooBig이고 error-index 필드의 값이 0으로 할당되는 것을 제외하고는, 동일한 형식의 GetResponse-PDU 를 수신 메세지의 송신자에게 보낸다.

(4) variable-bindings 필드에서 명명된 임의의 객체에 대해, 객체의 값이 선행하는 법칙의 어떤 것에 의해 적용되지 않는 이유들로 인해 검색될 수 없다면, 수신 엔티티는 error-status 필드의 값이 genErr이고 error-index 필드의 값이 수신 메세지에 있는 언급된 객체 이름 요소의 색인으로 할당되는 것을 제외하고는, 동일한 형식의 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

선행하는 법칙들중 적용되는 것이 없다면, 수신 프로토콜 엔티티는 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다. 이때, 수신 메세지의 variable-binding 필드에서 명명된 각 객체에 대해,GetResponse-PDU의 대응하는 요소는 그 변수의 이름과 값이 나타낸다.

GetResponse-PDU의 error-status 필드의 값이 noError이고 error-index 필드의 값이 0이다.
GetResponse-PDU의 request-id 필드의 값은 수신 메세지의 것이다.

4.3.1.3 GetNextRequest-PDU

GetNextRequest-PDU의 형식은 PDU 유형의 지시값을 제외하고 GetRequest-PDU의 형식과
동일하다. ASN.1 언어로 다음과 같다.

GetNextRequest-PDU ::=
[1]
IMPLICIT SEQUENCE {
request-id
RequestID,

error-status -- 항상 0
ErrorStatus,

error-index -- 항상 0
ErrorIndex,

variable-bindings
VarBindList
}

GetNextRequest-PDU는 해당 SNMP 응용 엔티티의 요청시에만 프로토콜 엔티티에 의해 만
들어진다.
GetNextRequest-PDU를 받자마자, 수신 프로토콜 엔티티는 아래의 목록에 있는 적용가능한 법
칙에 따라 응답한다.

(1) variable-bindings 필드에 있는 임의의 객체 이름에 대해, 그 이름이 관련 MIB 영역에 있는 get 동작에 이용가능한 객체의 이름에 사전 순으로 선행하지 않으면, 수신 엔티티는 error-status 필드의 값이 noSuchName이고 error-index 필드의 값이 수신 메세지에 있는 언급된 객체 이름 요소의 색인으로 할당되는 것을 제외하고는, 동일한 형식의 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

(2) 아래와 같이 기술됨으로써 만들어진 GetResponse-PDU의 크기가 국부적인 제한을 초과한다면, 수신 엔티티는 error-status 필드의 값이 tooBig이고 error-index 필드의 값이 0으로 할당되는 것을 제외하고는, 동일한 형식의 GetResponse-PDU 를 수신 메세지의 송신자에게 보낸다.

(3) variable-bindings 필드에서 명명된 임의의 객체에 대해, 명명된 객체에 대한 사전 순으로 다음의 값이 선행하는 법칙의 어떤 것에 의해 적용되지 않는 이유들로 인해 검색될 수 없다면, 수신 엔티티는 error-status 필드의 값이 genErr 이고 error-index 필드의 값이 수신 메세지에 있는 언급된 객체 이름 요소의 색인으로 할당하는 것을 제외하고는, 동일한 형식의 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

선행하는 법칙들중 적용되는 것이 없다면, 수신 프로토콜 엔티티는 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다. 이때, 수신 메세지의 variable-binding 필드에서 각 이름에 대해, GetResponse-PDU의 대응하는 요소는 그 객체의 이름과 값을 나타낸다.

그 객체의 이름은 그 값에 대한 바로 다음 요소의 이름 필드 값과 더불어, 관련 MIB 영역에서는 get 동작에 이용가능한 모든 객체들의 이름이 사전 순으로 존재한다. GetResponse-PDU의 error-status 필드의 값이 noError이고 error-index 필드의 값이 0이다. GetResponse-PDU의 request-id 필드의 값은 수신 메세지의 것이다.

4.3.1.3.1 테이블 조회의 예

GetNextRequest-PDU의 한가지 중요한 이용은 MIB 내에 있는 개념적인 정보 테이블의 조회이다.
MIB에 있는 객체 유형 각각의 실상(instance)을 구별하기 위한 프로토콜에 특이한 메카니즘과 더불어 이런 유형의 SNMP 메세지의 의미는 마치 그것들이 테이블 구성을 하고 있는 것처럼 MIB에 있는 관련 객체에 대한 접근을 제공한다.

아래에 기술된 SNMP 교환에 의해, SNMP 응용 엔티티는 특정 전산망 요소의 경로선택 테이블에 있는 각 엔트리에 대한 목적지 주소와 다음 홉 게이트웨이를 추출한다. 이 경로선택 테이블이 세가지 엔트리를 갖는다고 가정하자.

목적지 다음 홉 메트릭

10.0.0.99 89.1.1.42 5
9.1.2.3 99.0.0.3 3
10.2.0.0.51 89.1.1.42 5

관리 스테이션은 요청된 변수 이름으로 지시된 OBJECT IDENTIFIER 값을 포함 하는 GetNextRequest-PDU를 SNMP 수행자에게 보낸다.

GetNextRequest ( ipRouteDest, ipRouteNextHop, ipRouteMetric1 )

SNMP 수행자는 GetResponse-PDU로 응답한다.

GetResponse ((ipRouteDest.9.1.2.3 = "9.1.2.3"),
(ipRouteNextHop9.1.2.3 = "99.0.0.3"),
(ipRouteMetric1.9.1.2.3 = 3 ))

관리 스테이션은 다음과 같이 계속한다.

GetNextRequest ((ipRouteDest.9.1.2.3,
ipRouteNextHop9.1.2.3,
ipRouteMetric1.9.1.2.3)

SNMP 수행자는 다음과 같이 응답한다.

GetResponse ((ipRouteDest.10.0.0.51 = "10.0.0.51"),
(ipRouteNextHop10.0.0.51 = "89.1.1.42"),
(ipRouteMetric1.10.0.0.51 = 5 ))

관리 스테이션은 다음과 같이 계속한다.

GetNextRequest ((ipRouteDest.10.0.0.51,
ipRouteNextHop.10.0.0.51,
ipRouteMetric1.10.0.0.51)

SNMP 수행자는 다음과 같이 응답한다.

GetResponse ((ipRouteDest.10.0.0.99 = "10.0.0.99"),
(ipRouteNextHop10.0.0.99 = "89.1.1.42"),
(ipRouteMetric1.10.0.0.99 = 5 ))

관리 스테이션은 다음과 같이 계속한다.

GetNextRequest ((ipRouteDest.10.0.0.99,
ipRouteNextHop.10.0.0.99,
ipRouteMetric1.10.0.0.99)

테이블에 그 이상의 엔트리가 없을 때, SNMP 수행자는 알려진 객체 이름의 사전순으로있는 다음의 객체들을 반환한다. 이 응답은 관리 스테이션에 경로선택 테이블의 끝임을 알린다.

4.3.1.4 GetResponse-PDU

GetResponse-PDU의 형식은 PDU 유형의 지시값을 제외하고 GetRequest-PDU의 형식과 동일하다.
ASN.1 언어로 다음과 같다.

GetResponse-PDU ::=
[2]
IMPLICIT SEQUENCE {
request-id
RequestID,

error-status
ErrorStatus,

error-index
ErrorIndex,

variable-bindings
VarBindList
}

GetResponse-PDU는 이 표준의 다른 곳에서 기술된 것처럼 GetRequest-PDU, GetNextRequest-PDU, 또는 SetRequest-PDU를 받자마자 프로토콜 엔티티에 의해 만들어진다.
GetResponse-PDU를 받자마자, 수신 프로토콜 엔티티는 그 내용을 SNMP 응용 엔티티에게 전달한다.

4.3.1.5 SetRequest-PDU

SetRequest-PDU의 형식은 PDU 유형의 지시값을 제외하고 GetRequest-PDU의 형식과 동일하다.
ASN.1 언어로 다음과 같다.

SetRequest-PDU ::=
[3]
IMPLICIT SEQUENCE {
request-id
RequestID,

error-status -- 항상 0
ErrorStatus,

error-index -- 항상 0
ErrorIndex,

variable-bindings
VarBindList
}

SetRequest-PDU는 해당 SNMP 응용 엔티티의 요청시에만 프로토콜 엔티티에 의해 만들어진다.
SetRequest-PDU를 받자마자, 수신 프로토콜 엔티티는 아래의 목록에 있는 적용가능한 법칙에따라 응답한다.

(1) variable-bindings 필드에서 명명된 임의의 객체에 대해, 그 객체가 관련 MIB 영역에 있는 set 동작에 이용가능하지 않다면, 수신 엔티티는 error-status 필드의 값이 noSuchName이고 error-index 필드의 값이 수신 메세지에 있는 언급된 객체 이름 요소의 색인으로 할당하는 것을 제외하고는, 동일한 형식의 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

(2) variable-bindings 필드에서 명명된 임의의 객체에 대해, 값 필드의 내용이 ASN.1 언어에 따라 변수에 필요로 되는 것과 일치된 유형, 길이, 그리고 값을 명시하지 않는다면, 수신 엔티티는 error-status 필드의 값이 badValue이고 error-index 필드의 값이 수신 메세지에 있는 언급된 객체 이름 요소의 색인으로 할당하는 것을 제외하고는, 동일한 형식의 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

(3) 아래와 같이 기술되므로써 만들어진 Get Response 유형 메세지의 크기가 국부적인 제한을 초과한다면, 수신 엔티티는 error-status 필드의 값이 tooBig이고 error-index 필드의 값이 0으로 할당되는 것을 제외하고는, 동일한 형식의 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

(4) variable-bindings 필드에서 명명된 임의의 객체에 대해, 명명된 객체의 값이 선행하는 법칙의 어떤 것에 의해 적용되지 않는 이유들로 인해 변경될 수 없다면, 수신 엔티티는 error-status 필드의 값이 genErr이고 error-index 필드의 값이 수신 메세지에 있는 언급된 객체 이름 요소의 색인으로 할당되는 것을 제외하고는, 동일한 형식의 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

선행하는 법칙들중 적용되는 것이 없다면, 수신 메세지의 variable-bindings 필드에 있는 명명된 각 객체에 대해, 대응하는 값이 변수에 할당된다. SetRequest-PDU에 의해 명시된 각 변수 할당은 마치 동일 메세지에 명시된 모든 다른 할당에 관해 동시에 설정하는 것처럼 되어야 한다.

수신 엔티티는 생성된 메세지의 error-status 필드 값이 noError이고 error-index 필드의 값이 0으로 할당되는 것을 제외하고 동일한 형식의 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

4.3.1.6 Trap-PDU

Trap-PDU의 형식은 다음과 같다.

Trap-PDU ::=
[4]
IMPLICIT SEQUENCE {
enterprise -- 트랩을 발생시키는 객체 유형

OBJECT IDENTIFIER, --[5]의 sysObjectID를 참조

agent-addr -- 트랩을 발생시키는 객체 주소
NetworkAddress,

generic-trap -- 일반 트랩 유형
INTEGER {
coldStart(0),
warmStart(1),
linkDown(2),
linkUP(3),
authenticationFailure(4),
egpNeighborLoss(5),
enterpriseSpecific(6)
},

specific-trap -- 일반-트랩이 enterpriseSpecific이 INTEGER, -- 아니더라도 specific-code는 존재

time-stamp -- 전산망 엔티티의 마지막 초기화와
TimeTicks, -- 트랩 생성 사이의 경과된 시간

variable-bindings -- "관심있는" 정보
VarBindList
}

Trap-PDU는 SNMP 응용 엔티티의 요청시에만 프로토콜 엔티티에 의해 생성된다. SNMP 응용 엔티티가 SNMP 응용 엔티티의 목적지 주소를 선택하는 수단은 구현하기 나름이다.
Trap-PDU를 받자마자, 수신 프로토콜 엔티티는 그 내용을 SNMP 응용 엔티티에게 전달한다
Trap-PDU의 variable-bindings 요소의 의미는 구현하기 나름이다.

4.3.1.6.1 coldStart 트랩

coldStart(0) 트랩은 송신 프로토콜 엔티티가 그 수행자의 구조 또는 프로토콜 엔티티 구현이
변경될 수 있기 위해 스스로 재초기화하고 있는 것을 알린다.

4.3.1.6.2 warmStart 트랩

warmStart(1) 트랩은 송신 프로토콜 엔티티가 그 수행자의 구조 또는 프로토콜 엔티티 구현이 변경되지 않고 스스로 재초기화하고 있는 것을 알린다.

4.3.1.6.3 linkDown 트랩

linkDown(2) 트랩은 송신 프로토콜 엔티티가 그 수행자의 구조에 나타나는 통신 연결의 하나가 고장임을 인식하고 알리는 것이다. linkDown 형태의 Trap-PDU는 variable-bindings의 첫번째 구성요소로서 영향을 받은 인터페이스에 대한 ifIndex 실상(instance)의 이름과 값을 포함한다.

4.3.1.6.4 linkUp 트랩

linkUp(3) 트랩은 송신 프로토콜 엔티티가 그 수행자의 구조에 나타나는 통신 연결의 하나가 발생하였음을 인식하고 알리는 것이다. linkUp 형태의 Trap-PDU는 variable-bindings의 첫 번째 구성요소로서 영향을 받은 인터페이스에 대한 ifIndex 실상(instance)의 이름과 값을 포함한다.

4.3.1.6.5 authenticationFailure 트랩

authenticationFailure(4) 트랩은 송신 프로토콜 엔티티가 부당하게 인증된 프로토콜 메세지의 주소임을 알린다. SNMP 구현이 이 트랩을 생성할 수 있어야만 하는 반면, 구현에 의존적인 메카니즘을 통한 트랩의 발생을 저지할 수 있어야만 한다.

4.3.1.6.6 egpNeighborLoss 트랩

egpNeighborLoss(5) 트랩은 송신 프로토콜 엔티티가 동위 EGP였던 EGP 이웃 노드가 고장난 것으로 나타나고 더 이상 동위 관계를 얻을 수 없는 것을 알린다.

egpNeighborLoss 형태의 Trap-PDU는 variable-bindings의 첫번째 구성요소로서 영향을 받는 이웃 노드에 대한 egpNeighAddr 실상(instance)의 이름과 값을 포함한다.

4.3.1.6.7 enterpriseSpecific 트랩

enterpriseSpecific(6) 트랩은 송신 프로토콜 엔티티가 어떤 회사에 특정한 사건이 발생했음을 인식하고 알린다. 이 특정 트랩 필드는 발생한 특정 트랩을 식별한다.

4.4 정의

RFC1157-SNMP DEFINITIONS ::= BEGIN

IMPORTS
ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
FROM RFC1155-SMI;

-- top-level message

Message ::=
SEQUENCE {
version -- 이 RFC의 버젼-1
INTEGER {
version-1(0)
},
community
OCTET STRING, -- 공동체명

data -- 일상적인 인증이 사용된
ANY -- PDUs
}

-- 프로토콜 데이타 단위

PDUs ::=
CHOICE {
get-request
GetRequest-PDU,

get-next-request
GetNextRequest-PDU,

get-response
GetResponse-PDU,

set-request
SetRequest-PDU,

trap
Trap-PDU
}

-- PDUs

GetRequest-PDU ::=
[0]
IMPLICIT PDU

GetNextRequest-PDU ::=
[1]
IMPLICIT PDU

GetResponse-PDU ::=
[2]
IMPLICIT PDU

SGetRequest-PDU ::=
[3]

IMPLICIT PDU

PDU ::=
SEQUENCE {
request-id
INTEGER,

error-status -- 때로는 무시된다.
INTEGER {
noError(0),
tooBig(1),
noSuchName(2),
badValue(3),
readOnly(4),
genErr(5)
},

error-index -- 때로는 무시된다.
INTEGER,

variable-bindings -- 값은 때로 무시된다.
VarBindList
}

Trap-PDU ::=
[4]
IMPLICIT SEQUENCE {
enterprise -- 트랩을 생성하는 객체 유형
OBJECT IDENTIFIER, -- [5]의 sysObjectID 참조

agent-addr -- 트랩을 생성하는 객체 주소
NetworkAddress,

generic-trap --일반 트랩 유형
INTEGER {
coldStart(0),
warmStart(1),
linkDown(2),
linkUp(3),
authenticationFailure(4),
egpNeighborLoss(5),
enterpriseSpecific(6)
},

specific-trap
INTEGER,

time-stamp
TimeTicks,

variable-bindings
VarBindList
}

-- variable bindings

VarBind ::=
SEQUENCE {
name
ObjectName,
value
ObjectSyntax
}
VarBindList ::=
SEQUENCE OF
VarBind
END

4.5 참고 문헌

[1] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, IAB, April 1988.

[2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", RFC 1065, TWG, August 1988.

[3] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1066, TWG, August 1988.

[4] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC1109, IAB, August 1989.

[5] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", RFC 1155, Performance Systems International and Hughes LAN Systems, May 1990.

[6] McCloghrie, K. and M. Rose, "Management Information Base for TCP/IP-based internets", RFC 1156, Hughes LAN Systems and Performance Systems International, May 1990.

[7] Case, J., M. Fedor, M. Schoffstall, and J. Davin, "A Simple Network Management Protocol", Internet Engineering Task Force working note, Network Information Center, SRI International, Menlo Park, California, March 1988.

[8] Davin, J., J. Case, M. Fedor, and M. Schoffstall, "A Simple Gateway Monitoring Protocol", RFC 1028, Proteon, University of Tennessee at Knoxville, Cornell University, and Rensselaer Polytechnic Institute, November 1987.

[9] Information porcessing systems - Open Systems Interconnection, "Specification of Abstract Syntax Notation One(ASN.1)", International Organization for Standardization, International Standard 8824, December 1987.

[10] Information porcessing systems - Open Systems Interconnection, "Specification of Basic Encoding Rules for Abstract Syntax Notation One(ASN.1)", International Organization for Standardization, International Standard 8825, December 1987.

[11] Postel, J., "User Datagram Protocol", RFC 768, USC/Information Sciences Institure, November 1980.

제 5 장 TCP/IP 기반 연결망(internets)을 위한 관리 정보의 구조(SMI)

5.1 개요

관리정보구조 표준은 TCP/IP를 기반으로 하는 연결망(internets)을 관리하는데 사용되는 관리정보의 정의를 위한 공통 구조와 식별 기법을 기술한다. 관리 정보를 기술하기 위한 포괄적 유형의 집합과 전산망 관리를 위한 객체 정보 모델의 기술이 포함된다. 구조의 공식적 기술은 추상 구문 표기법 1(Abstract Syntax Notation One : ASN.1)[1]을 사용한다.

이 표준은 조직적인 관계와 행정적 정책에 주로 관여한다. 즉, 관리되는 객체 및 객체를 관리하기 위해 사용하는 프로토콜은 이 표준에서 다루지 않는다. 이런 것들은 두개의 관련 표준에 의해 설명된다.

하나는 관리 정보 베이스(MIB)를 기술한 표준[2]이며, 다른 하나는 단순 전산망 관리 프로토콜(SNMP)을 기술한 표준[3]이다.
관리정보구조 표준의 목적은 단순성과 확장성을 달성하는 것이다. 이 두 목적은 공통 문제에 의해 동기부여 되었다. 즉, 간단한 SMI를 제안하므로써 앞으로의 잠재적 기법에 부과되는 제약을 최소화한다. 더우기, 확장가능한 SMI를 작성하므로써 가능한한 많은 수의 잠재적 기법이 실험에 이용될 수 있다.

본 관리정보구조 표준과 관련된 문서는 "인터네트(Internet) 전산망 관리 표준의 개발을 위한 IAB 권고안", RFC 1052 [5]와 "전산망 관리 특수(Ad Hoc) 검토 그룹의 두번째 보고", RFC 1109 [6]에서 발표된 지침서 등이 있다. 특히, 우리는 관리 정보 베이스를 기술하는 표준과 더불어 이 표준은 인터네트(Internet)의 전산망 관리를 위한 확고한 기초를 제공한다고 생각한다.

5.2 관리 정보의 구조와 식별

관리 객체(Managed Objects)들은 관리 정보 베이스 또는 MIB로 불리는 가상 정보 저장소를 통해 접근된다. MIB에 있는 객체들은 추상 구문 표기법 1 (ASN.1)을 사용해서 정의된다[1].
각 객체의 유형(객체 유형이라 불리우는)은 이름, 구문, 부호를 갖는다. 이름은 OBJECT DENTIFIER로유일하게 표현된다. OBJECT IDENTIFIER는 행정적으로 할당되는 이름이다. 이름을 할당하는데 사용되는관리 방법은 이 표준의 끝부분에서 논의된다.

객체 유형의 구문은 객체 유형에 대응하는 추상 자료 구조를 정의한다. 예를 들면, 주어진 객 체 유형의 구조는 INTEGER 또는 OCTET STRING일 수 있다. 일반적으로, 객체 유형의 구문을 정의하는데 사용되는 모든 이용가능한 ASN.1 구성요소를 허락할 수 있으나, 이 표준에서는 사용될 수 있는 ASN.1 구성을 의도적으로 제한하고 있다. 이런 제한은 단지 단순성을 지원하기 위한 것이다.

객체 유형의 부호화(encoding)는 단순히 객체 유형 실상(instance)들이 객체 유형 구문을 사용 하여 어떻게 표현되는 가를 의미한다. 객체의 구문과 부호화 개념은 객체가 전산망에서 전송될 때 표현되는 방법을 암시한다. 이 표준은 ASN.1의 BER(Basic Encoding Rules)을 이용하여 명시한다[7].

5.2.1 이름

이름은 관리 객체를 식별하기 위해 사용된다. 이 표준은 이름을 명명할때 계층적인 구조를 명시하고 있다. OBJECT IDENTIFIER 개념은 계층적인 이름을 구현하기 위해 사용된다.

OBJECT IDENTIFIER는 관리 객체 유형을 명명하는 것 이외에 사용될 수도 있다. 예를 들면, 여러 국제 표준안들의 식별을 위해 OBJECT IDENTIFIER를 할당받을 수 있다. 단순히 OBJECT IDENTIFIER는 객체에 연관된 의미(예, 전산망 객체, 표준 문서 등)와는 무관하게 객체를 식별하는 수단이다.

OBJECT IDENTIFIER는 전체 트리를 조회하는 정수들의 나열이다. 이 트리는 에지(edge)를 통해서 여러개의 레이블된 노드와 연결된 루트노드로 구성되었다. 각 노드는 차례로 레이블되는 자신들의 후손노드들을 갖는다. 이 경우에, 그 노드를 서브트리라 한다. 이 과정은 임의의 깊이 수준까지 계속될 수 있다. OBJECT IDENTIFIER 개념의 핵심은 노드들에 할당되는 의미의 관리적 제어가 트리를 조회할 때 위임될 수 있다는 것이다. 레이블은 간단한 문자열과 정수의 쌍이다.

루트 노드 자체는 레이블되지 않지만 바로 세개의 후손노드들을 갖는다: 한 노드는 레이블 iso(1)로서 국제표준화기구에 의해 관리된다. 두번째 노드는 레이블 ccitt(0)로서 국제전신전화자 문위원회에 의해 관리된다. 세번째 노드는 joint-iso-ccitt(2)로서 ISO와 CCITT에 의해 연합 관리된다.

iso(1) 노드 하에 있는 ISO는 다른 국제조직에 의해 사용되는 하나의 서브트리, org(3)를 사용한다. 현재 후손 노드들 중 두개의 노드는 U.S. NIST에 의해 할당된다. 이 서브트리 중 하나 인 dod(6)는 NIST에 의해 미 국방성에게 양도되었다.

현재 이 표준에서, DoD(Department of Defense)는 그의 서브트리를 관리하는 방법을 지시하지는 않는다. 이 표준은 DoD가 다음과 같이 IAB에 의해 관리되기 위해 인터네트 공동체에게 한 노드를 할당할 것으로 가정한다.

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

다시 말해서, OBJECT IDENTIFIER인 인터네트 서브트리는 다음 접두사로 시작한다:

1.3.6.1.

IAB에 의해 승인된 표준안으로, 이 표준은 OBJECT IDENTIFIER 서브트리가 관리되는 방법을 명시한다.
시작 부분에 네개의 노드가 존재한다.

이는 다음과 같다.

directory OBJECT IDENTIFIER ::= { internet 1 }
mgmt OBJECT IDENTIFIER ::= { internet 2 }
experimental OBJECT IDENTIFIER ::= { internet 3 }
private OBJECT IDENTIFIER ::= { internet 4 }

5.2.1.1 디렉토리(Directory)

서브트리 directory(1)은 OSI 디렉토리가 인터네트에서 어떻게 사용될 수 있는 가를 논의할 표준에 사용된다.

5.2.1.2 Mgmt

서브트리 mgmt(2)는 IAB에서 승인한 문서에 정의된 객체들을 식별하기 위해 사용된다.
서브트리 mgmt(2)의 관리는 IAB에 의해 IANA(Internet Assigned Numbers Authority)에 위임된다. 인터네트 표준 관리 정보 베이스의 새 버젼을 정의하는 RFC들이 승인될 때, 그 문서에 의해 정의된 객체들을 식별하기 위해 IANA가 OBJECT IDENTIFIER를 할당한다.

예를 들면, 초기 인터네트 표준 MIB를 정의하는 RFC는 관리 문서 번호 1이 할당된다. 이 RFC는 인터네트 표준 MIB를 정의하는 OBJECT IDENTIFIER로 { mgmt 1 } 또는 1.3.6.1.2.1 을 사용한다.

인터네트 표준 MIB의 새 버젼은 정밀한 과정을 거쳐 출현한다. 이 표준의 5절은 새 버젼이 정의될 때 사용되는 법칙들을 기술한다.

5.2.1.3 Experimental

서브트리 experimental(3)은 인터네트 실험에 사용되는 객체들을 식별하는데 사용된다. 이 서브트리의 관리는 IAB에 의해서 인터네트의 IANA에게 위임된다.
예를 들면, 실험자는 번호 17을 받고, 이용가능한 OBJECT IDENTIFIER로 { experimental 17 } 또는 1.3.6.1.3.17
을 갖는다.

할당 과정의 부분으로, IANA는 서브트리가 어떻게 사용되는가에 관한 요구조건을 만들 수 있다.

5.2.1.4 Private

서브트리 private(4)는 단독으로 정의된 객체들을 식별하는데 사용된다. 이 서브트리의 관리는 IAB에 의해 IANA(Internet Assigned Numbers Authority)에게 위임된다. 처음에, 이 서브트리는 다음과 같이 적어도 하나의 후손을 갖는다.

enterprises OBJECT IDENTIFIER ::= { private 1 }

서브트리 enterprises(1)은 전산망 서브시스템을 제공하는 회사들이 그들의 상품 모델을 등록하도록 허락하기 위해 사용된다.
예를 들면, 기업은 서브트리를 받자마자 이 서브트리에 새로운 MIB 객체들을 정의할 수 있다.

게다가, 관리 프로토콜에 사용될 확실한 식별 메카니즘을 제공하기 위해 기업이 이 서브트리에 그의 네트워킹 서브시스템들을 등록하도록 권고된다. 예를 들면, "Flintstones, Inc." 기업이 전산망 서브시스템을 생산하였다면, 그들은 IANA로 부터의 enterprises 서브트리 하에 노드를 요구할 수 있다. 그런 노드는 다음과 같이 번호가 붙는다.

1.3.6.1.4.1.42

"Flintstones, Inc." 기업은 그들의 "Fred Router"를 다음과 같이 등록할 수 있다.

1.3.6.1.4.1.42.1.1

5.2.2 구문

구문은 객체 유형에 대응하는 구조를 정의하는데 사용된다. ASN.1 조립형은 ASN.1의 완전한 일반성이 허락되지 않을 지라도 이 구조를 정의하기 위해 사용된다.
ASN.1 유형 ObjectSyntax는 객체 유형을 정의하는데 사용될 수 있는 다른 구문들을 정의한다.

5.2.2.1 프리미티브 유형

ASN.1 프리미티브 유형으로 INTEGER, OCTET STRING, OBJECT IDENTIFIER, NULL이 가능하다. 이것들은 단일 유형으로 일컫는다.

5.2.2.1.1 열거형 INTEGER에 대한 지침

열거형 INTEGER가 객체 유형으로 나열된다면, 0의 값이 열거 리스트에 존재해서는 안된다.
이 값의 사용은 금지되어 있다.

5.2.2.2 조립형 유형

ASN.1 조립형 유형인 SEQUENCE가 테이블이나 리스트를 만들기 위해 사용 가능하다.
리스트의 구문은 다음과 같은 형태를 취한다:

SEQUENCE { , ..., }

각 은 위에서 나열된 ASN.1 프리미티브 유형 중 하나가 된다. 더우기, 이 ASN.1 유형들은 항상 존재한다 (DEFAULT와 OPTIONAL 절은 SEQUENCE 정의에 나타나지 않는다).
테이블의 구문은 다음과 같은 형태를 취한다.

SEQUENCE OF 는 리스트 조립형이 된다.
리스트들과 테이블들은 집합 유형으로 일컫는다.

5.2.2.3 정의된 유형

추가적으로, 응용 분야의 유형이 정의될 수 있다. 그것들은 잠재적으로 정의된 ASN.1 프리미 티브 유형, 리스트, 테이블, 또는 다른 응용 분야에 사용할 수 있는 유형으로 설명된다.

처음에 는, 거의 응용 분야에 사용할 수 있는 유형이 정의되지 않는다. 앞으로의 문서에서는 일단 합의만 되면 다른 것들을 정의할 것이다.

5.2.2.3.1 NetworkAddress

CHOICE는 여러 프로토콜 부류 중 하나인 주소를 표현한다. 현재, 유일한 프로토콜 부류인 인터네트 부류만이 CHOICE에 존재한다.

5.2.2.3.2 IpAddress

이 응용분야의 유형은 32-비트 연결망 주소를 표현한다. 그것은 길이가 4인 OCTET STRING 으로 전산망 바이트 순(network byte-order)으로 표현된다.
이 ASN.1 유형이 ASN.1 BER을 사용하여 부호화될 때, 프리미티브 부호 형태만이 사용되어야 한다.

5.2.2.3.3 Counter

이 응용 분야의 유형은 최대값이 될 때까지 단조롭게 증가하는 음이 아닌 정수를 표현한다.
최대값에 이르면 영(0)부터 다시 증가하기 시작한다. 이 문서는 Counter의 최대치로 2^32-1
(4294967295 십진수)을 명시하고 있다.

5.2.2.3.4 Gauge

이 응용 분야의 유형은 증가하거나 감소할 수 있는 음이 아닌 정수를 표현한다. 그러나 최대 치에서 정지된다. 이 문서는 Gauge의 최대치로 2^32-1 (4294967295 십진수)을 명시하고 있다.

5.2.2.3.5 TimeTicks

이 응용 분야의 유형은 어떤 시기이래로 백분의 1초 단위로 시간을 세는 음이 아닌 정수를 나타낸다.

객체 유형이 이 ASN.1 유형을 사용해서 MIB에 정의될 때 객체 유형은 참조 시기를 식별한다.

5.2.2.3.6 Opaque

이 응용 분야의 유형은 임의의 ASN.1 구문을 통과하기 위한 능력을 지원한다. 값은 ASN.1 BER을 사용하여 옥테트들의 나열로 부호화된다. 차례로, 이것은 OCTET STRING으로 부호화 된다.

실제로, 원래 ASN.1 값을 이중으로 감싸는 것과 같다. 구현시 지킬 것은 단지 불투명하게 부호화된 자료를 받아서 인식하면 된다. 그것은 자료를 복호화할 필요는 없고 내용을 해석하면 된다.

더우기, ASN.1 이외의 부호화는 ASN.1 EXTERNAL 유형을 이용하여, 불투명하게 부호화된 자료에 사용될 수 있다.

5.2.3 부호화

일단 객체 유형의 실상(instance)가 식별되면, 그것의 값은 객체 유형을 위한 구문에 ASN.1 BER을 적용하여 전송될 수 있다.

5.3 관리 객체

MIB 내의 객체들을 정의하는 것이 본 표준의 목적이 아니라, 이 표준은 이런 객체들을 정의하는 다른 표준들에 의해 사용되는 형식을 명시한다.
객체 유형 정의는 다섯개의 필드로 구성된다.

객체(OBJECT):
객체 기술자(OBJECT DESCRIPTOR)라 불리는 객체 유형의 문자열과 이에 대응하는 OBJECT IDENTIFIER

구문(SYNTAX):
객체 유형의 추상 구문.
이것은 ASN.1 유형 ObjectSyntax의 실상(instance)가 되어야 한다.

정의(Definition):
객체 유형의 의미를 나타내는 설명을 기술.

이 MIB는 많은 기업체의 제품이 운영되는 환경에서 사용되므로 구현은 객체의 실상(instance)이 이 정의를 이행하는 것을 보장해야 한다. 그와 같이 객체들 이 모든 장비에서 일관된 의미를 갖는 것은 중요하다.

접근(Access):
읽기전용, 읽기쓰기, 쓰기전용, 또는 접근금지 중 하나

상태(Status):
필수사항, 선택사항, 폐지사항 중 하나

앞으로의 표준은 그들이 정의한 객체들의 다른 필드를 역시 명시할 수 있다.

5.3.1 객체 이름에 대한 지침

인터네트 표준 MIB의 객체 유형은 이름 내에 부식별자 0을 사용해서는 안된다. 이 값은 앞으로의 확장을 위해 예약된다.
인터네트 표준 MIB에 있는 객체 유형에 대응하는 각 객체 기술자는 유일하면서 기억하기 쉬운 인쇄 가능한 스트링이어야 한다. 이것은 사람들이 MIB를 논의할 때 사용하기 위한 공통 언어를 장려하고 사용자 인터페이스를 위해 간단한 테이블 매핑을 돕는다.

5.3.2 객체 유형과 실상(instance)

객체 유형은 관리 객체 정의이다. 실제로 그것은 선언이다. 이와 대조적으로, 객체 실상 (instance)은 객체 유형이 값을 갖게되는 것 즉, 객체 유형의 실상(instance)이다. 예를 들면, 경로설정 테이블에 존재하는 엔트리 개념은 MIB에 정의되어야 한다. 그런 개념은 객체 유형에 해당한다

그러나,어느순간에 존재하는 특정 경로설정 테이블의 각각의 엔트리들은

그객체유형의객체실상(instance)이다.
객체 유형의 집합은 MIB에 정의된다. 각각의 객체 유형은 객체 식별자로 유일하게 명명되고, 그것의 객체 기술자인 이름을 갖는다. 객체 실상(instance)들이 참조되는 수단은 MIB에 정의되지 않는다. 객체실상(instance)들에 대한 참조는 프로토콜 특정 메카니즘에 의한다.

즉, 그것은 이 메카니즘을 정의하는 SMI를 준수하는 각 관리 프로토콜의 책임이다.
객체 유형의 실상(instance)이 "하위" 객체 유형의 실상(instance)에 의해 표현되는 정보의 집합을 나타내는 MIB에 객체 유형이 정의될 수 있다.

예를 들면, 다음의 객체 유형들이 MIB에 정의된다고 가정해보자:

객체:
atIndex { atEntry 1 }

구문:
INTEGER

정의:
실제 주소에 관한 인터페이스 번호

접근:
읽기쓰기

상태:
필수사항

객체:
atPhysAddress { atEntry 2 }

구문:
OCTET STRING

정의:
매체 의존적인 실제 주소

접근:
읽기쓰기

상태:
필수사항

객체:
atNetAddress { atEntry 3 }

구문:
NetworkAddress

정의:
매체 의존적인 실제 주소에 대응하는 전산망 주소

접근:
읽기쓰기

상태:
필수사항

그러면, 네번째 객체 유형은 또한 MIB에 정의된다.

객체:
atEntry { atTable 1 }

구문:
AtEntry ::= SEQUENCE {
atIndex
INTEGER,
atPhysAddress
OCTET STRING,
atNetAddress
NetworkAddress
}

정의:
주소 번역 테이블의 엔트리

접근:
읽기쓰기

상태:
필수사항

이 객체 유형의 각 실상(instance)은 이전의 세 객체 유형의 실상(instance)에 의해 표현되는 정보를 포함한다. 이런 방식으로 정의된 객체 유형을 리스트라 한다.
유사하게, 테이블은 리스트 유형의 집합에 의해 형성될 수 있다. 예를 들면, 다섯번째 객체 유형은 MIB에 정의된다.

객체:
atTable { at 1 }

구문:
SEQUENCE OF AtEntry

정의:
주소 번역 테이블

접근:
읽기쓰기

상태:
필수사항

atTable 객체의 각 실상(instance)은 주어진 atTable 객체 실상(instance) 즉, 주어진 주소 번역 테이블을 구성하는 atEntry 객체 유형의 집합에 의해 표현되는 정보를 포함한다.
테이블 내의 간단한 객체를 어떻게 참조하는지 고려해보자. 이전의 예제에서, 연속해서 객체 유형

{ atPhysAddress } 를 명명하고 프로토콜 특정 메카니즘을 이용하여 객체 실상(instance)

{ atNetAddress } = { internet "10.0.0.52" }
을 명시한다.

이 객체 유형과 객체 실상(instance)의 쌍은 관련된 atNetAddress 값이 { internet "10.0.0.52" }인 주소 번역 테이블에 있는 엔트리 부분인 atPhysAddress의 모든 실상(instance)을 참조한다.

이 예제에 계속해서, 테이블 내의 집합 객체를 어떻게 참조하는지 고려해보자.
객체 유형
{ atEntry }
을 명명하고, 특정 프로토콜 메카니즘을 사용하여 객체 실상(instance)

{ atNetAddress } = { internet "10.0.0.52" }

을 명시하는 것은 관련된 atNetAddress 값이 { internet "10.0.0.52" }인 테이블에 있는 엔트리들 의 모든 실상(instance)을 참조한다.

각 관리 프로토콜은 단순한 객체 유형에 접근하는 메카니즘을 제공해야 한다. 각 관리 프로토콜은 집합 객체 유형에 대한 접근을 지원하는 지를 명시한다. 더우기, 프로토콜은 객체 유형과 실상(instance) 쌍이 하나의 유형에 대한 여러개의 실상(instance)을 참조할 때 "반환되는" 실상 (instance)들을 명시해야 한다.

다양한 관리 프로토콜에 대한 지원을 제공하기 위해, 주어진 객체 유형의 실상(instance)들을 훌륭히 식별시킬 수 있는 정보는 MIB에 정의된 객체 유형의 실상(instance)들에 의해 표현된다.

5.3.3 관리 객체를 위한 매크로

MIB 정의를 처리하는 도구의 이용을 손쉽게 하기 위해 객체-유형 매크로가 사용될 수 있다.
이 매크로는 객체 유형의 중요한 점들이 형식적인 방법으로 표현되도록 한다.

객체-유형 매크로 ::=
시작
유형 표기 ::= "구문" 유형 (유형 ObjectSyntax)
"접근" 접근
"상태" 상태
값 표기 ::= 값 (값 ObjectName)

끝

처음에 정의된 객체 유형이 주어진다면, 우리는 MIB에 존재하는 다음의 정의들을 상상할 수 있다.

atIndex 객체-유형
구문 INTEGER
접근 읽기쓰기
상태 필수사항
::= { atEntry 1 }

atPhysAddress 객체-유형
구문 OCTET STRING
접근 읽기쓰기
상태 필수사항
::= { atEntry 2 }

atNetAddress 객체-유형
구문 NetworkAddress
접근 읽기쓰기
상태 필수사항
::= { atEntry 3 }

atEntry 객체-유형
구문 AtEntry
접근 읽기쓰기
상태 필수사항
::= { atTable 1 }

atTable 객체-유형
구문 SEQUENCE OF AtEntry
접근 읽기쓰기
상태 필수사항
::= { at 1 }

AtEntry ::= 객체-유형 {
atIndex
INTEGER,
atPhysAddress
OCTET STRING,
atNetAddress
NetworkAddress
}

처음의 다섯가지 정의는 예를 들어, 객체 기술자 atIndex에 관계된 객체 식별자 { atEntry 1 } 객체 유형을 기술한다. 게다가, 이 객체의 구문은 가능한 접근 (읽기쓰기)과 상태 (필수사항) 와 (INTEGER)로 정의된다. 여섯번째 정의는 AtEntry라 불리는 ASN.1 유형을 기술한다.

5.4 MIB 확장

모든 인터네트 표준 MIB 문서는 이전의 문서를 폐지시킨다.

객체 식별자

{ mgmt version-number }

다음에 나오는 객체를 명명하기 위해 사용되는 꼬리라 불리는 이름 부분은 버젼들 간에 바뀌어서는 안된다. 새로운 버젼은

(1) 구식 객체 유형을 폐지로 선언하지만 그들의 이름은 제거하지 않는다.

(2) 리스트 내에 있는 객체 유형에 단순 유형이 추가되면서 리스트에 대응하는 객체 유형의 정의를 확장한다. 또는,

(3) 완전히 새로운 객체 유형을 정의한다.

새로운 버젼들은 (1) 그 객체 이름을 바꾸지 않고 이전에 정의된 객체의 의미를 바꿀 수 없다.

이런 법칙들은 그들이 인터네트 표준 MIB의 많은 버젼들에 대한 좀 더 용이한 지원을 허용하므로 중요 하다. 특히, 이름의 꼬리에 연관된 의미는 MIB의 다른 버젼들을 통해 일정하게 남는다.

MIB의 많은 버젼들은 "꼬리 공간"에서 동시에 일어날 수 있으므로 MIB의 다양한 버젼을 지원하는 구현은 단순화될 수 있다.
그러나, 결과적으로 관리 수행자는 예상되는 객체 유형의 모집합에 대응하는 실상(instance)을 반환한다.

이런 예외적인 경우에, 확고한 원칙에 따라, 관리자는 예상되는 객체 유형의 정의를 넘어선 어떤 추가적인 정보를 무시해야 한다. 그러나, 확고한 원칙은 제어 행위에 관한 실행 보호 조치가 필요하다.

즉, 실상(instance)이 그의 예측된 객체 유형과 같은 구문을 갖지 않는다면, 그런 제어 행동은 실행되지 않아야 한다. 감시와 제어의 경우, 동작에 의해 반환되는 객체의 이름은 동작에 의해 요구된 이름과 같아야 한다.

5.5 정의

RFC1155-SMI 정의 ::= 시작

EXPORTS -- 모든 것
internet, directory, mgmt, experimental, private, enterprises,
OBJECT-TYPE, ObjectName, ObjectSyntax, SimpleSyntax,

ApplicationSyntax, NetworkAddress, IpAddress, Counter, Gauge,
TimeTicks, Opaque;

-- 루트로 부터의 경로

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

directory OBJECT IDENTIFIER ::= { internet 1 }

mgmt OBJECT IDENTIFIER ::= { internet 2 }

experimental OBJECT IDENTIFIER ::= { internet 3 }

private OBJECT IDENTIFIER ::= { internet 4 }

enterprises OBJECT IDENTIFIER ::= { private 1 }

-- 객체 유형의 정의

객체-유형 매크로 ::= 시작
유형 표기 ::= "구문" 유형 (유형 ObjectSyntax)
"접근" 접근
"상태" 상태
값 표기 ::= 값 (값 ObjectName)

끝

-- MIB 내의 객체 이름

ObjectName ::=
OBJECT IDENTIFIER

-- MIB 내의 객체 구문

ObjectSyntax ::=
CHOICE {
simple
SimpleSyntax,

-- 간단한 SEQUENCE는 단순성을 유지하기 위해 여기에서 직접 언급되지 않았다.
그러나, 간단한 SEQUENCE로 암시적으로 부호화되는 응용 분야에 사용할 수 있는 유형은 다음의 CHOICE에 나타날 수 있다.

application-wide
ApplicationSyntax
}

SimpleSyntax ::=
CHOICE {
number
INTEGER,
string
OCTET STRING,
object
OBJECT IDENTIFIER,
empty
NULL
}

ApplicationSyntax ::=
CHOICE {
address
NetworkAddress,
counter
Counter,
gauge
Gauge,
ticks
TimeTicks,
arbitrary
Opaque

-- 그들이 정의된 것처럼, 다른 응용 분야에 사용할 수 있는 유형은 여기에 추가 될 수있다
}

NetworkAddress ::=
CHOICE {
internet
IpAddress
}

IpAddress ::=
[APPLICATION 0] -- 전산망-바이트 순으로
IMPLICIT OCTET STRING (SIZE (4))

Counter ::=
[APPLICATION 1]
IMPLICIT INTEGER (0..4294967295)

Gauge ::=
[APPLICATION 2]
IMPLICIT INTEGER (0..4294967295)

TimeTicks ::=
[APPLICATION 3]
IMPLICIT INTEGER (0..4294967295)

Opaque ::=
[APPLICATION 4] -- 임의의 ASN.1 값,
IMPLICIT OCTET STRING -- "이중-봉쇄"

끝

5.6 참고 문헌

[1] Information porcessing systems - Open Systems Interconnection, "Specification of Abstract Syntax Notation One(ASN.1)", International Organization for Standardization, International Standard 8824, December 1987.

[2] McCloghrie, K. and M. Rose, "Management Information Base for TCP/IP-based internets", RFC 1156, Hughes LAN Systems and Performance Systems International, May 1990.

[3] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple Network Management Protocol", RFC 1157, University of Tennessee at Knoxville, Performance Systems International, and the MIT Laboratory for COmputer
Science, May 1990.

[4] LaBarre, L., "Structure and Identification of Management Information for the Internet", Internet Engineering Task Force working note, Network Information Center, SRI International, Menlo Park, California, April 1988.

[5] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, IAB, April 1988.

[6] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC 1109, IAB, August 1989.

[7] Information porcessing systems - Open Systems Interconnection, "Specification of Basic Encoding Rules for Abstract Syntax Notation One(ASN.1)", International Organization for Standardization, International Standard 8825, December 1987.

제 6 장 TCP/IP 기반 연결망의 전산망관리를 위한 관리 정보 베이스 (MIB-II)

6.1 개요

이 표준은 TCP/IP를 기반으로 하는 연결망(internets)의 전산망 관리 프로토콜을 이용한 관리 정보 베이스의 두번째 버젼을 정의한다.
단기적으로 간단하게 운용할 수 있는 시스템들을 만들기 위한 IAB 전략과 일치하여 여기에서 정의된 관리 객체들의 리스트는 필수적으로 고려되는 요소들만을 채택하는 것으로 유래되었다.

필수적인 객체들만을 채택하는 방법은 제한하지 않는다. 왜냐하면, 관련 문서에 정의된 SMI는 세 개의 확장 메카니즘을 제공하기 때문이다.

첫째, MIB의 새로운 버전 정의를 통한 새로운 표준 객체들의 추가 이다.

둘째, 실험 서브트리를 통하여 다방면에 이용가능하지만 비표준인 객체들의 추가이다.

셋째, 기업 서브트리를 통한 사적인 객체들의 추가이다. 추가된 그런 객체들은 특정 업체의 요소들 뿐아니라 다른객체들에 필수적인 지식에 요구되는 실험에도 사용될 수 있다.
MIB-II의 설계는 첫번째 확장 메카니즘에 의해 많은 영향을 받았다. 여러 새로운 변수들은 운
영 경험과 요구사항들을 기반으로 추가되었다. 이런 것을 기반으로, MIB-II에 있는 객체들을
포함하는 기준은 MIB-I의 기준과 매우 유사하다.

즉, 다음과 같다.

(1) 장애 또는 구성 관리에 필수적으로 요구되는 객체

(2) 약한 제어 객체들만이 허락된다(강력하지 못하므로, 그것들을 간섭하는 것은 단지 손상을 제한할 수 있다는 것을 의미한다). 이런 기준은 현재 관리 프로토콜들이 좀 더 강력한 제어 동작들을 수행할 정도로 안전하지 않다는 사실을 반영 한다.

(3) 현재 사용과 유용성의 확증이 요구된다.

(4) MIB-I에서는, 업체들이 그들의 소프트웨어를 적어도 기기에 설치하기 쉽도록 하기 위해 객체 수를 약 100 정도로 제한하였다. MIB-II에서는, MIB-I을 구현하는 다양한 기술적 기반으로 이런 제한이 향상되었다.

(5) 중복 변수를 피하기 위해, MIB에 있는 다른 변수들에서 유도될 수 있는 것이 포함되는 객체가 없도록 요구했다.

(6) 특정 구현 객체들은 배제된다.( 예를 들면, BSD UNIX )

(7) 코드의 기준 절들을 설치하는 것을 피하는데 합의되었다. 일반적인 지침은 계층 당 기준 절에 하나의 카운터이다.

이전의 버전인 인터네트 표준 MIB처럼 MIB-II는 필수적인 요소들만을 포함한다.
각각의 객체들이 선택사항이 될 필요는 없다. 오히려, 객체들은 다음 그룹들로 배열된다.

- 시스템
- 인터페이스
- 주소변환(삭제대상)
- IP
- ICMP
- TCP
- UDP
- EGP
- 전송
- SNMP

이런 그룹들은 적합성의 기본 단위이다. 즉, 방법은 다음과 같다. 어떤 그룹의 의미가 구현에 응용가능하다면, 그 그룹에 있는 모든 객체들을 구현해야 한다. 예를 들면, EGP를 구현할 때만 EGP 그룹을 구현해야 한다.

이런 그룹들을 정의하는 데는 두가지 이유가 있다. 첫째, 객체 구별자를 할당하는 수단을 제공하기 위해서이다. 둘째는, 그들이 어떤 객체들을 구현할 것인가를 알려고 하는 관리 수행자들의 구현을 위한 방법을 제공하기 위해서이다.

6.2 RFC 1156으로부터의 변화

이 MIB의 특성은 다음을 포함한다.

(1) 새로운 운영가능한 요구조건을 반영하기 위한 추가사항

(2) SMI/MIB와 SNMP와의 향상된 호환성

(3) 다양한 프로토콜 엔티티를 위한 개선된 지원

(4) 명확성과 판독성을 개선하기 위한 MIB 원문의 정리

MIB-II에 정의된 객체들은 다음과 같이 MIB-I에서 사용된 접두사와 같은 OBJECT IDENTIFIER 접두사를 갖는다.

mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }

6.2.1 삭제 대상 객체

구현자가 MIB 내의 앞으로의 변화를 준비하기 위해, 새로운 용어 "삭제대상"은 객체를 기술할 때 사용 될 수 있다. MIB에 있는 "삭제대상" 객체는 지원되어야 하지만 MIB의 새 버젼(예를 들면, MIB-III)에서는 거의 제거될 것이다.
MIB-II는 삭제대상으로 다음 객체를 명시한다.

atTable

atTable 객체를 삭제대상으로 하는 결과로써, 전체 주소 변환 그룹은 삭제대상이 된다.
이런 객체들의 삭제로 상실되는 기능은 없다. 다시 말해서 동등하거나 그 이상의 기능을 제공하는 새로운 객체들이 MIB-II에 정의된다.

6.2.2 출력 문자열

MIB 규정에 의해 다음과 같은 데이타 유형이 소개되고 있다.

DisplayString ::=
OCTET STRING

DisplayString은 [6]의 10쪽에서 11쪽에 정의된 NVT ASCII 문자 집합으로 제한된다.
다음 객체들은 DisplayString에 의해 정의된다.

sysDescr
ifDescr

이런 변화는 이 객체들의 구문이나 의미에 영향을 주지 않는다. DisplayString 표기의 사용은 MIB-II와 미래의 MIB에 사용되는 해석 방법상의 인공물일 뿐이다.
더우기 OCTET STRING에 의해 정의된 객체는 임의의 이진 자료를 포함하고, 각 옥테트는 0에서255(십진수)사이의 값을 갖는다.

6.2.3 물리적 주소

MIB 내에는 그 밖의 문서적 규정으로서,

PhysAddress ::=
OCTET STRING

과 같은 데이타 유형이 매체- 또는 물리-계층 주소들을 표현하기 위해서 소개되고 있다.
다음의 객체들은 PhysAddress에 의해 정의된다.

ifPhysAddress
atPhysAddress
ipNetToMediaPhysAddress

이런 변화는 객체의 구문이나 의미에 영향을 주지 않는다. PhysAddress 표기의 사용은 단지 MIB-II와 미래의 MIB에 사용되는 해석 방법의 인공물일 뿐이다.

6.2.4 시스템 그룹

네개의 새로운 객체들이 이 그룹에 추가된다.

sysContact
sysName
sysLocation
sysServices

이것들은 피관리 노드에 관한 접촉, 관리, 위치, 서비스 정보를 제공한다.

6.2.5 인터페이스 그룹

IP를 지원하기 위한 모든 인터페이스들을 필요로 할 때, ifNumber 객체의 정의는 잘못되었다. (예를 들면, 이 정의가 엄격하게 준수될 경우 MAC-계층 브리지와 같이 IP계층이 없는 장치들은 관리될 수 없다.) 따라서 ifNumber 객체의 기술은 바뀐다.

ifTable 객체는 읽기쓰기로 잘못 명시되었다. 그것은 접근금지로 올바르게 재설정되었다. 추가 로, 여러 새로운 값들이 ifTable 객체의 ifType 란에 추가되었다.

ppp(23)
softwareLoopback(24)
eon(25)
ethernet-3Mbit(26)
nsip(27)
slip(28)
ultra(29)
ds3(30)
sip(31)
frame-relay(32)

마지막으로, 다음과 같이 새로운 란이 ifTable 객체에 추가되었다.

ifSpecific

이것은 인터페이스를 실현하기 위해 사용되는 매체 특유의 정보에 관한 정보를 제공한다.

6.2.6 주소 변환 그룹

MIB-I에서 이 그룹은 전산망 주소(예를 들면, IP 주소)에서 물리적 주소(예를 들면, MAC 주소)로의 사상을 가능하게 하는 테이블을 포함했다. 이 테이블의 효율적인 구현은 두가지를 가정한다. 하나의 전산망 프로토콜 환경과 전산망 주소에서 물리적 주소로의 사상만 일어난다.

다양한 프로토콜 노드들을 지원하기 위한 요구(예를 들면, IP와 CLNP가 모두 살아있는 것 등을)와 역사상을 지원하기 위한 요구(예를 들면, ES-IS)는 이런 가정 모두를 무효화했다. 따라서, atTable 객체는 삭제대상으로 선언된다.

다양한 프로토콜과 역 사상 요구조건을 만족시키기 위해 MIB-II와 이것의 후속 문서들은 각 전산망 프로토콜 그룹 내의 두 주소 변환 테이블까지 할당할 것이다. 다시 말해서, IP 그룹은 IP 주소에서 물리적 주소로 가기 때문에 하나의 주소 변환 테이블을 포함할 것이다. 유사하게, CLNP를 위한 MIB 객체들을 정의하는 문서를 만들 때(예를 들면, [7]), 이것은 완전한 기능을 필요로 하기 때문에 양 방향으로의 사상을 위해 두개의 테이블을 포함할 것이다.

양 방향의 사상을 위해 두 테이블을 선택하는 것은 여러 가지로 구현에 편의를 제공하고 하나 의 내부 테이블을 통해 주소 변환 추상화를 실현하는 구현상의 부담이 없어진다.

6.2.7 IP 그룹

변수 ipForwarding의 접근 속성은 읽기전용에서 읽기쓰기로 바뀌었다.
특정 인터페이스 상에서 재결합될 수 있는 가장 큰 IP 데이타그램을 기억하는 ipAdEntReasmMaxSize
라는 새로운 열이 ipAddrTable 객체에 추가된다.
ipRoutingTable 객체의 기술자는 다른 IP 경로설정 객체들과의 일관성을 위해 ipRouteTable로 바뀌었다.
또한 ipRouteTable 객체에는 세개의 새로운 열이 있다.

ipRouteMask
ipRouteMetric5
ipRouteInfo

첫번째 것은 임의의 서브네트 마스크를 지원하는 IP 경로설정 서브시스템들을 위해 사용된다.
나머지 둘은 IP 경로설정 프로토콜에 특유한 것이다.
IP 그룹에 추가되는 두개의 새로운 객체는 다음과 같다.

ipNetToMediaTable
ipRoutingDiscards

첫번째 객체는 IP 그룹을 위한 주소 변환 테이블이다(주소 해석 그룹의 삭제대상 atTable과동일한 기능을 제공하는 것이다). 두번째 객체는 경로설정 정보가 버퍼 공간의 부족으로 상실될 때, 정보를 제공한다.

6.2.8 ICMP 그룹

이 그룹에는 변화가 없다.

6.2.9 TCP 그룹

두개의 새로운 변수가 추가된다.

tcpInErrs
tcpOutRsts

위 변수들은 오류로 수신된 TCP 세그먼트 수와 TCP에 의해 생성된 복귀 수를 기억한다.

6.2.10 UDP 그룹

새로운 테이블,

udpTable

이 추가된다.

6.2.11 EGP 그룹

EGP 감시에 유용한 객체들의 추가가 필요하다. egpNeighborTable 객체는 다음과 같다.
egpNeighAs
egpNeighInMsgs
egpNeighInErrs
egpNeighOutMsgs
egpNeighOutErrs
egpNeighInErrMsgs
egpNeighOutErrMsgs
egpNeighStateUps
egpNeighStateDowns
egpNeighIntervalHello
egpNeighIntervalPoll
egpNeighMode
egpNeighEventTrigger

위 객체에 추가로, EGP 엔티티에 연관된 독립적 시스템에 주는 egpAs 라는 새로운 변수가 추가된다.

6.2.12 전송 그룹

MIB-I은 전송 매체의 다른 유형들을 구별하지 않았다. 새로운 그룹인 전송 그룹은 이 목적을 위해 할당된다.

transmission OBJECT IDENTIFIER ::= { mib-2 10 }

전송 매체를 관리하는 인터네트 표준 정의들이 정의될 때, 전송 그룹은 그 객체들의 이름에 접두사를 제공하기 위해 사용된다.
실제로, 그런 정의들은 "입증"될 때까지 MIB의 실험 부분에 존재하다가 인터네트 표준화 과정 의 부분으로써, 그 정의가 적절히 향상되어서, 전송 그룹하에 새로운 객체 식별자가 정의된다.
규정에 따라 할당되는 이름은 다음과 같다.

type OBJECT IDENTIFIER ::= { transmission number }

"type"은 ifTable 객체의 ifType 란에 있는 매체에 사용된 기호 값이다. "number"는 기호에 대응하는 실제 정수 값이다.

6.2.13 SNMP 그룹

IETF의 응용 지향적 연구 그룹은 그들 각각의 응용에 특유한 MIB 변수들을 정의하여 잘 받 아들이도록 작업해오고 있다.

SNMP의 경우, 통계적인 정보를 갖는데 유용하다. 새로운 그룹인 SNMP 그룹은 이 목적을 위해 할당된다.

snmp OBJECT IDENTIFIER ::= { mib-2 11 }

6.2.14 RFC 1158로 부터의 변화

이 MIB의 특성은 다음을 포함한다.

(1) 이 표준에 있는 관리 객체는 [14]에 명시된 확장에 의해 개선된 인터네트 표준 SMI에 정의된 규정을 이용해서 정의되었다. 이런 확장을 이용해서 만들어진 정의는 RFC 1158의 것과 의미상으로 동일하다는 것이 강조되었다.

(2) PhysAddress 원문 표기는 매체 주소를 표현하기 위해 소개되었다.

(3) sysLocation의 접근 절은 읽기쓰기이다.

(4) sysServices의 정의가 명백해졌다.

(5) 새로운 ifType 값(29-32)이 정의되었다. 게다가, DS1과 E1 인터페이스 유형을 위한 본문의 기술자가 교정되었다.

(6) ipForwarding 정의가 명백해졌다.

(7) ipRouteType 정의가 명백해졌다.

(8) ipRouteMetric5와 ipRouteInfo 객체가 정의되었다.

(9) tcpConnState의 접근 절은 TCP 연결과 관련된 TCP의 제거를 제공하기 위한 읽기 쓰기이다. 이 객체의 정의는 용도를 설명하기 위해 명백해졌다.

(10) egpNeighEventTrigger 정의가 명백해졌다.

(11) 새로운 snmp 그룹에 있는 여러 변수의 정의가 명백해졌다. 게다가, snmpInBadTypes와 snmpOutReadOnlys 객체는 더 이상 존재하지 않는다. (그러나 객체에 관련된 객체 구별자들은 사용을 금지하도록 예약되었다.)

(12) snmpInReadOnlys 정의가 명백해졌다.

(13) snmpEnableAuthTraps의 본문 기술자는 snmpEnableAuthenTraps으로 바뀌었고, 정의가 명백해졌다.

(14) ipRoutingDiscards 객체가 추가되었다.

(15) IP 주소와 경로설정 테이블의 실체를 구별할 때 구현에 따른 작은 양수의 선택 적 사용은 금지되었다.

6.3 관리 객체

관리 객체들은 관리 정보 베이스 또는 MIB라 불리는 가상 정보 저장소를 통해 접근된다.
MIB에 있는 객체들은 SMI에 정의된 추상 구문 표기법 1(ASN.1)의 부분집합을 이용해서 정의 된다. 특히, 각 객체는 이름, 구문, 부호를 갖는다. 이름은 객체 유형을 명시하는 객체 식별자로 행정적으로 할당되는 이름이다. 객체 실체와 함께 객체 유형은 객체의 특정 실체를 유일하게 구분한다. 인간의 편의를 위해, 우리는 객체 유형을 참조하기 위한 객체 기술자라고 하는 문서상의 문자열을 이용한다.

객체 유형의 구문은 객체 유형에 대응하는 추상 자료 구조를 정의한다. ASN.1 언어는 이런 목적을 위해 사용된다. 그러나, SMI는 주로 사용될 ASN.1 구문들을 제한한다. 이런 제한은 단순성을 위해 명확하게 만들어진다.

객체 유형의 부호화은 객체 유형이 객체 유형의 구문을 사용해서 어떻게 표현되는가를 나타낸다. 객체 유형의 구문과 부호화 개념의 결합은 암시적으로 전산망로 전송될 때 객체 유형이 어떻게 표현되는 가를 보이는 것이다.
SMI는 SNMP에 의해 부과된 추가적인 요구조건에 의한 ASN.1 BER의 이용을 명시한다.

6.3.1 정의 형식

4절은 이 MIB 모듈에 포함된 모든 객체 유형의 명시를 포함한다. 객체 유형은 [14]에 명시된
확장들에 의해 개선된 SMI에 정의된 규정들을 이용해서 정의된다.

6.4 정의

RFC1213-MIB 정의 ::= 시작

IMPORTS
mgmt, NetworkAddress, IpAddress, Counter, Gauge, TimeTicks
FROM RFC1155-SMI
OBJECT-TYPE
FROM RFC-1212;
-- 이 MIB 모듈은 [14]에 정의된 것으로 확장된 OBJECT-TYPE 매크로를 사용한다.

-- MIB-II ( MIB-I과 같은 접두사 )

mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }

6.4.1 본문의 관례적 표기

DisplayString ::=
OCTET STRING

-- 이 데이타 유형은 NVT ASCII 문자 집합에서 채택된 정보를 구현하기 위해 사용된다. 관례에 따라, 이런 구문으로 된 객체들은 SIZE (0..255)로 선언된다.

PhysAddress ::=
OCTET STRING

-- 이 데이타 유형은 매체 주소를 모델화하기 위해 사용된다. 여러 매체 유형을 위해, 이것은 이진 표현일 것이다. 예를 들면, ethernet 주소는 6 옥테트 문자열로 표현된다.

6.4.2 MIB-II에서의 그룹

system OBJECT IDENTIFIER ::= { mib-2 1 }
interface OBJECT IDENTIFIER ::= { mib-2 2 }
at OBJECT IDENTIFIER ::= { mib-2 3 }
ip OBJECT IDENTIFIER ::= { mib-2 4 }
icmp OBJECT IDENTIFIER ::= { mib-2 5 }
tcp OBJECT IDENTIFIER ::= { mib-2 6 }
udp OBJECT IDENTIFIER ::= { mib-2 7 }
egp OBJECT IDENTIFIER ::= { mib-2 8 }

-- 과거를 반영(히스테리적이라고도 한다)
-- cmot OBJECT IDENTIFIER ::= { mib-2 9 }

transmission OBJECT IDENTIFIER ::= { mib-2 10 }
snmp OBJECT IDENTIFIER ::= { mib-2 11 }

6.4.3 시스템 그룹

-- 시스템 그룹의 구현은 모든 시스템을 위한 필수사항이다. 수행자가 이 변수들 중 임의의 값을 갖지 않는다면, 길이가 0인 문자열이 반환된다.

sysDescr 객체-유형
구문 DisplayString(SIZE (0..255))
접근 읽기전용
상태 필수사항
기술 "엔티티의 설명. 이 값은 시스템의 하드웨어 유형, 소프트웨어 운영 유형, 그리고 네트워킹 소프트웨어의 고유명과 버젼 구별을 포함하여 야 한다. 이것이 인쇄가능한 ASCII 문자를 포함할 때만 필수사항이 다."
::= { system 1 }

sysObjectID 객체-유형
구문 OBJECT IDENTIFIER
접근 읽기전용
상태 필수사항
기술 "엔티티에 포함되는 전산망 관리 서브시스템 제공자의 권한 구별.
이 값은 SMI enterprises 서브트리 (1.3.6.1.4.1) 내에 할당되어 관리되고 있는 '종류'를 결정하기 용이하고 분명한 수단을 제공한다.
예를 들면, 'Flintstones, Inc' 기업이 서브트리 1.3.6.1.4.1.4242로 할당되었다면, 그 기업의 'Fred Router'에는 식별자 1.3.5.1.4.1.4242.1.1을 할당한다."
::= { system 2 }

sysUpTime 객체-유형
구문 TimeTicks
접근 읽기전용
상태 필수사항
기술 "시스템의 전산망 관리 부분이 마지막으로 재초기화된 이후의 시간
(1/100 초 단위)."
::= { system 3 }

sysContact 객체-유형
구문 DisplayString(SIZE (0..255))
접근 읽기쓰기
상태 필수사항
기술 "이 피관리 노드를 위해 접촉할 사람의 구별과 이 사람과 접촉하는 방법에 관한 정보."
::= { system 4 }

sysName 객체-유형
구문 DisplayString(SIZE (0..255))
접근 읽기쓰기
상태 필수사항
기술 "이 피관리 노드를 위해 행정적으로 할당된 이름. 규정에 의해, 이것은 그 노드의 완전히 승인된 영역명이다.".
::= { system 5}

sysLocation 객체-유형
구문 DisplayString(SIZE (0..255))
접근 읽기쓰기
상태 필수사항
기술 "이 노드의 물리적인 위치(예를 들면, 3층 전화가 있는 방)"
::= { system 6 }

sysServices 객체-유형
구문 INTEGER (0..127)
접근 읽기전용
상태 필수사항
기술 "이 엔티티가 주로 제공하는 서비스의 집합을 가리키는 값.
이 값은 합이다. 이 합은 초기에 영의 값을 채택하고, 그 다음 1에서 7까지의 범위에 있는 각 계층 L을 위해 이 노드는 2의 (L-1) 승이 그 합에 더해지는 트랜잭션을 수행한다.

예를 들면, 주로 경로선택 기능 을 수행하는 노드는 2의 (3-1)승인 4의 값을 갖는다. 반대로, 응용 서비스를 제공하는 호스트인 노드는 (2^(4-1)+2^(7-1))인 72의 값을 갖게 된다. 인터네트 프로토콜 쌍의 환경에서 값들은 다음과 같이 그것에 따라 계산되어야 한다.

계층 기능
1 물리적 (예를 들면, 리피터)
2 데이타연결/서브네트워크 (예를 들면, 브릿지)
3 인터네트 (예를 들면, IP 게이트웨이)
4 종단간 (예를 들면, IP 호스트)
7 응용 (예를 들면, 메일 중계)

OSI 프로토콜을 포함하는 시스템의 경우, 계층 5와 6이 계산될 수 있다."
::= { system 7 }

6.4.4 인터페이스 그룹

-- 인터페이스 그룹의 구현은 모든 시스템에서 필수사항이다.

ifNumber 객체-유형
구문 INTEGER
접근 읽기전용
상태 필수사항
기술 "이 시스템 상에 존재하는 (그들의 현 상태와는 무관하게) 전산망 인터페이스의 갯수."
::= { interfaces 1 }

-- 인터페이스 테이블

-- 인터페이스 테이블은 엔티티의 인터페이스에 관한 정보를 포함한다. 각 인터페이스는 '서브네트워크'에 붙은 것으로 간주된다. 이 용어는 인터네트 프로토콜 쌍 에 사용되는 주소 분할 기법을 참조하는'서브네트'와 혼동되어서는 않된다.

ifTable 객체-유형
구문 SEQUENCE OF IfEntry
접근 접근금지
상태 필수사항
기술 "인터페이스 엔트리의 나열. 엔트리의 갯수는 ifNumber 값에 의해 주어진다."
::= { interfaces 2 }

ifEntry 객체-유형
구문 IfEntry
접근 접근금지
상태 필수사항
기술 "서브네트워크 계층과 특정 인터페이스 하에 있는 객체들을 포함하는 인터페이스 엔트리."
::= { ifTable 1 }

IfEntry ::=
SEQUENCE {
ifIndex
INTEGER,
ifDescr
DisplayString,
ifType
INTEGER,
ifMtu
INTEGER,
ifSpeed
Gauge,
ifPhysAddress
PhysAddress,
ifAdminStatus
INTEGER,
ifOperStatus
INTEGER,
ifLastChange
TimeTicks,
ifInOctets
Counter,
ifInUcastPkts
Counter,
ifInNUcastPkts
Counter,
ifInDiscards
Counter,
ifInErrors
Counter,
ifInUnknownProtos
Counter,
ifOutOctets
Counter,
ifOutUcastPkts
Counter,
ifOutNUcastPkts
Counter,
ifOutDiscards
Counter,
ifOutErro

rs
Counter,
ifOutQLen
Gauge,
ifSpecific
OBJECT IDENTIFIER
}

ifIndex 객체-유형
구문 INTEGER
접근 읽기전용
상태 필수사항
기술 "각 인터페이스에 유일한 값. 그 값의 범위는 1부터 ifNumber의 값이다. 각 인터페이스에 대한 값은 적어도 그 엔티티의 전산망 관리 시스템의 재초기화로부터 다음 재초기화까지 일정하게 남아야 한다."
::= { ifEntry 1 }

ifDescr 객체-유형
구문 DisplayString(SIZE(0..255))
접근 읽기전용
상태 필수사항
기술 "인터페이스에 관한 정보를 포함하는 문자열. 이 문자열은 하드웨어 인터페이스의 제조자 이름, 상품명, 그리고 버젼을 포함하여야 한다."
::= { ifEntry 2 }

ifType 객체-유형
구문 INTEGER {
other(1), -- 다음에 없는 것
regular1822(2),
hdh1822(3),
ddn-x25(4),
rfc877-x25(5),
ethernet-csmacd(6),
iso88023-csmacd(7),
iso88024-csmacd(8),
iso88025-csmacd(9),
iso88026-man(10),
starLan(11),
proteon-10Mbit(12),
proteon-80Mbit(13),
hyperchannel(14),
fddi(15),
lapb(16),
sdlc(17),
ds1(18),
e1(19), --T-1에 대응하는 유럽표준
basicISDN(20),
primaryISDN(21), -- 독자적인 선로
propPointToPointSerial(22),
ppp(23),
softwareLoopback(24),
eon(25), -- IP 상의 CLNP [11]
ethernet-3Mbit(26),
nsip(27), -- IP 상의 XNS
slip(28), -- 일반 SLIP
ultra(29), -- ULTRA 기술
ds3(30), -- T-3

sip(31), -- SMDS
frame-relay(32),
}
접근 읽기전용
상태 필수사항
기술 "프로토콜 스택에 있는 전산망 계층 바로 '아래'의 물리/연결 프로토콜에 따라 구별되는 인터페이스의 유형."
::= { ifEntry 3 }

ifMtu 객체-유형
구문 INTEGER
접근 읽기전용
상태 필수사항
기술 "인터페이스에서 송신 또는 수신할 수 있는 옥테트로 명시된 가장 큰 데이타그램의 크기. 전산망에 데이타그램을 전송하기 위해 사용되는 인터페이스의 경우, 이것은 그 인터페이스에 보내질 수 있는 최대
전산망 데이타그램의 크기이다."
::= { ifEntry 4 }

ifSpeed 객체-유형
구문 Gauge
접근 읽기전용
상태 필수사항
기술 "bps로 인터페이스의 현재 대역폭 평가. 대역폭이 변하지 않거나 정확한 평가가 이루어지지 않는 인터페이스에 대해, 이 객체는 명목 상의 대역폭을 포함해야한다."
::= { ifEntry 5 }

ifPhysAddress 객체-유형
구문 PhysAddress
접근 읽기전용
상태 필수사항
기술 "프로토콜 스택의 전산망 계층 바로 아래에 있는 프로토콜 계층의 인터페이스 주소. 그와 같은 주소 (예를 들면, 통신선로)를 갖지 않는 인터페이스의 경우, 이 객체는 길이가 0인 옥테트 문자열을 포함
하여야 한다."
::= { ifEntry 6 }

ifAdminStatus 객체-유형
구문 INTEGER {
up(1), -- 패킷을 넘길 준비가 됨
down(2),
testing(3), -- 테스트 모드
}
접근 읽기쓰기
상태 필수사항
기술 "인터페이스의 원하는 상태. testing(3) 상태는 동작 패킷이 통과될수 없음을 지시한다."
::= { ifEntry 7 }

ifOperStatus 객체-유형
구문 INTEGER {
up(1), -- 패킷을 넘길 준비가 됨
down(2),
testing(3), -- 시험 모드
}
접근 읽기전용
상태 필수사항
기술 "인터페이스의 현 동작 상태. testing(3) 상태는 동작 패킷이 통과될 수 없음을 지시한다."
::= { ifEntry 8 }

ifLastChange 객체-유형
구문 TimeTicks
접근 읽기전용
상태 필수사항
기술 "인터페이스가 현재 동작 상태에 들어갔을 때의 sysUpTime의 값. 현 상태가 국부 전산망 관리 서브시스템의 마지막 재초기화에 앞서 들어왔다면, 이 객체는 영의 값을 포함한다."
::= { ifEntry 9 }

ifInOctets 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "프레임 구성 문자를 합쳐서, 인터페이스에 수신된 옥테트의 총갯수."
::= { ifEntry 10 }

ifInUcastPkts 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "상위 계층 프로토콜에 전달되는 서브네트워크-유니캐스트 패킷의 갯 수."
::= { ifEntry 11 }

ifInNUcastPkts 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "상위 계층 프로토콜에 전달되는 비유니캐스트(서브네트워크-브로드캐스트 또는서브네트워크-멀티캐스트) 패킷의 갯수."
::= { ifEntry 12 }

ifInDiscards 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "상위 계층 프로토콜에 전달되는 것을 막는 오류가 검출되지 않았을지라도 버려지는 도착 패킷의 갯수. 그런 패킷을 버리는 이유 중의 하나가 버퍼 공간을 비우는 행위가 될 수 있을 것이다."
::= { ifEntry 13 }

ifInErrors 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "패킷에 포함된 오류때문에 상위 계층 프로토콜에 전달되지 못한 도착 패킷의 갯수."
::= { ifEntry 14 }

ifInUnknownProtos 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "알려지지 않았거나 지원되지 않은 프로토콜때문에 버려지는 인터페이스를 통해 수신된 패킷의 갯수."
::= { ifEntry 15 }

ifOutOctets 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "프레임 구성 문자를 포함하여, 인터페이스를 벗어나서 전송되는 총 옥테트 갯수."
::= { ifEntry 16 }

ifOutUcastPkts 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "요청된 상위 계층 프로토콜이 버려진 것과 전송되지 않은 것을 포함하여 서브네트워크-유니캐스트 주소에 전송되는 패킷의 총 갯수."
::= { ifEntry 17 }

ifOutNUcastPkts 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "요청된 상위 계층 프로토콜이 버려진 것과 전송되지 않은 것을 포함하여 비유니캐스트(다시 말해서, 서브네트워크-브로드캐스트 또는 서브네트워크-멀티캐스트) 주소에 전송되는 패킷의 총 갯수."
::= { ifEntry 18 }

ifOutDiscards 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "오류때문에 전송되지 못하는 패킷이 없을지라도 버려지는 발신 패킷 의 갯수. 그런 패킷을 버리는 이유 중의 하나가 버퍼 공간을 비우는 행위가 될 수 있을 것이다."
::= { ifEntry 19 }

ifOutErrors 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "오류때문에 전송될 수 없는 발신 패킷의 갯수."
::= { ifEntry 20 }

ifOutQLen 객체-유형
구문 Gauge
접근 읽기전용
상태 필수사항
기술 "출력 패킷 큐의 길이."
::= { ifEntry 21 }

ifSpecific 객체-유형
구문 OBJECT IDENTIFIER
접근 읽기전용
상태 필수사항
기술 "인터페이스를 실현하기 위해 사용되는 어떤 매체에 특정한 MIB 정의 에 대한 참조. 예를 들면, 인터페이스가 ethernet에 의해 실현된다면 이 객체의 값은 ethernet에 특정한 객체를 정의하는 문서를 언급한
이 정보가 존재하지 않는다면, 그것의 값은 OBJECT IDENTIFIER {0 0} 에 설정되어야 한다. 이 OBJECT IDENTIFIER는 타당한 OBJECT IDENTIFIER이고, ASN.1과 BER을 준수하는 구현은 이 값을 생성하고
인식할 수 있어야 한다."
::= { ifEntry 22 }

6.4.5 주소 변환 그룹

-- 주소 변환 그룹의 구현은 모든 시스템에 필수사항이다. 그러나, MIB-II는 이 그룹 을삭제대상으로 한다. 다시 말해서, 주소 변환 그룹은 MIB-I 노드와의 호환성을 위해서는 포함되고, MIB-III 노드에서는 제외되는 것이 바람직하다는 것이다.

-- MIB-II 이후로, 각 전산망 프로토콜 그룹은 그 자신의 주소 변환 테이블을 포함 한다.
-- 주소 변환 그룹은 NetworkAddress(예를 들면, IP 주소)를 서브네트워크에 특정한 주소로 변환하기 위한 변환 테이블의 모든 인터페이스를 거치는 결합된 하나의 테이블을 포함한다. 좀 더 좋은 용어의 결핍으로, 이 문서는 서브네트워크에 특정한 주소를 '물리적' 주소로 일컫는다.

-- 그와같은 변환 테이블의 예는 다음과 같다. ARP를 사용하는 방송전달 매체의 경우, 변환 테이블은 ARP 캐쉬와 동등하다. 또는 X.121 주소에 대한 비알고리즘 방식의 해석이 요구되는 X.25의 경우, 변환 테이블은 X.121 주소와 동등한 NetworkAddress를 포함한다.

atTable 객체-유형
구문 SEQUENCE OF AtEntry
접근 접근금지
상태 삭제대상
기술 "주소 변환 테이블은 '물리적' 주소와 동등 관계인 NetworkAddress를 포함한다. 몇몇 인터페이스는 동등 관계인 주소(예를 들면, DDN-X.25 는 알고리즘 방식을 갖는다)를 결정하기 위해 변환 테이블을 사용하
지 않는다.

모든 인터페이스가 이런 유형이 된다면, 주소 변환 테이블은 빈다. 다시 말해서, 엔트리를 갖지 않게된다."
::= { at 1 }

atEntry 객체-유형
구문 AtEntry
접근 접근금지
상태 삭제대상
기술 "각 엔트리는 '물리적' 주소와 동등 관계인 하나의 NetworkAddress를 포함한다."

인덱스 { atIfIndex,
atNetAddress }
::= { atTable 1 }

AtEntry ::=
SEQUENCE {
atIfIndex
INTEGER,
atPhysAddress
PhysAddress,
atNetAddress
NetworkAddress
}

atIfIndex 객체-유형
구문 INTEGER
접근 읽기쓰기
상태 삭제대상
기술 "이 엔트리의 동등 관계가 유효한 인터페이스. 이 색인의 특정 값에 의해 구별되는 인터페이스는 ifIndex와 동일한 값에 의해 구별되는 인터페이스와 같다."
::= { atEntry 1 }

atPhysAddress 객체-유형
구문 PhysAddress
접근 읽기쓰기
상태 삭제대상
기술 "매체-의존적인 '물리적' 주소.
이 객체를 널 문자열로 설정하는 것은 atTable 객체에 있는 대응하는 엔트리를 무효화하는 효과가 있다. 다시 말해서, 그것은 언급된 엔트리로 구별되는 사상으로 부터 언급된 엔트리로 구별된 인터페이스를
효과적으로 분리한다.

수행자가 테이블에서 무효화된 엔트리를 제거 하는 것은 구현에 따르는 문제이다. 따라서, 관리 스테이션은 현재 사용하지 않는 엔트리에 대응하는 수행자로 부터 테이블 정보를 받을 준비가 되어있어야 한다. 그런 엔트리들의 알맞은 해석은 관련된 atPhysAddress 객체의 시험을 필요로 한다."
::= { atEntry 2 }

atNetAddress 객체-유형
구문 NetworkAddress
접근 읽기쓰기
상태 삭제대상
기술 "매체-의존적인 '물리적' 주소에 대응하는 NetworkAddress(예를 들면, IP 주소)."
::= { atEntry 3 }

6.4.6 IP 그룹

-- IP 그룹의 구현은 모든 시스템에 대해 필수사항이다.

ipForwarding 객체-유형
구문 INTEGER {
forwarding(1), -- 게이트웨이로서 동작
not-forwarding(2) -- 게이트웨이로서 동작 안함
}
접근 읽기쓰기
상태 필수사항
기술 "이 엔티티로 주소가 지정되지 않았지만 이 엔티티에 의해 수신된 데이타그램의 발송에 관한 IP 게이트웨이로서 이 엔티티가 동작하는지 에 대한 지시. IP 게이트웨이는 데이타그램을 발송한다.

IP 호스트는 발송하지 않는다.(호스트에 의해 송신지가 경로를 지정한 것을 제외 하고). 몇몇 피관리 노드의 경우, 이 객체는 가능한 값들의 부분집합만을 채택할 수 있다는 것을 주목하라.

따라서, 관리 스테이션이 이 객체를 부적합한 값으로 변경하려한다면, 'badValue'라는 응답을 수행자에게 반환하는 것이 합당하다."
::= { ip 1 }

ipDefaultTTL 객체-유형
구문 INTEGER
접근 읽기쓰기
상태 필수사항
기술 "TTL 값이 수송 계층 프로토콜에 의해 지원되지 않을 때마다 이 엔티티에서 기인되는 IP 데이타그램 머리부분의 Time-To-Live 필드로 삽입되는 기본형 값."
::= { ip 2 }

ipInReceives 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "인터페이스로 부터 수신된 입력 데이타그램의 총 갯수로 오류로 수신된 것도 포함한다."
::= { ip 3 }

ipInHdrErrors 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "IP 머리부분 내의 오류로 인해 버려지는 입력 데이타그램의 갯수로서 잘못된 검사합, 버젼의 불일치, 다른 형식 오류, 패킷 존재 시간 (time-to-live) 초과, IP 선택사항 처리에서 발견된 오류 등을 포함 한다."
::= { ip 4 }

ipInAddrErrors 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "IP 헤더의 목적지 필드에 있는 IP 주소가 이 엔티티에 수신될 타당한 주소가 아니므로 버려진 입력 데이타그램의 갯수. 이 카운트는 의미 없는 주소(예를 들면, 0.0.0.0)와 지원되지 않는 등급(예를 들면,
등급 E)를 포함한다.

IP 게이트웨이가 아니므로 데이타그램을 진행시키지 않는 엔티티의 경우, 이 카운터는 목적지 주소가 국부 주소가 아니므로 버려진 데이타그램을 포함한다."
::= { ip 5 }

ipForwDatagrams 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "마지막 목적지에 데이타그램을 보내기 위한 경로를 찾는 시도의 결과 로, 이 엔티티는데이타그램들의 마지막 IP 목적지가 아닌 입력 데이타그램의 갯수. IP 게이트웨이로써 동작하지 않는 실체들의 경우에
대해, 이 카운터는 해당 엔티티를 경유하여 송신지에서 결정된 경로 를 갖는 패킷들 중 성공적으로 처리된 패킷들만 포함할 것이다."
::= { ip 6 }

ipInUnknownProtos 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "알려지지 않았거나 지원되지 않는 프로토콜때문에 성공적으로 수신되었지만 버려지는 국부적인 주소를 가진 데이타그램의 갯수."
::= { ip 7 }

ipInDiscards 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "데이타그램의 계속되는 처리를 막는 문제는 없으나 버려지는 입력 IP 데이타그램의 갯수(예를 들면, 버퍼 공간의 부족). 이 카운터는 재조 립을 기다리는 동안 버려지는 데이타그램은 포함하지 않는다."
::= { ip 8 }

ipInDelivers 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "IP 사용자 프로토콜(ICMP를 포함한다.)에 성공적으로 전달되는 입력 데이타그램의 총 갯수."
::= { ip 9 }

ipOutRequests 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "국부 IP 사용자 프로토콜(ICMP를 포함한다)이 전송을 위한 요청으로 IP에 지원했던 IP 데이타그램의 총 갯수. 이 카운터는 ipForwDatagrams에서 계산된 데이타그램을 포함하지 않는다."
::= { ip 10 }

ipOutDiscards 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "데이타그램의 목적지 전송을 방해하는 문제는 없으나 버려지는 출력 IP 데이타그램의 갯수(예를 들면, 버퍼 공간의 부족). 이 카운터는 어떤 패킷이 이런 (임의의) 버려지는 기준을 만족했다면 ipForwDatagrams에서 계산된 데이타그램을 포함한다."
::= { ip 11 }

ipOutNoRoutes 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "목적지까지 데이타그램을 전송하기 위해 찾을 수 있는 경로가 없으므로 버려지는 IP 데이타그램의 갯수. 이 카운터는 이런 '무경로' 기준 을만족하는 ipForwDatagrams에서 계산되는 패킷을 포함한다. 이것은
호스트의 기본형 게이트웨이 모두가 작동되지 않아 경로선택을 할 수 없는 데이타그램을 포함한다."
::= { ip 12 }

ipReasmTimeout 객체-유형
구문 INTEGER
접근 읽기전용
상태 필수사항
기술 "이 엔티티에서 재조합을 기다리는 동안 수신된 프레그먼트가 유지되는 최대치"
::= { ip 13 }

ipReasmReqds 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "이 엔티티에서 재조합되기 위해 요구되는 수신된 IP 프레그먼트의 갯 수."
::= { ip 14 }

ipReasmOKs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "성공적으로 재조합되는 IP 데이타그램의 갯수."
::= { ip 15 }

ipReasmFails 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "IP 재조합 알고리즘에 의해 검출되는 실패의 갯수(어떤 이유든, 즉 시간초과, 오류 등등). 몇가지 알고리즘(RFC 815에 있는 알고리즘)이 수신될때 결합되는 것에 의해 프레그먼트의 갯수를 잃을 수 있으므로 이것이 필요로해서 버려지는 IP 프레그먼트의 수는 아니다."
::= { ip 16 }

ipFragOKs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "성공적으로 분해된 IP 데이타그램의 갯수."
::= { ip 17 }

ipFragFails 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "이 엔티티에서 분해될 필요가 있었으나 Don't Fragment 플래그가 설정되었기에 분해될 수 없었으므로 버려졌던 IP 데이타그램의 갯수.
::= { ip 18 }

ipFragCreates 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "이 엔티티에서 분해의 결과로 생성되었던 IP 데이타그램의 프레그먼 트 갯수."
::= { ip 19 }

-- IP 주소 테이블
-- IP 주소 테이블은 해당엔티티의 IP 주소지정 정보를 포함한다.

ipAddrTable 객체-유형
구문 SEQUENCE OF IpAddrEntry
접근 접근금지
상태 필수사항
기술 "해당엔티티의 IP 주소에 관련된 주소지정 정보의 테이블."
::= { ip 20 }

ipAddrEntry 객체-유형
구문 IpAddrEntry
접근 접근금지
상태 필수사항
기술 "해당엔티티의 IP 주소 중 하나에 대한 주소지정 정보."
인덱스 { ipAdEntAddr }
::= { ipAddrTable 1 }

IpAddrEntry ::=
SEQUENCE {
ipAdEntAddr
IpAddress,
ipAdEntIfIndex
INTEGER,
ipAdEntNetMask
IpAddress,
ipAdEntBcastAddr
INTEGER,
ipAdEntReasmMaxSize
INTEGER (0..65535)
}

ipAdEntAddr 객체-유형
구문 IpAddress
접근 읽기전용
상태 필수사항
기술 "해당 엔트리의 주소지정 정보가 관계하는 IP 주소."
::= { ipAddrEntry 1 }

ipAdEntIfIndex 객체-유형
구문 INTEGER
접근 읽기전용
상태 필수사항
기술 "해당 엔트리가 적용될 수 있는 인터페이스를 유일하게 구별하는 인덱 스 값. 해당인덱스의 특정 값에 의해 구별되는 인터페이스는 ifIndex 의 값에 의해 구별되는 것과 같은 인터페이스이다."
::= { ipAddrEntry 2 }

ipAdEntNetMask 객체-유형
구문 IpAddress
접근 읽기전용
상태 필수사항
기술 "해당 엔트리의 IP 주소와 연관된 서브네트 마스크. 이 마스크의 값은 모든 네트워크 비트가 1로 설정되고 호스트 비트는 0으로 설정된 IP 주소이다."
::= { ipAddrEntry 3 }

ipAdEntBcastAddr 객체-유형
구문 INTEGER
접근 읽기전용
상태 필수사항
기술 "해당 엔트리의 IP 주소에 연관된 (논리적인) 인터페이스 상에 데이타 그램을 보내기 위해 사용되는 IP 브로드캐스트 주소에 있는 최하위 비트의 값. 예를 들면, 모두 1로 된 인터네트 표준 브로드캐스트 주
소가 사용될 때, 값은 1이 될 것이다.

이 값은 이런 (논리적) 인터페이스 상의 엔티티에 의해 사용되는 서브네트와 네트워크 브로드캐스트 주소에 적용한다."
::= { ipAddrEntry 4 }

ipAdEntReasmMaxSize 객체-유형
구문 INTEGER (0..65535)
접근 읽기전용
상태 필수사항
기술 "해당엔티티가 이 인터페이스 상에 수신되어 들어오는 분해된 IP 데이타그램의 입력을 재조립할 수 있는 최대 IP 데이타그램의 크기."
::= { ipAddrEntry 5 }

-- IP 경로선정 테이블
-- IP 경로선정 테이블은 현재 해당 엔티티에 알려진 각 경로를 위한 엔트리를 포함 한다.

ipRouteTable 객체-유형
구문 SEQUENCE OF IpRouteEntry
접근 접근금지
상태 필수사항
기술 "해당 엔티티의 IP 경로선정 테이블."
::= { ip 21 }

ipRouteEntry 객체-유형
구문 IpRouteEntry
접근 접근금지
상태 필수사항
기술 "특정 목적지로의 경로."
인덱스 { ipRouteDest }
::= { ipRouteTable 1 }

IpRouteEntry ::=
SEQUENCE {
ipRouteDest
IpAddress,
ipRouteIfIndex
INTEGER,
ipRouteMetric1
INTEGER,
ipRouteMetric2
INTEGER,
ipRouteMetric3
INTEGER,
ipRouteMetric4
INTEGER,
ipRouteNextHop
IpAddress,
ipRouteType
INTEGER,
ipRouteProto
INTEGER,
ipRouteAge
INTEGER,
ipRouteMask
IpAddress,
ipRouteMetric5
INTEGER,
ipRouteInfo
OBJECT IDENTIFIER
}

ipRouteDest 객체-유형
구문 IpAddress
접근 읽기쓰기
상태 필수사항
기술 "이 경로의 목적지 IP 주소. 값이 0.0.0.0인 엔트리는 기본형 경로로 간주된다. 한 목적지로의 다양한 경로들은 테이블 내에 있을 수 있다.

그러나 그런 여러 엔트리로의 접근은 사용중인 네트워크 관리 프로토콜에 의해 정의된 테이블-접근 메카니즘에 의존한다."
::= { ipRouteEntry 1 }

ipRouteIfIndex 객체-유형
구문 INTEGER
접근 읽기쓰기
상태 필수사항
기술 "이 경로가 다음 홉에 도달되기 위해 거쳐야 하는 국부 인터페이스를 유일하게 구별하는 인덱스 값. 이 인덱스의 특정 값에 의해 구별되는 인터페이스는 ifIndex의 같은 값에 의해 구별되는 것과 같은 인터페
이스이다."
::= { ipRouteEntry 2 }

ipRouteMetric1 객체-유형
구문 INTEGER
접근 읽기쓰기
상태 필수사항
기술 "이 경로에 대한 주요 경로선정 메트릭. 이 메트릭의 의미는 경로의 ipRouteProto 값에 명시된 경로선정 프로토콜에 의해 결정된다. 이 메트릭이 사용되지 않는다면, 그 값은 -1로 설정되어야 한다."
::= { ipRouteEntry 3 }

ipRouteMetric2 객체-유형
구문 INTEGER
접근 읽기쓰기
상태 필수사항
기술 "이 경로에 대한 대체 경로선정 메트릭. 이 메트릭의 의미는 경로의 ipRouteProto 값에 명시된 경로선정 프로토콜에 의해 결정된다. 이 메트릭이 사용되지 않는다면, 그 값은 -1로 설정되어야 한다."
::= { ipRouteEntry 4 }

ipRouteMetric3 객체-유형
구문 INTEGER
접근 읽기쓰기
상태 필수사항
기술 "이 경로에 대한 대체 경로선정 메트릭. 이 메트릭의 의미는 경로의 ipRouteProto 값에 명시된 경로선정 프로토콜에 의해 결정된다. 이 메트릭이 사용되지 않는다면, 그 값은 -1로 설정되어야 한다."
::= { ipRouteEntry 5 }

ipRouteMetric4 객체-유형
구문 INTEGER
접근 읽기쓰기
상태 필수사항
기술 "이 경로에 대한 대체 경로선정 메트릭. 이 메트릭의 의미는 경로의 ipRouteProto 값에 명시된 경로선정 프로토콜에 의해 결정된다. 이 메트릭이 사용되지 않는다면, 그 값은 -1로 설정되어야 한다."
::= { ipRouteEntry 6 }

ipRouteNextHop 객체-유형
구문 IpAddress
접근 읽기쓰기
상태 필수사항
기술 "이 경로의 다음 홉에 대한 IP 주소.(브로드캐스트 매체를 통해 실현 되는 인터페이스에 속한 경로의 경우에, 이 필드의 값은 그 인터페이 스에 관한 수행자의 IP 주소이다.)"
::= { ipRouteEntry 7 }
ipRouteType 객체-유형
구문 INTEGER {
other(1), -- 다음에 없는 것
invalid(2), -- 무효화된 경로
direct(3), -- 직접 연결된 (서브-) 네트워크
-- 로의 경로
indirect(4) -- 국부가 아닌 호스트/네트워크/
-- 서브-네트워크로의 경로
}
접근 읽기쓰기
상태 필수사항
기술 "경로 유형. direct(3)와 indirect(4) 값은 IP 구조 내의 직접 그리고 간접 경로선정의 개념을 나타낸다.

invalid(2) 값으로 이 객체를 설정하는 것은 ipRouteTable 객체에 있는 대응하는 엔트리를 무효화하는 것이다. 다시 말해서, 언급된 엔트로 구별되는 경로로부터 언급된 엔트리로 구별되는 목적지를 분리한다.

수행자가 테이블에서 무효화된 엔트리를 제거할지는 구현에 따르는 문제이다. 따라서, 관리 스테이션은 현재 사용하지 않는 엔트리에 대응하는 수행자들로 부터의 테이블 정보를 받을 준비가 되어 있어야 한다. 그런 엔트리에 대한 바른 해석은 관련 ipRouteType 객체의 검사를 요구한다."
::= { ipRouteEntry 8 }

ipRouteProto 객체-유형
구문 INTEGER {
other(1), -- 다음에 없는 것
local(2), -- 프로토콜이 아닌 정보 예를 들면, 수작업으로 구성된 엔트리
netmgmt(3), -- 네트워크 관리 프로토콜을 통해 설정
icmp(4), -- ICMP를 통해 얻어진 것
-- 예를 들면, 경로 재지정
-- 남은 값은 모든 게이트웨이 경로
-- 선택 프로토콜이다.
egp(5),
ggp(6),
hello(7),
rip(8),
is-is(9),
es-is(10),
ciscoIgrp(11),
bbnSpfIgp(12),
ospf(13),
bgp(14)
}
접근 읽기전용
상태 필수사항
기술 "경로를 알아내는 경로선정 메카니즘. 게이트웨이 경로선정 프로토콜
을 위한 값의 포함은 호스트가 그런 프로토콜을 지원해야한다는 것을
의미하려는 것은 아니다."
::= { ipRouteEntry 9 }

ipRouteAge 객체-유형
구문 INTEGER
접근 읽기쓰기
상태 필수사항
기술 "경로가 가장 최근에 이루어진 경로의 갱신 또는 경로가 교정되도록 결정된 이후에 경과된 초의 수. 주의할 점은 경로를 알아내는 경로 선택 프로토콜에 관한 이해없이는 어떠한 'too old'의 의미도 내포될
수 없다는 것이다."
::= { ipRouteEntry 10 }

ipRouteMask 객체-유형
구문 IpAddress
접근 읽기쓰기
상태 필수사항
기술 "ipRouteDest 필드에 있는 값과 비교되기 전에 목적지 주소와 마스크 를 논리적 AND 시키도록 지시. 임의의 서브네트 마스크를 지원하지 않는 시스템의 경우, 수행자는 대응하는 ipRouteDest 필드의 값이 등
급 - A, B, 또는 C 네트워크에 속하는지를 결정하고 다음 중 하나를 사용하여 ipRouteMask의 값을 구성한다.

마스크 네트워크
255.0.0.0 등급-A
255.255.0.0 등급-B
255.255.255.0 등급-C

ipRouteDest 값이 0.0.0.0라면(기본형 경로), 마스크 값은 또한 0.0.0.0이다. 모든 경로선정 IP 서브시스템이 암시적으로 이 메카니 즘을 사용한다는 것을 주목해야 한다."
::= { ipRouteEntry 11 }

ipRouteMetric5 객체-유형
구문 INTEGER
접근 읽기쓰기
상태 필수사항
기술 "이 경로에 대한 대체 경로선정 메트릭. 이 메트릭의 의미는 경로의 ipRouteProto 값에 명시된 경로선정 프로토콜에 의해 결정된다. 이 메트릭이 사용되지 않는다면, 그 값은 -1로 설정되어야 한다."
::= { ipRouteEntry 12 }

ipRouteInfo 객체-유형
구문 OBJECT IDENTIFIER
접근 읽기전용
상태 필수사항
기술 "경로의 ipRouteProto 값에 명시된 값에 의해 결정될 때, 이 경로에 책임이 있는 특정 경로선정 프로토콜에 대해서 특별한 MIB 정의에 대한 참조. 이 정보가 없다면, 그 값은 OBJECT IDENTIFIER { 0 0 }로
설정되어야 한다. 구문적으로 타당한 객체 식별자이고, ASN.1과 BER 을 준수하는 구현은 이 값을 생성하고 인식할 수 있어야 한다."
::= { ipRouteEntry 13 }

-- IP 주소 해석 테이블

-- IP 주소 해석 테이블은 '물리적' 주소와 동등 관계인 IpAddress를 포함한다. 몇몇 인터페이스는 동등 관계인 주소를 결정하기 위해 해석 테이블을 사용하지 않는다
-- (예를 들면, DDN-X.25는 알고리즘 방식을 갖는다). 모든 인터페이스가 이런 유형 이라면, 주소 해석 테이블은 비게한다. 다시 말해서, 엔트리를 갖지 않는다.

ipNetToMediaTable 객체-유형
구문 SEQUENCE OF IpNetToMediaEntry
접근 접근금지
상태 필수사항
기술 "IP 주소에서 물리적 주소로의 사상에 사용되는 IP 주소 해석 테이블."
::= { ip 22 }

ipNetToMediaEntry 객체-유형
구문 IpNetToMediaEntry
접근 접근금지
상태 필수사항
기술 "각 엔트리는 '물리적' 주소와 동등 관계인 하나의 IpAddress를 포함한다."
인덱스 { ipNetToMediaIfIndex,
ipNetToMediaNetAddress }
::= { ipNetToMediaTable 1 }

IpNetToMediaEntry ::=
SEQUENCE {
ipNetToMediaIfIndex
INTEGER,
ipNetToMediaPhysAddress
PhysAddress,
ipNetToMediaNetAddress
IpAddress,
ipNetToMediaType
INTEGER
}

ipNetToMediaIfIndex 객체-유형
구문 INTEGER
접근 읽기쓰기
상태 필수사항
기술 "이 엔트리의 동등 관계가 유효한 인터페이스. 이 인덱스의 특정 값에 의해 구별되는 인터페이스는 ifIndex와 동일한 값에 의해 구별되는 것과 같은 인터페이스이다."
::= { ipNetToMediaEntry 1 }

ipNetToMediaPhysAddress 객체-유형
구문 PhysAddress
접근 읽기쓰기
상태 필수사항
기술 "매체 의존적인 '물리적' 주소."
::= { ipNetToMediaEntry 2 }

ipNetToMediaNetAddress 객체-유형
구문 IpAddress
접근 읽기쓰기
상태 필수사항
기술 "매체 의존적인 '물리적' 주소에 대응하는 IpAddress."
::= { ipNetToMediaEntry 3 }

ipNetToMediaType 객체-유형
구문 INTEGER {
other(1), -- 다음에 없는 것
invalid(2), -- 무효화된 사상
dynamic(3),
static(4)
}
접근 읽기쓰기
상태 필수사항
기술 "사상의 유형.

이 객체를 invalid(2)로 설정하는 것은 ipNetToMediaTable에 있는 대응하는 엔트리를 무효화하는 것이다.

다시 말해서, 실제로 언급된 엔트리로 구별되는 사상으로 부터 언급된 엔트리로 구별되는 인터페이스를 분리한다. 수행자가 테이블에서 무효화된 엔트리를 제거할지는 구현에 따르는 문제이다.

따라서, 관리 스테이션은 현재 사용하지 않는 엔트리에 대응하는 수행자들로 부터의 테이블 정보를 받을 준비가 되어 있어야 한다. 그런 엔트리에 대한 바른 해석은 관련 ipNetToMediaType 객체의 조사를 요구한다."
::= { ipNetToMediaEntry 4 }

-- 추가되는 IP 객체

ipRoutingDiscards 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "엔트리들이 유효하더라도 버려지도록 선택된 경로선정 엔트리의 갯수. 그런 엔트리를 버리는 이유 중의 하나가 다른 경로 엔트리를 위해서 버퍼 공간을 비우는 행위가 될 수 있을 것이다."
::= { ip 23 }

6.4.7 ICMP 그룹

-- ICMP 그룹의 구현은 모든 시스템에 필수사항이다.

icmpInMsgs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "엔티티가 수신한 ICMP 메세지의 총 갯수. 이 카운터는 icmpInErrors 에 의해 계산된 것 모두를포함한다."
::= { icmp 1 }

icmpInErrors 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "엔티티가 수신했으나 ICMP 정의 오류(불량 ICMP 검사합, 길이 불량 등)를 가지고 있는 것으로 판명된 ICMP 메세지들의 갯수."
::= { icmp 2 }

icmpInDestUnreachs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "수신된 ICMP 목적지 도달 불가능 메세지의 갯수."
::= { icmp 3 }

icmpInTimeExcds 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "수신된 ICMP 시간 초과 메세지의 갯수."
::= { icmp 4 }

icmpInParmProbs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "수신된 ICMP 매개변수 문제 메세지의 갯수."
::= { icmp 5 }

icmpInSrcQuenchs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "수신된 ICMP 발신지 억제 메세지의 갯수."
::= { icmp 6 }

icmpInRedirects 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "수신된 ICMP 경로전환 메세지의 갯수."
::= { icmp 7 }

icmpInEchos 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "수신된 ICMP 에코우(요청) 메세지의 갯수."
::= { icmp 8 }

icmpInEchosReps 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "수신된 ICMP 에코우 응답 메세지의 갯수."
::= { icmp 9 }

icmpInTimestamps 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "수신된 ICMP Timestamp(요청) 메세지의 갯수."
::= { icmp 10 }

icmpInTimestampReps 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "수신된 ICMP Timestamp 응답 메세지의 갯수."
::= { icmp 11 }

icmpInAddrMasks 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "수신된 ICMP 주소 마스크 요청 메세지의 갯수."
::= { icmp 12 }

icmpInAddrMaskReps 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "수신된 ICMP 주소 마스크 응답 메세지의 갯수."
::= { icmp 13 }

icmpOutMsgs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "해당 엔티티가 송신하려고 시도했던 ICMP 메세지의 총 갯수. 이 카운터는 icmpOutErrors에 의해 계산된 모든 것을 포함한다."
::= { icmp 14 }

icmpOutErrors 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "해당 엔티티가 버퍼 부족과 같은 ICMP 내에서 발견되는 문제로 인해 송신하지 않은 ICMP 메세지의 갯수. 이 값은 IP의 결과로서 생성된 데이타그램의 경로를 정하지 못하는 것과 같은 ICMP 계층을 벗어나서
발견된 오류를 포함해서는 안된다. 몇가지 구현에서, 이 카운터 값의 원인인 오류 유형은 없다."
::= { icmp 15 }

icmpOutDestUnreachs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "송신된 ICMP 목적지 도착 불가능 메세지의 갯수."
::= { icmp 16 }

icmpOutTimeExcds 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "송신된 ICMP 시간 초과 메세지의 갯수."
::= { icmp 17 }

icmpOutParmProbs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "송신된 ICMP 매개변수 문제 메세지의 갯수."
::= { icmp 18 }

icmpOutSrcQuenchs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "송신된 ICMP 발신지 억제 메세지의 갯수."
::= { icmp 19 }

icmpOutRedirects 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "송신된 ICMP 경로전환 메세지의 갯수. 호스트의 경우, 이 객체는 항상 0이다. 호스트는 방향전환 메세지를 보내지 않기 때문이다."
::= { icmp 20 }

icmpOutEchos 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "송신된 ICMP 에코우 (요청) 메세지의 갯수."
::= { icmp 21 }

icmpOutEchoReps 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "송신된 ICMP 에코우 응답 메세지의 갯수."
::= { icmp 22 }

icmpOutTimestamps 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "송신된 ICMP Timestamp (요청) 메세지의 갯수."
::= { icmp 23 }

icmpOutTimestampReps 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "송신된 ICMP Timestamp 응답 메세지의 갯수."
::= { icmp 24 }

icmpOutAddrMasks 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "송신된 ICMP 주소 마스크 요청 메세지의 갯수."
::= { icmp 25 }

icmpOutAddrMaskReps 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "송신된 ICMP 주소 마스크 응답 메세지의 갯수."
"
::= { icmp 26 }

6.4.8 TCP 그룹

-- TCP 그룹의 구현은 TCP를 구현하는 모든 시스템에 필수사항이다.
-- 특정 TCP 접속에 대한 정보를 표현하는 객체 유형의 실체들은 일시적이다. 그 실체들은 접속이 끝남과 동시에 없어진다.

tcpRtoAlgorithm 객체-유형
구문 INTERGER {
other(1), -- 다음에 없는 것

constant(2), -- 상수 rto
rsre(3), -- MIL-STD-1778, 부록 B
vanj(4) -- Van Jacobson의 알고리즘[10]
}
접근 읽기전용
상태 필수사항
기술 "인정되지 않은 옥테트를 재전송하기 위해 사용되는 타임아웃 값을 결정하기 위해 사용되는알고리즘."
::= { tcp 1 }

tcpRtoMin 객체-유형
구문 INTEGER
접근 읽기전용
상태 필수사항
기술 "1/100 초 단위로 측정되는 재전송 타임아웃를 위한 TCP 구현에 의해 허용되는 최소 값. 이런 유형의 객체를 위한 좀 더 다듬어진 의미는 재전송 타임아웃을 판정하기 위해 사용되는 알고리즘에 의존한다. 특
히, 타임아웃 알고리즘이 rsre(3)일때, 이런 유형의 객체는 RFC 793 에서 기술된 LBOUND 양의 의미를 갖는다."
::= { tcp 2 }

tcpRtoMax 객체-유형
구문 INTEGER
접근 읽기전용
상태 필수사항
기술 "1/100 초 단위로 측정되는 재전송 타임아웃를 위한 TCP 구현에 의해 허용되는 최대 값. 이런 유형의 객체를 위한 좀 더 다듬어진 의미는 재전송 타임아웃을 판정하기 위해 사용되는 알고리즘에 의존한다. 특
히, 타임아웃 알고리즘이 rsre(3)일때, 이런 유형의 객체는 RFC 793 에서 기술된 UBOUND 양의 의미를 갖는다."
::= { tcp 3 }

tcpMaxConn 객체-유형
구문 INTEGER
접근 읽기전용
상태 필수사항
기술 "엔티티가 지원할 수 있는 TCP 접속의 총 갯수에 관한 제한. 연결의 최대 갯수가 유동적인 엔티티들에 대해, 이 객체는 -1 값을 포함해야 한다."
::= { tcp 4 }

tcpActiveOpens 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "TCP 접속이 CLOSED 상태에서 SYN-SENT 상태로의 직접적인 전이가 이 뤄진 횟수."
::= { tcp 5 }

tcpPassiveOpens 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "TCP 접속이 LISTEN 상태에서 SYN-RCVD 상태로의 직접적인 전이가 이뤄진 횟수."
::= { tcp 6 }

tcpAttemptFails 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "TCP 접속이 SYN-SENT 상태 또는 SYN-RCVD 상태에서 CLOSED 상태로의 직접적인 전이가 이뤄진 횟수와 TCP 접속이 SYN-RCVD 상태에서 LISTEN 상태로의 직접적인 전이가 이뤄진 횟수를 더한 것."
::= { tcp 7 }

tcpEstabResets 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "TCP 접속이 ESTABLISHED 상태 또는 CLOSE-WAIT 상태에서 CLOSED 상태로의 직접적인 전이가 이뤄진 횟수."
::= { tcp 8 }

tcpCurrEstab 객체-유형
구문 Gauge
접근 읽기전용
상태 필수사항
기술 "현 상태가 ESTABLISHED 또는 CLOSE-WAIT인 TCP 접속의 갯수."
::= { tcp 9 }

tcpInSegs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "오류로 수신된 것을 포함하여, 수신된 세그먼트의 총 갯수. 이 계산 은 현재 설정된 연결 상에서 수신된 세그먼트를 포함한다."
::= { tcp 10 }

tcpOutSegs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "현재 연결된 것을 포함하여 송신된 세그먼트의 총 갯수. 그러나 재전송되는 옥테트를 제외한다."
::= { tcp 11 }

tcpRetransSegs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "재전송되는 세그먼트의 총 갯수. 다시 말해서, 이전에 한번이상 전송 된 옥테트들을 포함하여 전송되는 TCP 세그먼트의 갯수."
::= { tcp 12 }

-- TCP 접속 테이블
-- TCP 접속 테이블은 해당 엔티티에 존재하는 TCP 접속에 관한 정보를 포함한다.

tcpConnTable 객체-유형
구문 SEQUENCE OF TcpConnEntry
접근 접근금지
상태 필수사항
기술 "TCP 접속 정의 정보를 포함하는 테이블."
::= { tcp 13 }

tcpConnEntry 객체-유형
구문 TcpConnEntry
접근 접근금지
상태 필수사항
기술 "현재 특정한 TCP 접속에 대한 정보. 이 유형의 객체는 일시적이다.
그런 점에서, 연결이 CLOSED 상태로 전이할 때 이 객체의 존재는 사라진다."
인덱스 { tcpConnLocalAddress,
tcpConnLocalPort,
tcpConnRemAddress,
tcpConnRemPort }
::= { tcpConnTable 1 }

tcpConnEntry ::=
SEQUENCE {
tcpConnState
INTEGER,
tcpConnLocalAddress
IpAddress,
tcpConnLocalPort
INTEGER (0..65535),
tcpConnRemAddress
IpAddress,
tcpConnRemPort
INTEGER (0..65535)
}

tcpConnState 객체-유형
구문 INTEGER {
closed(1),
listen(2),
synSent(3),
synReceived(4),
established(5),
finWait1(6),
finWait2(7),
closeWait(8),
lastAck(9),
closing(10),
timeWait(11),
deleteTCB(12)
}
접근 읽기쓰기
상태 필수사항
기술 "해당 TCP 접속의 상태.

관리 스테이션에 의해 설정될 수 있는 유일한 값이 deleteTCB(12)이다. 따라서, 관리 스테이션이 이 객체를 어떤 다른 값으로 설정하려 한다면, 수행자가 'badValue' 응답을 반환하는 것이 합당하다.

관리 스테이션이 이 객체를 deleteTCB(12)로 설정한다면, 이것은 피관리 노드 상에 있는 대응하는 연결의 TCB를 제거하고 바로 그 연결 을 해제한다.

구현에 따른 선택사항으로, RST 세그먼트는 피관리 노드에서 다른 TCP 종점으로 보내질 수 있다(그러나, 주목해야할 점은 RST 세그먼트 는 비신뢰적으로 송신된다는 것이다)."
::= { tcpConnEntry 1 }

tcpConnLocalAddress 객체-유형
구문 IpAddress
접근 읽기전용
상태 필수사항
기술 "해당 TCP 접속을 위한 국부 IP 주소. 그 노드에 접속된 IP 인터페이 스를 위한 연결을 받아들이는 LISTEN 상태에 있는 연결에 대해, 값 0.0.0.0이 사용된다."
::= { tcpConnEntry 2 }

tcpConnLocalPort 객체-유형
구문 INTEGER (0..65535)
접근 읽기전용
상태 필수사항
기술 "해당 TCP 접속을 위한 국부 포트 번호."
::= { tcpConnEntry 3 }

tcpConnRemAddress 객체-유형
구문 IpAddress
접근 읽기전용
상태 필수사항
기술 "해당 TCP 접속을 위한 원격 IP 주소."
::= { tcpConnEntry 4 }

tcpConnRemPort 객체-유형
구문 INTEGER(0..65535)
접근 읽기전용
상태 필수사항
기술 "해당 TCP 접속을 위한 원격 포트 번호."
::= { tcpConnEntry 5 }

-- 추가되는 TCP 객체

tcpInErrs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "오류로 수신된 세그먼트의 총 갯수(예를 들면, 불량 TCP 검사합)."
::= { tcp 14 }

tcpOutRsts 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "RST 플래그를 포함하는 송신된 TCP 세그먼트의 갯수."
::= { tcp 15 }

6.4.9 UDP 그룹

-- UDP 그룹의 구현은 UDP를 구현하는 모든 시스템에 필수사항이다.

udpInDatagrams 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "UDP 사용자들에게 전달되는 UDP 데이타그램의 총 갯수."
::= { udp 1 }

udpNoPorts 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "목적지 포트에 응용 프로그램이 없는 경우, 수신된 UDP 데이타그램의 총 갯수."
::= { udp 1 }

udpInErrors 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "목적지 포트에서 응용 프로그램의 문제 이외의 이유로 전달될 수 없는 수신된 UDP 데이타그램의 갯수."
::= { udp 3 }

udpOutDatagrams 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "해당 엔티티로 부터 송신된 UDP 데이타그램의 총 갯수."
::= { udp 4 }

-- UDP Listener 테이블

-- UDP Listener 테이블은 국부 응용이 현재 데이타그램을 받아들이는 해당 엔티티의UDP 종단점에 대한 정보를 포함한다.

udpTable 객체-유형
구문 SEQUENCE OF UdpEntry
접근 접근금지
상태 필수사항
기술 "UDP Listener 정보를 포함하는 테이블."
::= { udp 5 }

udpEntry 객체-유형
구문 UdpEntry
접근 접근금지
상태 필수사항
기술 "특정한 현재 UDP Listener에 관한 정보."
인덱스 { updLocalAddress,
udpLocalPort }
::= { udpTable 1 }

UdpEntry ::=
SEQUENCE {
udpLocalAddress
IpAddress,
udpLocalPort
INTEGER(0..65535)
}

udpLocalAddress 객체-유형
구문 IpAddress
접근 읽기전용
상태 필수사항
기술 "이 UDP Listener에 대한 국부 IP 주소. 그 노드에 접속된 IP 인터페이스를 위한 데이타그램을 받아들이는 UDP Listener에 대해, 값 0.0.0.0이 사용된다."
::= { udpEntry 1 }

udpLocalPort 객체-유형
구문 INTEGER(0..65535)
접근 읽기전용
상태 필수사항
기술 "이 UDP Listener에 대한 국부 포트 번호."
::= { udpEntry 2 }

6.4.10 EGP 그룹

-- EGP 그룹의 구현은 EGP를 구현하는 모든 시스템에 필수사항이다.

egpInMsgs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "오류없이 수신된 EGP 메세지의 갯수."
::= { egp 1 }

egpInErrors 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "오류로 판명되어 수신된 EGP 메세지의 갯수."
::= { egp 2 }

egpOutMsgs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "국부적으로 생성된 EGP 메세지의 총갯수."
::= { egp 3 }

egpOutErrors 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "EGP 엔티티 내에 있는 자원 제한때문에 송신되지 않아서 국부적으로 생성된 EGP 메세지의 갯수."
::= { egp 4 }

-- EGP 이웃 노드 테이블

-- EGP 이웃 노드 테이블은 해당 엔티티의 EGP 이웃 노드들에 대한 정보를 포함한다.

egpNeighTable 객체-유형
구문 SEQUENCE OF EgpNeighEntry
접근 접근금지
상태 필수사항
기술 "EGP 이웃 노드 테이블."
::= { egp 5 }

egpNeighEntry 객체-유형
구문 EgpNeighEntry
접근 접근금지
상태 필수사항
기술 "해당 엔티티의 특정 EGP 이웃 노드와의 관계에 관한 정보."
인덱스 { egpNeighTable 1 }
::= { egpNeighTable 1 }

EgpNeighEntry ::=
SEQUENCE {
egpNeighState
INTEGER,
egpNeighAddr
IpAddress,
egpNeighAs
INTEGER,
egpNeighInMsgs
Counter,
egpNeighInErrs
Counter,
egpNeighOutMsgs
Counter,
egpNeighOutErrs
Counter,
egpNeighInErrMsgs
Counter,
egpNeighOutErrMsgs
Counter,
egpNeighStateUps
Counter,
egpNeighStateDowns
Counter,
egpNeighIntervalHello
INTEGER,
egpNeighIntervalPoll
INTEGER,
egpNeighMode
INTEGER,
egpNeighEventTrigger
INTEGER
}

egpNeighState 객체-유형
구문 INTEGER {
idle(1),
acquisition(2),
down(3),
up(4),
cease(5)
}
접근 읽기전용
상태 필수사항
기술 "해당 엔트리의 EGP 이웃 노드에 관한 국부 시스템의 EGP 상태. 각 EGP 상태는 RFC 904에서 언급된 상태와 연관된 수치보다 1 더 큰 수 치로 표현된다."
::= { egpNeighEntry 1 }

egpNeighAddr 객체-유형
구문 IpAddress
접근 읽기전용
상태 필수사항
기술 "해당 엔티티의 EGP 이웃 노드의 IP 주소."
::= { egpNeighEntry 2 }

egpNeighAs 객체-유형
구문 INTEGER
접근 읽기전용
상태 필수사항
기술 "해당 EGP의 상대 EGP인 독립적 시스템. 이웃 노드의 자율 시스템 번호가 아직 알려지지 않으면, 0이 명시되어야 한다."
::= { egpNeighEntry 3 }

egpNeighInMsgs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "해당 EGP의 상대 EGP로 부터 오류없이 수신된 EGP 메세지의 갯수."
::= { egpNeighEntry 4 }

egpNeighInErrs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "오류로 판명된 해당 EGP의 상대 EGP로 부터 수신된 EGP 메세지의 갯수(예를 들면, 불량 EGP 검사합)."
::= { egpNeighEntry 5 }

egpNeighOutMsgs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "해당 상대 EGP로 국부적으로 생성된 EGP 메세지의 갯수."
::= { egpNeighEntry 6 }

egpNeighOutErrs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "EGP 엔티티 내의 자원 제한때문에 상대 EGP로 송신되지 못한 국부적으로 생성된 EGP 메세지의 갯수."
::= { egpNeighEntry 7 }

egpNeighInErrMsgs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "상대 EGP로 부터 수신된 EGP 정의 오류 메세지의 갯수."
::= { egpNeighEntry 8 }

egpNeighOutErrMsgs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "상대 EGP로 송신된 EGP 정의 오류 메세지의 갯수."
::= { egpNeighEntry 9 }

egpNeighStateUps 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "상대 EGP의 UP 상태로의 EGP 상태전이 갯수."
::= { egpNeighEntry 10 }

egpNeighStateDowns 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "상대 EGP의 UP 상태에서 다른 상태로의 EGP 상태전이 갯수."
::= { egpNeighEntry 11 }

egpNeighIntervalHello 객체-유형
구문 INTEGER
접근 읽기전용
상태 필수사항
기술 "EGP Hello 명령어 재전송 사이의 간격(1/100초 단위). 이것은 RFC 904에 정의된 것으로 t1 타이머를 나타낸다."
::= { egpNeighEntry 12 }

egpNeighIntervalPoll 객체-유형
구문 INTEGER
접근 읽기전용
상태 필수사항
기술 "EGP 폴 명령어 재전송 사이의 간격(1/100초 단위). 이것은 RFC 904에 정의된 것으로 t3 타이머를 나타낸다."
::= { egpNeighEntry 13 }

egpNeighMode 객체-유형
구문 INTEGER { active(1), passive(2) }
접근 읽기전용
상태 필수사항
기술 "EGP 엔티티의 폴링 모드. 수동 또는 능동의 값을 갖는다."
::= { egpNeighEntry 14 }

egpNeighEventTrigger 객체-유형
구문 INTEGER { start(1), stop(2) }
접근 읽기쓰기
상태 필수사항
기술 "운용자에 의해 개시된 시작과 종료사건을 기동하는데 사용되는 제어변수. 판독할 경우에는 이 변수는 항상 egpNeighEventTrigger에게 설정된 가장 최근의 값을 반환한다. 만약 노드상의 네트워크 관리 서브
시스템의 마지막 초기화후 egpNeighEventTrigger가 설정되어있지 않았다면 'stop'이라는 값을 반환한다.

설정시에는, RFC 904의 8-10페이지에 명시된 것같이 이 변수가 시작 사건이거나 종료사건을 명시된 이웃 상에서 일으키게 한다. 간단하게 말해서, 시작사건은 Idle 상태의 이웃 노드가 이웃 노드의 acquisition 상태를 시작할 수 있도록 해주고, Idle 상태가 아닌 상대 노드가 이웃 노드의 acquisition 상태를 재초기화하도록 한다.

종료사건은 Idle 상태가 아닌 상대 노드가 시작사건이 일어날 때까지 Idle 상태를 유지시킨다. 이때 egpNeighEventTrigger 또는 다른 것을 이용한다."
::= { egpNeighEntry 15 }

-- 추가되는 EGP 객체

egpAs 객체-유형
구문 INTEGER
접근 읽기전용
상태 필수사항
기술 "이 EGP 엔티티의 독립적 시스템 갯수."
::= { egp 6 }

6.4.11 전송 그룹

-- 어떤 시스템 상의 각 인터페이스의 기초를 이루는 전송 매체에 근거하여 전송그룹과 일치하는 부분이 그 시스템에 대하여 의무적인 사항이 된다.

-- 전송 매체를 관리하기 위한 인터네트 표준 정의가 내려질때, 전송그룹은 그들 객체들의 접두어를 제공하기 위해 사용된다.

-- 실제로, 그런 정의들은 "입증"될때까지 MIB의 실험적 부분에 속하며, 그후에 인터네트 표준화 과정의 한 부분으로서 그 정의들은 적절하게 향상되어 전송그룹 내에 새로운 객체 식별자가 정의된다. 규정에 의해, 할당된 이름은 다음과 같다.

-- type OBJECT IDENTIFIER ::= { transmission number }
-- "type"은 ifTable 객체의 ifType 열 내에 있는 매체를 위해 사용되는 기호값이며 "number"는 그 기호에 대응하는 실제 정수 값이다."

6.4.12 SNMP 그룹

-- SNMP 그룹을 구현하는 것은 SNMP 프로토콜 엔티티를 유지하는 모든 시스템에 필수사항이다.

다음에 정의된 객체들 중 어떤 것은 관리 수행자 또는 관리 스테이션에 명시된 기능들만을 지원하도록 최적화된 SNMP 구현에서 0의 값이 된다. 특히, 주의해야할 것은 아래의 객체들은 SNMP 엔티티를 언급하고, 몇몇 SNMP 엔티티들은 관리 노드에 속할 수 있다는 것이다(예를 들면, 만약 노드가 관리 스테이
-- 션처럼 호스트 역할을 한다면).

snmpInPkts 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "전송 서비스로 부터 SNMP 엔티티로 전달된 메세지들의 총 갯수."
::= { snmp 1 }

snmpOutPkts 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티로 부터 전송 서비스에게 전달되는 SNMP 메세지의 총 갯수."
::= { snmp 2 }

snmpInBadVersions 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 전달되었으나 지원되지 않는 SNMP 버전에 대한 SNMP 메세지의 총 갯수."
::= { snmp 3 }

snmpInBadCommunityNames 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "언급된 엔티티에게는 알려지지않은 SNMP 공동체 명을 사용하여 SNMP프로토콜 엔티티에게 전달된 SNMP 메세지의 총 갯수."
::= { snmp 4 }

snmpInBadCommunityUses 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "전달된 메세지 내에 있는 SNMP 공동체 이름에 의거하여 허가되지 않 은 어떤 SNMP 동작을 갖는 SNMP 프로토콜 엔티티에게 전달되었던 SNMP 메세지의 총 갯수."
::= { snmp 5 }

snmpInASNParseErrs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "수신된 SNMP 메세지를 복호화할 때 SNMP 프로토콜 엔티티가 접하는 ASN.1이나 BER 오류의 총 갯수."
::= { snmp 6 }

-- { snmp 7 }은 사용되지 않는다.

snmpInTooBigs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에게 전달되고 오류 상태 필드 값이 'too big' 인 SNMP PDU들의 총 갯수."
::= { snmp 8 }

snmpInNoSuchNames 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에게 전달되고 오류 상태 필드의 값이 'noSuchName'인 SNMP PDU들의 총 갯수."
::= { snmp 9 }

snmpInBadValues 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에게 전달되고 오류 상태 필드의 값이 'badValue'인 SNMP PDU들의 총 갯수."
::= { snmp 10 }

snmpInReadOnlys 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에게 전달되고 오류 상태 값이 'readOnly'인 유효한 SNMP PDU들의 총 갯수. 주의해야할 점은 오류 상태 필드에 'read only' 값을 담고 있는 SNMP PDU를 생산하는 것은 프로토콜 오
류라는 것이다. 이와같이, 이 객체는 SNMP의 잘못된 구현을 탐지하는 수단으로서 제공된다."
::= { snmp 11 }

snmpInGenErrs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에게 전달되고 오류 상태 값이 'genErr'인 유효한 SNMP PDU들의 총 갯수."
::= { snmp 12 }

snmpInTotalReqVars 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "유효한 SNMP Get-Request와 Get-Next PDU를 수신한 결과로써 SNMP 프로토콜 엔티티에 의해서 성공적으로 회수된 MIB 객체들의 총 갯수."
::= { snmp 13 }

snmpInTotalSetVars 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "유효한 SNMP Set-Request PDU를 수신한 결과로써 SNMP 프로토콜 엔티티에 의해서 성공적으로 회수된 MIB 객체들의 총 갯수."
::= { snmp 14 }

snmpInGetRequests 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 의해서 받아들여져서 처리된 SNMP Get-Request PDU의 총 갯수."
::= { snmp 15 }

snmpInGetNexts 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 의해서 받아들여져서 처리된 SNMP Get-Next PDU의 총 갯수."
::= { snmp 16 }

snmpInSetRequests 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 의해서 받아들여져서 처리된 SNMP Set-Request PDU의 총 갯수."
::= { snmp 17 }

snmpInGetResponses 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 의해서 받아들여져서 처리된 SNMP Get-Response PDU의 총 갯수."
::= { snmp 18 }

snmpInTraps 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 의해서 받아들여져서 처리된 SNMP Trap PDU 의 총 갯수."
::= { snmp 19 }

snmpOutTooBigs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 의해서 생산되고 오류 상태 필드의 값이 'tooBig'인 SNMP PDU들의 총 갯수."
::= { snmp 20 }

snmpOutNoSuchNames 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 의해서 생산되고 오류 상태 필드의 값이 'noSuchName'인 SNMP PDU들의 총 갯수."
::= { snmp 21 }

snmpOutBadValues 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 의해서 생산되고 오류 상태 필드의 값이 'badValue'인 SNMP PDU들의 총 갯수."
::= { snmp 22 }

-- { snmp 23 }은 사용되지 않는다.

snmpOutGenErrs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 의해서 생산되고 오류 상태 필드의 값이 'genErr'인 SNMP PDU들의 총 갯수."
::= { snmp 24 }

snmpOutGetRequests 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 의해서 생산된 SNMP Get-Request PDU들의 총 갯수."
::= { snmp 25 }

snmpOutGetNexts 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 의해서 생산된 SNMP Get-Next PDU들의 총 갯수."
::= { snmp 26 }

snmpOutSetRequests 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 의해서 생산된 SNMP Set-Request PDU들의 총갯수."
::= { snmp 27 }

snmpOutGetResponses 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 의해서 생산된 SNMP Get-Response PDU들의 총 갯수."
::= { snmp 28 }

snmpOutTraps 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 의해서 생산된 SNMP Trap들의 총 갯수."
::= { snmp 29 }

snmpEnableAuthenTraps 객체-유형
구문 INTEGER { enabled(1), disabled(2) }
접근 읽기쓰기
상태 필수사항
기술 "SNMP 수행자 프로세스가 인증 실패 트랩들을 생성하도록 허용되었는지의 여부를 가리킨다. 이 객체의 값은 어떠한 구성 정보도 무시한다.

즉, 어떤 방법을 제공하는데 그 방법에 의해서 모든 인증 실패 트랩들이 생성될 수 없다.

이 객체들을 비휘발성 기억소자에 저장하여 네트워크 관리 시스템의 재초기화 사이의 변함없는 값을 유지할 수 있도록 할 것이 강력히 권고되고 있음을 유의하여야 한다."
::= { snmp 30 }

6.5 참고 문헌

[1] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, IAB, April 1988.

[2] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets," RFC 1065, TWG, August 1988.

[3] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1066, TWG, August 1988.

[4] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC 1109, IAB, August 1989.

[5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol(SNMP)", RFC 1098, University of Tennessee at Knoxville, NYSERNet, Inc., Rensselaer Polytechnic Institute, MIT Laboratory for
Computer Science, April 1989.

[6] Postel, J., and J. Reynolds, "TELNET Protocol Specification", RFC 854, USC/Information Sciences Institute, May 1983.

[7] Satz, G., "Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) Management Information Base", RFC1162, cisco Systems, Inc., June 1990.

[8] Information porcessing systems - Open Systems Interconnection, "Specification of Abstract Syntax Notation One(ASN.1)", International Organization for Standardization, International Standard 8824, December
1987.

[9] Information porcessing systems - Open Systems Interconnection, "Specification of Basic Encoding Rules for Abstract Syntax Notation One(ASN.1)", International Organization for Standardization, International
Standard 8825, December 1987.

[10] Jacobson, V., "Congestion Avoidance and Control", SIGCOMM 1988, Stanford, California.

[11] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as a Subnetwork for Experimentation with the OSI Network Layer", RFC 1070, U of Wiscsonsin - Madison, U of Wiscsonsin - Madison, The Wollongong Group, February 1989.

[12] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990.

[13] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple Network Management Protocol", RFC 1157, University of Tennessee at Knoxville, Performance Systems International, and the MIT Laboratory for COmputer
Science, May 1990.

[14] Rose, M., and K. McCloghrie, Editor, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems March 1991.

보 칙

1. 이 표준에서 정하지 아니한 사항에 대하여는 "전산망 기술기준에 관한 규칙"의 관계 규정을 적용한다.

부 칙

1. 이 표준은 1994년 3월 1일 부터 시행한다.

Posted by 두장

TAG Protocol, snmp

트랙백0 댓글0