요약

  • Demand RIP는 주기적 WAN 브로드캐스트를 확인 응답이 있는 트리거형 교환으로 대체하여 스위치형 X.25 및 ISDN 회선을 닫을 수 있게 했다. 이러한 교환을 통해 학습된 경로는 일반적인 침묵 속에서 만료되지 않고 보통 영구 상태가 되었다.
  • 회선 수립 시도가 실패하면 회선 관리자가 다음 홉이 다운되었다고 보고할 수 있었고, 그 후 경로 항목은 노화되고 홀드다운에 들어가며 사라질 수 있었다. 확인 응답은 갱신이나 프래그먼트의 수신을 증명했을 뿐, 경로의 진실이나 사용자 트래픽의 성공을 증명하지 않았다.
  • RFC 1581은 완성된 구현 하나가 두 가지 WAN 유형에서 자체 대상으로 테스트되었다고 보고했다. RFC 1264는 이 근거의 한계를 분명히 했다. 하나의 환경에서 하나의 구현은 독립적이고 다중 벤더의 상호 운용성에 대한 증명이 아니었다.

비용이 드는 하트비트

첫 번째 문제는 RIP가 경로를 기술하지 못한다는 것이 아니었다. 문제는 계속 살아 있음을 증명하는 평상시 방식이 자신을 반복할 때마다 비용과 용량을 소모한다는 점이었다.

RFC 1582는 공식기록에 따르면 1994년 2월로 연대되며, 연결 지향 공중 데이터 네트워크에서 시작되었다. X.25 또는 ISDN 회선은 트래픽이 나타나면 열리고 트래픽이 멈추면 해제될 수 있었다. 사용자 교환은 짧고 드물 수 있었다. 주기적 라우팅 갱신은 그 경제성에 저항했다. 라우터가 이미 말한 내용을 다시 말하기 위해 호출이 열려 있거나 반복적으로 열려야 했다.

이 문서는 그 압력에 숫자를 붙였다. N개의 라우터가 있을 때, 그런 WAN에서의 브로드캐스트 주기는 그 절반에 해당하는 상호 연결 수만큼 N 곱하기 N 빼기 하나의 개별 갱신이 될 수 있었다. WAN이 공통 브로드캐스트 기능을 제공하지 않았기 때문에 “브로드캐스트”라는 말은 직렬 작업을 감추었다. 인터페이스는 목적지보다 적은 채널을 가질 수도 있었다. RFC는 동시 호출 두 건이 가능한 ISDN 기본 요금 인터페이스를, 동시에 접촉할 수 있는 것보다 더 많은 피어를 알아야 하는 시스템의 단순한 예로 사용했다.

덜 자주 보내는 것은 공짜 해법이 아니었다. 요금과 큐 압력을 낮추는 대신 변경 사항이 전파되는 속도를 늦추었다. 평상시 간격으로 보내면 응답성은 유지되지만 네트워크가 구매한 스위치형 회선의 이점 자체를 소모했다. 따라서 이 설계는 침묵이 무엇을 의미하는지 바꾸었다.

회선이 조용해지면 경로는 노화를 멈췄다

동반 문서인RFC 1581은 Informational 프로토콜 분석 문서이며,RFC Editor 기록은 그 지위를 동반 사양과 구분한다. 이 문서는 중심 거래를 요약했다. Demand WAN 링크에서는 주기적 브로드캐스트가 사라졌다. 라우팅 갱신은 데이터베이스 이벤트가 필요할 때만 이동했고, 수신자는 평상시에는 그 정보를 시간 초과하지 않았다.

RFC 1582는 같은 변화를 두 가지 경로 등급으로 표현했다. 주기적 LAN 응답에서 학습된 정보는 임시적이었다. 또 다른 브로드캐스트가 없으면 만료되었다. WAN에서 트리거된 응답으로 학습된 정보는 보통 영구적이었다. 조용함은 더 이상 근거가 늙어 가고 있다는 뜻이 아니었다. 시스템이 자신의 규칙이 모순으로 인식하는 이벤트를 아직 보지 못했다는 뜻이었다.

여기가 역사적 경첩이다. 조용한 회선은 지속적인 도달 가능성에 대한 관찰이 아니었다. 비싼 회선을 다시 열 이유가 없다는 부재였다. 경로가 살아남은 이유는 프로토콜이 지속성을 마지막으로 수용된 상태에 부여했기 때문이다.

이것은 무분별한 낙관이 아니었다. 반박 방법이 이름으로 지정된 명시적 추정이었다. 응답이 경로를 도달 불가로 표시할 수 있었다. 완전한 응답이 이전에 존재하던 경로를 생략할 수 있었다. 인터페이스가 다운될 수 있었다. 반복되는 라우팅 교환이 확인 응답을 받지 못할 수 있었다. 가장 중요하게는, 평상시 트래픽을 전달하려는 시도가 가상 회선 수립에 실패하여 회선 관리자가 다음 홉이 다운되었다고 보고할 수 있었다.

이 구분이 중요한 이유는 타임아웃과 테스트는 서로 다른 기록이기 때문이다. 평상시 RIP는 경로를 반복적으로 갱신하고 갱신이 없으면 노화시켰다. Demand RIP는 그 반복 근거에 비용을 지불하는 일을 멈추고 이벤트 기반의 반대 근거를 기다렸다. 경로를 불멸로 만든 것이 아니라, 경로가 죽기 시작하기 전에 누가 말해야 하는지를 바꾼 것이다.

회선 관리자가 라우팅 목소리를 갖게 되었다

RFC 1582는 IP, IPX와 그 라우팅 응용이 회선 관리자 위에 놓이고, 회선 관리자가 다시 연결 지향 WAN을 제어하는 스택을 그렸다. 회선 관리자는 다음 홉 네트워크 계층 주소를 호출을 걸기 위해 필요한 물리 주소로 변환했다. 데이터가 도착했는데 가상 회선이 없으면 하나를 열려고 시도했다. 비활성 후에는 회선을 닫을 수 있었다.

이 구성 요소는 호출을 거는 일 이상을 했다. 정상적인 라우팅 중에 회선을 수립할 수 없으면, 라우팅 응용에게 내부 circuit-down 표시를 보냈다. 그 다음 홉을 통과하는 경로는 영구적 확신에서 시간이 정해진 순서로 옮겨 갔다. 노화, 홀드다운 기간 중의 도달 불가 광고, 그리고 결국 삭제가 그 순서였다. 과정이 끝나기 전에 회선이 돌아오면 경로를 복원할 수 있었다. 이미 만료되었다면 라우팅 작업이 새 교환을 요청하고 양쪽 데이터베이스를 다시 준비했다.

circuit-up 표시도 마찬가지로 한계가 있었다. 이것은 회선 관리자가 자신의 복구 규칙에 따라 피어에 접촉하는 데 성공했음을 보여주었다. 이전 데이터베이스의 모든 경로가 여전히 유효함을 증명하지 않았다. 그래서 복구 후에 라우팅 응용들은 전체 정보를 교환했다.

RFC는 회선 관리자의 복구 과정을 범위 밖으로 두었다. 재시도, 채널 선택, 주소 매핑, 제품별 결정이 필요할 수 있었다. 라우팅 프로토콜은 up 또는 down 표시를 소비하면서, 그 표시를 고장에 대한 보편적 설명으로 바꾸지 않았다. 사용 중인 채널 풀, 잘못된 피어 매핑, 실패한 원격 시스템, 끊어진 회선이 모두 같은 내부 경계에서 끝날 수 있었다.

구현 절은 또 다른 이음새를 드러냈다. 설명된 제품은 회선 관리자와 라우팅 작업을 거의 하나의 프로그램처럼 긴밀하게 결합했다. Unix 시스템은 회선 관리자를 커널에, 라우팅 응용을 별도 프로세스에 둘 수 있었다. 다른 제품은 별도의 카드를 사용할 수 있었다. 두 부분이 독립적으로 죽고 재시작할 수 있다면, RFC 1582는 keepalive와 상태 재동기화 방법을 요구했다. 살아 있는 회선 관리자 옆의 죽은 라우팅 프로세스는 건강한 라우팅이 아니었다. 살아 있는 라우팅 프로세스 옆의 죽은 회선 관리자는 자신의 영구적 주장을 안전하게 유지할 수 없었다.

확인 응답은 전달 질문을 닫았다 — 경로 질문을 닫지는 않았다

트리거형 갱신은 반복 트래픽을 절약했지만 각 변경을 더 중요하게 만들었다. 단일 데이터그램은 가상 회선이 없거나, 전송 큐가 넘치거나, 회선이 선점되거나, 손상된 프레임이 버려지는 이유로 사라질 수 있었다. 다음 주기적 브로드캐스트가 없으면 잃어버린 변경은 스스로 복구되지 않을 수 있었다.

따라서 RFC 1582는 요청, 응답, 확인 응답을 추가했다. 응답은 확인될 때까지 재전송되었다. 큰 갱신은 번호가 매겨진 프래그먼트로 분할되어 각각 개별적으로 확인되었다. 수신자는 모든 프래그먼트가 도착한 후에야 데이터베이스 변경을 적용했다. 재조립 구간이 지나도록 집합이 불완전하게 남으면 프래그먼트를 버리고 전체 갱신을 다시 요청했다. 새 시퀀스 번호를 가진 프래그먼트는 불완전한 오래된 집합을 대체했다.

이 규칙들은 유용한 수취 기록을 만들었다. 확인 응답은 피어가 특정 응답 프래그먼트를 받았는지에 답했다. 재조립은 수신자가 하나의 데이터베이스 갱신에 필요한 완전한 집합을 갖고 있는지에 답했다. 시퀀스는 갱신의 한 버전을 다른 버전과 분리했다.

그러나 어느 것도 광고된 네트워크가 실제로 사용자 패킷을 전달하는지에 답하지 않았다. 피어는 거짓이거나 낡은 경로를 안정적으로 전달할 수 있었다. 완전한 갱신이 설치된 후 응용이 실패할 수 있었다. 라우팅 교환에 사용된 물리 호출이 작동하는 동안 다른 호출 시도나 채널은 실패할 수 있었다. 인증과 구성된 피어 목록은 누가 보낼 수 있는지를 제한할 수 있었지만, 말할 권한은 여전히 말해진 모든 문장의 진실이 아니었다.

프로토콜 자체가 이 부정적 경계를 인식했다. 반복된 요청이나 응답이 확인되지 않으면, 라우터는 그 피어를 통과하는 경로를 도달 불가로 표시하고 홀드다운에 들어가며 폴링 빈도를 낮출 수 있었다. 이것조차 원인을 식별하지 않았다. 경계가 정해진 통신 실패를 안전한 라우팅 조치로 변환했을 뿐이다.

회선 비용 절감은 상태 비용을 만들었다

영구 경로는 잊는 것에 의존할 수 없다. RFC 1582는 라우팅 데이터베이스가 모든 대안을 유지하거나, 정의된 하위 집합을 유지하면서 나머지 선택이 사라지기 전에 대안을 다시 요청할 수 있도록 대안이 버려진 시점을 기억해야 한다고 말했다. 주기적 갱신이 다시 만들어 주던 정보는 이제 메모리에 남거나 의도적으로 다시 획득되어야 했다.

이것이 더 싼 회선 뒤에 숨은 교환이었다. 더 적은 호출은 더 내구적인 상태를 의미했다. 더 내구적인 상태는 정확한 무효화를 요구했다. 정확한 무효화는 신뢰할 수 있는 갱신 전달, 피어별 시퀀스 처리, 프래그먼트 재조립, 회선 관리자 조율, 복구 절차를 요구했다. 네트워크는 반복에 덜 지출하는 대신, 라우터가 기억할 더 큰 의무를 받아들였다.

피어 목록도 비슷한 무게를 지녔다. 이 목록은 트리거 형식 또는 평상시 주기적 형식을 받을 목적지를 지명했고, 갱신을 수용하는 집합을 겸했다. 누락된 항목은 단지 트래픽을 줄이는 데 그치지 않았다. 호환성 관계를 바꾸었다. 적절한 목록 밖의 피어에서 도착한 갱신은 폐기해야 했다.

이것은 로컬로 구성된 관계를 둘러싼 최소 상호 운용성 규칙이었다. 프로토콜은 메시지 유형과 상태 전이를 고정했다. 운영자는 여전히 피어, 호환 가능한 범위 내의 타이머 값, 채널 구독, 회선 복구의 구현을 선택했다. 공표가 작동하는 관계를 만들지는 않았다. 두 참여자가 일치하는 행동을 구성하고 실행해야 했다.

하나의 구현은 범위가 좁은 수취 기록이었다

RFC 1581은 구현 근거를 과장하지 않았다. 완성된 구현이 하나 있다고 믿어진다고 말했다. Spider Systems 제품은 그 단계에서 IP RIP-1, IPX RIP, IPX SAP를 지원했지만 RIP-2는 지원하지 않았다. X.25와 ISDN에서 자체 대상으로 테스트되었다. 이더넷 LAN에서 평상시의 라우터 및 호스트 구현 곁에서도 작동했다. Novell 전용 구현 두 개가 개발 중이라고 알려져 있었다.

그 기록은 종이보다 더 증명했지만 성숙한 생태계보다는 덜 증명했다. 작동하는 코드가 있었다. Demand 회선 메커니즘은 자체 호환성 테스트에서 두 가지 이름 있는 WAN 기술을 실제로 다루었다. 평상시의 LAN 상호 운용성은 더 넓은 주변 집합을 갖고 있었다. 그러나 새로운 WAN 행동에 대해 두 번째 독립적인 완성 구현은 보고되지 않았다.

RFC 1264와 그공식 기록은 RFC 1581이 답변하던 표준화 규율을 제공했다. 라우팅 프로토콜은 분산 실시간 알고리즘이며, 하나의 구현이 한 환경에서 성공하는 것이 여러 벤더가 다른 곳에서 성공함을 보장하지 않는다. 독립 구현과 보안 메커니즘을 포함한 모든 기능의 테스트는 별개의 근거 요건이었다.

역사적 가치는 그 세분성을 보존하는 데 있다. “구현됨”은 “상호 운용 가능함”으로 고쳐 써서는 안 된다. “자체 대상으로 테스트됨”은 아무것도 아닌 것으로 무시해서는 안 된다. “Standards Track”은 배포됨으로 보고되어서는 안 된다. 각각은 서로 다른 수취 기록이다.

후속 설계는 갱신 기계 장치를 바꾸었지 근거 경계를 바꾸지 않았다

1997년 1월에RFC 2091이 나왔으며여기에 기록되어 있다. 이 문서는 RFC 1582의 Demand RIP에 비해 효율상의 이점을 설명했다. 전체 교환 후에는 변경된 정보만 보냈고, 메모리를 덜 사용했으며, 그 프래그먼트화 방식을 피함으로써 이전 설계의 255-프래그먼트 상한을 제거했다.

그러나 중심 거래는 여전히 보였다. 트리거된 WAN 응답에서 학습된 경로는 여전히 보통 영구적이었다. 회선 관리자는 여전히 실패한 연결 시도와 이후의 복구를 보고했다. 요청과 응답은 여전히 확인 응답과 재전송을 요구했다. 확인되지 않은 교환이 너무 많으면 여전히 추정된 도달 가능성이 도달 불가 상태로 바뀔 수 있었다. 복구는 여전히 전체 플러시와 데이터베이스 교환을 필요로 했다.

그 연속성은 이 메커니즘이 저렴하게 제거할 수 없었던 것이 무엇인지 보여준다. 주기적 갱신이 멈춘 후에도, 시스템은 여전히 내구적인 최후 알림 상태, 반대 도달 가능성 근거를 보고할 권한이 있는 구성 요소, 신뢰할 수 있는 변경 전달, 오래된 확인 응답이나 오래된 경로가 새로운 존재로 넘어가지 못하게 하는 재시작 경계를 필요로 했다.

회선이 잠잠해진 것은 침묵이 설계되었기 때문이었다. 경로가 계속 도달 가능했던 것은 지속성 역시 설계되었기 때문이었다. 어느 사실도 그 순간에 패킷이 WAN을 건넜음을 증명하지 않았다. 정직한 기록은 회선 상태, 라우팅 상태, 갱신 수취, 포워딩, 사용자 결과를 별도의 열에 유지했다.

출처