요약

  • RFC 1095는 CMOT와 SNMP에 동일한 'Draft Standard' 및 'Recommended' 지위를 부여했습니다. IAB는 두 프로토콜 모두가 구현되고 검증되기를 원했으며, 그 이전 정책이 SNMP를 단기 도구로, CMIS/CMIP를 장기 체계로 다루었음에도 그렇습니다.
  • 두 프로토콜은 하나의 인터넷 MIB에 정렬되었지만, 공유된 객체 이름이 공유된 관리 애플리케이션을 제공하지는 않았습니다. CMOT 상호운용성은 CMIS, CMIP, ACSE, ROSE, ASN.1 및 TCP 또는 UDP 위의 경량 프레젠테이션에 대한 특정 프로파일을 필요로 했습니다.
  • 프로파일은 하나의 관리 도메인을 다루었고, 애플리케이션은 범위 밖으로 두었으며 접근 제어 파라미터를 선택 사항으로 만들었습니다. 따라서 수락된 연결이나 반환된 작업은 프로토콜 진행 상황을 보여주었지만, 기관의 위임이나 독립적으로 검증된 장치 효과를 보여주지는 않았습니다.

표준 문서 페이지에는 승자가 둘 들어갈 자리가 있었습니다

유명한 결말은 지나치게 정리되어 있습니다. SNMP는 인터넷 운영의 익숙한 도구가 되었고, CMOT는 그렇지 못한 무거운 대안으로 보통 소개됩니다. 하지만RFC 1095는 그 결말이 기억으로 굳어지기 전의 순간에서 시작합니다. 이 문서는 Internet Activities Board가 두 개의 서로 다른 네트워크 관리 프로토콜에 정확히 동일한 지위, 즉 Draft Standard와 Recommended를 지정했다고 말합니다.

하나는 SNMP였습니다. 다른 하나는 TCP/IP 위의 Common Management Information Services and Protocol, 줄여서 CMOT였습니다. 네트워크 관리 가능한 구현체는 최소한 하나를 채택할 것으로 기대되었습니다. IAB는 두 프로토콜 모두의 개발자와 사용자로부터 보고를 원했습니다.

동일한 표지가 동일한 역사를 의미하지는 않았습니다. 1년 전RFC 1052는 소프트웨어가 이미 존재하고 운영 중이었기 때문에 SNMP를 단기 기반으로 권고했습니다. CMIS/CMIP에는 장기 과제가 할당되었습니다. ISO 기반 관리 체계를 개발, 배포, 검증한 다음, 실제 인터넷 경험으로 표준 논의를 개선하라는 것이었습니다.

이것은 경주라기보다는 정책적 헤지였습니다. 인터넷은 급속한 성장을 위한 도구를 절싞히 필요로 했지만, 동시에 더 넓은 국제 관리 아키텍처로 들어가는 경로도 원했습니다. 'Recommended'는 실험에 대한 허가와 우선순위를 기록했습니다. 그것이 비슷한 수준의 코드, 배포 또는 운영자 신뢰를 인증한 것은 아니었습니다.

이 구분은 거의 즉시 드러났습니다. 1989년 6월 검토를 보고한RFC 1109는 네트워크와 제품 속의 SNMP 구현을 기술했습니다. CMOT에 대해서는 당시 회의에서 공개적으로 이용 가능한 구현이 없다고 보고했지만, 벤더들과 University of Wisconsin이 작업을 계획하고 있었다고 밝혔습니다. RFC 1095의 Interop '88 프로토타입은 실현 가능성과 멀티벤더 가능성을 입증했을 뿐, 실제 운영 사용에 대한 조사는 아니었습니다.

하나의 MIB는 다리였지 목적지가 아니었습니다

가장 중요한 공통 결정은 두 와이어 프로토콜 위에 놓여 있었습니다. RFC 1052는 인터넷 Management Information Base를 정의하는 별도의 노력을 만들어 SNMP 그룹과 Netman 그룹 모두에 공급하도록 지시했습니다. RFC 1109는 나중에 두 그룹이 필수로 수용한 공개 서브트리 변수를 대략 100개 정도로 셌습니다.

이는 IP 입력 카운터, 라우팅 테이블 항목 또는 다른 관리 대상 객체가 운영자가 질의에 사용하는 프로토콜을 바꾼다는 이유만으로 서로 무관한 의미를 갖지 않아도 된다는 뜻이었습니다. 공통 MIB는 의미론적 다리였습니다. RFC 1052는 심지어 이것이 단기 SNMP에서 장기 CMIP로의 원활한 전환을 지원할 수 있다고 상상했습니다.

그러나 공통 명사가 공통 대화를 만들지는 않습니다. 두 시스템은 관리 대상 객체의 존재에는 동의하면서도 인스턴스 선택 방법, 작업 범위 지정, 이벤트 보고, 세션 수립, 오류 인코딩, 요청 보호 방식에 대해서는 불일치할 수 있습니다. 같은 변수가 전혀 다른 운영자 도구로 전송될 수도 있습니다.

RFC 1109는 이 구분을 인식했습니다. 관리의 효과는 지원 프로토콜뿐 아니라 운영자가 사용할 수 있는 도구에 의해 결정된다는 것입니다. 당시 어느 서비스 인터페이스도 과거 정보를 요청하거나 30분 뒤 작업을 예약할 수 없었습니다. MIB는 관찰 가능한 것들의 이름을 지었을 뿐, 그것을 유용하게 만드는 애플리케이션을 만들지는 않았습니다.

그래서 RFC 1095가 그토록 긴 것입니다. 공통 MIB는 프로파일의 필요를 없애지 못했습니다. 대신 프로파일의 임무를 더 정확하게 만들었습니다. 독립적으로 구현된 시스템들이 와이어에서 만날 수 있도록, 이 인터넷 관리 의미론을 선정된 CMIS/CMIP 옵션 집합 하나를 통해 전달하라는 것입니다.

상호운용성은 틈새에 살았습니다

CMOT는 TCP 위에 얹힌 단일 헤더가 아니었습니다. 구현자는 추상 데이터를 위한 ASN.1, 애플리케이션 연결을 열고 닫는 Association Control Service Element, 작업을 전달하는 Remote Operations Service Element, 관리 서비스와 프로토콜을 위한 CMIS와 CMIP, 인터넷 SMI와 MIB, 그리고RFC 1085에 정의된 경량 프레젠테이션 서비스가 필요했습니다.

따라서 RFC 1095는 아키텍처와 구현자 합의 사이를 오갑니다. 어떤 기능 단위가 연결에 속하는지, 객체 클래스와 인스턴스가 CMIP에 어떻게 매핑되는지, 어떤 프로토콜 데이터 단위가 발생할 수 있는지, 범위와 필터가 어떻게 처리되는지, 그리고 ACSE, ROSE, CMIP가 경량 프레젠테이션 계층을 통해 어떻게 직렬화되는지를 설명합니다.

경량 계층의 요점은 실용적이었습니다. CMOT는 완전한 ISO 프레젠테이션, 세션, 전송 스택을 구현하지 않고도 ISO 애플리케이션 프로토콜을 사용할 수 있었습니다. RFC 1085는 프레젠테이션 서비스 인터페이스를 보존하면서 이를 익숙한 인터넷 전송 계층에 매핑했습니다.

그러나 이런 축소가 선택적 표준을 슬로건으로 바꾸지는 않았습니다. 상호운용성은 어떤 대안이 허용되고 어떻게 표현되는지에 대한 결정에 달려 있습니다. 벤더가 '우리는 CMIP를 구현한다'고 말하는 것은, 실제 지원되는 애플리케이션 컨텍스트, 기능 단위, 인코딩 합의, 전송 매핑, MIB 버전에 대한 기록보다 정보가 적습니다.

따라서 프로파일은 경계 문서였습니다. 넓은 옵션 공간을, 두 기계가 의미 있는 관리 작업을 교환할 수 있는 더 작은 집합으로 축소했습니다. 그것은 기계, 애플리케이션 또는 조직을 인증하지 않았습니다.

TCP와 UDP는 같은 여정을 약속하지 않았습니다

RFC 1085는 두 가지 전송 매핑을 제공했습니다. TCP는 문서가 말하는 고품질 서비스를, UDP는 저품질 서비스를 공급했습니다. '저품질은 정말 저품질을 의미한다'는 기억에 남는 경고는 장식이 아니었습니다. UDP는 둘 다 프레젠테이션 데이터를 운반한다는 이유만으로 TCP의 연결, 순서, 복구 속성을 조용히 물려받지 않았습니다.

RFC 1095는 이 선택을 활용했습니다. 경량 프레젠테이션 프로토콜은 TCP 또는 UDP 위에서 동작할 수 있었으며, 매니저는 포트 163, 에이전트는 포트 164를 사용했습니다. UDP의 경우 문서의 가정 하에서 단편화되지 않은 IP 데이터그램에 들어가도록 CMOT 프로토콜 데이터 단위는 484 옥텟으로 제한되었습니다. 발견은 디렉터리, 로컬 구성 또는 연결 시도에서 나올 수 있었습니다.

따라서 'CMOT 엔드포인트'는 하나의 보편적 좌표가 아니었습니다. 운영자는 전송 매핑, 주소, 역할, 프로파일, 발견 기반을 알아야 했습니다. 성공한 TCP 연결과 수신된 UDP 데이터그램은 경로에 대해 서로 다른 증거를 제공했습니다. 어느 쪽도 매니저 뒤에 있는 사람의 권한 위임에 대한 증거는 제공하지 않았습니다.

같은 구분이 실패에도 적용됩니다. 타임아웃은 전송 손실, 프레젠테이션 불일치, 연결 거부, 지원되지 않는 CMIS 기능, 접근 정책 또는 관리 대상 객체 자체를 반영할 수 있습니다. 모든 계층을 'CMOT 실패'로 뭉개면 프로파일이 애써 정의한 바로 그 경계들이 사라집니다.

아키텍처는 하나의 도메인 주위에 원을 그렸습니다

RFC 1095는 매니저와 에이전트, 관리 대상 객체, OSI 관리의 익숙한 다섯 가지 기능 영역을 기술합니다. 그런 다음 그 작업을 수행할 관리 애플리케이션의 표준화를 거부합니다. 그 목표는 상호운용 가능한 멀티벤더 관리에 필요한 최소한의 아키텍처였으며, 애플리케이션은 경쟁의 영역으로 남았습니다.

또한 관리 도메인 간의 관계와 상호작용도 제외합니다. 아키텍처는 단일 관리 도메인에 국한됩니다. 이 선은 처음 보이는 것보다 더 중요합니다.

관리 도메인은 단순히 서브넷이 아닙니다. 그것은 행정적 합의입니다. 어떤 시스템이 매니저로 행동하는지, 어떤 요소가 그 작업을 수용하는지, 어떤 정책이 그들을 묶는지, 책임이 어디에 놓이는지입니다. 패킷은 IP 경계를 쉽게 넘을 수 있지만, 기관이 권한을 위임하기는 더 어렵습니다. CMOT는 프로토콜 경로를 명시했을 뿐, 두 행정 기관 사이의 계약을 발명하지 않았습니다.

따라서 표준은 매니저가 에이전트에게 작업을 요청하는 방법을 기술할 수 있었지만, 다른 조직의 매니저가 그 요청을 할 자격이 있는지는 답하지 않았습니다. 객체를 노출할 수는 있었지만, 그 변경의 결과를 누가 소유하는지는 해결하지 않았습니다. 도메인 간 연합에는 프로토콜 프로파일 위의 합의가 필요했습니다.

이는 관리를 대칭적이고 보편적으로 보이게 만드는 다이어그램에 대한 유용한 해독제입니다. 프로토콜 역할은 어느 쪽에서든 구현될 수 있고 작업은 일관되게 표현될 수 있습니다. 그러나 기관적 권력은 비대칭적이고, 범위가 한정되며, 회수 가능합니다.

연결 수립은 권한 부여가 아니었습니다

CMOT는 ACSE를 사용해 애플리케이션 연결을 수립했습니다. 당사자들은 관리 작업이 흐르기 전에 애플리케이션 컨텍스트와 기능 단위를 협상했습니다. 그 협상은 실제 증거였습니다. 두 프로토콜 구현이 호환되는 컨텍스트를 찾았다는 것을 보여주었습니다.

그러나 그것은 고용 기록도, 위임 문서도, 소유권 증서도 아니었습니다. RFC 1095는 연결 수준과 요청 수준의 접근 제어 파라미터를 선택 사항으로 만들었습니다. 연결 수립 시 접근 제어를 처리할 것을 권고하고 미래의 인터넷 인증 작업을 예상했지만, 수신자는 요청 필드를 무시할 수 있었습니다. 임시적인 단순 방법은 암호화되지 않은 암호 정도일 수 있었습니다.

이 조항들은 1989년의 한계를 그대로 두고 읽어야 합니다. 저자들이 접근과 인증을 서로 다른 문제로 이해했음을 보여줍니다. 그러나 모든 준수 연결이 상대를 강하게 인증했거나, 암호 필드가 완전한 인가 정책을 표현했다는 것을 입증하지는 않습니다.

RFC 1109는 몇 달 뒤 이 간격을 명시했습니다. 사용자 접근 제어와 관리 명령 및 응답의 인증을, CMOT나 SNMP 어느 쪽도 해결하지 않은 중요한 사항 목록에 넣었습니다. 표준 프로파일은 접근 정보를 위한 자리를 제공할 수 있지만, 완전하게 배포된 신뢰 체계를 제공하지는 않았습니다.

따라서 증거의 사다리는 순서를 유지해야 합니다. 네트워크 도달 가능성은 시도를 허용합니다. 프레젠테이션과 연결 합의는 프로토콜 대화를 허용합니다. 인증은 어떤 방식으로든 메시지를 보안 주체에 귀속시킵니다. 인가는 정책 안에서 작업을 허용합니다. 어느 단계도 바로 아래 단계만으로 추론될 수 없습니다.

반환된 결과는 기계의 결과 앞에서 멈췄습니다

CMIS는 단순 변수 조회보다 풍부한 서비스 구조로 정보 요청, 속성 변경, 이벤트 보고를 할 수 있었습니다. 그러나 RFC 1095는 모든 작업이 물리적 세계에 대한 트랜잭션이라고 약속하지 않았습니다. 최선 노력 동기화는 필수였고, 원자적 동기화는 선택 사항이었습니다.

매니저가 수락된 연결과 set 작업에 대한 성공 응답을 받았다고 가정해 봅시다. 무엇이 입증됩니까? 많아야, 프로파일된 스택이 요청을 전달하고 처리했으며, 에이전트가 그 작업에 정의된 결과를 보고했다는 것입니다. 그 응답은 카드가 모드를 변경했는지, 트래픽이 이동했는지, 재시작이 설정을 보존했는지, 사용자가 의도된 서비스를 보았는지를 독립적으로 보여주지 않습니다.

그것들은 이후의 관찰입니다. 별도 객체를 통한 읽기 검증, 이벤트 보고, 트래픽 카운터, 구성 지속성 증거 또는 관리 대상 요소 밖의 측정이 필요할 수 있습니다. 같은 장치가 명령 상태와 확인을 모두 제공할 때, 운영자는 그 공유 출처를 기록해야 하며 그 증거를 독립적이라고 불러서는 안 됩니다.

이 차이는 프로토콜에 대한 불신이 아닙니다. 올바른 귀속입니다. CMOT는 메시지와 의미론을 표준화합니다. 계측은 그 의미론을 장치 동작으로 번역합니다. 하드웨어와 네트워크 조건이 효과를 만들어 냅니다. 각 계층은 다음 계층이 실패하는 동안 성공할 수 있습니다.

RFC 1189는 프로파일을 개정했지 경계를 개정하지 않았습니다

1990년 10월,RFC 1189는 RFC 1095를 대체했습니다. CMIS와 CMIP는 초안에서 최종 국제 표준으로 이동했습니다. 개정판은 튜토리얼 자료를 제거하고, 인터넷 MIB 의미론을 별도 문서로 옮기고, 갱신된 구현자 합의를 재사용하고, 이전 애플리케이션 컨텍스트 이름의 인식을 보존하면서 연결 협상을 변경했습니다.

이 역사는 프로파일이 존재하는 이유를 확인해 줍니다. 기본 표준이 바뀌면, 인터넷 합의는 어떤 버전, 옵션, 컨텍스트가 여전히 상호운용되는지를 말해야 합니다. 프로토콜 이름만으로는 그 상태를 운반할 수 없습니다.

또한 더 좁은 교훈을 보존합니다. 1989년, 인터넷은 두 개의 관리 프로토콜을 권고하고 하나의 MIB를 공유하면서도 그들이 하나의 체계라고 가장하지 않을 수 있었습니다. 프로파일은 구문과 전송을 상호운용을 시도할 만큼 긴밀하게 결합했습니다. 관리 도메인, 인가 정책, 운영자 애플리케이션, 관찰된 장치 결과는 그 결합의 바깥에, 혹은 너머에 남았습니다.

인터넷의 이후 선호가 그 아키텍처를 지우지는 않습니다. RFC 1095는 정확히 승자의 역사가 압축해 버리는 계층들을 기록하기 때문에 가치가 있습니다. 같은 것의 이름을 짓는 것, 같은 것을 운반하는 것, 그것을 변경할 수 있도록 허용받는 것, 그리고 그 변경을 증명하는 것은 서로 다른 네 가지 성취입니다.

출처