요약

  • RFC 3020은 멀티링크 프레임 릴레이(Multilink Frame Relay) 번들에 대해 네 가지 활성 정책을 정의했습니다. 링크 하나, 전체 링크, 지정된 수 기준 임계값, 또는 구현별 규칙 중 하나가 논리 인터페이스를 운영상 up으로 만들 수 있었습니다.
  • 따라서 번들-up은 선택된 조건식이 통과했다는 사실만 기록했습니다. 활성 링크 수, 대역폭, 지연, 불일치, 순서 및 재정렬 근거, 그리고 궁극적으로 수신 측 관찰은 더 강한 주장을 위해 여전히 별도로 필요했습니다.

첫 회선이 돌아오자 알람이 해제되었습니다.

하나의 논리 프레임 릴레이 인터페이스 아래에 세 개의 물리 링크가 설정되어 있었습니다. 두 개는 여전히 사용 불가능했습니다. 그런데도 번들은 down에서 up으로 바뀌었고, 대시보드가 초록으로 칠할 만한 평범한 상태 전이를 내보냈습니다. 이 일련의 흐름에는 모순이 전혀 필요하지 않았습니다. RFC 3020의 기본 활성 클래스에서는 운영 가능한 링크 하나면 충분했습니다.

여기서 중요한 역사적 교훈은 상태가 부정확했다는 것이 아닙니다. "up"이 엔지니어링 희망보다 정책 질문에 먼저 답했다는 점입니다. 번들은 설정된 활성 경계를 넘었을 뿐입니다. 그것이 모든 용량을 회복했는지, 모든 구성요소를 복구했는지, 재정렬 손실을 피했는지, 원격 애플리케이션에 유용한 프레임을 전달했는지는 말해주지 않았습니다.

2000년 12월에 발표된 RFC 3020은 프레임 릴레이 포럼(Frame Relay Forum)의 FRF.16 협정이 기술한 UNI/NNI 멀티링크 프레임 릴레이 기능에 대한 관리 대상(managed 주체)을 정의했습니다. 그 MIB는 여러 물리 링크로 구성된 논리 인터페이스를 중심으로 구성과 관찰을 하나로 묶었습니다. 그 과정에서 이후의 집계 시대를 위한 정확한 경고를 남겼습니다. 즉, 집계 상태에는 작성자와 규칙, 그리고 분모가 있다는 것입니다.

하나의 인터페이스는 설계상 여러 링크를 감췄다

멀티링크 프레임 릴레이는 프레임 단위의 역다중화를 수행했습니다. 번들 링크(bundle links)라 불리는 하나 이상의 물리 링크가 하나의 번들로 집계되었습니다. Q.922 데이터 링크 계층에는 그 번들이 단일 물리 인터페이스처럼 동작하며 프레임 순서를 보존해야 했습니다.

관리 모델은 두 관점을 모두 보여줘야 했습니다. 모든 번들 링크는 일반 인터페이스 MIB에 나타났고, 번들 자체도 그 MIB에 독립적인 논리 인터페이스로 나타났습니다. 미디어별 번들 테이블, 번들 링크 테이블, 매핑 테이블이 이 조각들을 연결했습니다.

식별자조차 서로 다른 권한에 속했습니다. 관리자는 번들 행을 만들 때mfrBundleIndex를 선택했습니다. 에이전트는 대응하는 일반ifIndex를 선택했습니다. 따라서 RFC 3020은 양방향 매핑을 제공했습니다. 인터페이스 12와 번들 7을 보는 것은 중복을 증명하지 않으며, 두 개의 색인 체계를 통해 같은 논리 대상을 기술하는 것일 수 있었습니다.

생성은 또 다른 경계를 넘었습니다.mfrBundleRowStatus를createAndGo로 설정하면 번들이 생성되고 에이전트가 일반 인터페이스 항목을 만들도록 했습니다. 에이전트는 선택적으로createAndWait를 지원할 수 있었습니다. 번들 링크는 자신의 물리 인터페이스ifIndex를 사용하고,mfrBundleLinkConfigBundleIndex를 통해 기존 번들을 지명하며, 유효한 연계 없이는 활성 상태가 될 수 없었습니다.

행 생성 확인은 구성의 존재를 확립했습니다. 그것은 구성요소 협상, 집계 활성, 전달된 프레임을 확립하지 않았습니다. 그런 상태들은 나중에 도래하며 서로 다른 증거를 가졌습니다.

"up"은 네 가지 의미 중에서 선택되었다

mfrBundleActivationClass는 번들이 활성화되는 조건을 통제했습니다.

클래스 A는 최소 한 링크가 운영상 up이어야 했습니다. 클래스 B는 전체 링크를 요구했습니다. 클래스 C는mfrBundleThreshold에 저장된 지정 개수를 요구했습니다. 클래스 D는 사용자 정의이며 구현별이었습니다. 정의된 규칙 중 가장 관대한 클래스 A가 기본값이었습니다.

클래스 C에서 임계값 항목은 최소 활성 링크 수를 지칭했습니다. 개수가 그 값에 도달하면 논리 번들은 운영상 up이 되었습니다. 개수가 그 아래로 떨어지면 번들은 비활성이 되었습니다. 임계값이 적용되지 않는 클래스에서는 이 항목이-1을 보고했습니다.

RFC 3020은 번들 linkUp/linkDown 통지를 같은 판정에 묶었습니다. 활성 클래스와 임계값 기준으로 충분한 수의 구성 링크가 up이면 논리ifOperStatus전이에 따라 번들 linkUp 트랩이 이어졌습니다. 개수가 불충분해지면 그 역전이에 linkDown 트랩이 이어졌습니다.

통지는 규칙을 감추지 않았습니다. MIB가 그것을 노출했습니다. 모니터링 시스템은 이벤트에 의미를 부여하는 활성 클래스, 임계값, 설정된 링크 수, 활성 링크 수를 저장하지 않고 초록 이벤트만 저장할 때만 규칙을 감추는 것입니다.

네 개 링크가 설정되어 있다고 가정해 보십시오. 클래스 A에서는 활성 링크 하나로 번들이 up이 될 수 있었습니다. 클래스 B에서는 활성 링크 셋으로도 down에 머물 수 있었습니다. 임계값 2인 클래스 C에서는 두 번째 링크가 집계 상태를 바꾸었고, 세 번째와 네 번째 링크는 이진 상태를 바꾸지 않으면서 용량만 바꾸었습니다. 클래스 D는 관찰자가 조건식을 재구성하려면 구현 근거 자체가 필요했습니다.

따라서 같은 표시 단어가 실질적으로 다른 운영 조건을 나타낼 수 있었습니다. 정책은 상태에 붙는 주석이 아니었습니다. 정책이 상태를 만들어냈습니다.

용량에는 자기만의 영수증이 있었다

RFC 3020은 설정된 링크 수와 활성 링크 수를 별개의 항목으로 두었습니다. 또한 번들의 가용 대역폭도 보고했습니다.

이 구분은 흔한 오류 추론을 막았습니다. 번들-up 이벤트가mfrBundleLinksActive가mfrBundleLinksConfigured와 같음을 함의하지 않았습니다. 보고된 대역폭이 설계 용량과 같다는 함의도 없었습니다. 4중 1 클래스 A 번들은 합법적으로 up이면서 동시에 심하게 저하된 상태일 수 있었습니다.

가용 대역폭 자체가 응용 처리량 측정이 아니라 관리 값이었습니다. 이름이 붙은 트래픽 샘플, 공급 부하, 혼잡 이력, 상위 계층 재전송, 수신 결과를 포함하지 않았습니다. 집계의 현재 자원 상태를 기술하는 데 도움을 줄 뿐, 특정 흐름이 그 속도를 달성했다는 인증을 할 수 없었습니다.

MIB는 번들 링크 최대 수, 단편화 구성, 최대 단편 크기, 순서번호 크기, 최대 차등 지연도 노출했습니다. 집계는 단일 물리 링크가 하지 않는 작업을 도입했기 때문입니다. 프레임이나 단편이 서로 다른 지연을 지닌 링크들을 통과할 수 있고, 이후 순서를 복원해야 합니다.

대역폭이 줄어든 초록 집계는 사용 가능할 수 있습니다. 그러나 활성 정책이 인코딩하지 않은 서비스 요구사항을 위반할 수도 있습니다. 정책과 서비스 목표는 별개의 계약이었습니다.

조건식이 참인 동안 순서는 실패할 수 있었다

mfrBundleResequencingErrors는 수신기가 순서 위치가 손실되었다고 판단한 이벤트를 집계했습니다. RFC 3020은 정확한 경고를 남겼습니다. 하나의 이벤트가 여러 손실 프레임에 대응할 수 있습니다. 순서번호 56, 59, 60이 도착하고 57과 58이 손실로 판정되면, 카운터는 두 개가 아니라 하나만큼 올랐습니다.

이 때문에 카운터는 겉보기보다 정보가 많으면서 변환하기 어려웠습니다. 변화는 최소 한 건의 재정렬 오류 이벤트가 기록되었음을 증명하지만, 누락된 프레임 수를 직접 주지 않습니다. 평탄한 카운터도 전달을 증명하지 않습니다. 카운터 불연속성, 순환, 수집 간격, 관찰되지 않은 실패 모드가 여전히 문제였습니다.

링크별 항목들은 인과 기록의 다른 조각들을 제공했습니다. 현재 왕복 지연, 무효 제어 프레임, 만료된 타이머, 의심되는 루프백, 예상치 못한 순서, 번들 이름 불일치가 그것입니다. 링크 상태 자체도 단일 전기적 불리언이 아니라 FRF.16 상태 머신을 따랐습니다.

불일치 통지는 특히 시사적이었습니다. 이 트랩은 근단과 원단의 설정된 번들 이름과 보고된 번들 이름을 함께 실었고, RFC 3020은 설정값 자체가 자동 구성되었을 수 있음을 밝혔습니다. 트랩은 관리 관점과 프로토콜 관점이 더 이상 일치하지 않음을 뜻했습니다. 그것만으로는 로컬 구성, 원격 광고, 자동화, 낡은 상태 중 무엇이 원인 오류였는지 식별하지 않았습니다.

구성요소 근거는 활성 조건식이 여전히 충족된 상태에서도 집계가 손상된 이유를 설명할 수 있었습니다. 그러나 그것 역시 수신 측 서비스 영수증에는 미치지 못했습니다.

쓰기 가능한 정책은 다음 알람의 의미를 바꿨다

활성 클래스, 임계값, 타이머, 단편화, 순서 선택은read-create로 선언되었습니다. 관리자는 번들 및 링크 행을 생성·변경·삭제하고, 링크가 어느 번들에 속할지 선택할 수도 있었습니다.

이것이 모든 적합 제품이 모든 쓰기를 노출해야 함을 의미하지는 않았습니다. RFC 3020의 준수 선언은 여러 항목에 대해 최소 접근을 읽기 전용으로 낮췄습니다. 쓰기 지원은 선택 사항이었지만 실제 사용 중인 값은 여전히 보고되어야 했습니다. 스키마의 최대 접근, 구현된 능력, 호출자 권한은 서로 다른 세 가지 사실이었습니다.

쓰기가 가능한 곳에서 임계값 변경은 물리 회선을 바꾸지 않고도 다음 집계 전이를 바꿀 수 있었습니다. 클래스 C 임계값을 3링크에서 2링크로 낮추면 2링크 상태가 불충분에서 충분으로 바뀔 수 있었습니다. 클래스 B에서 클래스 A로 전환해도 같은 결과가 나왔습니다. 새 초록 상태는 새 정책을 정확히 반영했을 것입니다.

이것이 변경 이력 추적이 가용성 이력 옆에 있어야 하는 이유입니다. 그렇지 않으면 운영자는 정책 완화를 인프라 회복으로 오인할 수 있습니다.

RFC 3020의 보안 장은 무단 SET 작업을 네트워크 운영 리스크로 다뤘습니다. SNMPv1만으로는, 다른 방식으로 보호된 네트워크에서조차 어떤 주체가 항목을 읽고 변경·생성·삭제할 수 있는지 결정하지 못했습니다. 문서는 SNMPv3의 사용자 기반 보안 모델(User-based Security Model)과 뷰 기반 접근 제어 모델(View-based Access Control Model)을 권고하고, 올바른 권한 부여를 운영자에게 맡겼습니다.

인증은 SET를 누가 보냈는지에 답했습니다. 권한 부여는 그 주체가 이 항목을 변경할 수 있는지에 답했습니다. 어느 쪽도, 변경된 링크 정책이 서비스의 비즈니스 요구사항을 충족하는지에는 답하지 않았습니다.

표준은 배포된 성공 사례를 주장하지 않았습니다

RFC 3020은 Proposed Standard로 표준화 트랙에서 발표되었습니다. RFC 9141은 이후 폐지된 IETF FTP 서비스에 대한 참조를 교체하는 방식으로만 이를 갱신했습니다. 그 행정적 갱신은 활성 클래스, 임계값, 번들-up의 증거적 의미를 바꾸지 않았습니다.

출처 기록은 MIB 설계를 확립합니다. 그것은 특정 벤더가 모든 항목을 구현했다는 사실, 통신사가 MFR을 배포했다는 사실, 어떤 번들이 목표 가용성을 달성했다는 사실, 고객이 손실 없이 프레임을 받았다는 사실을 확립하지 않습니다. 별도의 근거 없이 이런 배포 주장이 이 역사에 들어와서는 안 됩니다.

Lu Heng의 Reality Layers는 이 경계를 보여줍니다. 설정된 행, 활성 조건식, 구성요소 프로토콜 상태, 집계 인터페이스 상태, 프레임 무결성 카운터, 수신 결과는 서로 다른 계층을 점유합니다. Running-Code Primacy는 활성 규칙이 명시적으로 구현별이었던 클래스 D에서 가장 중요합니다. Minimum Initial Specification은 MIB가 종단 간 서비스 모니터가 되도록 요구하지 않고도 그 한정된 MIB의 가치를 설명합니다.

이것들은 공개된 분석 렌즈입니다. Lu Heng은 RFC 3020을 저작하거나 보증하지 않았습니다.

번들의 초록불은 거짓이 아니었습니다. 그것은 보조절이 빠진 한 문장이었습니다. 즉, "이 규칙에 따라, 이 링크 집합 위에서, 이 순간에 up"이라는 문장이었습니다. 그 보조절이 버려질 때 운영 근거는 위험해집니다.

출처