요약

  • RFC 1283은 SNMP를 비연결형과 연결 지향 OSI 전송 서비스 양쪽에 실험적으로 매핑했다. COTS 교환은 연결을 설정하고, 하나 이상의 메시지를 보내고, 연결을 해제하는 방식으로 이루어졌다.
  • 개시자는 그 응답이 같은 연결로 돌아올 것을 기대할 자격이 없었고, 연결에 신뢰성을 부여할 수도 없었다. SNMP의 타임아웃과 재전송은 여전히 애플리케이션의 책임이었다.
  • RFC 1418은 이후 COTS 매핑을 제거하고, UDP가 없는 환경을 위한 비연결형 OSI 형태를 유지했다. 이것은 사양을 바꾼 것이지, 모든 구현이나 배포가 그와 함께 바뀌었다는 증명이 아니었다.

운영 경험을 지닌 실험적 개정판

RFC 1161은 1990년 6월, OSI 전송 위에서 SNMP를 실행하는 실험적인 방법을 제안했다. 비연결형 전송 서비스인 CLTS와 연결 지향 서비스인 COTS 양쪽을 다루었다. 문서는 자신의 지위에 대해 명확했다. 실험과 충분한 합의가 이후의 표준을 뒷받침할 수는 있지만, 이것은 인터넷 표준이 아니었다는 점이었다.

18개월 뒤,RFC 1283이 그 첫 번째 문서를 대체(obsolete)했다. 지위는 여전히 실험적(Experimental)이었다. 편집자는 이 개정판이 최초 공개 이후 축적된 운영 경험을 반영한다고 밝혔다. 그 문장은 겸손하지만 중요하다. 특정 네트워크가 성공했거나 실패했다는 판정이 아니라 학습 과정을 기록한 것이다.

역사적 문제는 실용적인 것이었다. SNMP는 이미 TCP/IP 네트워크에서 상당한 사용 기반을 갖고 있었다. OSI 역량을 도입하는 사이트들은 그 관리 투자를 재활용하고 싶어했다. 그래서 RFC 1283은 SNMP를 OSI 애플리케이션 계층 프로토콜로 다시 만드는 대신, OSI 전송 서비스에 직접 매핑했다.

비연결형 전송은 익숙한 메시지 모델을 유지했다

CLTS 매핑은 UDP 위의 SNMP와 비슷하게 보였다. 두 서비스 모두 완전한 주소 지정 정보를 담은 패킷을 전달했다. 이 설정에서 전송 주소는 네트워크 주소에 전송 선택자(transport selector)를 결합한 것이었다.

OSI는 이 역할에 인터넷의 웰노운 포트를 사용하지 않았다. 디멀티플렉싱은 수신 측 로컬에서만 의미를 갖는 불투명한 선택자 옥텟을 사용했다. RFC 1283은 CLNP 기반 서비스에서 일반 SNMP 트래픽용으로 4개의 ASCII 문자snmp, 트랩용으로snmp-trap을 조정해 두었다.

이 선택자들은 한 좁은 경계에서 상호운용성을 만들었다. 수신자는 어떤 로컬 서비스에 전송 단위를 전달해야 하는지 알 수 있었다. 그러나 선택자는 내구성 있는 장치를 식별하지도, 매니저를 인증하지도, Set 요청을 승인하지도, 변수 바인딩이 참임을 증명하지도 않았다. 그것은 전달 레이블이지 관리 권한이 아니었다.

COTS는 연결을 추가했지만 애플리케이션의 질문을 바꾸지 않았다

COTS 매핑이 더 어려웠던 이유는 SNMP가 본래 상시 연결을 요구하지 않기 때문이었다. RFC 1283은 절차를 제공했다. 전송 연결을 설정하고, 하나 이상의 SNMP 메시지를 보내고, 연결을 해제한다.

이 절차는 관찰 가능한 세 가지 상태를 만든다. 연결은 열리기 전에 실패할 수 있다. 완전한 SNMP 요청을 하나도 실지 않은 채 열릴 수 있다. 바이트를 실어 나르다가, 의도된 애플리케이션이 응답을 만들기도 전에 닫힐 수 있다. 이 셋을 모두 "SNMP 요청 실패"라고 부르면 실패 지점에 대한 정보가 사라진다.

더 위험한 것은 반대 방향의 실수다. 연결 성공은 전송 결합(association)이 자신의 established 상태에 도달했다는 것만 증명한다. 주소 지정된 프로세스가 메시지를 디코딩했는지, 커뮤니티나 접근 규칙을 적용했는지, 지정된 객체를 읽었는지, Set 연산을 커밋했는지, 애플리케이션 결과를 만들었는지는 증명하지 않는다.

응답이 반드시 같은 개구부로 돌아올 필요는 없었다

RFC 1283은 특이한 비대칭을 유지했다. 연결 개시자는 응답이 요청을 실어 나른 연결로 돌아오기를 요구해서는 안 된다. 다만 응답자가 그 연결에서 SNMP 메시지를 보낸다면, 그 메시지들은 반드시 그곳에서 수신한 요청에 대한 응답이어야 했다.

따라서 열린 결합은 보편적인 회신 경로가 아니라 조건부 상관 규칙을 제공했다. 연결에서 관찰된 응답은 그곳에서 수신한 작업과 결합될 수 있었다. 그러나 연결 위의 침묵이 다른 곳에 응답이 존재하지 않음을 증명하지 않았고, 결합 자체도 내구성 있는 연산 식별자를 제공하지 않았다.

연결 수명의 소유자도 나뉘어 있었다. 이상적으로는 개시자가 해제한다. 응답자는 자원 제한 때문에 닫을 수 있었다. 얼마나 오래 열려 있었는지는 구현에 따라 다르며 적절한 동적 알고리즘이 필요했다. 그 결과 폐쇄는 정책, 자원 압박, 유휴 상태 또는 실패를 묘사할 수 있었다. 그것은 저절로 설명되는 SNMP 결과가 아니었다.

전송 신뢰성은 SNMP 완료 직전에서 멈췄다

RFC 1283에서 가장 날카로운 문장은 개시자에게 연결 사용에 신뢰성 특성을 결부하지 말라고 한 것이다. SNMP 메시지의 재전송은 전송 서비스가 아니라 SNMP 애플리케이션에 남아 있었다.

두 달 앞서 공개된RFC 1270은 이 구분을 설명했다. 전송 계층의 확인 응답이 반드시 데이터가 목적지 애플리케이션 프로세스에 도달했다는 뜻은 아니었다. SNMP는 자신의 소프트웨어가 패킷을 수신했는지 판단하기 위해 여전히 타임아웃과 재시도 절차가 필요했다.

이는 전송 신뢰성이 중요하지 않다는 부정이 아니었다. 애플리케이션 아래의 체크섬, 순서 보장, 재전송은 바이트 전달을 개선할 수 있었다. 그러나 "이 바이트들이 전송 계약을 통과했다"는 주장과 "의도된 관리 연산이 완료되었다"는 주장은 서로 달랐다. 후자는 애플리케이션 응답과 상관 규칙을 필요로 했다. 그렇게 해도 반환된 값은 에이전트가 보고한 증거일 뿐, 물리적 네트워크에 대한 자동 증명은 아니었다.

연결 관리는 자기만의 대장을 요구했다

RFC 1270은 연결 지향 SNMP를 관리하는 세 가지 방법을 다루었다. 모든 관리 대상마다 연결 하나를 계속 열어 두는 방식, 연산마다 열고 닫는 방식, 그리고 제한된 풀을 유지하며 LRU 같은 알고리즘으로 교체하는 방식이다. 문서는 세 방식 모두에서 심각한 비용을 발견했다.

영구 연결은 수백, 수천 에이전트에 걸쳐 기록을 소모했고 쓸모없는 keepalive 트래픽 위험을 낳았다. 연산별 연결은 설정, 해제, TIME-WAIT 비용을 반복적으로 지불했다. 제한된 풀은 사용 상태와 교체 논리를 요구했고, 풀이 감당할 수 있는 수보다 많은 에이전트를 폴링하면 연산별 교체로 기울었다.

이것은 단순한 성능 세부 사항이 아니었다. 소유권 질문을 만들었다. 어떤 구성 요소가 유휴 연결이 더 이상 자원을 받을 자격이 없다고 판단하는가? 어떤 관찰이 교체를 정당화하는가? 결합을 닫는 것이 지연된 응답을 상관시키기 위한 유일한 편리한 맥락을 지워버릴 수 있는가? 전송 표면은 한 문제를 해결하고 감사 가능성을 유지해야 하는 새로운 상태 표를 만들었다.

이후의 사양은 비연결형 경로를 유지했다

1993년 3월,RFC 1418이 RFC 1161과 RFC 1283을 모두 대체했다. OSI 비연결형 매핑은 유지하고 COTS 절을 삭제했다. UDP는 여전히 선호되는 SNMP 전송이었고, OSI 매핑은 UDP를 사용할 수 없는 환경을 위한 것이었다. 이기종 네트워크에서 에이전트가 여러 매핑을 지원할 것으로 기대되지도 않았다.

이 개정판은 미묘한 계층화 포인트도 드러냈다. CLTS는 비연결형 네트워크 서비스 위에서도, 연결 지향 네트워크 서비스 위에서도 실현될 수 있었으며, 두 경우에 선택자가 달랐다. 하위 네트워크 서비스가 연결 지향 형태를 갖더라도 애플리케이션에 대한 전송 계약은 비연결형으로 남았다. 아키텍처는 잘못된 계층에 적용된 한 단어로부터 추론될 수 없었다.

obsolete 표시는 문서에 관한 증거다. 어떤 사양이 다른 사양을 대체했는지 말해 준다. 제품이 언제 COTS 지원을 제거했는지, 특정 운영자가 이를 사용했는지, 실제 장애에서 어떤 전송이 더 나은 결과를 냈는지는 보여 주지 않는다.

출처와 한계

이 글은RFC 1161,RFC 1270,RFC 1283,RFC 1418의 공식 문서를 사용했다. 이 문서들은 문서 지위, 매핑 규칙, 명시된 설계 논거, 개정 이력을 확정한다. 네 문서 모두 보안 이슈를 논의하지 않는다고 밝힌다. 그러나 현재 구현, 인증된 주체, 승인된 연산, 관찰된 요청, 응답, 재시도, 장애 또는 관리 결과를 확정하지는 않는다.