요약

  • RFC 3919는 RMON-2 에이전트에 IPv6와 MPLS 디코딩 경로에 대한 공유 이름을 제공했지만, 그 이름들을 그 안에 담기는 모든 서비스의 설명으로 확장하지는 않았다.
  • 가장 뚜렷한 한계는 MPLS 엔트리 자체에 기록되어 있다. 엔트리 계층에서는 유니캐스트와 멀티캐스트를 구분할 수 있지만, 그 하위 항목들은 "체계적으로 식별할 수 없다"고 명시되어 있다.

원격 모니터링은 겉보기에는 사소한 질문에 의존한다. 프로브가 이해한다고 말할 수 있는 패킷의 종류는 무엇인가? RMON-2의 프로토콜 디렉터리는 하나의 목록으로 답했다. 특정 에이전트가 모니터링할 수 있는 프로토콜 유형을 나열함으로써, 관리 소프트웨어가 카운터와 호스트 또는 대화 테이블을 이름이 지정된 캡슐화에 연결할 수 있게 한 것이다. 이 디렉터리는 보편적인 패킷 조사 목록이 아니었고, 관리자가 행을 추가했다고 해서 프로브가 새로운 디코더를 학습하게 만들지도 않았다. RFC 2021은 이를 제한된 확장성이라고 부른다. 구성이 상위 계층을 확장하려면 소프트웨어가 이미 관련 디멀티플렉싱 논리를 알고 있어야 한다.

2004년 10월에 Informational 메모로 발표된 RFC 3919는 IPv6와 멀티프로토콜 레이블 스위칭(Multi-Protocol Label Switching)을 위한 추가 식별자 매크로를 제공했다. 그 목적은 소박하게도 RMON-2 에이전트 간의 상호운용성이었다. 구현체들이 공통 패킷 경로를 서로 다른 방식으로 기술한다면, 관리 도구는 프로토콜별 뷰를 신뢰할 수 있게 비교할 수 없다. 이 메모는 RMON-2 구현이 이 식별자들 없이도 준수할 수 있다고 명시적으로 밝히고 있다. 이들은 유용한 공유 어휘였을 뿐, 새로운 준수 테스트도 아니었고 모든 프로브가 이를 지원한다는 주장도 아니었다. (RFC 3919;RFC Editor 기록)

문서 내부의 대비가 중요하다. IPv6의 경우 하위 프로토콜을 1옥텟 Protocol 필드로 선택할 수 있다. 따라서 식별자는 알려진 디멀티플렉싱 값을 따라갈 수 있다. 문서는 ICMPv6를 프로토콜 58로 명명하고, 네이티브 IPv6를 통해 도달하는 UDP를 IPv6-in-IPv4 터널링 내부의 UDP와는 다른 경로로 보여준다.ether2.ip6.udp와ether2.ip.ipip6.udp는 서로 교환 가능한 레이블이 아니다. 경로는 파서가 전송 프로토콜에 이르게 된 방식을 기술하며, 단순히 마지막 단어 "UDP"만을 뜻하지 않는다.

MPLS의 경우 RFC 3919는 더 짧은 분기를 그린다. 문서는mplsu와mplsm을 명명하여 대응하는 링크 계층 값(EtherType0x8847과0x8848)으로 유니캐스트와 멀티캐스트를 구분하고, 다른 링크 유형에 대한 인코딩도 나열한다. 그러나 두 엔트리 모두 거기서 멈춘다. MPLS의 하위 항목은 체계적으로 식별할 수 없다는 것이다. 이 한 줄은 MPLS가 IP를 절대 실을 수 없다는 주장도, 레이블 뒤의 패킷을 디코딩할 수 없다는 주장도 아니다. 이 식별자 집합이 MPLS 기술자 아래에 일반적으로 사용할 수 있는 하위 트리를 정의하지 않는다는 뜻이다. (RFC 3032)

이 한계는 디렉터리 레이블이 과장된 약속을 하지 않도록 막아준다. 프로브는 외부 프레이밍이나 특정 MPLS 엔트리를 알 수 있으면서도, 레이블 스택 뒤에 있는 모든 페이로드나 서비스에 대한 안정적이고 공유된 이름을 노출하지 않을 수 있다. 라우트 레이블은 그 자체로 프로토콜 패밀리 선언이 아니며, 그 해석은 다른 메커니즘과 문맥에 속한다. RFC 3919는 레이블로부터 그 문맥을 추론하려 하지도, 두 에이전트가 동일한 로컬 행 번호를 부여한다고 약속하지도 않는다.

프로토콜 이름과 인덱스의 구분도 똑같이 중요하다. RFC 2895는 인코딩된protocolDirID와 매개변수 문자열을 정의하는 반면, 카운팅 테이블은protocolDirLocalIndex를 사용한다. RFC 2021에 따르면 이 정수는 하나의 SNMP 엔티티 내에서만 의미를 가진다. 이는 그 에이전트의 디렉터리로 향하는 로컬 핸들일 뿐이며, 다른 프로브의 데이터에 복사해 넣고 같은 의미라고 가정할 수 있는 식별자가 아니다. 상호운용성은 공유된 기술자 규칙과 신중한 해석에서 나온다, 모든 구현이 동일한 로컬 번호를 갖는다는 가정에서 나오지 않는다.

따라서 RFC 3919는 작지만 시사적인 경계 문서다. IPv6가 표준화된 다음 헤더 값을 노출하는 곳에서는 식별자 어휘가 더 깊은 파서 경로를 기술할 수 있다. MPLS의 하위 항목이 이 프레임워크 안에서 비슷한 체계적 매핑을 갖지 못하는 곳에서는 어휘가 외부 엔트리에서 멈춘다. 기능 목록은 관리자가 더 나은 질문을 던지도록 도울 수 있다. 그러나 프로브가 실제로 패킷을 보았고, 올바르게 디코딩했으며, 주어진 구간 동안 카운트했고, 레이블이 우연히 실은 비즈니스 서비스를 인식했다는 주장까지는 성립시킬 수 없다. 그런 주장에는 관찰 기록과 추가 근거가 필요하지, 테이블 속 더 긴 이름은 필요하지 않다.

출처