ABOUT ME

    -

    Today
    -
    Yesterday
    -
    Total
    -
    • [네트워크] SDN과 ICMP
      카테고리 없음 2023. 12. 7. 22:34

      SDN(Software Defined Network) 이란?

       

      SDN은 프레임워크로 network control(path selection algo 구현 + middlebox at brain)을 하는데, 이는 인터넷 고객의 패킷이 최종적으로 통과하는 단순하고 빠른 네트워크 장치(data plane)와 구별되고 멀리 떨어져 있는 서버(network-control app, layer of control plane)에서의 정교한 소프트웨어인 high-level(northbound) API를 사용하여 프로그래밍된다.

       

      SDN is a framework

      • 네트워크 관리자가 자동적이고 동적으로 관리 및 제어할 수 있도록 허용하기 위한
      • 다수의 네트워크 장치, 서비스, 토폴로지, 트래픽 경로 및 패킷 처리(QoS) 정책을 위한
      • high-level languages and APIs를 사용하기 위한
      • 관리에는 provisioning, operation, monitoring, optimizing, and managing FCAPS
        (Faults, Configuration, Accounting, Performance, and Security) in a multi-tenant environment가 포함된다.

      how?

      The physical separation of the network control plane from the forwarding plane, and where a logically centralized control plane (server) controls several routers.

      • Why a logically centralized control plane? 
        • Easier network management
          • avoid router misconfigurations, greater flexibility of traffic flows
        • Programmable router: centralized “programming” easier: compute flow tables centrally and distribute
        • open (non-proprietary) implementation of control plane(개방적 연결성): 하드웨어와 소프트웨어를 분리함으로써, 네트워크 장비의 제조사 및 종류에 구애를 받지 않고 빠르게 진보가 가능하다.

       

       

      SDN control plane 등장 배경은?

       역사적으로 네트워크는 distributed, per-router 로 구현 되어왔다. monolithic router는 switching hardware를 가지고 있고, 자신만의 구현을 하는데 여러가지 프로토콜을 가진다. 그런데 각기 다른 middleboxes가 존재한다. firewall, load balancers, NAT boxes, 등등… 이것을 어떻게 해결해줄까? 회사는 본인의 라우터에 맞게 이런 기능을 다 개발해야하는 걸까? 그래서 network control plane에 대한 고민의 해결책으로 SDN이 등장했다.

       

       

       좀 더 알아보기 위해 per-router control plane과 logically centralized control plane을 살펴보자.

       

      SDN 라우터의 control plane과 data plane을 서로 분리시키고, controller를 중앙화시킨 개념이다. 라우터의 control plane 부분에서 라우팅 알고리즘을 통해 최적의 경로를 계산하고,  계산된 경로에 따라 data plane 부분에서 forwarding을 수행하는 per-router control plane 방식과는 다르게, 최적 경로를 계산하는 controller 부분을 하나로 집중시킨 개념이다. 따라서 라우터는 전송역할(data plane)만 한다. 

      초록색 부분이 돌아가는 brain 서버가 있고, SDN control을 하는 서버가 각각 존재한다. SDN control을 하는 서버는 여러개 존재하지만 초록색 부분은 하나이기 때문에 logically centralized 서버인 것이다. 

       

      per-router control plane 이란?

       

       per-router contol plane은 각각 라우터들이 개별적으로 Routing Algorithm을 돌리면서 정보를 주고받는다. 그래서 각 라우터별로 control plane을 돌려 forwarding table을 각자 계산해서 갖고 있는 것이다. Routing Algorithm이 메시지를 서로 주고받고 있는 것이다. 그래서 이 알고리즘을 토대로 forwarding table이 만들어진다. 

       

       

      logically centralized control plane(SDN)이란?

       

       

       하나의 logical하게 중앙화된 Remote Controller에서 모든 계산을 해준다. 각자 있던 control plane을 떼다가 한 곳에 몰아 넣었다고 보면된다. 그러면 CA가 Remote Controller하고 이야기 해서 계산된 결과만 받아오면 된다.

       이것을 발전시켜보면, data plane은 각 라우터별로 있고, control plane만 떼다가 묶어서 하나로 만들어주고, 이것을 프로그래밍 하는 것이 SDN인 것이다.

       

       

       SDN은 위와 같은 배경으로 등장하였다.

      SDN을 사용함으로써 이전에는 라우터가 잘못 구성되는 경우도 있었는데 이를 피할 수 있고, traffic flow에 대한 유연성을 더 좋게 만들 수 있었다. 그래서 table-based forwarding 프로그래밍을 하게 된 것이다 (centralized 프로그래밍). 지금까지는 분리된 프로그래밍이었다.

       그래서 table-based forwarding에 API를 하나 둔 후, 이부분을 OpenFlow API를 제공해주어 프로그래밍을 줄 수 있었다. 이 OpenFlow는 control plane을 open(누구나 쓸 수 있게)으로 구현했다.

       

       

       

       PC를 생각했을 때 PC는 맨 밑에 하드웨어가 있고, 그 위에 OS, 그 위에 Application이 있다. 하드웨어도 여러 종류, OS도 여러 종류, Application도 여러 종류이다. 이럴 때 맨 아래 Microprocessor 위에 Open Interface를 만들면, 그 위에 어떤 OS가 돌아가도 작동한다. OS와 Application 사이도 마찬가지이다. 왼쪽이 per-router control plane이고, 오른쪽이 logically centralized control plane이다.

       

       

       

       u에서 z로 보내려면은, 기존에는 라우팅 돌려서 경로를 결정해야한다. 그런데 역으로 생각해서 경로를 먼저 정해주고 보내주는 것은 어떨까?

       예를 들면 u-z로 보낼 때 uvwz를 통해서만 traffic을 지나갈 수 있게 경로를 만들어주려고 한다. 그리고 x-z로 보낼 때 xwyz를 통해서만 지나갈 수 있게 만드려고 한다. 이것은 기존 라우팅 프로토콜로 불가능하다.

       => 이런 경로를 SDN에서 프로그래밍 해주는 것이다.

       

       u-z로 보내는데 traffic을 분할하고 싶다. 절반은 uvwz로, 절반은 uxyz로. 이것은 load balancing하는 것인데, 라우팅 알고리즘이 두개 필요로 하게 된다. 그래서 기존 라우팅 프로토콜은 항상 최적의 경로만 찾기 때문에 불가능하다.

       => 이런 경로를 SDN에서 프로그래밍 해주는 것이다.

       

      SDN logical structure 를 살펴보자

       

       

       

      • Analogy of  SDN = unbundled systems (NW control applications, SDN controller (NW OS), NW devices are separately developed by different companies)  
        • 1) NW control application layer : Dijkstra의 알고리즘, NAT 알고리즘,로드 밸런서 등 어떻게 동작할 것인지 제어하는 기능을 실질적으로 구현한다. SDN controller에 의해 API를 제공받는다. 라우팅테이블을 만든다.
        • 2) SDN controller (NW OS) : NW 제어 앱의 출력을 이용하여 패킷 스위치(네트워크 토폴로지 DB 등)를 유지보수/제어합니다.네트워크 어플리케이션과 통신하는 northbound API가 있고, data plane switch들과 통신하는 southbound API가 있다. 성능, 확장성 등의 개선을 위해 분산 시스템 형태로 구현된다. 라우팅테이블에서 best of best를 뽑아 포워딩테이블을 만든다.
        • 3) Packet switches : Simple&Fast, 엔드 호스트의 메시지가 전달되는 H/W로 구성되며, 소프트웨어를 통해 구현된 라우팅 방법에 따라 generalized forwarding을 수행한다. SDN controller와 통신하기 위한 API가 존재하며 대표적인 예시로는 Openflow가 있다.
      • Analogy of Traditional router = mainframe computer (control plane and data plane are built in one node by one company)

       

      SDN-controlled switches 이란?

       

       

       data plane은 SDN control 되어있는 SDN-controlled switch들이다. 이것들은 스위치 기능(보통 라우터라고 안 부른다)을 해주는 하드웨어이다.

       이 내부에는 flow table이 있어 table 기반의 switch control이다. software에 의해 control 되는 API가 존재하는데 이 API는 OpenFlow를 통해서 단일화되어 있다. OpenFlow에는 어떤 것이 control 가능한지, 어떤 것이 안되는지 이런 것들이 정의되어 있다. 그리고 이 controller하고 communication해야 하므로 이에 대한 protocol이 있는데, 이 protocol은 OpenFlow에 의해서 정의가 되어있다.

       

       

      SDN controller 이란?

       

      하드웨어 switch 위에는 SDN controller가 있다. 이 controller는 network OS로 생각하면 된다. Network에 대한 상태정보를 갖고 있다. 그래서 실제 application들과 SDN-controlled switches들의 중간역할을 하게 된다. 그래서 SDN controller는 각각 분산적으로 구현이 된다. performance, scalability, fault-tolerance 등을 해결하기 위한 역할을 한다.

       

       

      network-control applications란?

       

       맨 위에 network-control application들 있다. 이게 핵심적인 routing, load balance, access control과 같은 부분이 있다. 여기서 중요한 것은 unbundled이다. 밑에 있는 하드웨어와 독립되어 있다. API를 통해서 routing vendor 또는 SDN controller와 분리시킬 수 있다. 

       

       

      SDN controller에 들어가는 요소들을 살펴보자

       

      communication layer : switch하고 통신하는 부분. OpenFlow나 SNMP가 있다. 이런 네트워크를 관리하는 protocol들이 붙어있다.

      Network-wide state management layer : 분산된 switch, router들에 대한 정보들이 DB에 저장이 된다. link-state에 대한 정보, host 정보, 물리적인 switch 정보들이 중간에 쌓인다. 그러면 이것으로부터 통계를 뽑아내고 flow table도 만든다.

      interface layer : 바깥 routing이랄지, 맨 위에 있는 프로그램을 실제 하기 위한 API들이 있다.

       

      OpenFlow protocol 이란?

       

      OpenFlow란 data plane과 control plane 사이를 이어주는 인터페이스이다. 메시지 교환에는 TCP가 사용되며 openflow 메시지에는 controller to switch, switch to controller 클래스가 있다. (symmetric 클래스도 있으나 생략)

       

      OpenFlow는 SDN controller에게 네트워크 상태에 대한 최신의 정보를 제공한다. controller와 라우터들(SDN으로 제어받는 장치들)간의 통신은 south-bound 인터페이스를 넘나든다. 이 통신 기능을 제공하는 프로토콜이 OpenFlow이다.

       

      ⇒ Fortunately, network operators(SDN controller) don’t program switches by creating/sending OpenFlow messages directly. Instead use higher-level abstraction (northbound API) at controller.

      flow table은 SDN controller가 아닌 network-control applications가 programming하고, controller는 전달만 한다.

       

       

      1. OpenFlow: controller-to-switch messages

      Controller에서 switch로, 위에서 아래로 내려가는 것이다. 이 때는 어떤 message가 내려갈까?

      - features : controller가 어떤 switch features에 대한 쿼리를 보내서 switch가 응답한다.

      - configure : controller가 어떤 parameter를 설정하는 것이다.

      - modify-state : OpenFlow tabale을 추가, 삭제 및 수정한다.

      - packet-out : controller가 switch port에서 어떤 패킷을 보내라고 요청한다.

       

       

      2. OpenFlow: switch-to-controller messages

      switch에서 controller로, 아래서 위로 올라가는 messages이다.

      - packet-in : 어떤 패킷을 controller에다가 전달한다.

      - flow-removed : switch에 있는 어떤 flow table entry를 삭제되었다는 것을 알려준다.

      - port status : controller에다가 내 port가 바뀌었다고 알려준다.

       

       

       network operator들은 OpenFlow messages를 통해 바로 프로그램하는 것은 아니다. 이것은 공통되도록 정해지는 것이고, 실제 모든 것은 SDN controller에서 작동한다. 즉 네트워크의 효율적 운용을 위해서 기능을 잘 분리시켜 놓았다는 것이다.

       

      실제 interaction 하는 예시

       

      1. s1이 controller에다가 link failure가 생겼다고 OpenFlow protocol을 통해서 알려준다.

      2. 중간에 있는 SDN controller가 이를 받고, 자신의 link state information을 업데이트 한다.

      3. 이 내용을 위쪽으로 올려서 다이제스트라 알고리즘이 이 변화를 적용해서 알고리즘을 돌리게 된다.

      4. 이 알고리즘의 계산 결과인 route 정보를 밑으로 내려준다.

      5. 맨 위에 있는 routing application이 계산된 Flow table을 밑으로 내려준다.

      6. controller가 OpenFlow 통해서 밑에 있는 모든 switch들에게 이렇게 적용하라고 뿌려준다.

       

      SDN의 selected challenges는?

       SDN은 2010년 이후에 나온 기술로, 나온지가 오래되지는 않았다. 몇 년 되지는 않았지만 급속도로 시스템에 파고들고 있다. 실제 모바일 쪽, 5G 기관망에서도 SDN의 철학이 다 들어가 있다.

       그래서 좀 전에 보듯이 controller들을 dependable하게 만들 수 있을까. 즉 얼마나 더 신뢰할 수 있을까. reliable의 상위개념이라고 보면 된다. performance-scalable, secure distributed system. 이런 부분들을 control plane을 얼마나 더 잘 설계할 것인가 하는 이슈가 계속 남아있음. real-time이라던지 ultra-secure 이런 mission-specific한 요구조건들을 맞추도록 어떻게 잘 설계할 것인가는 아직도 연구가 이루어지고 있다. -> 인터넷을 중앙통제할 만큼의 니즈가 있다.

      • internet-scailing
      • mission-specific requirements에게 유용

      SDN vs NFV

      • SDN: Separation of control plane & data plane
      • NFV: Separation of HW and function (가상화). 여전히 dest-IP based forwarding

       

      ICMP(Internet Control Message Protocol) 란?

       

       

      인터넷 상에서 보내고 받고 하는 수많은 control에 대한 부분을 해결해주는 protocol이다. 그래서 host나 router에서 사용된다. 주로 error reporting에 많이 사용된다. ICMP report의 수신자는 문제가 발생한 패킷을 처음 생성해 보낸 IP이다.

      네트워크의 성능을 평가할 수 있는 traceroute 또는 ping 모두 ICMP를 사용한다. traceroute를 사용하면 데이터 패킷이 대상에 도달하기 위해 통과한 장치를 나타내며, ping은 데이터가 두 지점 간을 이동하는 데 걸리는 시간을 나타낸다.

       ICMP 자체는 네트워크 계층의 프로토콜인데, IP 위에 올라간다. ICMP message는 type, code를 정의해놓고 8byte 정도의 message로 IP datagram에 넣는다. -> ipmp보낸 어플리케이션을 포트번호로 찾으려고

       

       

      traceroute 란?

       

      출발지에서 도착지까지의 경로의 상태를 살펴보는 traceroute가 ICMP 이다. traceroute하는 과정을 살펴보자.

      TTL=1로 보내 one hop delivery time을 측정할 수도 있고, destination까지의 hop 수도 측정 가능하다.

       

       UDP로 보내는데, 일단 맨 처음 TTL=1로 찍어서 보낸다. TTL은 라우터 한번만 건너겠다는 뜻이다. 그러면 그 한 번에 담긴 시간과 정보들이 있다. 그리고 TTL=2로 찍어서 보낸다. 라우터를 두번 건너띄게 되고, 건너갈 때마다 각각에 대한 측정된 delay, 시간을 종합하면 전체 경로, node에 대한 정보를 수집할 수 있다. 그 때 사용하는 것이 ICMP로 하는 것이다.

       그래서 ICMP message 내에 라우터의 이름이나 주소가 들어가 있다. delay도 계산 가능하다. 결국 destination host에 도착하게 되면, port unreachable message를 type3, code3으로 바꿔서 주면 source는 멈추게 된다.

       

       

       

      네트워크 관리에는 합리적인 비용으로 네트워크 및 요소 리소스를 모니터링, 테스트, 폴링, 구성, 분석, 평가 및 제어하기 위한 하드웨어, 소프트웨어 및 인적 요소의 배치, 통합 및 조정이 포함된다. 수많은 하드웨어와 소프트웨어가 서로 상호작용하며 얽혀 있는 구조에서 이를 부분적으로 관리하는 주체가 필요하다. 

       

       

       

      네트워크 관리의 핵심 요소를 살펴보자.

      • managing server: 네트워크 관리자가 있는 어플리케이션
      • Network management protocol : 디바이스를 질의, 구성, 관리하기 위해 managing server에 의해 사용되거나, managing server에게 데이터나 이벤트를 알리기 위해 디바이스에 의해 사용된다.
      • managed devices: 관리 대상 네트워크에 존재하는 장비들(host, router, switch, middle boxes)

       

      SNMP(Simple Network Management Protocol) 란? 

      SNMP는 IP 네트워크상의 장치로부터 정보를 수집 및 관리하며, 또한 정보를 수정하여 장치의 동작을 변경하는 데에 사용되는 인터넷 표준 프로토콜이다. network operator는 SNMP를 이용해 디바이스 데이터를 질의하거나 설정한다.

       

       

      MIB (Management Information Base)란? 

      MIB란 Management Information Base를 의미하며, 네트워크를 관리할 때 관리되어야 할 특정한 정보나 자원의 객체 이다. 

      managed device에 agent를 띄워 manabed devices에 관련된 정보들을 MIB에 저장하면, 이 값들을 managing server에서 이용할 수 있다.

      • Managing server와 Agent간에 MIB data를 주고 받는데에 사용하는 프로토콜이 SNMP(UDP로 동작)

       

      SNMP의 두가지 모드는?

       

      1) request/response mode

       

      managing server가 디바이스에게 MIB를 요청하면 각각의 디바이스는 이에 응답하는 구조이다.

       

      2) trap mode

       

      디바이스가 먼저 managing server에게 trap 메시지를 보내는 구조로, 주로 어떤 예외 사항이 발생했을 때 사용한다.

       

       NETCONF 란?

      Network as a platform, 즉 네트워크를 더 이상 호스트를 연결하는 역할로만 보는 것이 아니라, 서비스 제공자와 사용자가 만나는 플랫폼으로 인식하게됨으로써 기존의 SNMP로는 NMS의 한계를 느껴 다양한 서비스 기능과 데이터를 설정/제어 할 수 있는 NETCONF가 등장했다.

      YANG 이란?

      YANG (Yet Another Next Gerneration) 은 NETCONF로 전달하고자 하는 데이터를 특정하기 위한 데이터 모델링 언어로, 디바이스를 표현하는 XML 문서는 YANG 표현으로 생성될 수 있다.
      YANG은 유효한 NETCONF configuration에 필요한 제약 조건을 명시해 줄 수 있다.

       

       

       

      네트워크 관리 시스템(NMS)은 다음으로 구성됩니다.

      1. 서버 관리,
      2. 관리되는 개체(장치),
      3. 관리 서버와 통신하는 각 관리 중인 장치의 에이전트
      4. SNMP(Simple Network Management Protocol)/관리 정보 베이스(MIB)
      5. 넷컨프/양
      6. SNMP 또는 NETCONF : 관리 서버와 에이전트 간의 통신 프로토콜
      7. MIB 또는 YANG : 데이터 모델링 언어
      • SNMP와 비교한 NETCONF의 강점
      1. SNMP는 모니터링(monitoring) 위주인 반면 NETCONF는 제어(controlling) 중심
      2. 더 다양한 네트워크 장비를 관리하기 효과적임 = 더 다양한 서비스 기능/데이터를 정의할 수 있음.
      3. SNMP와는 달리 GUI(Graphic User Interface) 제공이 용이함.
      4. Error 전달/복구 기능이 강화됨.
      5. 많은 개수의 네트워크 장비를 포함하는 대형 네트워크에 (SNMP 보다 더) 적합함.
      6. UDP를 통한 SNMP 대 TLS/TCP를 통한 NETCONF: SNMP보다 더 안전함
    Designed by Tistory.

    티스토리툴바