요약

  • RFC 1307은 전송 공급자에게up과down만을 제공했고, DSLCP는 컨트롤러 응답을 이전 작업이 끝나기 전에 방향이 바뀔 수 있는 연결·해제 요청과 조정하기 위해 여섯 개의 내부 상태를 유지했다.
  • Up상태에서 해제 요청이 오면 DSLCP는 해제 요청을 전송하고Going Down으로 전환한 뒤 즉시 공급자에게 링크가 down이라고 통보했다. 따라서 논리적 답변은 컨트롤러 완료에 앞섰다.
  • RFC는 항상 공급자에게 해제 성공을 반환했고, 컨트롤러가 알 수 없는 트랜잭션을 보고한 뒤에도 성공한 것처럼 계속 진행할 수 있었다. 따라서 로컬 수렴, 컨트롤러 상태, 물리적 해제는 서로 다른 근거로 남았다.

값싼 인터페이스가 비싼 링크를 지배했다

회선 교환은 1992년 인터넷 호스트에게 특이한 문제를 만들었다. 대용량 전송을 실을 수 있는 링크는 연결 상태로 두기에는 비용이 너무 많이 들었는데, 그 구성은 호스트 밖의 작업이 필요했다. 이를 확보할 유용한 시점은 전송 세션이 경로를 필요로 할 때였고, 해제할 유용한 시점은 그 수요가 끝날 때였다.

RFC 1307은 동적으로 스위치되는 링크 제어 프로토콜(Dynamically Switched Link Control Protocol, DSLCP)을 실험적(Experimental) 답변으로 문서화했다. 전송 공급자는 특별한 다운스트림 링크를 준비해야 한다는 사실을 알았다. 링크 컨트롤러는 하드웨어와 관리적 세부사항을 알았다. DSLCP는 이 둘 사이에 놓여 전송 측에 단순한 요청-해제 인터페이스를 제공했다.

이 분담은 실용적이었다. 전송 구현은 스위치마다 별도의 어휘를 가질 필요가 없었다. 컨트롤러는 장비 차이를 흡수할 수 있었다. 호스트는 비싼 네트워크 자원을 영구적이 아니라 임시적인 것으로 만들 수 있었다. 그러나 이 단순함은 상태를 제거한 것이 아니라 숨김으로써 얻어졌다.

따라서 RFC의 오래된 주제는 단순히 T3 회선이 아니다. 그것은 깨끗한 로컬 약속과 복잡한 외부 행위 사이의 관계다. 제어 계층이down이라고 말했을 때 호출자는 무엇을 알고 있었는가? 무엇이 미결 상태로 남았는가? 늦게 도착한 응답이 현재 상태와 모순된다면 어떤 기록이 진실을 소유하는가?

이 질문들은 인터페이스를 약화시키지 않는다. 인터페이스의 경계를 기술한다.

제어 경로는 데이터 경로보다 먼저 존재했다

DSLCP는 다운스트림 링크를 준비했지만, 그 준비를 요청하는 메시지들은 다른 경로를 필요로 했다. RFC 1307은 DSLCP 트랜잭션이 시작되기 전에 전송 서비스를 제공하는 호스트와 링크 컨트롤러 사이에 네트워크 경로를 요구했다. 제어 메시지는 IP나 UDP 데이터그램으로 실릴 수 있었고, 프로토콜은 신뢰성 있는 전송을 요구하지 않았다.

이 구분은 단일 연결 그림 속에서 놓치기 쉽다. 요청된 데이터 링크가 존재하지 않는 동안에도 호스트는 컨트롤러에 도달할 수 있었다. 따라서 제어 요청이 전달되었다는 사실은, 그 제어 대상 링크가 존재한다는 것도 애플리케이션 데이터가 이미 그것을 건널 수 있다는 것도 증명하지 않았다. 한 경로는 다른 경로에 대한 지시를 실었다.

이로 인해 적어도 네 가지 관찰이 동시에 가능해졌다. 제어 경로가 사용 가능하다는 것, 설정 요청이 호스트를 떠났다는 것, 컨트롤러가 응답했는지 여부, 그리고 물리적 데이터 링크가 어떤 상태에 있느냐는 것이다. "네트워크가 작동했다"만 보고하면 어떤 네트워크에 대해 어떤 작업이 관찰되었는지가 사라진다.

RFC 1307은 링크 준비의 세부사항을 컨트롤러에 맡겼다. 상호운용성을 위한 올바른 추상화였다. 그러나 그것은 전송 공급자가 스위치의 내부 작업에 대한 권위자가 아님을 의미하기도 했다. 공급자의 시각은 메시지로부터 구성되어야 했다.

트랜잭션은 짧은 식별자 그 이상이었다

제어 메시지는 식별자, 전체 길이, 기능, 이벤트 상태, 두 개의 엔드포인트 주소, 컨트롤러 고유 본문을 실었다. 16비트 식별자는 컨트롤러가 트랜잭션을 식별할 때 엔드포인트 주소와 결합하여 사용하도록 되어 있었다.

이 복합적 맥락이 중요하다. 식별자만으로는 재사용될 수 있을 만큼 작았다. 엔드포인트는 그것을 특정 요청 연결 안에 위치시켰다. 기능은 메시지가 연결 설정에 관한 것인지 해제에 관한 것인지를 말했다. 이벤트 상태는 마지막 기능 요청에 상대적으로 제어 대상 링크를 기술했다.

"마지막 요청에 상대적"이라는 것은 강한 제한이다. 설정 성공 값은 링크가 여전히 up 상태여야 한다는 시간을 초월한 증명서가 아니었다. 해제 결과는 사용자 수요가 반대로 바뀐 뒤에 도착할 수 있었다. 비동기 네트워크 다운 이벤트는 또 다른 원인에 속했다. 상태는 트랜잭션, 엔드포인트, 선행 상태, 미결 작업, 시간으로부터 의미를 얻었다.

이 필드들이 저장소에서 분리되었다가 나중에 관찰자에 의해 재결합되면, 제어 교환을 재구성할 수 있다. 그러나 한 줄의 "성공"으로 평탄화되면, 그 단어는 프로토콜이 결코 주장하지 않은 주장으로 전이 가능하게 된다.

가시적 두 상태에는 여섯 개의 숨은 상태가 필요했다

전송 공급자가 인지할 수 있는 상태는 up과 down 두 가지뿐이었다. 그러나 DSLCP는 여섯을 사용했다.

Down은 활성 전송 연결도 준비된 제어 링크도 없음을 의미했다.Coming Up은 수요가 존재하고, 설정이 전송되었으며, 컨트롤러 응답이 대기 중임을 의미했다.Up은 링크가 준비되었고 적어도 하나의 전송 연결이 활성 상태임을 의미했다.Going Down은 수요가 끝났고, 짝이 맞는 up/down 요청이 누적되었으며, 해제가 전송되고 응답이 대기 중임을 의미했다.

나머지 두 상태는 사람과 애플리케이션이 외부 작업이 끝나기를 정중히 기다리지 않기 때문에 존재했다.Bring Down에서는 설정이 아직 대기 중인 동안 해제가 도착했다. DSLCP는 설정 요청이 전송된 적 없는 것처럼 가장할 수 없었다. 응답을 기다리고, 설정이 성공하면 그 뒤에 해제를 보냈다.Bring Up에서는 해제가 대기 중인 동안 새 수요가 도착했다. DSLCP는 그 작업이 해결되기를 기다린 뒤 설정을 다시 전송했다.

따라서 가시적 이진 상태는 시간적 과정의 투영이었다. 하나의 내부 상태는 "현재 의도는 down이며, 이전 설정이 미결 상태이고, 보상 작업이 필요할 수 있다"고 말할 수 있었다. 또 다른 상태는 "현재 의도는 up이며, 해제가 이미 진행 중이고, 설정이 그 뒤를 따라야 한다"고 말할 수 있었다.

이 모든 것을 하나의 불리언이 보존할 수는 없었다. 그러나 불리언은 여전히 유용했다. 공급자에게 필요한 것은 컨트롤러 대화록이 아니라 진행하거나 기다리라는 지시였다. 문제는 그 지시가 나중에 대화록인 것처럼 인용될 때만 시작된다.

하나의 링크가 여러 요청을 서비스할 수 있었다

RFC 1307은 여러 전송 사용자가 동일한 제어 링크에 의존할 수 있음도 인식했다. 한 연결이 이미 링크를 활성 상태로 유지하고 있다면, 링크가 여러 전송 연결을 지원하는 경우 다른 설정 요청은 즉시 ready 응답을 받을 수 있었다. 해제는 대응하는 수요가 해제될 때까지 기다렸다.

이것은 또 다른 분리를 만들었다. 사용자의 해제가 곧 링크 해제는 아니었다. 그것은 수요를 줄였다. 외부 링크는 다른 전송 연결에 의해 여전히 필요할 수 있었다. 반대로 마지막 로컬 해제는 컨트롤러가 그것을 마쳤다는 증명 없이 해제를 시작할 수 있었다.

관련 기록은 단순히 "사용자가 닫았다"가 아니었다. 활성 수요 개수, 동시 연결 능력, 내부 상태, 컨트롤러 트랜잭션이 그것이었다. 용량 회계와 서비스 소유는 단일 사용자의 행위 밖에 있었다.

RFC는 여러 연결을 지원하지 못하는 링크가 여러 설정 요청을 만났을 때 오류를 요구했다. 그 경우에도 능력 제한과 현재 물리적 상태는 달랐다. 링크가 존재하면서도 또 다른 전송 세션에는 사용 불가능할 수 있었다.

Down은 물리적 수령증 이전에 지시였다

가장 날카로운 경계는 해제 테이블에 나타난다. 공급자가 DSLCP가Up상태일 때 해제를 요청하면, DSLCP는 해제 요청을 전송하고,Going Down으로 전환하고, 공급자에게 링크가 down이라고 통보했다.

그 시점에 컨트롤러 응답은 정의상 여전히 대기 중이었다. 로컬 답변은 전송 계층에게 어떻게 행동할지를 말해 주었을 뿐, 외부 스위치가 이미 회선을 해체했다는 것을 증명하지 않았다.

RFC는 이 추상화를 일반적으로 강화했다. DSLCP는 설정이 성공했는지 실패했는지를 공급자에게 알리지만, 공급자는 해제 성공을 가정할 수 있었다. DSLCP는 해제 요청에 항상 성공 응답을 반환하기 때문이었다.

이 비대칭은 타당했다. 설정 성공은 데이터를 보내기 위한 전제였으므로, 잘못된 낙관은 사용 불가능한 경로 위로 트래픽을 밀어 넣을 수 있었다. 해제는 달랐다. 더 이상 어떤 로컬 전송 사용자도 링크에 의존해서는 안 된다면, 공급자는 그것을 사용 가능한 것으로 취급하는 것을 중단해야 했다. DSLCP는 그 경계 아래에서 조정을 마칠 수 있었다.

그러나 나중의 감사는 살아 있는 호출자와 다른 질문을 한다. 컨트롤러가 요청을 받았는가? 그 트랜잭션 기록이 존재했는가? 물리적 스위칭 동작이 일어났는가? 용량은 언제 반환되었는가? 과금은 멈췄는가? 로컬down답변은 그 자체로 이러한 사실을 전혀 공급하지 않는다.

신뢰할 수 없는 제어는 의도의 반복 없이 반복을 의미했다

DSLCP는 신뢰성 있는 전송을 요구하지 않기로 의도적으로 했다. 따라서 타임아웃과 재전송이 필요했다. 저자들은 빠른 로컬 컨트롤러 환경에서 5초 타임아웃과 3회 재전송을 보고하면서, 다른 구성에서는 다른 값이 필요하고 이상적으로는 적응적 접근이 바람직하다고 경고했다.

재전송된 데이터그램은 관찰이 없었기 때문에 제어 메시지를 반복했다. 그것이 새로운 사용자 의도를 나타낼 필요는 없었다. 원래 요청이 도착했고 응답이 단지 지연되고 있을 수도 있었다. 두 번째 요청은 중복 응답을 유발할 수 있었다. 패킷은 순서가 바뀔 수 있었다.

RFC 1307은 타임아웃 후 중복 요청이 만들어내는 예상치 못한 컨트롤러 메시지에 대해 명시적으로 대비했다. 그래서 메시지 수신은 미결 트랜잭션과 로컬 상태 없이는 해석될 수 없었다. 동일한 설정 성공 코드가Coming Up에서는 환영받고,Up에서는 무관하며,Down에서는 오래된 작업의 증거일 수 있었다.

타임아웃은 또한 어느 구성 요소가 실패했는지 식별하지 않았다. 요청이 손실되었을 수 있고, 컨트롤러가 사용 불가능했을 수 있고, 응답이 손실되었을 수 있고, 설정된 간격이 부적합했을 수 있었다. 재전송은 불확실성 아래의 복구 행동이었지, 컨트롤러에 대한 판결이 아니었다.

진짜 성공이 이미 시대에 뒤떨어질 수 있었다

DSLCP가 로컬에서Down상태인 동안 설정 성공이 도착하는 경우를 생각해 보라. RFC는 그 메시지가 중복 요청과 네트워크 재정렬의 결과일 수 있다고 말한다. 규정된 응답은 부재중인 사용자를 위해 링크를 다시 여는 것이 아니었다. DSLCP는 해제를 전송했다.

그 성공은 원래 트랜잭션 안에서는 진실일 수 있고, 현재 의도에 대해서는 틀릴 수 있었다. 이것은 비동기 제어의 결정적 성질이다. 유효성과 적용 가능성은 별개다.

Bring Down에서도 같은 논리가 기대되었다. 설정이 시작되었고, 사용자가 이후 해제했으며, 성공적인 컨트롤러 응답이 시대에 뒤떨어진 작업을 완료했다. DSLCP는 즉시 반대 상태를 요청하고Going Down으로 들어갔다.

최신 성공 코드만 기록하는 모니터링 시스템은 이야기를 뒤집을 수 있다. 그것은 상태 머신이 이제 불필요해진 링크를 취소하던 바로 그 순간에 수요가 충족되었다고 결론 내릴 수 있다. 요청 순서를 보존하면, 설정이 역사적으로 성공했지만 더 이상 원하는 상태를 지배하지 않는다는 것이 드러난다.

해제 성공은 불일치를 드러낼 수 있었다

늦게 도착한 해제 성공에는 그 자체의 역설이 있었다. DSLCP가Up상태인 동안 그것이 도착했다면, RFC는 어떤 오류가 발생했다고 말한다. 호스트의 현재 시각이 여전히 활성 링크를 지지하는 동안 이전 해제가 완료된 것처럼 보였다.

보수적 응답은 연결을 내리고 재동기화하는 것이었으며, 다만 원문은 그 메시지를 무시하는 것이 때때로 해를 끼치지 않을 수 있다고 밝혔다. 이 선택은 프로토콜의 인식론적 입장을 드러낸다. 메시지는 중요했지만, 세계를 유일하게 재구성하지는 못했다. 구현은 복구 정책을 선택해야 했다.

재동기화는 로컬과 원격 상태가 더 이상 일치한다고 가정되지 않는다는 증거다. 그것은 통상적 성공으로 위장되어서는 안 된다. 유용한 이벤트 기록은 예상치 못한 응답, 수신 시점의 상태, 미결 요청, 복구 결정, 이후의 물리적 또는 데이터 평면 관찰을 포함할 것이다.

알 수 없는 트랜잭션도 로컬 성공으로 끝날 수 있었다

가장 인상적인 규칙은Up상태에서의 해제 실패에 관한 것이다. 컨트롤러는 해제가 유효하지 않은 트랜잭션을 참조했다고 보고했다. 식별자와 엔드포인트 쌍에 대한 기록이 없었다는 것이다. DSLCP는 요청이 성공한 것처럼 계속 진행하도록 지시받았다.

이것은 컨트롤러가 물리적 해제를 확인했다는 뜻이 아니었다. 프로토콜의 로컬 수렴 관점에서, 그 정체성 아래 해체할 컨트롤러 트랜잭션이 더 이상 남아 있지 않다는 뜻이었다. 계속 진행은 해결 불가능한 기록 불일치가 전송 공급자를 영원히 가두는 것을 막았다.

동일한 응답 뒤에는 여러 역사가 놓일 수 있었다. 이전 해제가 기록을 제거했을 수도 있고, 상태가 손실되었을 수도 있고, 식별자 맥락이 맞지 않았을 수도 있다. RFC는 이 중에서 선택하지 않았다. DSLCP가 다음에 무엇을 해야 하는지를 규정했다.

따라서 "성공한 것처럼"은 절차적 언어다. 그것은 로컬 프로토콜 머신 안에서의 상태 전이를 승인한다. 명명된 스위치 동작이 일어났다는 소급적 진술이 아니다. 전자를 후자로 바꾸는 것은 증거를 조작하는 것이다.

네트워크 다운은 사용자 해제가 아니었다

컨트롤러는 비동기 네트워크 다운 이벤트를 보낼 수도 있었다. 활성 또는 과도적 up 상태에서 DSLCP는Down으로 이동하고 공급자에게 통보했다. 이 경로는 전송 사용자가 서비스를 해제하면서 시작되지 않았고, 호스트 해제 요청에 대한 성공 응답도 아니었다.

공급자는 매우 다른 원인들로부터 동일한 이진 결과인 down을 볼 수 있었다. 수요 없음, 설정 실패, 해제 진행, 응답 타임아웃, 컨트롤러가 보고한 네트워크 실패, 예상치 못한 메시지 후의 조정. 원인은 전이 기록에 속했고, 불리언 출력에 속하지 않았다.

이 구분은 책임 소재에 영향을 미친다. 계획된 해제, 컨트롤러 거부, 외부 네트워크 손실은 모두 호출자가 링크를 사용할 수 없게 만든다는 이유만으로 하나의 설명을 공유할 수 없다.

보안은 주장의 범위 밖이었다

RFC 1307의 보안 고려사항 절은 보안 문제가 논의되지 않았다고 말한다. 그 부재는 한계이지 유리한 결과가 아니다.

문서는 컨트롤러 메시지가 어떻게 인증되는지, 누가 비싼 링크를 요청할 권한이 있는지, 데이터그램에 무결성 보호가 있었는지, 엔드포인트 주장이 어떻게 검증되는지, 컨트롤러 고유 문자열이 민감한 정보를 노출하는지를 확립하지 않는다. 상태 머신은 그 공백을 발명으로 채우지 않고 연구될 수 있다.

마찬가지로, 이 RFC는 하나의 역사적 프로젝트 맥락에서 나온 실험적 프로토콜 기술이다. 현재의 통신사 시스템, 살아 있는 회선, 보편적 구현 관행의 증거가 아니다.

출처

이 출처는 프로토콜의 1992년 설계, 메시지 의미론, 상태 머신 규칙을 확립한다. 그것은 실제 컨트롤러 교환, 물리적 해제, 용량 반환, 과금 결과, 보안 성질, 패킷 전달, 애플리케이션 결과를 확립하지 않는다.