요약

  • RFC 892는 전송 연결(Transport Connection)에 자체 종단점 선택 참조 쌍을 부여하여, 그 프로토콜 단위를 운반하는 네트워크 연결로부터 독립시켰다.
  • 매핑은 양방향으로 작동했다: 여러 전송 연결이 하나의 네트워크 연결을 공유할 수 있었고, 클래스 4에서는 하나의 전송 연결이 여러 캐리어에 분할될 수 있었다.
  • 독립성에는 한계가 있었다. 네트워크 품질, 전역적(pervasive) 캐리어 상태, 협상된 클래스 및 클래스별 복구 규칙이 캐리어를 재사용할 수 있는지, 교체할 수 있는지, 아니면 전송 연결 자체의 수명으로 취급할지를 결정했다.

“연결”이라는 단어는RFC 892에서 서로 다른 두 계층에 등장한다. 네트워크 연결(Network Connection)은 하위 서비스를 통해 두 전송 개체(transport 주체)를 연결했다. 전송 연결(Transport Connection)은 상위 프로토콜을 통해 두 전송 사용자를 연결했다. 이 둘을 혼동했다면 가장 단순한 클래스는 기술하기 쉬웠겠지만, 나머지 아키텍처는 불가능했을 것이다.

전송 연결이 데이터를 운반하기 전에, 하나의 네트워크 연결—또는 분할이 가능한 경우 둘 이상—에 할당되어야 했다. 캐리어는 이미 존재할 수도 있고 그 목적을 위해 새로 생성될 수도 있었다. 따라서 할당은 전송 상태의 출생 증명서가 아니라 지역적 운영 결정이었다.

이 구분은 특이한 제도적 환경에서 발표되었다. RFC 892는 정보 제공 목적으로 ISO 전송 사양을 재현하면서 ARPA-인터넷 표준을 정의하지 않는다고 명시했다.RFC 905는 몇 달 뒤 동일한 정보 제공 경계 아래 더 최신의 ISO DP 8073 문서로 이를 대체했다. RFC 시리즈는 다른 표준화 프로젝트를 들여다보는 창 역할을 했을 뿐, 그 프로젝트를 조용히 인터넷 법규로 바꾸지는 않았다.

두 개의 참조가 하나의 전송 연결을 지칭했다

연결 설정은 연결 요청(Connection Request, CR TPDU)과 연결 확인(Connection Confirm, CC TPDU)으로 시작되었다. 개시자는 16비트 소스 참조를 제공했다. 응답자는 확인 메시지에 자신의 참조를 제공했다. 각 측은 상대방이 목적지 참조로 사용할 값을 선택했다.

이 값들은 지역적이고 범위가 한정되어 있었다. 참조는 0이거나 이미 사용 중이거나 이전 연결 이후 여전히 동결 중일 수 없었다. 이는 전역 이름, 공개 신원 또는 자격 증명이 아니었다. 그 힘은 수신 전송 개체의 상태 테이블에서 나왔다.

RFC 892는 이 배치를 대칭적이라고 불렀다. 어느 쪽도 마스터나 슬레이브로 선언될 필요가 없었고, 동시 호출 처리도 중앙 참조 할당자에 의존하지 않았다. 더 중요하게는, 이 문서는 참조들이 네트워크 연결과 독립적으로 전송 연결을 식별한다고 명시했다.

이 독립성은 형이상학적이지 않고 증거적이었다. 캐리어를 통해 도착한 TPDU에는 여전히 인식 가능한 소스/목적지 맥락과 살아 있는 할당이 필요했다. 참조는 “어떤 전송 상태인가?”라는 질문에는 답했다. 그러나 “이 조직은 누구인가?”, “이 행위는 승인되었는가?”, “애플리케이션이 이 데이터를 받아들일 것인가?”에는 답하지 않았다.

요청은 클래스를 제안했고, 확인이 그것을 선택했다

RFC 892는 하나의 전송 동작을 정의하지 않았다. 다섯 개의 클래스를 정의했다: 단순 클래스 0, 기본 오류 복구 클래스 1, 멀티플렉싱 클래스 2, 오류 복구 및 멀티플렉싱 클래스 3, 그리고 오류 감지 및 복구 클래스 4.

개시자는 선호 클래스를 제안하고 대안을 나열할 수 있었지만, 클래스 0 선호는 대안을 허용하지 않았다. 대기하는 동안 선호가 수용될 것이라 가정하고 동작할 수 있었다. 그 가정은 잠정적이었다. 응답자의 CC는 선택된 클래스를 담았고, 허용된 선택이 다르면 개시자는 자신의 기능을 조정해야 했다.

다른 매개변수들은 자체적인 협상을 유지했다. 응답자는 제안된 최대 TPDU 크기를 수용하거나 정의된 하한까지 더 작은 허용 크기를 선택할 수 있었다. CR의 제안된 옵션은 CC의 선택된 옵션이 되었다. 성공적인 네트워크 연결, 구문상 유효한 CR, 호출자의 선호는 서로 다른 세 가지 사실이었고, 그중 어느 하나만으로 최종 운영 계약이 확정되지 않았다.

이용 가능한 네트워크 서비스가 선택을 좌우했다. RFC 892는 잔여 오류와 신호된 장애로 네트워크 품질을 구분했다. 사용자 요구와 비용도 중요했다. 네트워크 연결은 전송 연결의 품질 요구를 충족하지 못하거나, 전역 함수의 기존 사용이 제안된 클래스와 충돌하기 때문에 부적합할 수 있었다.

공유는 양방향으로 작동했다

멀티플렉싱은 여러 전송 연결을 하나의 네트워크 연결에 매핑했다. 각 TPDU는 목적지 참조를 담아 수신자가 이를 올바른 전송 상태로 반환할 수 있게 했다. 캐리어는 공유되었지만 대화들은 병합되지 않았다.

공유는 결합을 만들어냈다. 일부 기능은 “전역적(pervasive)”이었다: 네트워크 연결에서 첫 전송 연결에 사용된 후, 그 캐리어의 수명 동안 이를 사용하는 모든 전송 연결에 적용되었다. 따라서 하위 계층 자원은 식별 기능이 없으면서도 그 위의 모든 것에 공통 동작을 부과할 수 있었다.

역방향 매핑은 분할(splitting)과 재결합(recombining)에 나타났다. RFC 892는 복원력이나 처리량 등을 개선하기 위해 하나의 전송 연결에 여러 네트워크 연결을 사용하는 방식을 기술했다. 그 클래스/기능 테이블은 모든 곳에서 이를 제공하지 않았다. 이 메커니즘은 가장 강력한 오류 감지 및 복구 클래스에 속했다. 이 글의 주장은 모든 ISO 전송 연결이 멀티패스였다는 것이 아니다. 아키텍처가 여러 캐리어 위의 하나의 전송 상태를 위한 어휘를 갖추고 있었다는 것이다.

재할당은 또 다른 경계를 제공했다. 네트워크 연결이 사라지면, 그 메커니즘을 호출하는 복구 클래스는 전송 연결을 다른 캐리어에 할당하고 재동기화할 수 있었다. 피어는 주소가 여전히 동일한 전송 개체를 암시하는 네트워크 연결을 통해 유효한 TPDU가 도착하면 새 할당을 인식했다.

클래스 0은 이 한계를 드러낸다. 클래스 0에는 명시적 전송 해제 절차가 없었고, 그 전송 연결 수명은 네트워크 연결 수명과 직접 상관되었다. 아키텍처는 슬로건으로 독립성을 약속하지 않았다. 독립성의 정도를 클래스별 역량으로 만들었다.

이후 인터넷 매핑이 캐리어를 다시 바꾸었다

설계자들이 ISO 전송 서비스를 TCP 위에 올리면서 이 분리는 구체화되었다.RFC 983은 내부적으로 TCP/IP를 사용하면서 ISO TSAP 면을 향한 서비스를 제안했다. 그 목표는 상위 ISO 세션, 표현 및 애플리케이션 개체가 하위 서비스가 TCP라는 사실을 모른 채 작동하도록 하는 것이었다. 또한 완전한 전환 계획을 주장하는 것을 거부했다.

RFC 1006은 그 제안을 버전 3으로 대체하며 TCP 위의 ISO 전송 클래스 0에 대한 인터넷 표준을 제시했다. TCP는 신뢰성 있는 연결 지향 서비스를 제공했지만, 이산적인 네트워크 서비스 데이터 단위가 아니라 옥텟 스트림을 전달했다. 그리하여 RFC 1006은 각 TPDU를 길이 구분 TPKT로 감쌌다. 래퍼는 경계를 복원했을 뿐, 발신자를 인증하거나 콘텐츠 무결성을 보호하지는 않았다.

이 매핑은 의도적으로 RFC 892의 일부 자유를 축소했다. TCP 오픈이 하위 연결을 제공했고, TCP 종료가 단절을 제공했으며, 그 위에서 클래스 0이 작동했다. 그럼에도 ISO 전송 인터페이스와 TPDU 계약은 1983년 문서가 ARPA 표준으로 명시하지 않은 캐리어 위에서 살아남았다.

RFC 2126은 나중에 IPv4 또는 IPv6 위의 TCP에 대해 이 배치를 정제하며 클래스 0과 클래스 2 변형을 기술했다. TPKT 버전 호환성을 유지한 것은 부분적으로 기존 RFC 1006 기반을 보호하기 위함이었다. 또한 레지스트리 사실과 보편적 라우팅 규칙을 분리했다: TCP 포트 102는 예약되었지만, 적합한 연결은 다른 포트를 사용할 수 있었다.

현재IANA 서비스 이름 및 포트 레지스트리는 포트 102에iso-tsap을 기록하고 있다. 그 행은 번호의 조정을 증명한다. 그러나 그것은 어떤 리스너가 특정 클래스를 구현한다는 것, CR이 확인되었다는 것, 참조가 살아 있는 상태에 매핑된다는 것, 또는 어떤 애플리케이션 교환이 성공했다는 것을 증명하지 않는다.

출처와 한계

이 글은 RFC 892, 이를 대체한 RFC 905, RFC 983·RFC 1006·RFC 2126의 TCP 매핑, 그리고 IANA 레지스트리를 사용한다. 이들은 명시된 메커니즘, 문서의 지위, 이후의 캐리어 매핑을 확립한다. 이들은 현재의 배포, QUIC 또는 SCTP로의 직접 계보, 분할이나 재할당의 보편적 사용, 인증된 피어, 성공적인 OSI 전환, 또는 특정 구현의 동작을 확립하지 않는다.