요약

  • RFC 3423은 전송 확인과 애플리케이션 확인에 서로 다른 역할을 부여했다. 전송 확인은 패킷 손실이나 무응답 수신자를 탐지하고, CRANE DATA ACK는 기록이 올바르게 처리되어 영구 저장소에 배치된 후에만 진전됐다.
  • 그러나 영속 경계선이 최종 청구서는 아니었다. DSN 연속성, 대체 서버 페일오버, 중복 제거, 템플릿 버전, 보안, 하류 과금에는 각각 자신의 영수증이 필요했다.

두 개의 녹색 불, 두 가지 사실

네트워크 요소가 사용량 기록을 내보낸다. 신뢰할 수 있는 전송이 바이트를 전달하고 확인 응답을 받아 건강해 보인다. 몇 밀리초 뒤 수신 프로세스가 기록을 커밋하기 전에 실패한다. 어느 시스템이 옳은가?

둘 다 옳을 수 있다. 전송 계층은 자신의 명제를 증명했다: 상대 스택이 전송 상태를 진전시킬 만큼 충분한 데이터를 받았다. 과금 시스템은 아직 서로 다른 명제를 증명하지 못했다: 기록이 해석되고 처리되어 영구 저장되었다. 2002년 11월에 발표된RFC 3423은 XACCT의 Common Reliable Accounting for Network Element 프로토콜을 바로 이 간격을 중심으로 설계했다.

이 문서는 명시적으로 인터넷 표준이 아니라Informational이었다.일반 텍스트 기록,IETF 문서 페이지,이력,참고문헌,정오표 검색은 네트워크 요소에서 미들웨어, 비즈니스 지원 및 운영 지원 시스템으로 대량 과금 데이터를 이동하는 벤더 기반 제안을 보존하고 있다. 이것들은 현재의 배포를 입증하지 않는다.

전송 신뢰성은 원장 앞에서 멈췄다

CRANE은 신뢰할 수 있고 연결 지향적이며 순서를 지키는 전송을 가정했다. TCP나 SCTP가 이를 운반할 수 있었고, 문서는 메시지 지향성, 인증 능력, 더 빠른 실패 탐지 때문에RFC 2960의 당시 SCTP를 선호했다. 과금 전송으로 UDP를 사용하는 것은 금지되었지만, 선택적 버전 발견 교환은 훨씬 좁은 목적으로 UDP를 사용했다.

이어서 아키텍처는 핵심 구별을 밝혔다. 전송 확인은 손실된 패킷과 무응답 서버 탐지에 도움을 주었다. CRANE은 메시지가 처리되고 과금 정보가 영구 저장소에 배치된 후에야 메시지를 확인했다.

이 두 번째 확인은 장식적 중복이 아니었다. 증거 경계를 “바이트가 상대에 도달했다”에서 “수신 애플리케이션이 자신의 영속 경계선이 진전되었다고 주장한다”로 옮겼다.RFC 2975는 비휘발성 저장소와 중복 제거를 포함한 더 넓은 과금 관리 문제를 서술한 바 있다. CRANE은 하나의 범용 성공 램프 뒤에 이 우려들을 숨기는 대신 대량 전송 프로토콜 안에서 노출하려 했다.

DATA ACK는 경계선에 이름을 붙였다

모든 DATA 메시지는 데이터 시퀀스 번호(DSN)를 실었다. 시작 직후나 다른 서버로의 전환 후, 클라이언트는 첫 메시지에 S, 즉 DSN 동기화 비트를 표시했다. 새로 생성되는 메시지마다 DSN은 1씩 증가했다. 수신자는 순서대로 온 기록을 받아들이고 순서가 벗어난 도착은 폐기했다.

DATA ACK는 마지막으로 올바르게 처리된 순차 메시지의 DSN을 실었다. 순서가 벗어난 기록이 도착하면 수신자는 현재 확인을 다시 보내, 아직 확인되지 않은 나머지의 즉각 재전송을 유도했다.

따라서 그 숫자는 지금까지 관측된 최대 패킷 번호가 아니라 연속 처리된 경계선을 서술했다. 3122가 아직 빠져 있는 채로 3123을 본 수신자는 정직하게 경계선을 3123으로 진전시킬 수 없다. 그리고 경계선은 기록이 올바르게 과금되었거나, 올바른 가입자에 연결되었거나, 청구되고 정산되었거나, 영구 보존되었다는 말도 하지 않았다. 그것은 정확한 주제를 지닌 애플리케이션 저장 영수증이었다.

신뢰성은 하나의 시퀀스를 여러 서버에 걸쳐 나눌 수 있었다

CRANE은 한 세션이 우선순위가 매겨진 중복 서버들을 포함하도록 허용했다. 클라이언트는 자신이 작동 중이라고 판단한 최고 우선순위 수신자에게 기록을 보냈다. 어느 것도 사용할 수 없으면 수신자가 돌아오거나 로컬 큐 공간이 소진될 때까지, 이 시점에서 경보가 기대되는 동안 기록을 큐에 쌓았다.

서버 전환은 여러 관측에 연결되었다: 전송이 무응답 포트를 보고할 수 있고, 확인되지 않은 바이트가 설정된 기간 동안 설정된 임계값 위에 남을 수 있고, 활성 서버가 STOP을 보낼 수 있고, 선호 서버가 복구할 수 있었다. 프로토콜은 상태와 메시지를 제공했지만 전환 알고리즘은 구현에 맡겼다.

페일오버라는 말보다 그 수치 예가 더 유익하다. 서버 1이 DSN 3042부터 3095까지, 서버 2가 3096부터 3122까지 받고, 서버 1이 3123에서 재개할 수 있다. 어떤 단일 수신자도 전체 런을 보유하지 않는다. 송신자는 여전히 미들웨어나 과금 시스템에 완전한 시퀀스를 갚고 있는 셈이다.

재시도는 같은 논리 기록을 두 번 이상 전달할 수도 있었다. 다른 서버로 재전송된 기록은 Duplicate 비트를 실었고, 하류 시스템은 DSN을 사용해 중복을 제거하도록 되어 있었다. 그 비트는 “이것이 반복일 수 있다”는 뜻이었을 뿐, 쌍둥이가 존재한다거나 발견되었다거나 사본 하나를 지우는 것이 의미론적으로 안전하다는 것을 증명하지 않았다.

기록에는 스키마 영수증도 필요했다

효율적인 전송은 각 기록에서 필드 기술자를 제거했다. 대신 협상된 템플릿이 정렬된 키와 그 유형과 의미를 기술했다. 키는 활성화되거나 비활성화될 수 있었고, 한 세션의 모든 서버는 같은 템플릿 집합과 키 상태를 공유하도록 되어 있었다.

각 기록은 Template ID와 Configuration ID를 모두 실었다. 이 쌍이 중요했다. 적용 가능한 구성 없는 식별자는 잘못된 레이아웃을 가리킬 수 있고, 오래된 구성은 보존된 템플릿 이력을 요구할 수 있으며, 일찍 도착하는 미래 구성은 잘못 읽힐 수 있었다. 문서는 새 템플릿을 보내기 전에 이전 구성 아래의 DATA가 확인될 때까지 기다릴 것을 권했다.

협상에는 제어 경계도 있었다. 서버는 변경을 제안할 기회를 한 번 받았다. 클라이언트가 최종 집합을 선택해 모든 서버에 FINAL TMPL DATA를 보냈다. 그 시점부터 수신자는 추가 수정 없이 이를 받아들이고 확인해야 했다. 중복 수신자들 사이의 끝없는 반복을 피하기 위해서였다.

따라서 DATA ACK는 저장 매체 이상에 의존했다. 세션, DSN, 서버, Template ID, Configuration ID, 협상된 키 상태에 의존했다. 잘못된 스키마 아래 저장된 바이트 배열은 영속적이지만 반드시 의미 있는 것은 아니었다.

과금 프로토콜들은 서로 다른 조건을 제시했다

CRANE의 서론은 자신의 목표를 RADIUS 및 Diameter와 비교했다.RFC 2865는 RADIUS 접근을,RFC 2866은 RADIUS 과금을 정의한다. 당시 새로 시작된 Diameter 작업은RFC 3588이 되었고 나중에RFC 6733이 되었다.RFC 3334는 정책 기반 과금 요구사항을 서술한다.

이후의 IPFIX 문서들—프로토콜,정보 모델,구현 지침—은 템플릿과 내보낸 기록에 대한 또 다른 맥락을 제공한다. 이 출처들은 되풀이되는 설계 압력을 비춘다. 이것들은 CRANE이 같은 시스템에 배포된 선구자라고 만들지 않으며, 서로 다른 확인 응답을 동등한 것으로 다룰 허가도 주지 않는다.

문서의 규범적 대문자 표기는RFC 2119를 따른다. MUST는 명세의 규칙을 서술한다. 특정 바이너리가 그것을 준수했다거나, 큐가 넘치지 않았다거나, 저장 장치가 살아남았다는 것을 증명하지 않는다.

보안 영수증은 별도로 남았다

RFC 3423은 프로토콜 자체가 강한 기밀성이나 무결성을 제공하지 않는다고 밝혔다. 클라이언트와 서버 주소의 정적 프로비저닝은 운영 신뢰 배열을 뒷받침할 수 있지만, 추가 보호 없이는 주소 스푸핑에 취약한 채였다. 문서는 필요할 때 IPsec이나 TLS 같은 하위 계층 보안을 권했다.

따라서 DATA ACK만으로는 누가 그것을 보냈는지, 중간 장치가 기록을 바꾸었는지, 해당 엔드포인트가 그 세션에 대해 권한을 받았는지 증명하지 못했다. 전송 수립, 피어 인증, 메시지 무결성, 템플릿 합의, 영속 처리, 비즈니스 수용은 분리 가능한 사실로 남는다.

출처, 방법, 한계

이 분석은 위에서 링크된 RFC 3423의 일곱 가지 일차 표면 전부, 과금·전송·RADIUS·Diameter·정책 과금·IPFIX 맥락 출처들, 그리고 Lu Heng의현실 계층과실행 코드 우선에세이를 사용한다. 에세이는 방법을 제공한다: 상징적 상태가 하위 또는 이후의 운영 계층만이 확립할 수 있는 것을 흡수하게 두지 말라.

이 출처들은 프로토콜 역사와 명시된 의미론을 뒷받침한다. 현재 배포 조사, 측정된 성능, 이름 붙여진 사건, 또는 생존한 제품이 CRANE을 구현한다는 증거는 제공하지 않는다. 영구 저장 확인은 그 명시된 목적에 대해 전송 ACK보다 강하지만, 여전히 수신자, 구성, 관측 시점, 관측되지 않은 이후의 실패에 의해 제한된다.