RadarURL
Skip to content
2009.09.28 18:48

Openet

조회 수 3586 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄

네이버 지식iN에서 가져온 글입니다.


 


 


과거 네트워크 관리하면 대부분 어드레스를 설정하고, 장비를 컨피규레이션하는 등의 구성 관리와 네트워크를 감시하고, 그것을 통제하는 장애 관리에 많이 매달려 왔다. 그것은 현재도 마찬가지다. 한 조사 기관의 발표에 따르면 기업의 관리 영역 중 장애 관리가 60%를 차지하고 있는 것으로 나타났다.



트래픽 관리의 등장

90년대 말부터는 구성과 장애 관리를 벗어나 성능 관리가 점차 주제거리로 등장하기 시작한다. 성능 관리는 겉으로는 드러나지 않지만 네트워크의 투자 가치를 효율적으로 향상시키고, 네트워크 품질을 높이는데 주목한다.



하지만 문제는 구성, 장애, 성능 등에 대한 관리는 모두 정적(static)인 부분에 초점을 맞추고 있다는 점이다. ‘지금 현재 라우터의 메모리가 부족하다. 회선 속도가 느리다’ 등 특정 분야만을 평가하는 관리였다.

그 러나 네트워크는 상당히 동적인 존재다. 사용자가 인터넷에 접속하는 과정만 살펴봐도 브라우저를 열고, 원하는 페이지의 URL을 치면 허브를 거쳐 라우터까지 도착하고, 여기서 2개 이상의 경로 중 하나를 선택해 ISP나 망 사업자 서버에 액세스하게 되고, 서버 앞에서 대기했다가 필요한 정보를 꺼내 다시 사용자에게 돌아오는 것이다. 이처럼 네트워크는 액세스, 패턴, 사용자, 경로 모든 것이 동적으로 변하는 유기적인 존재다.



이런 네트워크의 특성을 제대로 반영하면서 거시적인 관점에서 네트워크를 관리하고자 하는 목적에서 등장한 것이 트래픽 관리다. 트래픽 관리는 네트워크나 시스템 관리에서 발전된 다음 단계의 주제다.

트래픽 관리의 목적은 제한된 자원을 이용해 최상의 서비스 품질을 보장하는 것이다. 여기서 자원은 시간, 돈, 관리 인력의 능력일 수도 있고, 네트워크 장비 자체의 성능일 수도 있다.



트래픽의 유형과 특성

트 래픽 관리는 크게 관리 대상, 관리 속성, 관리 툴의 3가지 요소로 구성돼 있다. 첫 번째 관리 대상은 트래픽의 유형을 파악하는 작업이다. 초기의 트래픽은 싱글 미디어였기 때문에 단순했다. 즉, 음성과 같은 단일 미디어를 초당 8000번(8Kbps)의 속도로 샘플링해서 디지털화시켜 전달하기만 하면 된다. 음성은 끊어지지 않고 균일한 속도로 대역폭을 100% 차지하면서 통신한다. 여기서 트래픽 관리는 회선의 사용 여부만 살피면 되기 때문에 쉽다. 경로도 단순해 양단의 전화와 전화가 연결되는 경로가 잘 연결돼 있는가만 살펴보면 관리 끝이다.

음성 이후에 등장한 두번째 유형의 트래픽은 온라인 트랜잭션이다. 온라인 트랜잭션의 대표적인 예는 은행 거래에서 찾아 볼 수 있다. 고객이 은행에 입출금하기 위해서는 단말기에 이름과 계좌번호, 액수 등을 입력하게 된다. 이 트래픽이 호스트로 전달되고 호스트에서 처리 과정을 거쳐 다시 단말기로 돌아오고 화면에 필요한 정보가 나타난다.



온라인 트랜잭션은 아무리 데이터가 커도 총 트래픽의 양은 2∼3초 당 최대 2KB를 넘지 않는다. 이 경우, 전체 트래픽 사용량은 네트워크 사용자 총 수×초당 트래픽 사용량으로 쉽게 측정할 수 있다.

그 러나 80년대부터 LAN이 등장하면서 상황은 달라지기 시작했다. 가장 단순한 클라이언트/서버 환경은 로컬에 위치한 1대의 서버에 다수의 사용자들이 액세스하는 것이다. 그러나 사용자가 늘고, 전자우편이나 인트라넷이 필요하면서 서버가 늘어나게 되고, 사용자들은 2개 이상의 서버에 액세스하게 됐다(그림 1). 이로서 한 네트워크에 2개 이상의 경로가 존재하게 되고 이 때문에 서로 충돌이 일어나게 된다. 이 순간이 바로 트래픽 관리에서 큰 전환점이 되는 시점이다.



LAN 트래픽이 온라인 트랜잭션이나 음성과 크게 다른 점은 대용량의 데이터가 순간적으로 전달된다는 점에 있다(화면 1). 관리의 용이함은 예측 가능한가 그렇지 않은가로 판명할 수 있다. LAN 트래픽은 앞서 말한 바로 그런 특성 때문에 상당히 관리가 어렵다.

LAN의 등장과 더불어 트래픽 관리 분야에서는 더욱 더 골치 아픈 문제가 생겼다. 최근 10년 사이에 네트워크 시대가 본격적으로 시작되면서 화상이 새로운 미디어로 등장하게 된 것이다. 동화상 역시 예측불가능한 특성을 그대로 가지고 있다(화면 2, 3).



트래픽 관리의 기준

트 래픽은 절대량과 지연 민감도의 2가지 측면에서 평가해야 한다. (그림 2)와 같이 현존하는 트래픽들은 각기 다른 특성을 보유하고 있다. 이점이 트래픽 관리를 어렵게 만드는 요소다. 화상의 경우도 만약 화상만이 존재하는 네트워크라면 관리가 그리 어렵지 않을 것이다. 인터넷 환경이 보급되고 LAN과 WAN 개념이 모호해지는 현 상황에서는 전송 기법이 문제가 아니라 트래픽이 공존한다는 사실이 가장 큰 골치거리다.

대역폭을 적게 소모하지만 지연에 민감한 음성과 갑작스럽게 많은 양이 쏟아져 들어오는 파일 전송이 함께 일어난다면 음질을 보호할 것인가 속도를 보장할 것인가, 이 물음 자체가 바로 트래픽 관리의 본질에 대한 해답이다.

트 래픽 관리란 우선 순위 관리인 것이다. 트래픽들이 모두 동일한 속성을 갖고 있다면 들어오는 대로 처리하면 되므로 우선 순위를 이야기할 필요가 없지만, 현재 트래픽들은 각기 다른 속성들이 있기 때문에 우선 순위가 중요하게 등장한다. 이 우선 순위 보장을 위해 업체들은 다양한 기술을 선보이고 있다. 한창 주가가 오르고 있는 QoS 역시 궁극적인 목적은 우선 순위의 보장이며, 이는 다시 말하면 트래픽 관리를 위한 기법인 것이다.



QoS 보장의 지표 6가지

앞서 트래픽 관리란 QoS와 밀접한 관련이 있음을 살펴봤다. 이번에는 QoS를 보장하기 위한 몇 가지 지표에 대해 알아보자. QoS는 아래 등장하는 지표들 간의 상관 관계를 어떻게 잘 엮어 가는가에 달려 있다.



처리율(throughput)

가 장 바람직한 네트워크 모델은 인입된 모든 데이터가 단 하나의 손실도 없이 처리 과정을 거쳐 인출되는 것이다. 그러나 언제나 트래픽은 100% 처리되지 못한다. 이유는 들어오는 데이터는 순간적으로 너무 많고, 처리하는 장비들의 자원은 항상 한정돼 있으며, 출력하는 포트의 속도는 언제나 입력 포트보다 느리기 때문이다.



이용률(Utilization)

이 용률은 보유한 네트워크 자원을 얼마나 잘 사용하고 있는가를 말한다. 이용률은 백분율로 나타낼 수 있는데, 분모는 나의 능력이 되고 분자는 이동하고 있는 데이터 트래픽의 양이 된다. 능력은 고정돼 있으며 능력 이상의 일은 할 수 없다. 때문에 어떤 경우도 이용률은 100% 이상이 될 수 없다.

돈을 투자한 바에는 욕심으로는 100%를 이용하는 게 좋지만 현실은 그렇지 못하다. 사람도 능력 이상의 작업을 하면 피로를 느끼듯이 장비들도 피로를 느끼게 된다. 회선의 경우 무슨 문제가 있겠는가 하겠지만, 실상은 회선을 연결하는 양쪽 장비가 피로해진다는 이야기다.

그런 면에서 이용률은 항상 어느 정도까지 부하를 거는 것이 좋은가 하는 임계치를 설정하는 작업으로 이어진다.



전 용회선의 경우 85%에서 88% 수준에 이르면 피로 현상이 나타나고, 데이터 패킷이 분실된다. 그럼 막무가내로 85%로 유지하는 것이 바람직한가. 그렇지는 않다. 전용회선 서비스 업체의 경우, 이용률이 50% 이상을 넘게 되면 사용자들이 불평하기 시작할 것이다. 때문에 일반 기업보다도 서비스 업체들의 임계치는 낮게 책정될 수밖에 없다. 이용률의 결정은 해당 네트워크의 특성과 네트워크 관리자의 경험에 의해 복합적으로 결정된다.



패킷 손실(Loss)

패킷 손실은 QoS를 보장함에 있어 가장 치명적인 요소다. 앞서 말했듯이 데이터 트래픽은 송신자가 만들어 보낸 데이터가 수신자한테 정확하게 100% 전달되는 것을 목표로 하는데, 현실은 그렇지 못하다. 어디서인가 패킷 손실이 발생하게 된다. 회선에서, 스위칭 허브에서, 라우터에서 어디에서나 패킷이 분실될 위험이 있다.

라우터는 전형적으로 패킷 손실이 많이 발생하는 장비다. 사실 라우터는 데이터 통신쪽에서 볼 때 가장 불쌍한 장비 중 하나다. 24시간 의도하지 않게 갑자기 데이터가 많이 들어왔다가 한순간에 빠져 나간다. 이처럼 입력 편차가 심한 가운데서 자신의 능력을 벗어나면 패킷 손실이 발생한다. 패킷 손실이 일어나는 원인은 두 가지다. 라우터와 같은 장비가 가진 능력에 비해 더 많은 처리를 요구할 때와 장애가 발생했을 경우다.



지연 시간과 레이턴시(delay time & latency)

지연은 한 송신지에서 다른 수신지까지 트래픽이 전달되는데 걸리는 시간이다. 사용자의 관점에서 보면 데이터를 요구하고 난 후 응답이 돌아올 때까지 걸리는 시간 즉, 응답 시간이다.

기술적으로 보면 특정 노드에서 특정 노드로 가는데 걸리는 시간은 짧을수록 좋다. 그러나 항상 어느 정도는 느릴 수밖에 없는 절대 시간이 있다. 아무리 속도를 높여도 사용자들은 곧바로 빨라진 속도에 익숙해지기 때문이다.

몇 년전만 해도 2400bps 모뎀을 쓰던 시절이 있었다. 이후에 4800bps으로 속도가 늘어났다고 해서 사용자들의 만족도가 2배로 높아졌을까. 그렇지 않다. E1을 설치해도, 10Mbps를 독점해서 사용해도 사용자들은 시간이 흐르면 응답 속도가 불만족스럽다고 말할 것이다.

레이턴시는 지연 시간보다 조금 더 수준이 높은 관리 지표다. 이는 평상시에 평균적 지연 시간과 한순간에 그 트래픽이 전달되는 지연 시간과의 편차를 말한다.



레 이턴시가 크면 클수록 사용자들의 불만은 높아진다. (그림 3)에서 B는 평상시에 1초라는 짧은 응답 시간을 기록했지만 어느 순간에 4초를 어느 순간에는 5초를 기록하는 등 상당히 레이턴시가 크다. 이렇게 편차가 클 경우는 아무리 평상시 1초로 응답 시간이 빨라도 평균 4초를 기록한 A에 비해 사용자들은 불만족을 표시하게 된다.

많은 경우, 트래픽 문제를 개선한다면서 평균적인 응답 속도만 높이기에 급급하는 경우가 있다. 그러나 이것은 비용에 비해 효과가 크지 않다. 평균 응답 시간 1초를 0.5초로 끌어 내리려면 비용을 2배 이상 들여야 한다. 반면, 우발적으로 나빴던 즉, 응답 편차가 컸던 원인을 찾아서 해결하면 그 절반의 비용으로 효과는 더욱 크게 볼 수 있다. 인터넷 이용자들은 빠르다 갑자기 느려지면 가장 느렸던 순간의 품질을 해당 네트워크의 품질로 생각하기 때문이다.



가용성(available)

가용성이란 네트워크 서비스를 하기로 예정된 시점에서 서비스가 당연히 일어나는 것을 말한다. 가용성은 어느 사이트나 24시간 365일 서비스해야 한다는 의미가 아니다. 가용성은 ‘실제 서비스 시간/예정된 서비스 시간’이다. 가용성을 나타내는 데는 다음과 같은 보조 지표가 사용되기도 한다.

MTTR(Mean Time To Repair)
MTBF(Mean Time Between Failure)

모 든 장비들은 고장이나 장애가 발생할 수 있다. MTTR은 고장과 고장 사이 시간의 평균이다. 이 시간은 길수록 좋다. 무한대면 영원이 고장이 나지 않는다는 말이다. MTBF는 수리에 걸렸던 시간의 평균이다. 이것은 짧을수록 좋다.



트래픽 관리의 프로세스

트 래픽 관리의 첫 단계는 모니터링이다. 그냥 바라보는 것이 아니라 ‘충돌율이 심하다’ ‘처리율이 적다’ 등 앞서 말한 여러 지표를 기준으로 감시하는 것이다. 모니터링 다음 단계는 분석을 하는 것이다. 분석 과정에서 반드시 들어가야 하는 것은 수치의 계량화다. 즉, ‘응답 시간이 느리다’가 아니라 ‘평상시에는 평균 응답시간이 3초였는데 사용자가 20% 증가하면서 응답시간이 늘어났다’는 식으로 수치를 기반으로 의미를 해석하는 것이다.

분석을 통해 원인을 찾아냈다면 그 다음은 여러 가지 방안으로 시뮬레이션해 보는 단계다. 시뮬레이션 기법은 다양하다.



쉽게는 연필로 써 보면서 경험을 바탕으로 생각해 보는 것도 시뮬레이션이며, 조금 더 분석적으로 들어가서 수학적으로 계산해 볼 수도 있다. 하지만 가장 정교한 방법은 전문 시뮬레이션 툴을 사용하는 방법이다.

시 뮬레이션까지 끝났다면 이제 직접 적용해 보는 단계만 남았다. 먼저 프로토타입으로 만들어 시뮬레이션과 동일한 상황을 만들어 실제로 운영을 해보는 단계다. 당시의 결과가 어떻게 될 것인지 알아보고, 시뮬레이션과 동일한 결과가 나오면 문제가 없다고 검증된 것이다.

이제 정상 상황에서 구축하기만 하면 된다. 만약 문제가 없다면 다행이지만 문제가 생긴다면 다시 모니터링 단계로 돌아가야 할 것이다.

이것이 트래픽 관리의 프로세스다. 아마 의아해하는 독자들이 있을 것이다. 이 과정들이 네트워크 관리 과정과 똑같지 않냐고. 그렇다. 사실 트래픽 관리는 네트워크 관리의 흐름속에 있다. 그러나 차이는 관점을 어디에 두는가에 있다.



지 금까지의 네트워크 관리는 트래픽을 효율적으로 처리하는 것보다는 주로 기능 중심으로 이뤄졌다. 지금껏 회선이 잘 연결됐는지 장비가 잘 구동됐는지에 치중했다면, 이제는 트래픽의 원활한 흐름을 위해서는 어떻게 네트워크를 재구성해야 하고, 장비를 구성해야 할 것인가로 초점이 변해야 한다. 아래의 사례들은 트래픽 관점에서 네트워크를 바라보지 않았을 때 어떤 오류를 범하게 되는가를 잘 보여주는 예들이다.

사례 1은 무엇이 잘못됐을까. A사의 경우 스위칭 허브가 전혀 필요하지 않은 환경이라는 점이다. A사의 PC에서 발생하는 트래픽은 1개의 서버로만 향하고 있기 때문이다. 오히려 스위칭 허브를 설치할 경우 쓸데없이 버퍼에 대기하는 시간덕에 패킷 손실만 발생하게 될 것이다.

사례 2의 서버는 오로지 홍보를 위한 목적으로 사용되고 있다. 즉, 누구나 보고자하는 내용을 보여주는게 목적이기 때문에 파이어월이 필요가 없는 사이트다.



얼 핏보기에 사례 3은 지방 영업소에서 본사 영업 서버로 접속하는 전용의 고속 도로를 만든 것 처럼 보인다. 그러나 실상은 100Mbps라는 고속도로를 두고 386Kbps의 오솔길을 만든 경우다. 이 사이트는 지방에서 영업 서버에 백본을 거쳐서 접속한다고 해도 미치는 영향이 백본의 0.4%밖에 되지 않는다는 점을 간과한 것이다(386Kbps는 100Mbps의 0.4%에 불과하다). 각 지사들의 회선 접속 속도를 높이기 위해서는 애써 새로 연결한 전용회선만 끊어버리면 된다.



트래픽 관리 툴

트 래픽은 눈에 보이지 않기 때문에 모니터링부터 시뮬레이션까지 여러 다양한 툴의 도움을 받을 수밖에 없다. 이 툴을 고려할 때 주의할 점은 여러 객관적인 지표들을 적어도 2개 이상은 동시에 고려할 수 있도록 설계된 것인지 확인해야 한다는 것.

최 근 인터넷 환경이 급속도로 증가하면서 웹 트렌드와 같은 웹 트래픽 분석 툴들이 인기를 끌고 있다. 이런 툴을 선택할 때는 과연 어떤 관점에서 트래픽을 분석하는가를 잘 살펴야 한다. 웹 서버는 항상 2가지 관점 즉, 해당 서버를 중심으로 여러 사용자가 접속해 들어오는가 하면, 해당 서버를 중심으로 여럿이 나가기도 하기 때문이다.



이들 모니터링이나 분석 툴 외에 트래픽 조절 장비들도 있다. 로드밸런싱이 가장 대표적인 예다. 그밖에 트래픽 관리 툴, 캐싱 등도 여기에 해당된다. 캐싱은 다른 기술들이 경로를 조절해 트래픽을 완화시키는데 반해 경로를 단축시켜서 트래픽을 컨트롤하는 툴로, 아주 효율적인 트래픽 관리 기법이다.




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

트래픽 기반의 네트워크 분석·시뮬레이션·설계 툴

인티 ‘Mona Lisa’

Mona Lisa는 인티가 그간의 컨설팅 경험, 특히 네트워크 진단 및 분석 컨설팅을 통해 축적한 노하우와 기술적 이론을 바탕으로 개발한 네트워크 관리 및 분석 소프트웨어로, TCP/IP 네트워크에 접속된 SNMP 장치 및 이를 통해 유통되는 트래픽의 장애와 성능 감시, 분석 기능을 제공한다. Mona Lisa가 주요 기능으로 제공하고 있는 것은 네트워크에 대한 구성, 장애, 성능 분석이다. 이는 네트워크의 운영 상황을 객관적으로 파악해 근본적인 원인을 찾아내고, 데이터 흐름과 서비스 특성을 분석해 향후 네트워크 구성 변경 및 용량 계획을 위한 정보 획득에 반영할 수 있도록 한다. 이는 네트워크 상에서의 서비스 품질 개선을 위한 정보로 적극 활용해야 하는 중요한 기능이다. www.monalisa.co.kr



네트워크 제너럴 ‘Expert Sniffer’

Expert Sniffer는 네트워크 상에서 유통되는 트래픽을 실시간으로 캡처하는 것을 기반으로 운영된다. 이를 바탕으로 사용 프로토콜 및 장애 등을 OSI 7계층 별로 나눠 해석하고 분석한다.

이 제품은 모니터링과 트래픽 분석 기능에 덧붙여 기능의 추가로 발생된 상황에 대해서 그 문제가 발생할 수 있는 원인과 해결 방안을 제시한다. 거의 대부분의 주요 프로토콜을 지원하고 있다. www.ngc.com



넷스위트 ‘NetSuiter Professional Design’

NetSuite Professional Design은 네트워크 설계 도구로 표준을 준수하는 장비와 기술을 실시간으로 설계하도록 지원하며, 설계시 새로운 네트워크 설계 기법과 네트워크 장비에 대한 정보를 손쉽게 제공한다.

또 한 복잡하고 다양해지는 요구사항에 맞도록 신속하고 유연하게 변경하고, 수시로 확장/변경을 요구하는 네트워크 자원을 효율적으로 관리할 수 있도록 도와준다. 그리고, 현 네트워크 환경을 보고서 형식으로 양식화해 분석 및 진단해주며, 향후 발전된 네트워크를 설계할 경우 현재 네트워크와 비교해 자료로 제시해 주는 등 지금까지의 설계 방법과는 다른 품질의 서비스를 제공한다. www.netsuite.com



MIL3 ‘OPNET’

MIL3의 OPNET 시리즈는 네트워크 모델링, 시뮬레이션 툴로 다양한 프로토콜과 라이브러리를 제공한다. 불규칙한 트래픽 패턴을 정확히 이해해 트래픽 패턴별로 시뮬레이션 변수를 정확히 정의할 수 있도록 하는 것이 강점이다


 


 







OPNET Technology사는
1986년 미국 국방부 전산망 프로젝트의 일환으로 추진된네트워크 시뮬레이션 프로그램 개발을 위해 설립 되었으며, 현재 세계 네트워크 시뮬레이션 시장의 80%를 점유하고 있는 네트워크/어플리케이션 관리 소프트웨어 업체입니다.









 


 














































OPNET 제품 군

1. 제품 토폴로지

 

2. 제품의 특성




























































제품 명


기술


주요 기능


기본


사양


 


Modeler


 


대학 및 연구소에서 사용하는 네트워크 모델러/시뮬레이터



  1. 네트워크 모델링 & 시뮬레이션 (Process, Node, Link, Network 레벨)


 


IT Guru


기업체를 위한 네트워크 모델러/시뮬레이터


  1. 네트워크 모델링 & 시뮬레이션 (Link, Network 레벨 only)


 


SP Guru


Service Provider를 위한 네트워크 모델러/시뮬레이터



  1. 네트워크 모델링 & 시뮬레이션 + 부가 기능 (Process, Node, Link, Network 레벨)

WDM Guru
광전송망 사업자를 위한 네트워크 모델러/시뮬레이터

  1. 네트워크 모델링 & 시뮬레이션 (Link, Network 레벨 only)

추가


모듈



 


ACE (Application Characterization Environment)


어플리케이션의 네트워크상에서의 문제를 진단하는 모듈



  1. 응용 프로그램의 효율성 진단


  2. 네트워크 지연 및 장애 진단


  3. 서버 지연 진단


  4. 응용 프로그램 지연 진단


 


ADM (Application Decoding Module)


어플리케이션의 프로토콜을 디코딩하는 모듈



  1. 캡쳐한 네트워크 트래픽 Trace를 decode.(400 여개의 프로토콜 및 응용 프로그램 코드를 decode할 수 있음.)


 


Wireless


무선 네트워크 모델링을 하는 모듈



  1. 무선 네트워크의 디자인 & 테스트


 


Net Doctor


네트워크상의 라우터 Configuration을 진단하는 모듈



  1. 네트워크 구성 및 규칙 진단


  2. 네트워크 상의 라우터 설정 오류의 최소화


  3. 네트워크의 문제 발생 장소 진단 및 해결방안 제시


  4. 네트워크 관리 업무 효율성 최대화


 


Server Specialized Module


서버의 특성을 모델링하는 모듈



  1. 서버의 효율성 진단


  2. 서버시스템과 구성 요소들의 모델링


  3. 네트워크와 응용프로그램에 가장 적합한 서버 컴퓨터 제시


 


VNE Server


 

서버상에 버추얼 네트워크 환경을 구성하는 자체 NMS 모듈


  1. 전체 네트워크의 통일된 데이터(장비/프로토콜/트래픽/응용 프로그램)를 24시간 수집, 관리하는 테이터으 베이스 서버, IT Guru를 통하여 데이터의 실정을 그래픽 상으로 관찰할 수 있음.

ESP (Expert Service Prediction)
네트워크의 서비스 진단 모듈

  1. 계약된 서비스의 수준 진단
  2. 네트워크의 서비스 수준 디자인 진단


 


MVI (Multi Vendor Import)


기존의 네트워크 장비 관련 파일을 불러와서 네트워크 지도를 구성하는 모듈


  1. 기존 네트워크 장비 및 프로토콜 등의 구성 파일 불러오기
  2. 네트워크 지도 구성
  3. 모니터링 툴을 사용하여 트래픽, 링크 활용도 등의 네트워크 모델요소를 가져와 사용
  4. 변화에 적응하는 망
   
3. OPNET의 역사  
OPNET은 1984년 Optimization Theory, Communication Network 및 Parallel Algorithm 분야의 세계적인 권위자인 MIT의 Dimitri Bertsekas 교수와 Robert Gallager 교수가 이끄는 MIT의 LIDS (Laboratory for Information and Decision Systems)에서 미 국방성 연구프로젝트를 수행하면서 탄생한 제품으로서, 여타 시뮬레이션 도구와는 달리 OPNET은 그 근본을 통신망에 두고 있는 실로 통신관련 시뮬레이션 도구로서는 유일하다 하겠습니다. OPNET을 제품화한 OPNET사는 현재 나스닥에 상장되어 있으며 1985년 이래로 미국, 유럽 및 전세계에 수 많은 유.무선 통신관련 실무 프로젝트에 OPNET을 보급하고 있습니다.
   
4. OPNET의 통합 기능  

4.1 칩 설계자 (ASIC Designer)


OPNET 통신망 시뮬레이션 도구와 VHDL/Verilog 칩설계 도구를 하나로 결합하였습니다. 즉 칩설계를 해가면서 과연 지금 설계하고 있는 칩이 실제 통신장비 상에서 어떻게 동작할 것인지를 예측하고 분석할 수 있기 때문에 설계상의 오류를 최소화하여, 여러번의 설계변경 등으로 발생하는 막대한 비용과 시간적 손실을 미연에 방지 할 수 있게 되었습니다.


4.2 통신망 운용 관리자


통신망 설계자에게는 망설계시 OPNET을 사용하고, 실제 장비를 설치한 후 이 통신망을 관리할 수 있도록 여러 망관리 프로그램(NMS)과 OPNET을 연동함으로써, 향후에 발생할지 모르는 각종 원인으로 인한 통신망 마비 사테를 실제 통신망에 살아있는 데이타에 근간해서 OPNET에서 그 방지 대책을 수립할 수 있도록 한다는 것입니다. OPNET을 통신망관리를 위한 Expert System으로 활용하는 것은 이미 통신 선진국에서는 보편화 되어 있습니다. 이를 위하여 OPNET은 RDB (Informix, Oracle, Sybase...), NMS (HP OpenView, IBM Tivoli NetView, Bay Network Optivity, CA Unicenter, Sun NetManager), Data Analyzer (Network General Sniffer, HP NetMetrix...) 그리고 통계적 예측을 위하여 SAS, MatLab등의 통계프로그램과의 인터페이스를 제공하고 있습니다.


4.3 무선통신망 설계자


무선 통신망 설계자를 위해서 OPNET은 지형 정보와의 인터페이스를 통하여 지형의 형상에 따른 전파 환경 분석을 가능하게 하여, 무선 Cell 설계를 효과적으로 수행할 수 있도록 합니다.


4.4 위성통신망 설계자


위성통신망 설계자를 위하여 OPNET은 위성과 지상 중계국 사이의 공기층에서의 전파 환경 분석등을 가능하게 합니다. 이것은 현재 ITU-R Working Party 3J 표준사항을 포함한 광범위한 전파환경 분석을 가능하게 합니다.

   
5. OPNET의 주요 기능  

5.1 OPNET 제품의 응용분야


5.1.1 유.무선 텔레커뮤니케이션: 전화망, WLL, PCS, VOD, LMDS, Paging System 등


5.1.2 위성 통신망 시스템: IRRIDUM, INTELSAT, INMARSAT, LEO, VSAT 등     


5.1.3 군 전략 방어 시스템: Digital Battlefield, DISC4, TACMIS, NETWARS, 육.해.공군 전시 통합 망 관리 등


5.1.4 항공 관제 시스템: 위성, 항공기, 관제탑, 지상 이동망, 통합 백-본망 설계 등


5.1.5 유.무선 CATV 망: CATV 서비스망 설계, IP over CATV 망 설계, LMDS 망 설계 등


5.1.6 통신망 컨설팅: 망 설계, 분석, 진단, 비용분석, 망 관리 등


5.1.7 기초 기술 연구개발: 새로운 통신망 알고리즘 및 프로토콜 검증 및 성능 분석


5.1.8 장비 제조 기술: VHDL/Verilog Co-Simulation (Chip 및 Board 레벨 설계)


5.2 OPNET 제공 프로토콜


5.2.1 유선통신망 분야: ATM, ATM Lan Emulation, 10/100/1000Mbps, Ethernet, TokenRing, FDDI, P1394 HSSB, LAPB, X.25, TCP/IP/UDP, FrameRelay, CATV(802.14), SNA, X.25, RIP, OSPF, RSVP, QOSPF, IGMP, Ipmc, 802.1d, Spanning Tree Bridge, J1850 SAE bus protocol, TP4*, CLNP*


5.2.2 무선 및 위성 통신망 분야: Aloha, Slotted Aloha, AMPS Cellular Telephone, CDMA, CSMA, GSM* Digital Cellular Telephone, TDMA Satellite


5.2.3 벤더 장비 모델: 3Com, ACC, Alantec, Bay Networks, Bytex, Chipcom, Cisco, Crosscomm, Grand Junction, HP, Lannet, Novell, Proteon, Retix, UB Networks, Xylan


5.2.4 Third Party 제품과 Interface: HP OpenView Network Management Tool, Network General Sniffer, HP NetMetrix Data Analyzers, VHDL/Verilog Component/Board Level Co-Simulation Database


5.3 OPNET 주요 기능 설명


5.3.1 Network Editor


Topology 설계: Mesh, Ring, Star, Tree, Bus, Randomized Mesh, Unconnected Net 등
Application Traffic Generator: WWW, E-mail, FTP, Data Base, Videoconference, MPEG Video, Video Gaming 등
Remote Login, PDF based traffic
Network Management System (NMS) Interface
Hardware Vendor Device Network
Connectivity Check
위도, 경도 및 고도 스케일 (실제 지구상의 값과 일치시킴)
세계지도 정보 ( CIA World Database II )


5.3.2 Node Editor


통신 장치 내부 Layer 아키텍처 설계                                         Inter Layer Data Flow Control
Queuing Model
User Definable Traffic Generator
Transmitter and Receiver Model (Bus, Pear-to-Pear, RF links)
Antenna Model                                                        Vendor Specific Model Design


5.3.3 Process Editor
프로토콜 설계
알고리듬 설계
C/C++ 프로그램 에디터 ( C/C++ 소스 디자인, C/C++ Syntax)
State Transition Diagram (STD) ( Event-Driven Simulation Architecture)
다중 구조의 계층적 설계 기법 ( Chield Process의 개수에 제한 없음)
C/C++를 이용한 사용자 그래픽 인터페이스(GUI) 설계
Auto C/C++ Source Code Generation


5.3.4 Parameter Editor
전송 에러 모델링 (유선 또는 무선 전송 시 에러 모델링 )
PDF Based Traffic Generator
패킷 포맷 설계
프로세서간 통신 제어 포맷 설계
통신 선로(링크) 설계
안테나 패턴 설계
RF Modulation Function 설계
Normalization Function


5.3.5 Probe Editor


노드상태 분석을 위한 Node Probe
링크상태 분석을 위한 Link Probe
통신망 전체 분석을 위한 Global Probe
Animation Probe ( Auto, Statistic, Custom Animation )


5.3.6 Simulation Editor


Vector or Scalar Output Design
Error Debugging
Random Number Generation
Multi-Simulation (변수 값들을 자동 변경하면서 한번에 시뮬레이션을 함)
Simulation Time Control


5.3.7 Analysis Editor


시뮬레이션 결과 분석 및 해석을 위한 도구 제공
Vector 결과 및 Scalar 결과 분석
확률 분포 해석 기법
여러 결과의 그래프를 한 그래프 화면에 동시에 표현


5.3.8 Filter Editor


시뮬레이션 결과의 해석을 돕기 위한 에디터


5.3.9 Animation Tool


통신장비들간의 트래픽 흐름 모니터링
통신선로 (RF Channel)의 Utilization의 변동 모니터링
통신량 폭주로 인한 장비 또는 선로의 스트레스 정도의 모니터링
통신 Link의 연결성 모니터링 (무선망, 위성망, Broad Band 통신망...)
Voice, Data, Control신호의 흐름
이동체 및 위성체의 움직임
통신장비 내부의 레이어간 Voice, Data, Control신호 흐름
Routing - En- and De-Capsulization
Application Traffic Flow
Switching Mechanism
Traffic over In and Out Port
설계한 프로토콜 및 알고리즘의 각 프로세서간 처리상황 모니터링
Event 발생 시점에 생성되는 Data 또는 Packet의 Numbering 표시
RF 통신에서 통신중인 사용자간 링크 모니터링
위성통신에서 통신중인 위성간 또는 지상 기지국간 링크 모니터링
사용자가 직접 Animation을 만들 수도 있음.


5.3.10 위성 Simulator


위성 궤도 산출
위성체 모델링
3-D 궤도 Display
위성의 움직임 Animation
NASA 궤도산출 프로그램을 사용함
위성체 전파가 미치는 영역의 Animation ( Coverage )
송신단의 안테나 각도 조절


5.3.11 기타


Debegger
Icon 저작 도구

   
6. OPNET 사용 환경  
Sun, HP, Silicon Graphics (SGI), DEC, Windows NT
SunOS4.1.3이상, Solaris2.x, HP-UX 9.x, IRIX 5.2.x, OSF/1 3.x, NT 3.5.1이상
C-compiler가 필요 (단, Windows NT는 Visual C++ ver. 4.0이상이 요구됨)
최소 32MB Main Memory, 600MB HDD 용량, CD-ROM


출처 : http://nsjokt.springnote.com/pages/2685456
?

List of Articles
번호 제목 글쓴이 날짜 조회 수
23 LACP(Link Aggregation Control Protocol) JaeSoo 2010.01.27 8707
22 윈도우 라우팅 테이블 관리하기 JaeSoo 2010.01.25 6799
21 http://cafe.naver.com/ArticleRead.nhn?clubid=10344409&articleid=79763&menuid=&boardtype=&page=0 JaeSoo 2010.01.22 6634
20 듀얼 WAN 사용 시 대역폭 문제 JaeSoo 2010.01.22 6127
19 네트워크 충돌검색 [nbtstat]명령어 JaeSoo 2009.10.05 4721
18 윈도우즈에서 Squid 프락시 서버 설치 JaeSoo 2009.10.05 3787
» Openet JaeSoo 2009.09.28 3586
16 인터넷 친구를 만들거나 비지니스 인맥을 만드는 웹어플리케이션, SNS JaeSoo 2008.07.22 3502
15 무료 PC 원격제어 JaeSoo 2008.07.01 4170
14 초고속 정보통신 인증제, 홈네트워크 인증제 JaeSoo 2008.02.25 3568
13 조기경보시스템(3)-조기경보 시스템(Early Warning System)의 국내외 구축·운영 사례 JaeSoo 2008.01.27 3660
12 조기경보시스템(2)-조기경보 시스템의 기술 동향 JaeSoo 2008.01.27 3449
11 조기경보시스템(1)-조기경보 시스템의 개요 JaeSoo 2008.01.27 3599
10 정보통신기반보호법(요약) 및 검토 JaeSoo 2007.12.28 4911
9 자가전기통신설비(자가망)관련 법령 JaeSoo 2007.12.28 4758
8 Ten things Your IT department won't tell you (IT 부서가 당신에게 말해주지 않는 10가지) JaeSoo 2007.12.28 3987
7 `IPv6` 9월 부터 시범서비스 JaeSoo 2007.12.06 3470
6 초고속선도망(KOREN) 사업 보고서 JaeSoo 2007.12.06 4388
5 smtp를 이용하여 mail 보내기 (pear 사용) JaeSoo 2007.06.07 3779
4 메일 발송시 리턴메일 메시지 JaeSoo 2007.06.05 3481
Board Pagination Prev 1 2 3 4 5 Next
/ 5

PageViews   Today : 422   Yesterday : 1,268   Total : 19,715,129  /  Counter Status   Today : 163   Yesterday : 463   Total : 1,395,033
Site Info   Member : 230  /  Total documents : 1,221   New documents : 0  /  Total comments : 24

Edited by JAESOO

sketchbook5, 스케치북5

sketchbook5, 스케치북5

나눔글꼴 설치 안내


이 PC에는 나눔글꼴이 설치되어 있지 않습니다.

이 사이트를 나눔글꼴로 보기 위해서는
나눔글꼴을 설치해야 합니다.

설치 취소