요약

  • RFC 1190은 각 ST-II 홉이CONNECT를 확인 응답하고 포워딩 식별자를 협상하며, 대상 애플리케이션이 스트림 참여 여부를 결정하기 전에 자원 예약을 시도하도록 허용했다.
  • HID-APPROVE는 홉 로컬 식별자 교환을 종결했다. 대상의 별개ACCEPT는 해당 브랜치에서 실제로 누적된 FlowSpec을 기점 쪽으로 되돌려 보냈다.
  • 다중 대상 기점은 모든 대상에 대한 결과를 필요로 했으며, 브랜치를 제거하거나 스트림을 분할하거나 초과 예약을 축소할 수 있었다. 수락은 이후의 전송이나 유용한 미디어를 증명하지 못했다.

동의보다 먼저 도착한 확인 응답

RFC 1190은 실험용 인터넷 스트림 프로토콜 버전 2, 즉 ST-II를 기술했다. 1990년 10월에 발표되었으며 인터넷 표준이 아니라 제한적 사용의 실험이었다. 현재RFC Editor 기록과IETF Datatracker 항목은 RFC 1819가 이를 대체했음을 보여주지만, 메시지 다이어그램을 실제 배포의 증거로 만들지는 않는다.

가장 계시적인 다이어그램은 평범해 보이는 응답으로 시작한다. 중간 ST 에이전트가CONNECT를 수신한다. 오류가 없다고 가정하면 자신의 로컬 가상 링크 상태를 선택하고 이전 홉에게 빠르게ACK,HID-REJECT또는HID-APPROVE로 답한다. 그런 다음 라우팅을 호출하고 자원을 예약하며 관련 대상들 쪽으로 새CONNECT메시지를 보낼 수 있다.

이 응답은 해당 이웃이 하나의 제어 요청을 처리했음을 증명하고, 승인의 경우에는 효율적인 포워딩을 위해 제안된 Hop Identifier를 수용했음을 보여준다. 대상 애플리케이션은 여전히 여러 에이전트 너머에 있을 수 있다. 대상은 제안된 스트림, 누적된 FlowSpec, 애플리케이션 셀렉터의 신원을 아직 보지 못했다. 포워딩 테이블을 소유한 홉이 자신이 통제하지 않는 애플리케이션을 대신해 동의할 수는 없다.

데이터가 이동하기 전에 설정 작업이 복잡성을 소비했다

ST-II는 IP 옆의 인터넷 계층에 위치했다. 그 모델은 독립적인 데이터그램의 연속이 아니었다. 스트림은 하나의 기점, 하나 이상의 대상, 경로, 에이전트별 상태와 할당된 자원을 갖는 방향성 다중 목적지 트리였다. 설정이 먼저 왔고, 데이터 패킷은 트리가 존재한 후에야 이동했다.

이 선택은 작업을 빠른 경로 밖으로 옮겼다. 라우팅은 각 대상 부분집합에 대해 다음 홉을 선택했다. 제안된 HID는 이후 데이터를 위한 짧은 로컬 핸들을 제공했다. 가상 링크 식별자는 제어 메시지를 올바른 상태 머신으로 보냈다. 네트워크 멀티캐스트는 전송된 한 벌이 여러 다음 홉에 도달하도록 할 수 있었지만, 구성원들은 여전히 공통 HID에 합의해야 했다.

스트림의 전역 Name, 브랜치 TargetList, 홉 로컬 HID, 애플리케이션 서비스 접근점은 서로 다른 역할을 했다. 어느 것도 사람 신원이나 권한 부여 토큰이 아니었다. 이 분리 덕분에 빠른 포워딩이 가능했지만, 조사 역시 대응하는 기록을 따로 유지해야만 했다.

요청된 FlowSpec은 트리를 통과하며 바뀌었다

자원 예약은 대역폭보다 넓었다. RFC 1190은 포워딩 상태, 패킷 스위치 처리, 버퍼 공간, 네트워크 용량, 멀티캐스트 그룹 식별자를 나열했다. 그 밑에 하나의 보편적 할당자를 명시하지는 않았다. 문서는 당시 네트워크 중 예약을 제공하는 경우가 드물고, 저자들이 아는 한 전체 집합을 예약하는 네트워크는 없었다고 공개적으로 밝혔다.

FlowSpec은 희망(Desired) 값과 보호되는 한계(Limits)를 담았다. 브랜치가 원하는 것을 모두 제공할 수 없지만 한계 내에 머물 수 있다면, ST 에이전트는 요청을 실제로 얻은 자원으로 갱신했다. 다음CONNECT를 전달하기 전에 희망 대역폭을 낮추거나 지연을 추가하거나 패킷 크기 기대치를 줄일 수 있었다. 중간 및 대상 에이전트는 기점의 최소 수용 한계를 재작성할 수 없었다.

이로써 몇 가지 서로 다른 사실이 남는다: 네트워크가 기술한 용량, 기점이 요청한 자원, 한 에이전트에서 시도된 할당, 한 브랜치에서 얻어진 값, 기점이 넘기를 거부한 하한선. 이 좌표 없이 말하는 "예약됨"은 서비스 주장을 뒷받침하기엔 너무 모호하다.

대상 애플리케이션만이 자신을 위한 답을 할 수 있었다

대상에서 호스트 ST 에이전트는 먼저 HID 협상을 마쳤다. 그런 다음 스트림 Name, FlowSpec, 옵션, 그룹, 애플리케이션 셀렉터를 지정된 프로세스에 제시했다. 프로세스는 수락하거나 거부하거나 원하는 서비스를 축소할 수 있었다. 그 결정 후에야 에이전트는 상류로ACCEPT또는REFUSE를 보냈다.

반환된ACCEPT는 새 참조 번호를 담고 이전CONNECT와 자신을 연결했다. 각 중간 에이전트는 그 관계를 검증하고 즉시 응답을 확인 응답하며 개별ACCEPT를 역방향 경로로 전달했다. FlowSpec은 그 대상을 위해 누적된 결과와 함께 돌아왔다.

이 반환 여정은 의례가 아니었다. 다른 권한 표면을 닫는 일이었다. 경로 함수는 브랜치를 선택했다. 자원 소유자는 무엇을 공급할 수 있는지 결정했다. 포워딩 이웃은 로컬 핸들을 승인했다. 대상 애플리케이션은 참여를 결정했다. 기점은 반환된 조건이 여전히 유용한지를 결정했다. 어떤 행위자도 다섯 가지 결정을 모두 조용히 상속받지 않았다.

하나의 스트림이 여러 답변을 담을 수 있었다

세 대상을 가진 기점은 하나의 전역 수락을 받지 않았다. 각 대상마다ACCEPT,REFUSE또는 오류를 기대했다. 응답이 도착하면서 애플리케이션은 각 경로가 실제로 어떤 자원을 누적했는지 알게 되었다. 설정은 모든 대상이 결과를 만들고 식별자 협상이 끝난 후에야 완료되었다.

답변들은 다루기 어려울 수 있었다. 한 브랜치는 큰 패킷을 낮은 비율로 지원하고, 다른 브랜치는 작은 패킷을 더 높은 비율로 지원할 수 있었다. 기점이 하나의 안전한 조합을 찾지 못할 수도 있었다. 그래서 RFC 1190은 대상을 제거하거나 스트림을 해체하거나 두 번째 스트림을 만드는 것을 허용했다. 이후CHANGE는 매개변수가 조정된 후 초과 예약을 해제할 수 있었다.

그래서 초록불이 켜진 하나의 브랜치가 트리 전체를 대변할 수 없다. 대상 B의ACCEPT는 반환된 FlowSpec 하에서 B로 가는 경로에 대한 근거일 뿐이다. 그것은 C, D, 또는 기점이 아직 선택하지 않은 집계 비율에 대해 최종적으로 아무 말도 하지 않는다.

수락은 결과 이전에 여전히 뒤집힐 수 있었다

반환된ACCEPT조차 상류로의 신뢰할 수 있는 전달이 필요했다. 에이전트가 확인 응답 없이 이를 재전송했다면, RFC 1190은 결국 기점 쪽으로는REFUSE, 대상 쪽으로는DISCONNECT로 대체했다. 더 높은 우선순위의 스트림이 설정 후 자원을 선점할 수 있었다.NOTIFY는 축소된 보장을 보고할 수 있었다. 실패한CHANGE는 부분적으로 변경된 예약을 남기고 복구를 강요할 수 있었다.

프로토콜은 자체적으로 보안 서비스를 제공하지 않았다. 사람을 인증하거나 결제를 승인하거나 애플리케이션의 동의가 기관적 주체로부터 나왔음을 증명하지 않았다. 그리고 그 설정 상태는 이후 패킷이 도착했는지, 음성이 디코딩되었는지, 비디오가 표시되었는지, 참여자가 약속된 품질을 경험했는지를 보여주지 않았다.

따라서 근거 사다리는ACCEPT너머로 계속된다: 확정된 기점 매개변수, 현재 예약 상태, 전송된 패킷, 수신자 관측, 애플리케이션 처리, 사람 또는 기관적 결과. 실험 프로토콜은 앞쪽 단계를 정의했다. 뒤쪽 단계를 폐지하지는 않았다.

개정은 경계를 보존하고 약칭을 제거했다

RFC 1819는RFC Editor및Datatracker기록과 함께 1995년 이 실험을 ST2+로 개정했다. IESG 노트는 두 버전 모두 인터넷 표준이 아니며 그 지위 검토 대상도 아니라고 명시했다.

ST2+는 중요한 사슬을 유지했다: 중간 에이전트가CONNECT를 확인 응답하고, 로컬 자원 관리자에게 묻고, 브랜치 요청을 전달하고, 대상 애플리케이션이 결정하도록 하며,ACCEPT를 기점에 반환했다. 다만 HID는 상호운용성을 가로막는 복잡성 때문에 제거했다. 또한 경험상 허용된 부분집합 구현이 일관되지 않은 기능을 낸다는 것이 드러나자 부분집합 구현도 제거했다.

이 개정은 1990년의 필드를 영원한 사실로 읽는 것에 대한 유용한 경고다. 로컬에서 승인된 식별자는 다음 설계에서 사라질 수 있었지만, 애플리케이션 동의 경계는 남았다. 구현 호환성, 자원 할당, 참여는 별개의 문제였다.

앞선RFC 1077은 고대역폭 네트워킹을 단순한 빠른 미디어 이상으로 규정했다. 이후RFC 1633과RFC 2212는 다른 예약 및 보장 서비스 표면을 정의했다. 유사한 질문이 직접적 계보를 증명하지는 않는다. 물리적 용량, 조건부 서비스 약속, 측정된 결과 사이의 구분을 강화할 뿐이다.

출처