Computer Networking[컴퓨터 네트워크] chap 5. Network layer (5.5 | 5.6 | 5.7)

5.5 소프트웨어 정의 네트워크(SDN) 제어 평면

Traditional Internet: Per-router control plane

• 인터넷 네트워크 레이어: 역사적으로 라우터별 분산 접근방식을 통해 구현됨
  • monolithic(단일시스템, 모든 기능이 한 덩어리로 설계) 라우터는 스위칭 하드웨어(ex. cisco 회사 -> 회사에 특정한 운영체제 설치)를 포함하고, 전용라우터 OS(예: Cisco IOS)에서 인터넷 표준 프로토콜(IP, RIP, IS-IS, OSPF, BGP)의 독점적 구현 실행
    • 인터넷 프로토콜들이 전부 open, 이런 표준 프로토콜들을 자기네들이 독점적인 구현 탑재
    • 라우터, 운영체제, 라우터컨트롤하는 모든 프로토콜 :  단일시스템적으로 한 박스로 제품으로 라우터장비로  만들어짐 -> 라우터에 변화 꾀하는 것 힘듦. 
  • 방화벽, 로드 밸런서, NAT 박스 등 다양한 네트워크 계층 기능을 위한 다양한 middlebox
    • 문제점: 필요한 네트워크 계층 기능이 생길때마다 middle box 계속 늘어남

Traditional Internet: 기존 라우팅으로는 어려운 문제

*네트워크 상 performance 높아짐, 보안상 이유로 route를 flexible하게 결정 통칭

• Q. 네트워크 사업자가 UXYZ가 아닌 UVWZ를 따라 U-to-Z 트래픽이 흐르기를 원한다면 어떻게 하나요?
• A. 트래픽 라우팅 알고리즘이 그에 따라 경로를 계산하도록 링크 가중치를 다시 정의해야 합니다.(또는 새로운 라우팅 알고리즘이 필요)!
• 링크 가중치는 제어 "knobs(조정할 수 있는 작은 제어장치)"일 뿐 : 제어할 수 있는 게 많지 않음 --> SDN이 이런 한계점 벗어남

• Q. 네트워크 사업자가 uvwz와 uxyz(부하분산)을 따라 u-to-z트래픽을 분할하려는 경우 어떻게 해야 하나요?
• A. 불가능하거나 새로운 라우팅 알고리즘이 필요.

• Q. 파란색과 빨간색 트래픽을 W에서 Z로 다르게 라우팅하려는 경우 
• A. 불가능하다. (목적지 기반 포워딩 및 LS, DV 라우팅 사용)
• traffic engineering의 한계점(많은 middlebox 필요, 단일디자인만 가능)

--> 4장에서 일반화된 포워딩과 SDN을 사용하여 원하는 모든 라우팅을 달성할 수 있다는 것 배움 ~~

 

SDN : 어떻게?

• 네트워크 control plane과 forwarding plane을 물리적으로 분리하고 논리적으로 중앙집중화된 control plane(서버)이 여러 라우터 제어하는 방식
  • controller: 여러 라우터들을 중앙에서 이 라우터들의 forwarding이 coordinate되게 조정 컨트롤. logical 하게 centralized된 control plane 사용
• 물리적으로 control plane과 forwarding table 분리

 

• 논리적으로 중앙 집중화된 컨트롤 플레인이 필요한 이유?
  • 더 쉬운 네트워크 관리
    • 라우터 구성 오류 방지(라우터 오류 막음-> 개별 라우터 하나하나가 일치되게 동작하기 위한 configuration할  필요 x- 라우터가 포워딩 테이블 받아서 match&action만 하면 됨 
    • 예전에는 라우터 개별적으로 configuration-> central하게 포워딩 테이블 계산해서 알아서 컨트롤러가 라우터들에게 다운로드 시켜줌
    • 트래픽 흐름의 유연성 향상
  • 프로그래밍 가능한 라우터(centralized program vs distributed program)
    • 중앙집중식"프로그래밍" 이 더 용이: 중앙에서 테이블 계산, 분산시킴, flexible하게 forwarding table 계산해냄.
      • 라우터 회사가 단일화된 제품을 만들 수밖에 없음 -> 라우터 회사가 자기네 독점적 os 위에 독점적 인터넷 프로토콜 부여 탑재한 전체 통으로의 라우터제품 만들게 됨 -> 라우터회사가 독식, 한 회사가 모든 제품을 한 통으로 짜게 되면 individual한 기능 만들어낼 수 있는 산업 제한 
        • 각 individual 기능(운체나 라우팅테이블등) 의 발전 더딤 -> 미들박스 문제, 트래픽 엔지니어링 굉장히 유연하지 못함, 단일한 제품 사용해야 함 -> 이런 여러가지 traditional한 distributed routing algorithm의 한계점을 SDN(중요한 패러다임)이 극복가능. 
    • 분산형 "프로그래밍"이 더 어려움: 모든 라우터에 구현된 분산 알고리즘(프로토콜)로 인해 계산테이블 분산, 훨씬 여러개의 컴퓨터가 distributed way로 동작 -> 일치하는 목적 달성해야 함 -> 한계점 많고 복잡
  • 제어 플레인의 개방형(독점적이지 않은) 구현

SDN 비유: mainframe에서 PC로의 진화

• 수직 통합 폐쇄형, 독점형, 느린 혁신, 소규모 산업 -> 수평적 개방형 인터페이스,빠른 혁신, 거대한 산업
• mainframe으로부터 PC evolution의 굉장히 유사한 패러다임을 SDN 통해 네트워크 라우터에 가져오게 됨
  1. 옛날에는 Cisco같은 대표적 라우터 제조업체가 하드웨어+특별화된 독점 운체도 만들고 그 위 프로토콜(얘 자체는 오픈) 부여는 독점적으로 올림 -> 하나의 덩어리로 판매
  2. SDN이 나와서 packet switch 간은 굉장히 general한 match&action(forwarding table보고 header match해서 action 취하는) 가능한 스위치들 만드는 회사가 나옴

• 원격 제어 컴퓨팅, 라우터에 포워딩 테이블 설치
• forwarding table계산해서 각 라우터에 다 install하는 패러다임 -스위치들은 generalized된 flow based forwarding 할 수 있음
• destination based는 목적지 하나만 딱 봄. 헤더의 여러 필드들(link, network, transport, application protocal등) 을 갖고 종합적으로 특징 갖는 flow 트래픽에 대해 같은 포워딩(action)취할 수 있게 해주는 generalized flow based forwarding을 하게 됨.
• control plane과 data plane이 분리됐고, control plane 기능은 data plane의 switch 바깥에서 시행. switching의 processing volumn도 줄어들 뿐만 아니라 스위치가 스위칭 열심히 하고 있는 동안 컨트롤플레인의 기능- 플로우테이블 계산하는 일은 여기에서 이뤄질 수 있음.
  1. 각 스위치들은 generalized "flow-based" 포워딩 
  2. 제어,데이터 플레인 분리
  3. 데이터 플레인 스위치 외부의 컨트롤 플레인 기능
  4. 프로그래밍 가능한 제어 applications. programmable한 control plane 마음껏 사용할 수 있음

SDN 관점: Data plane switches

 

[SDN 네트워크의 구성요소]

• 빠르고, 단순하며, 상용화된 스위치는 하드웨어에서 generalized data-plane 포워딩을 부여 - 매치&액션만 할 수 있으면 됨
• 컨트롤러에 의해 설치된 스위치 플로우테이블이 컴퓨팅됨
• (southbound) API(ex. Openflow)
  • 테이블 기반 스위치 제어용; 제어 가능한 것과 그렇지 않은 것 정의
  • 컨트롤러와의 통신 위해
• SDN-controlled switches: 얘만이 데이터플레인에 속하는요소. flowtable에서 헤더 매치하고 플로우테이블에서 지시한 일 할 수만 있는 하드웨어 구성
• 네트워크 wide state 정보. 분산 entity

SDN 관점: SDN 컨트롤러(network OS)

1. 네트워크 wide 상태정보 유지 관리 
2. 노스바운드 API를 통해 위 네트워크 제어 애플리케이션과 상호작용
3. South bound API를 통해 아래의 네트워크 스위치와 상호작용
4. 성능, 확장성, 내결함성, 견고성을 위해 분산 시스템으로 구현
   • 개념적 이유로 인해 logical 하게 centralized 된 controllel 얘 자체가 물리적으로 중앙집권화된 하나의 서버는 아님. 네트워크 state information을 maintain하는 분산 entity로 물리적 구성

SDN 관점: 네트워크 제어 application(컨트롤 plane의 Top에 있음)

• 제어의 '두뇌': 하위수준 서비스, SDN 컨트롤러에서 제공하는 노스바운드 API를 사용하여 제어기능 구현
• 네트워크 status 정보. API가 제공하는 interface통해 접근
• 모두 control plane에 존재 but 구분됨.

• unbundled: 제 3자가 제공할 수 있음: 라우팅 vendor 또는 SDN 컨트롤러와 구분됨.

분산형 SDN 컨트롤러의 구성요소

• 네트워크 제어 앱에 대한 인터페이스 계층: 추상화 API
  • 추상화의 동작을 위해 사용될. 모델링해놓음
  • 네트워크 컨트롤 application과 얘기하기 위한 interface
  • 네트워크 그래프, REST(인터페이스)ful API
• 네트워크 전체 상태 관리 계층: 네트워크 링크, 스위치, 서비스상태(상태정보 모아놓음): 분산 데이터베이스-물리적으로 구성, database(지엽적으로 분산된)라 볼 수 있는데 물리적으로 centralized x
  • statistics(스위치로부터 모아와서 관리하고 있음)(ex. flowtable의 세 번째 entry)...,flowtable, link-state info(라우터로부터 수집), host info, switching info
• 통신계층: SDN 컨트롤러와 제어 스위치(SDN controlled switch들과 얘기하는 protocals)간 통신,
  • OpenFlow(SDN이 처음 등장할 때 나옴)
  • SNMP(분산 라우팅 알고리즘을 사용하는 traditional internet에서부터 있던 네트워크 관리 프로그램)

OpenFlow 프로토콜

[SDN controller, controlled switch, controlled device]와 [SDN controller] 사이의 인터페이스

• 컨트롤러와 스위치 사이에서 작동
• TCP(openflow msg가 여기 encapsulate됨)는 메시지교환에 사용
  • 선택적 암호화
• OpenFlow msg
  • controller-to-switch
  • switch-to-controller

*entity는 이런 분산된 역할을 맡는 개별 장치나 시스템

 

오픈플로우: 컨트롤러->스위치  메시지(MSG 이름과 기능이 거의 일치)

• 기능: 컨트롤러는 switch features와 switch replies를 쿼리(너의 특징-파라미터-들을 보내라)
• configure: 컨트롤러는 현재 스위치 구성 매개변수를 쿼리/세팅
  • SDN 컨트롤러: 상태정보 모으는중
• modify-state: 오픈플로우 테이블에서 flow entries를 add, delete, modify  -스위치 상태 수정 명령
• packet-out: 컨트롤러가 특정 스위치 포트에서 이 패킷을 보낼 수 있음 -이런 패킷은 너의 특정 스위치 포트로 아웃시켜라 라고 말함- 자기에게 오게 할수도 있음. 특정 서버 패킷을 검사해서 뭔가를 처리할 특정 서버로 보내게 할 수도 O
  • dataplane의 SDN -> ex. 특정 processing에 의해 스위치가 컨트롤러에게 패킷 갖다가 내보내는 것 요청

오픈플로우: 스위치->컨트롤러 메시지 전송

• packet-in(packet out으로 스위치가 명령한 것에 대해 이 패킷을 갖다가 컨트롤러에게 transfer): 패킷(해당 제어)를 컨트롤러로 전송.메시지를 flowtable에 싸서 내보냄. 컨트롤러로부터 packet-out msg 봄
• flow-removed: 스위치에서 삭제된 플로우테이블 entry, 스위치에서의 플로우테이블 entry가 delete됐을 때 이것을 컨트롤러에게 알림
• port status: 컨트롤러에게 포트상태 변경 알림

네트워크 운영자(SDN 컨트롤러)는 OpenFlow 메시지를 직접 생성/전송하여 스위치를 프로그래밍하지 x

(컨트롤러가 스위치를 컨트롤하는건데, 컨트롤러나 운영자가 직접 스위치를 컨트롤하지는 않음)

대신 컨트롤러에서 더 높은 수준의 추상화(노스바운드 API)사용-항상 얘네 통해 감

 

SDN: 제어/데이터 플레인 상호작용 예시

1.  S1, 링크장애 발생시 오픈플로우 포트상태 메시지를 사용하여 컨트롤러에게 알림
2. SDN 컨트롤러가 OpenFlow메시지를 수신하고 링크상태 업데이트
3. 링크상태가 변경될때마다 호출하도록 이전에 등록한 Dijkstra의 라우팅 알고리즘 애플리케이션 호출
4. Dijkstra 라우팅 알고리즘은 컨트롤러의 네트워크 그래프 정보, 링크 상태 정보에 액세스하여 새 경로 계산
5. 링크 상태 라우팅 앱은 SDN 컨트롤러의 플로우 테이블 계산 구성요소와 상호작용하여 필요한 새 플로우테이블 계산
6. 컨트롤러는 오픈플로우 사용하여 업데이트가 필요한 스위치에 새 테이블 설치

 

 

 

SDN: 선택된 챌린지

ㄴlogical하게는 performance but 물리적으로는 분산시스템- 어떻게 reliable하게 동작하게 해줄거냐?

• 새로운 패러다임, 네트워크가 빠르게 evolve할 수 있게 만들어주는 중요한 패러다임
• 컨트롤 플레인 강화: 신뢰할 수 있고 안정적이며 성능확장 가능하고 안전한 분산시스템
  • 장애에 대한 견고성: 제어 플레인을 위한 신뢰할 수 있는 분산 시스템의 강력한 이론 활용
• 네트워크, 프로토콜 미션별 요구사항 충족
  • 실시간. 초고신뢰성, 초고보안 등 - 이전 요구들도 어떻게 만족시켜줄건가
• 인터넷 확장: 단일 AS넘어선 인터넷 확장성
• 5G 셀룰러 네트워크에서 중요한 SDN - 수많은 AS로 구성되는 인터넷의 SDN 컨트롤러가 제대로 동작할 수 있는 구조연구돼야함.

5.6 인터넷 제어 메시지 프로토콜(ICMP)

ICMP: internet control message protocal

• 네트워크 레벨 정보 전달을 위해 호스트 및 라우터 사용 
• 네트워크 레벨의 문제를 report하는 IP나 ICMP나 모두 네트워크 계층 프로토콜이지만 IP데이터그램에 encapsulate돼서 목적지로 전달돼야 함.
• traditional 한 인터넷 네트워크 계층의 아래에 있는 control protocol 
  • 오류 보고(주된 목적): 연결할 수 없는 호스트, 네트워크, 포트, 프로토콜 -> IP가 전달하려니까 전달할 대상 없는 것과 유사
  • 에코 요청/응답(핑에서 사용)
• 네트워크 계층 "above" IP: 
  • IP로 전달되는 ICMP msg
• ICMP msg : 유형, 코드+ 오류를 일으킨 IP데이터그램의 첫 8바이트/ encapsulate+ carry 
  • 라우터-라우터로 가게 됨. 라우터-호스트간의 1홉이나 2홉이상인 경우가 많음. 결국 호스트의 목적지 주소를 향해서 네트워크를 travel 해야함.-> ip 데이터그램에 encapsulate되지 않을수가 x.

 

실제 인터넷 딜레이와 라우터

• 목적지로 가기 위해 거치게 되는 각 라우터의 이름과 ip주소, 그리고 그 라우터까지 라운드트립 딜레이 - 각 라우터별로 3개씩 알려줌(1개만으로는 약간 time varing결과기에 더 general 한 아이디어 얻고자.)
  • 이거 구현할 때 ICMP TTL expired랑 목적지포트 언리쳐블 메시지 활용했음. ip데이터그램 계속 포워딩하다가 TTL이 0이 되면 너무 오랫동안 네트워크 돌아다니면서 목적지에 이르지 못했구나 하고 버림.

 

Traceroute and ICMP

*내보낸 시간과 ICMP msg 받은(TTL expired) 시간차 -> 라운드트립타임 구할 수 있음

* **Traceroute(트레이스 라우트)**는 네트워크에서 **패킷이 목적지에 도달하기까지 거치는 경로(라우터들)**를 추적하고, 각 경로에서의 응답 속도와 지연 시간을 확인하는 데 사용되는 네트워크 진단 도구

• 소스에서 대상에게 일련의 UDP 세그먼트(3개씩 1세트) 전송.- trace route 구현하기 위해 
  • 가능성이 없는 포트번호 - 무작위의 있을 것 같지 않은 아무 포트번호를 UDP segment의 포트번호로 집어넣음
    • 목적지 포트번호 명시
  • 첫번째 세트는 TTL=1 - 첫번째 라우터까지만 감
  • 두번째 세트는 TTL=2 등 - 2번째 라우터까지만 감 -> TTL expired돼서 drop. -> n번째 set는 n번째 라우터까지 감.
• n번째 세트의 데이터그램이 n번째 라우터에 도착하면
  • 라우터는 데이터그램을 버리고 source ICMP msg(type 11, code 0)를 보낸다. - 이후로 TTL이 expire해서 너의 데이터그램을 DROP했어. 
    • ICMP받았을 때 RTT 체크 - 시간차 갖고 라운드트립 계산 
    • n번째 set받은 라우터는 UDP segment에 실려있는 IP 데이터그램 DROP <- TTL expired돼서. 
  • ICMP msg에는 라우터 이름 및 IP주소 포함. 
• ICMP msg가 도착했을 때 source는 RTT를 기록한다.
• 중지기준
  • 매 세트 내보낼떄마다 TTL 하나씩 증가. 궁극적으로 UDP segment가 destination host까지 TTL expired 하지 않고 가게됨. 
  • UDP 세그먼트가 결국 목적지 호스트에 도착
  • 목적지가 ICMP "포트 언리쳐블" 메시지(type3, code3) 반환-포트번호와 다르게 거의 존재하지 않는 포트번호,
  • source 중지

 

5.7 네트워크 관리와 SNMP, NETCONF/YANG

 

네트워크 관리란 무엇인가?

• 자율시스템(일명 네트워크): 1000개 이상의 하드웨어/소프트웨어 구성요소 상호작용. 
• 모니터링, 구성, 제어 필요
• 네트워크 관리 프로토콜
  • 네트워크 및 요소 리소스를 모니터링, 테스트, 폴링, 구성, 분석, 평가, 제어하기 위한것
  • 합리적인 비용으로 실시간(동작할 때 요구되는 사용자들에게 제공해야 하는 QoS, 운영성능 및 서비스 품질(QoS) 요구사항 충족
  • ex. SNMP(단순 네트워크 관리 프로토콜) - 전통적으로 internet에서 가장 오랫동안 사용된 네트워크 관리 프로토콜

네트워크 관리를 위한 구성요소

 

• 서버(or controller)관리: 애플리케이션, 일반적으로 네트워크 관리자(많은 경우 involve)(사람)가 루프에 있는 애플리케이션
• 네트워크 관리 프로토콜: 관리 서버가 장치를 쿼리, 구성, 관리하는 데 사용, 장치가 관리 서버에 데이터, 이벤트 알리는 데 사용
• 관리되는 디바이스: 관리 및 구성 가능한 하드웨어, 소프트웨어 구성요소를 갖춘 장비
• 데이터: 디바이스 "state" 구성 데이터, 운영 데이터, 디바이스 통계

 

네트워크 운영자의 관리 접근 방식

* **"CONFIGURE"**는 설정하다, 구성하다, 또는 조정하다라는 뜻

• CLI(command line interface)-가장 원시적인 것
  • 운영자가 개별 장치에 직접 발행(유형(commend line typing, 스크립트-직접적으로 configure, data collect) (예: vis ssh)
• SNMP/MIB(SNMP라는 프로토콜이 사용되는 환경에서 다뤄질 네트워크데이터 모아놓은 정보데이터)
  • 목적: managed device를 query해서 상태를 알아오거나 managed device의 configuration setting 
  • 운영자가 단순 네트워크 관리 프로토콜(SNMP)을 사용하여 디바이스 데이터(MIB)(실제로 사용된 것 : periodic 하게 managed device의 상태정보 collecting에 초점)를 쿼리/설정하는 방식
  • 운영자가 MIB에 저장돼있는 애들 query, MIB에 configuration data setting
  • SNMP: 각 managed device query해서 상태 알아옴 or managed device와 configuration setting 둘 다 하고 싶었음. 하지만 실제사용: periodic하게 management device의 상태정보를 collect하는 것에 초점 맞춰짐.
• NETCONF/YANG
  • 보다 추상적이고 네트워크 전반(configuration enforce할 수 있게.)에 걸친 총체적인 접근방식
  • managed device를 configure한다던가 하려면 사람이 많이 involve돼서 해야함. -> 좀 더 abstract하게 네트워크 상태정보, configuration 정보 modeling - configuration aspect들 사이에 conflict가 없게 모델링
  • 멀티 디바이스 구성 관리에 중점을 둠
    • YANG: 데이터 모델링 언어 - NETCONF에서 사용할것
    • NETCONF : YANG-호환가능한 원격장치와의 action/data to/from/among 통신, YANG comparable한 action이나 data를 remote device와 주고받는 역할

 

SNMP2 프로토콜

• UDP위에 올라가있음. V1,V2 securex. V3:보안구현
• UDP(포트 161,162-well known port)의 애플리케이션 계층 프로토콜
  • UDP segment에 SNMP msg 쌓여서 전달 
  • 네트워크 관리 제어(서버-> 관리 디바이스로 나가는 msg) 및 정보메시지(managed device로부터 server로 오는) 전달용
  • 관리 서버와 에이전트 간
• MIB정보(설명 언어 SMI(관리데이터를 묘사하는 언어)에 명시, management data갖다가 MIB라는 특정 이름이 붙은 DB로 유지)를 전달하는 2가지 방법, 명령:

 

NETCONF 개요

• 목표: 네트워크 전반의 디바이스 능동적 관리/구성(한계극복-> 좀 더 active하게 device management, configue, individual device  차원 x, 네트워크 차원에서 그렇게 하고싶어서 나온 프로토콜)-좀더 active하게, networkwide로
• 관리서버와 관리네트워크 디바이스 사이에서 작동
  • action: 데이터를 retrieve, configuration 파라미터를 set, configuration을 modify, 기능을 activate configuration
  • 여러 장치에 대한 actomic-commit(원자 커밋- 연속적인 action을 취함) action 
    • multiple device에 수행: 하나의 명령 지시 -> 그 명령이 연속적 action에 쫙 수행
  • 운영 데이터 및 통계 쿼리
  • 장치에서 알림구독
• 원격 과정 호출(RPC)패러다임
  • NETCONF 프로토콜의 서버와 클라이언트 사이에는 원격 절차 call 패러다임으로 프로토콜 메시지 주고받음.
    • 함수호출하면 거기에 대한 return value알려줌. local procedure call은 call의 메인결과; return value-but 얘는 action취하는게 주됨. 
  • NETCONF 프로토콜 메시지는 XML로 encoded
  • 안전하고 신뢰할 수 있는 전송(예: TLS)프로토콜을 통해 교환(프로토콜 메시지로 encapsuate돼서) 
  • SMTP가 version 1,2 전부 security 전혀 x, UDP 위에서 UDP에 encapsulate됨. but 얘는 TLS에 프로토콜 메시지로 encapsulate

 

YANG

• NETCONF 네트워크 관리 데이터의 구조, 구문, 의미를 지정하는 데 사용되는 데이터 모델링 언어
  • SMI(SNMP의 MIB에 해당)와 같은 내장 데이터 유형
  • 어떻게 표현하냐? syntax, sementix 묘사
• 장치를 설명하는 XML문서, 가능성은 YANG설명에서 자동으로 생성될 수 있음
• valid한  NETCONF에 의해 만족돼야 하는 데이터 사이의 제약을 표현할 수 있음
  • YANG의 모델링 된 data로부터 generate 
  • NETCONF 구성이 정확성, 일관성 제약 조건을 충족하는지 확인 -YANG으로 모델링된 데이터로부터 generate해낸다면  configuration한 제약을 다 정의해놓음 -> 위반하지 않도록(conflect 없도록)

 

Chapter 5 요약

• 네트워크 control plane에 대한 접근방식
  • per-router control(전통적) - 일반적인 routing algorithm들(Dikstra, linkstate, Bellman ford DV)
  • logically centralized control(software defined networking - SDN)
• Traditional routing 알고리즘
  • 인터넷에서의 구현: RIP, OSPF, BGP
• SDN 컨트롤러
• ICMP(인터넷 제어 메시지 프로토콜)
  • 인터넷에서 에러 리포딩, ping app, traceroute app, packet이 네트워크 정신없이 돌아다닐 때 막기 위한 (packet drop했을 때 source측에서 알려주는) 여러가지 역할 하는 error reporting 프로토콜
• 네트워크 관리 프로토콜
  • CLI command line interface 통해 가장 primitive하게 이루어짐. 
  • 네트워크 디바이스들의 상태정보 모니터링 목적으로 주요하게 사용됐던 SNMP 프로토콜, 원자커밋 액션을 네트워크 전체에 적용하는 좀 더 발전된 configuration을 정말 할 수 있는 프로토콜로 등장한 NETCONF, 얘를 위한 DATA modeling language