Network Layer 문서 원본 보기

상위 문서: [[컴퓨터 네트워크]]

==개요==
[[파일:The network layer.png|대체글=Figure 1. The network layer|섬네일|Figure 1. The network layer|339x339픽셀]]
네트워크 계층은 송신 호스트(host)에서 수신 호스트까지의 종단 간 데이터 전송을 담당하는 계층이다. Figure 1은 호스트 H1과 H2와, 그 사이의 경로에 있는 여러 라우터(router)들로 구성된 네트워크를 보여준다. H1이 H2에게 정보를 보내고 있다고 가정해 보고, 이때 H1과 H2 및 그 사이의 라우터들에 있는 network layer의 역할을 살펴보자. H1의 network layer는 H1의 transpot layer로부터 세그먼트(segment)를 받아, 각 세그먼트를 데이터그램(datagram)으로 캡슐화하고, 그런 다음 이 데이터그램들을 근처 라우터인 R1으로 보낸다. 수신 호스트인 H2에서는, network layer가 근처 라우터 R2로부터 데이터그램을 받아, transport layer 세그먼트를 추출하고, 이 세그먼트들을 H2의 transport layer로 전달한다. 이와 같이 network layer는 transport layer가 애플리케이션(application) 간 통신을 지원할 수 있도록, 호스트 간 통신 서비스를 제공한다. 해당 문서에서는 forwarding과 routing과 같은 핵심 기능 부터, 라우터의 작동 방식 등, network layer의 전반적인 내용들을 다룬다. 

==Routing and Forwarding==
[[파일:Control Plane- The Traditional Approach.png|대체글=Figure 2. Control plane: The traditional approach|가운데|섬네일|500x500픽셀|Figure 2. Control plane: The traditional approach]]
Network layer의 주된 역할은 패킷을 송신 호스트에서 수신 호스트로 이동시키는 것이다. 이를 구현하기 위해 netwrok layer는 두 부분으로 나뉜다. 바로 '''data plane'''과 '''control plane'''이다. '''data palne은 forwarding''' 과정을 담당하며, '''control plane은 routing'''을 담당한다. 
Forwarding이란 라우터의 '''입력 링크(link)로 들어온 패킷을 적절한 출력 링크로 이동'''시키는 작업이다. 예를 들어, figure 1에서 호스트 H1에서 라우터 R1로 도착한 패킷은 H2로 향하는 경로 상의 다음 라우터로 전달되는데, 이때 forwarding table이 사용된다. '''Forwarding table'''에 저장된 항목 들은 해당 패킷이 전송되어야 할 출력 링크를 나타낸다. 따라서 forwarding은 '''라우터가 입력 링크로 도착한 패킷의 헤더의 필드 값을 검사하고, 해당 값을 이용해 forwarding table을 조회'''하여 출력 링크를 결정하는 방식으로 실행된다. 해당 작업은 '''지엽적으로(local), 매 라우터 마다''' 일어나는 작업이며, '''하드웨어 수준'''에서 구현되어 매우 짧은 시간(일반적으로 '''몇 나노초''')동안 수행된다.<br>
또한 routing은 '''패킷이 송신자에서 수신자로 어떤 경로(end-to-end path)를 따라 이동할지를 결정'''하는 작업이다. 이러한 경로를 계산하는 알고리즘을 routing 알고리즘이라고 한다. 예를 들어 라우팅 알고리즘은 figure 1에서 H1에서 H2로 가는 경로를 결정한다. 라우팅은 종단간 경로를 결정하기 때문에 '''네트워크 전역적(network-wide)'''으로 일어나며, '''소프트웨어 수준'''에서 구현되어 상대적으로 매우 긴 시간(일반적으로 몇 '''밀리초''')동안 수행된다. 이때 routing이 최종적으로 만드는 결과물은 forwarding table이다. 이때 control plane이 forwarding table을 어떻게 각 라우터에 설정하는 지에는 두가지 접근 방식이 있다. 하나는 traditional routing algorithms이고, 하나는 '''software-defined networking(SDN)'''이다. 

===Control Plane: The Traditional Approach===
Figure 2는 전통적인 control plane의 forwarding table에 대한 접근 방식을 보여준다. '''각각의 라우터들은 개별적으로 routing 알고리즘을 실행'''하며, forwarding 및 routing 기능 모두가 라우터 내에 포함되어 있다. 즉, routing을 통해 다음으로 어떤 라우터에게 패킷을 보낼지를 결정하고, forwarding을 통해서 실제로 패킷을 보낼 출력 링크를 찾는 것이다.<br>
이때 라우터는 routing 알고리즘을 수행하기 위해 다른 라우터의 routing 알고리즘 기능과 통신하여 forwarding table을 구현한다. 이는 Figure 2에 잘 나타나 있다. Figure 2에 나타나 있듯이 routing 알고리즘은 control plane에서 실행되며, 개별 라우터에서 실행된 routing 알고리즘에 의해 forwarding table이 생성되고, data plane에서 비로소 forwarding이 구현된다.<br>
이러한 방식은 치명적인 약점을 가지고 있다. 수많은 라우터에 의해서 routing 알고리즘이 수행되고, 각각의 결과를 기반으로 forwarding이 수행되기 때문에 몇몇의 라우터가 오작동을 할 수 있다는 것이다. 최악의 경우, 한 지역 혹은 한 나라 전체의 인테넷이 마비될 수도 있다.

===Control Plane: The SDN Approach===
[[파일:Control Plane- The SDN Approach.png|대체글=Figure 2. Control Plane: The SDN approach|가운데|섬네일|500x500픽셀|''Figure 2. Control Plane: The SDN approach'' ]]
'''SDN(software-defined networking)''' 방식은 이러한 분산적인 처리 방식의 한계를 해결하고 일관성과 효율성을 높이기 위해 도입된 방식이다. 이는 Figure 3가 잘 보여주고 있다. figure 2와 3의 data plane 구성은 동일하지만, figure 3에서는 '''control plane 기능이 물리적인 라우터에서 분리'''되어 있으며, '''라우터는 오직 forwarding만 수행하고, remote controller가 forwarding table을 계산'''하고 배포한다. 이때 각각의 라우터 내에는 control agent(CA)가 존재해 remote controller로부터 forwarding table을 수신할 수 있도록 한다.<br>
SDN에서 software-defined라는 말은 forwarding table을 계산하고 라우터들과 상호작용하는 controller가 소프트웨어로 구현되어 있다는 의미이다. 즉 이는 각 라우터가 스스로 routing 알고리즘을 수행하는 전통적인 하드웨어 기반의 방식과 달리, 소프트웨어 기반의 중앙 집중형 제어 방식이라는 점에서 큰 차이가 있다.

==Network service model==
Network layer는 개별적인 데이터그램 전송의 면에서 다음과 같은 서비스들을 제공할 수 있다:
# Guaranteed delivery: 이 서비스는 송신 호스트에서 전송한 패킷이 결국 목적지 호스트에 도착할 것을 보장한다.
# Guaranteed delivery with bounded delay: 특정 호스트 사이에 정해진 delay 내에 도착할 것을 보장한다.
Network layer는 데이터 그램의 흐름(flow of datagrams) 전송의 면에서 다음과 같은 서비스들을 제공할 수 있다:
# In-order packet delivery: 패킷이 전송된 순서대로 목적지에 도착함을 보장한다.
# Guaranteed minimal bandwidth: Networking layer는 호스트 사이의 특정 bandwidth를 가지는 링크처럼 작동한다.
# Restrictions on changes in inter-packet spacing: 이는 datagram이 수신되는 간격을 조정하여 영상 등을 시청할 때 끊기지 않도록 한다.
이외에도 network layer는 security와 같이 transport layer의 세그먼트에 대한 기밀성을 제공하는 등의 서비스를 제공한다.

==[[Router]]==
자세한 내용은 [[Router]] 문서를 참조하십시오.

==[[Internet Protocol]]==
자세한 내용은 [[Internet Protocol]] 문서를 참조하십시오.

==Generalized Forwarding and SDN==
[[파일:Generalized forwarding.png|대체글=Figure 3. Generalized forwarding|섬네일|'''Figure 3. Generalized forwarding''' ]]
전통적인 라우터의 forwarding 방식은 패킷의 목적지 IP 주소를 바탕으로 이루어진다. 예를 들어, 패킷의 목적지 IP 주소가 <code>192.168.0.1</code>이면 3번 포트로 보내는 방식이다. 이 과정은 크게 두가지로 나뉜다. 바로 목적지 IP 주소를 라우팅 테이블에서 찾는 '''match'''와, 해당 출력 포트로 패킷을 전달하는 '''action'''이다. 하지만 최근에는 단순히 라우터보다 훨씬 복잡하고 다양한 기능을 수행하는 장비들이 등장했다. 이렇게 라우터 외에 '''네트워크에서 특정한 기능을 수행하는 장비들을 middlebox'''라고 한다. 예를 들면 아래와 같은 middlebox들이 있다:
* NAT: 패킷의 IP 주소와 포트 번호를 수정
* 방화벽: 특정 IP/포트 번호에 해당하는 패킷을 차단
이러한 장비들은 network layer 이상의 복잡한 기능을 하고 제각기  하드웨어/소프트웨어/관리 인터페이스를 가져서 운영이 매우 복잡하고 비용이 많이 든다. 이러한 상황에서 SDN의 발전은 이러한 network layer 기능들과 일부 link layer 기능들을 현대적으로 제공할 수 있는 통합 접근 방식을 가능하게 한다. SDN의 핵심 철학은 '''네트워크 장비들은 단순히 “명령을 따르는” 역할'''만 수행하고, '''실제 제어/결정은 중앙의 컨트롤러'''가 담당하는 것이다. 이는 network layer의 control plane과 data plane을 분리하는 역할을 한다. 이를 통해서 다양한 middlebox의 기능들을 하나의 통합된 방식으로 제어하며, forwarding 동작을 "소프트웨어"처럼 설계하고 제어할 수 있다. 

이를 통해서 전통적인 forwaring 방식보다 훨씬 일반화된(generalized) forwarding 방식인 '''match+action'''을 정의할 수 있다. 기존에는 목적지의 IP 주소만을 match하였지만, generalized forwarding에서는 이보다 '''다양한 헤더 필드(IP, TCP, UDP, VLAN 등)를 조합하여 match'''할 수 있다. 또한 match되는 조건에 따라 더욱 '''다양한 action이 수행''' 가능하다. 예를 들어, 패킷을 하나 또는 여러 출력 포트로 전달<ref>기존 목적지 기반 포워딩처럼</ref>, 의도적으로 패킷을 차단/버리기<ref>방화벽처럼</ref> 등 다양한 작업을 포함할 수 있다.<br>
기존에는 link layer의 장비를 스위치(switch), netwrork layer의 장비를 라우터라고 불렀으나, generalized forwarding을 쓰는 장비는 그 둘을 모두 포함하는 역할을 한다. 따라서 SDN과 연관하여 forwarding 장치들을 일컬을 때에는 '''패킷 스위치(packet switch)'''라고 부르는 것이 적절하다. Figure 3는 각 패킷 스위치 내에 있는 match+action 테이블과, 해당 테이블들이 remote controller에 의해 계산되고 설치되며 갱신되는 모습을 보여준다. 그리고 각 장비들은 테이블에 따라 기계적으로 동작한다. 

'''Open Flow'''는 SDN에서 가장 널리 쓰이는 표준 프로토콜이며, 패킷 스위치가 가지는 flow table<ref>forwarding table에 해당한다.</ref>을 정의한다. flow table은 다음의 구성을 가진다:
{| class="wikitable"
|+
!항목
!설명
!예시
|-
|헤더 필드 값 집합
|수신된 패킷이 매치되는 기준이 되는 값들
|IP, MAC, TCP 포트 등 헤더필드
|-
|counter 집합
|패킷이 해당 플로우 테이블 항목과 매치될 때마다 갱신되는  counter 값들
|몇 번 매치되었는지, 마지막 업데이트 시간 등
|-
|수행할 action의 집합
|패킷이 테이블 항목과 매치되었을 때 취할 행동들
|전달, 삭제, 복사, 헤더 변경 등
|}
이후의 설명 들은 모두 open flow 프로토콜을 기준으로 한다.

===Match===
[[파일:Packet matching fields.png|대체글=Figure 4. Packet matching fields|가운데|섬네일|600x600픽셀|'''Figure 4. Packet matching fields''' ]]
OpenFlow에서는 패킷이 특정 조건에 부합할 때만 어떤 action을 취하는데, 이때 사용하는 기준이 match이다. OpenFlow는 link/network/transport layer의 헤더 정보들을 읽어서 매치할 수 있다. 각각의 layer에 대한 필드는 아래와 같이 주어진다:
{| class="wikitable"
|+
!Layer
!설명
!예시 필드
|-
|Link layer
|스위치처럼 작동한다.
|MAC 주소 (출발지/목적지), VLAN<ref>VLAN 필드들은 가상 LAN(Virtual LAN)과 관련되어 있는, 네트워크 안에서 논리적으로 나눠진 그룹을 구분하는 정보이다.</ref>, EtherType<ref>EtherType은 이 프레임의 페이로드가 어떤 프로토콜(IP, ARP 등)인지 알려주는 값이다.</ref>
|-
|Network layer
|라우터처럼 작동한다.
|IP 주소, 프로토콜 번호, 서비스 유형
|-
|Transport layer
|포트를 기반으로 하여 제어 가능하다.
|TCP/UDP 포트 번호
|}
이는 layering priciple을 어기는 것이지만, 이를 통해서 세 layer의 경계를 허물고 open flow를 지원하는 장치들이 다양한 layer의 장치처럼 작동할 수 있도록 한다. 예를 들어 MAC 주소 기준으로 매치된다면 스위치처럼 동작하고, IP 주소 기준으로 매치된다면 라우터처럼 동작하는 것이다. 아래는 각각의 장치에 대하여 match와, 그에 해당하는 action을 나타낸 표이다.
{| class="wikitable"
|+
!장치
!match
!action
|-
|라우터
|longest destination IP prefix
|forward out a link
|-
|스위치
|destination MAC address
|forward or flood
|-
|방화벽(firewall)
|IP addresses and TCP/UDP port numbers
|permit or deny packets
|-
|NAT
|IP address and port
|rewrite address and port
|}
Flow table 항목은 '''wildcard'''를 가질 수 있다. 예를 들어 flow table에 <code>128.119.*.*</code>인 IP 주소가 있다면, IP 주소 필드의 처음 16비트가 <code>128.119</code>인 모든 데이터그램과 match된다. 또한 각 flow table은 '''priority'''를 가지고 있어 패킷이 여러 flow table 항목과 매칭되는 경우, 우선 순위가 가장 높은 항목에 해당하는 match/action이 선택된다.

하지만, IP 헤더의 모든 필드가 매치 대상으로 사용될 수 있는 것은 아니다. 예를 들어, OpenFlow는 TTL 필드나 length 필드를 기준으로 match하는 것을 허용하지 않는다. 이는 너무 많은 세부 사항과 범용성을 포함시켜 추상화가 비대해지고 사용 불가능하게 되는 것을 피하기 위함이다.

===Action===
각 flow table 항목에는 flow table 항목과 일치하는 패킷에 어떤 작업을 할지를 결정하는 action 항목이 0개 이상 존재한다. 이때 가능한 action들 중 가장 중요한 것들은 아래와 같다:
* Forwarding
** 수신된 패킷은 특정 출력 포트로 전달될 수 있다.
** 수신된 패킷은 모든 포트로 브로드캐스트 될 수 있다. 
** 수신된 패킷은 특정 포트 집합에 대해 멀티캐스트될 수 있다.
** 수신된 패킷은 캡슐화되어 해당 장치에 대한 remote controller로 전송될 수 있다. 해당 controller는 해당 패킷에 대해 어떤 동작을 취할 수도 있다. 혹은, 새로운 flow table 항목들을 설치하고, 패킷을 장치에 되돌려 보낸 후에 갱신된 flow table 규칙에 따라 forwarding하도록 할 수 있다.
* Dropping
** 아무 액션도 지정되지 않은 flow table 항목은 match된 패킷을 삭제해야 한다는 뜻이다.
* Modify-field
** 패킷이 선택된 출력 포트로 전달되기 전에, 10가지의 필드<ref>Figure 4에 제시된 패킷 헤더 중 IP 프로토콜 필드 제외한 필드에 해당한다.</ref> 값을 수정할 수 있다.

===Simple Forwarding Example===
Figure과 같이 네트워크가 주여졌을 때, h5/h6 → h3/h4 로 가는 트래픽을 s3 → s1 → s2에 해당하는 경로로 보낸다고 가정하자. 이 경우, s3, s1, s2의 flow table은 다음과 같이 구성된다.
{| class="wikitable"
|+s3 Flow Table
!Match
!Action
|-
|IP Src = 10.3.*.* ; IP Dst = 10.2.*.*
|Forward(3)
|-
|...
|...
|}
s3는 IP src가 <code>10.3.*</code>, IP dst가 <code>10.2.*</code>이라면, s1을 향하는 포트 3로 해당 패킷을 전송한다. 
{| class="wikitable"
|+s1 Flow Table
!Match
!Action
|-
|Ingress Port = 1;<ref>Ingress port는 수신 포트를 의미한다.</ref> IP Src = 10.3.*.* ; IP Dst = 10.2.*.*
|Forward(4)
|-
|...
|...
|}
s3는 ingress port가 1이고, IP src가 <code>10.3.*</code>, IP dst가 <code>10.2.*</code>이라면, s2을 향하는 포트 4로 해당 패킷을 전송한다.
{| class="wikitable"
|+s2 Flow Table
!Match
!Action
|-
|Ingress port = 2 ; IP Dst = 10.2.0.3
|Forward(3)
|-
|Ingress port = 2 ; IP Dst = 10.2.0.4
|Forward(4)
|-
|...
|...
|}
s2는 ingress port가 2이고, IP dst가 <code>10.2.0.3</code>이라면, 포트 3로 해당 패킷을 전송한다.<br>
혹은 ingress port가 2이고, IP dst가 <code>10.2.0.4</code>이라면, 포트 4로 해당 패킷을 전송한다.

===Firewalling Example===
똑같이 figure과 같이 상황을 주어졌을 때, s2가 s3에서 들어오는 트래픽 중, h3(10.2.0.3), h4(10.2.0.4)이 목적지인 것만 허용할 때, 다음과 같이 s2의 flow table이 구성되어있다고 해보자.
{| class="wikitable"
|+s2 Flow Table
!Match
!Action
|-
|Ingress port = 2 ; IP Dst = 10.2.0.3
|Forward(3)
|-
|Ingress port = 2 ; IP Dst = 10.2.0.4
|Forward(4)
|}
이때 s2의 테이블에 다른 항목이 존재하지 않는다면, match되지 않는 트래픽은 drop된다.

==[[Routing Algorithms]]==
자세한 내용은 [[Routing Algorithms]] 문서를 참조하십시오.

==Making routing scalable==
위 문단에서의 라우팅 알고리즘에서는 네트워크를 단순히 상호 연결된 라우터들의 모음으로 본다. 이때 하나의 라우터는 다른 라우터와 구별되지 않으며, 모든 라우터가 동일한 라우팅 알고리즘을 실행하여 전체의 네트워크 경로를 계산한다고 보았다. 하지만 이는 두 가지 본질적인 한계를 가진다.
* Scale(규모)
**  라우터의 수가 많아짐에 따라, 라우팅 정보를 공유하고, 계산하고, 저장하는 데 필요한 오버헤드가 과도하게 커진다.
** 오늘날 인터넷에는 수억 개의 라우터가 존재하며, 따라서 단순하게 각각의 라우터들이 서로에 대한 정보를 공유한다면 오버헤드가 막대해진다.
** 또한 DV 라우팅 알고리즘이 이렇게 방대한 수의 라우터 사이에서 실행된다면, 절대 수렴하지 못할 것이다. 
** 즉, 인터넷처럼 큰 네트워크에서는 라우팅 계산의 규모를 줄이기 위한 조치가 필요하다.
* Administrative Autonomy(관리의 자율성)
** 인터넷은 ISP들의 네트워크로 이루어져 있고, 각 ISP는 자신만의 라우터 네트워크를 가진다. 일반적으로 ISP는 자신의 네트워크를 원하는 방식대로 운영하길 원한다.<ref>예를 들어, 자신의 네트워크 내에서 자유롭게 라우팅 알고리즘을 선택하거나, 내부 구조를 외부에 숨기고자 할 수 있다.</ref>
** 이상적으로는, 하나의 ISP가 자신의 네트워크를 독립적으로 운영·관리하면서, 외부 네트워크와도 연결 가능해야 한다.
[[파일:Interconnected ASes.png|대체글=Figure 5. Interconnected ASes|섬네일|200x200픽셀|Figure 5. Interconnected ASes]]
위 두가지 문제는 '''라우터를 AS(Autonomous System)으로 조직'''하여 해결할 수 있다. 각 AS는 동일한 관리를 받는 라우터들의 집합이다. 따라서 대개 하나의 ISP에 속한 라우터들과 그 사이를 연결하는 링크들이 하나의 AS를 구성하지만, 일부 ISP는 자신들의 네트워크를 여러 AS로 분할하기도 한다. 이때 AS는 전세계적으로 고유한 ASN(Autonomous System Number)로 식별된다.

Figure 5는 AS1, AS2, AS3 간 라우터 연결을 시각적으로 보여주고 있다. 이때 해당 figure에 나타나 있듯이, forwarding table은 intra-AS와 inter-AS 라우팅 알고리즘 둘 다에 의해 구성된다. 이때 '''intra-AS 라우팅 알고리즘은 해당 AS 내부에서의 목적지를 위한 경로'''를 설정하며, '''inter-AS 라우팅 알고리즘은 외부 목적지를 설정하기 위한 경로'''를 설정한다. 또한, 해당 figure에서 3a, 1c, 1b, 2a 라우터와 같이 어떤 AS 내에 속한 채로 '''다른 AS에 연결되는 링크를 가지고 있는 라우터를 gateway 라우터(gateway router)'''라고 한다.

Intra-AS 라우팅 알고리즘과 inter-AS 알고리즘이 구분되어서 작동하는 이유는 다음 세가지 이다:
* policy: 각 AS가 intra-AS 라우팅 알고리즘을 통해 자율적으로 경로를 제어하도록 할 수 있다.
* Scale: Inter-AS에서는 전 세계 수천 개의 AS가 존재하므로, 계층적 구조가 필수이다.
* Performance: Intra-AS는 성능 중심, Inter-AS는 라우팅 정책을 우선적으로 고려한다.

===Intra-AS Routing===
[[파일:Intra-AS Routing.png|섬네일|Figure 6. Intra-AS Routing|200x200픽셀]]
AS1의 라우터가 외부 AS를 향하는 데이터그램을 수신해서 어느 gateway 라우터로 포워딩해야 할지 결정해야 한다고 가정하자.  이를 위해서, AS1의 각 라우터는 각 목적지에 대해 어떤 AS를 통해 도달 가능한지 계산해야 한다. 또한 해당 정보를 AS1 내부에 브로드캐스트하여 내부의 모든 라우터에게 공유해야 한다. 이를 통해서 AS1의 모든 라우터가 동일한 forwarding 작업을 수행할 수 있다. 이러한 작업을 Intra-AS Routing이라고 하며, IGP(Interior Gateway Protocol)라고도 한다. 이때 IGP는 RIP<ref>Routing Information Protocol</ref>, [[OSPF]]<ref>Open Shortest Path First</ref>, IGRP<ref>Cisco에 의해 개발되었고, 2016년까지 비공개되었던 프로토콜이다.</ref>등으로 나뉜다. 이와 같은 라우팅 프로토콜의 분류는 figure 6에 잘 나타나 있다. 

OSPF 라우팅 프로토콜에 대한 자세한 내용은 [[OSPF]] 문서를 참조하십시오.

===Inter-AS routing: BGP===
어떤 패킷의 출발지와 목적지가 동일한 AS에 위치할 때, 패킷이 따라가는 경로는 전적으로 intra-AS 라우팅 프로토콜에 의해 결정된다. 하지만 여러 AS를 가로질러 패킷을 라우팅하고자 할때, inter-AS 라우팅 프로토콜이 필요하다. 이때 inter-AS 라우팅 프로토콜은 여러 AS가 한 몸 처럼 움직이며 작동하기 때문에 동일한 AS를 통해 실행된다. 이때 쓰이는 프로토콜이 바로 [[BGP]](Border Gateway Protocol)이다.

BGP 라우팅 프로토콜에 대한 자세한 내용은 [[BGP]] 문서를 참조하십시오.

==[[The SDN Control Plane]]==
자세한 내용은 [[The SDN Control Plane]] 문서를 참조하십시오.

==ICMP: The Internet Control Message Protocol==
ICMP(Internet Control Message Protocol)란, 호스트와 라우터가 서로에게 network layer의 정보를 전달할 때 사용되는 프로토콜이다. ICMP의 가장 일반적인 용도는 오류를 보고하는 것이다. 예를 들면, http 세션을 실행할 때, "목적지 네트워크에 연결할 수 없음"과 같은 오류 메시지가 발생한다면, 이는 ICMP 프로토콜이 작동한 결과이다. 즉, HTTP request가 지정한 호스트로 가는 경로를 찾을 수 없었던 IP 라우터가 있었고, 그 라우터가 이 오류를 알리는 ICMP 메시지를 호스트에게 생성하여 보낸 것이다.<br>
또한, ICMP는 echo request/reply 기능 또한 가지고 있으며, 이는 ping 프로그램을 구현하는데 사용된다. ping 프로그램은 지정된 호스트에 ICMP 필드에서 type이 8, code가 0인 메시지를 보낸다. 이를 받은 호스트는 이를 echo request로 인식하여 이에 대한 응답(reply)로 호스트에 ICMP 필드에서 type이 0, code가 0인 메시지를 보낸다. 이를 통해서 서버와 호스트 사이의 서버 지연 시간을 측정할 수 있다.

ICMP는 network layer의 프로토콜에 해당하지만, transport layer의 특징 또한 가지고 있다. 그 이유는 ICMP 메시지들이 데이터그램의 페이로드에 담겨 전송되기 때문이다. 

ICMP 메시지에는 type과 code 필드가 존재하며, 이는 해당 ICMP 메시지가 생성되게 한 IP 데이터그램의 헤더 및 처음 8바이트를 포함한다. 이를 통해서 송신측은 어떤 데이터그램이 오류를 유발했는지를 확인할 수 있다.

==Network Management and SNMP==

==각주==

[[분류:데이터베이스 시스템]]