요약
- RFC 1270은 관리 트래픽이 라우터를 넘어 이동해야 하고 기반 링크 기술과 독립적이어야 했기 때문에 SNMP가 평상시에는 UDP/IP 위에서 전달되어야 한다고 주장했습니다.
- 라우팅, 체크섬, 멀티플렉싱, 단편화는 네트워크 스택의 기능이었고, 링크별 관리 교환은 관찰 대상 세그먼트에 갇힐 수 있었습니다.
- 이 메모는 Informational이었으며 새로운 표준이 아니었고, UDP/IP가 전체 네트워크 장애 상황에서도 관리 트래픽을 전달할 수 있다고 주장하지 않았습니다.
관리 경로는 링크를 넘어야 했다
1991년경 SNMP의 역할은 관리 스테이션이 네트워크 장비를 점검하고 제어할 수 있도록 하는 것이었습니다. 그러나 이러한 장비에 도달하는 패킷 경로는 실용적인 질문을 던졌습니다. SNMP 메시지가 각 로컬 네트워크 기술 위에서 직접 전달되어야 할까요, 아니면 이러한 네트워크들을 연결하는 동일한 인터네트워크 계층이 운반해야 할까요?
RFC 1270은 일반적인 인터넷 사용에 대해서는 후자를 선택했습니다. 이 논거는 프로토콜 다이어그램에서 사라질 수 있는 특성에서 출발합니다. 관리 스테이션과 그것이 감시하는 장비는 종종 같은 물리적 링크 위에 있지 않습니다. 이더넷 전용 관리 교환은 한 세그먼트의 장비에는 도달할 수 있지만, 그 자체로는 라우터를 넘어 다른 세그먼트의 장비에 닿지 못합니다. 네트워크 계층 주소와 라우팅 경로는 가능했습니다.
이 구분은 관리 평면을 로컬 매체에 덜 의존하게 만들었습니다. 서로 다른 링크 기술로 네트워크들을 연결하면서 IP가 그 위에 공통 계층을 제공할 수 있었습니다. 따라서 동일한 SNMP 메시지 형식이 각 홉이 어떤 링크 기술을 사용하는지 관리 애플리케이션이 알 필요 없이 라우터 사슬을 통해 이동할 수 있었습니다.
하나의 논거, 여러 네트워크 계층의 역할
이 메모는 IP를 장식용 포장으로 취급하지 않았습니다. 네트워크 관리 전송이 필요로 하는 작업들을 열거하고, 네트워크 계층이 이미 그 상당 부분을 제공한다고 주장했습니다. 라우팅은 국지적 장애 주변으로 패킷을 우회시킬 수 있었습니다. IP는 헤더 체크섬을 담고, 여러 프로토콜이 네트워크 계층을 공유할 수 있도록 멀티플렉싱과 디멀티플렉싱을 제공하며, 패킷이 링크의 전송 단위를 초과할 때 단편화와 재조립을 처리했습니다.
각 기능은 서로 다른 조정 비용을 다루었습니다. 라우팅은 관리가 네트워크 경계를 넘어 도달할 수 있게 했습니다. 매체 독립성은 모든 기반 링크마다 별도의 관리 전송을 작성하는 일을 피하게 했습니다. 멀티플렉싱은 관리가 다른 네트워크 프로토콜과 공존하도록 했습니다. 단편화는 크기 제한이 다른 링크를 패킷이 건너갈 수 있게 했으나, 한 단편이라도 유실되거나 지연되면 전체 데이터그램을 재조립할 수 없다는 위험을 수반했습니다. 따라서 RFC 1270은 불안정하게 동작하는 네트워크에서는 작은 패킷을 사용하라고 조언했습니다.
이는 IP가 모든 장애 상황에서 관리 가능성을 유지한다는 주장이 아닙니다. 경로가 존재하는 위치에 대한 주장입니다. 한 지역이 손상되었더라도 대체 경로가 남아 있다면, 라우팅은 그 지역 너머의 장비에 도달하는 방법을 보존할 수 있습니다. 유일한 경로나 목적지 자체가 사라졌다면 UDP는 대체 경로를 만들거나 응답을 보장하지 않습니다. 네트워크를 관찰하려는 것이었다 하더라도 관찰 가능성은 네트워크에 의존합니다.
표준화 경계이지 보편 법칙이 아니다
RFC 1270은 자신의 지위에 대해 명시적이었습니다. 이는 Informational 메모였고 인터넷 표준을 규정하지 않았습니다. 당시 유효한 SNMP 명세인 RFC 1157은 SNMP 메시지 교환을 위해 UDP를 규정했고, RFC 1270은 그 당시 이 목적으로 표준화된 전송은 UDP뿐이라고 밝혔습니다. 따라서 UDP/IP에 대한 권고는 부분적으로는 기존 표준에, 부분적으로는 인터넷 전반의 상호운용성에 관한 배포 논거에 근거했습니다.
이 메모는 예외도 유지했습니다. 전용 대역 외(point-to-point) 네트워크에는 IP 라우팅이 필요하지 않을 수 있습니다. 운영체제가 관리 가능한 링크 드라이버 인터페이스를 노출한다면, 특정 장비에 대해 직접 접근이 유용할 수 있습니다. 이러한 예외는 일반적 경우를 뒤집지 않았습니다. 오히려 올바른 통신 서비스는 토폴로지와 관리 대상에 따라 달라진다는 점을 보여줍니다.
이후 RFC 1418은 UDP/IP를 사용할 수 없는 환경을 위해 OSI의 비연결형 전송 서비스 위의 SNMP를 규정하면서도, 대부분의 인터넷 환경에서는 UDP/IP가 더 바람직하다고 기술했습니다. 이 후속 작업은 1991년의 선택이 관리가 단 하나의 전송만 사용할 수 있다는 형이상학적 규칙이 아니었다는 점을 상기시킵니다. 그것은 저자들이 SNMP가 넘어갈 것으로 예상한 네트워크에 대한 실용적인 답이었습니다.
성공한 질의가 증명할 수 없는 것
라우팅된 관리 경로에 대한 논거를 관리 작업이 성공했다는 증거와 혼동해서는 안 됩니다. UDP로 보낸 요청은 확인 응답이 아닙니다. 라우팅된 주소가 의도한 장비가 응답했다는 증거가 되지는 않습니다. 응답이 도착했다고 해서 모든 중간 세그먼트가 건전했다는 증거도 아니며, 무응답은 그 원인이 노드 장애인지, 분할인지, 필터인지, 혼잡인지, 유실된 단편인지, 누락된 경로인지를 식별해 주지 않습니다.
이 구분이야말로 RFC 1270의 설계 논거가 지닌 역사적 가치입니다. 관리 채널은 네트워크의 라우팅 구조를 가로지를 만큼 넓고, 링크 매체의 변화를 견딜 만큼 중립적이어야 했습니다. 그러나 채널 자체는 한계가 있는 증거원으로 남았습니다. 네트워크 도달 가능성, 장비 상태, 요청 전달, 응답 수신, 운영자의 후속 조치는 서로 구별되는 사건들이었습니다. 이 아키텍처는 관리가 이동할 수 있는 범위를 넓혔지만, 그 사건들을 증명으로 하나로 묶지는 않았습니다.
회원 브리핑
프로필 심층 컨텍스트
올바른 멤버십 등급으로 로그인하면 전체 브리핑과 출처 노트를 볼 수 있습니다.
Strategic Circle 전용
Strategic Circle
모든 독자에게 공개됩니다. 가입 후 로그인하면 프로필 브리핑를 열람할 수 있습니다.
Strategic Circle 가입하기Leadership Alliance 전용
Leadership Alliance
자격을 갖춘 IP 자산 소유자 및 운영진을 위한 콘텐츠입니다. 로그인하면 Leadership Alliance 브리핑을 열람할 수 있습니다.
Leadership Alliance 가입하기





