요약

  • RFC 3524는 SDP에SRF를 추가하여, 이름이 지정된 미디어 라인들이 개별 흐름 대신 하나의 공유 자원 예약 흐름을 요청할 수 있게 했다.
  • 그룹핑 라인은 매핑 의도를 전달했다. 허가, 정책 승인, 분류기 및 스케줄러 상태, 갱신 생존, 패킷 처리, 렌더링된 미디어는 여전히 별개의 절차였다.

a=group:SRF 1 2의 매력은 간결함이었다. 두 개의 미디어 서술—오디오와 비디오일 수 있다—를mid값으로 이름 붙여 하나의 Single Reservation Flow 그룹 안에 넣을 수 있었다. 원격 사용자 에이전트는 더 이상 예약을 하나 요청할지 둘 요청할지 추측할 필요가 없었다. 시그널링 문서가 송신자가 요청한 그룹핑을 담고 있었기 때문이다.

그렇다고 SDP가 자원 할당자가 된 것은 아니다. RFC 3524는 서두에서 미디어 스트림과 자원 예약 흐름을 구분했다. 멀티미디어 세션은 모든 스트림을 하나의 예약 흐름에 넣거나, 모든 스트림에 별개의 흐름을 부여하거나, 두 방식을 혼합할 수 있었다. SRF는 그 가능성들 가운데 하나의 관계를 선택했을 뿐이다. 대역폭을 공급하거나, 경로를 선택하거나, 스케줄러를 설정하지 않았다.

규범적 동사들은 이 구분을 유지했다. SRF 그룹 안의 미디어 라인은같은예약 흐름에 매핑되어야(SHOULD) 하고, 그룹 밖의 라인은 그 흐름에 매핑되지 말아야(SHOULD NOT) 했다. 그룹은 심지어 하나의 미디어 라인만 포함할 수도 있었다. 이는 자원 예약 요청을 구성하는 준수 엔드포인트에 대한 지시이지, 네트워크가 하나를 수락했다는 보고가 아니었다.

그룹핑 프레임워크는 주소 지정 메커니즘을 공급했다. 각 미디어 서술에는 고유한mid가 있었고,group라인은 명명된 의미론 아래에서 그 식별자들을 참조했다. 그룹 라인에 나타났다는 이유만으로 해석되지 않은 식별자가 효력을 얻지는 않았다. 이후 RFC 5888이 이 구조를 유지했고, 현대 SDP는 지원되지 않는 속성은 무시한다는 확장 규칙을 계속 따랐다. 따라서 문법은 실제 동작 없이 도착할 수 있었다.

RFC 3524는 원격 측이 예약에 참여해야 할 때 가장 유용했다. 세션 서술 생성자가 양방향을 스스로 할당할 수 있다면 SRF 없이도 매핑을 선택할 수 있었다. 반대로 원격 측이 group 라인 없이 동일한 오디오·비디오 라인을 받으면, 두 개의 서로 다른 RSVP 세션을 자유롭게 만들 수 있었다. 이 토큰은 하나의 선택을 국지화했을 뿐, 자원 절차의 나머지를 중앙화하지 않았다.

예제에는 SIP와 RSVP가 등장했지만, 문서는 다른 시그널링 및 예약 메커니즘도 명시적으로 허용했다. 이것은 역사적으로 중요하다. SRF는 서술 계층에 속했다. 어떤 기계 장치가 그것을 실현하려 시도할지는 구현이 선택했다.

RSVP는 얼마나 많은 절차가 남아 있었는지 보여 준다. 수신자는 원하는 QoS에 대한 flowspec과 패킷을 선택하는 filter spec을 담은Resv를 보냈다. 참여하는 모든 노드에서 허가 제어는 충분한 자원이 있는지 물었고, 정책 제어는 별도로 요청이 허용되는지 물었다. 어느 한 검사라도 실패하면 요청된 상태는 그 노드에 설치되지 않았다. 성공한 후에야 패킷 분류기와 스케줄러를 프로그래밍할 수 있었다.

성공조차 시간적인 것이었다. RSVP는 Path와 Resv 갱신을 통해 소프트 상태를 유지했다. 경로가 바뀌면 새 경로를 따라 상태가 만들어지는 동안 이전 경로의 미사용 상태는 만료될 수 있었다. 그룹핑 라인은 그러한 전환을 알지 못했다. 자원 경로가 그 아래에서 사라진 뒤에도 바이트 단위로 유효하게 남아 있을 수 있었다.

RFC 2205는 이 증거상의 한계를 더 선명하게 만들었다.ResvConf의 수신은 어떤 보장도 주지 않는다. 확인 메시지는 어느 한 지점에서 생성된 뒤, 이후 경쟁이나 병합이 결과를 바꾸면서 예약 오류로 이어질 수 있었다. 예약 프로토콜의 확인조차 한계가 있다면, 그 이전의 SDP 그룹핑 선언을 서비스 증명으로 다루는 것은 무리한 일이었다.

RFC 3312는 현재와 원하는 QoS 사전조건이라는 별도의 어휘를 도입했다. 원하는 상태를 서술하는 것만으로 그것이 현재가 된다면, 이 설계는 필요하지 않았을 것이다. SRF 그룹은 "어떤 미디어가 하나의 예약을 공유해야 하는가?"에 답했다. "필요한 예약이 각 방향에서 수립되었는가?"에는 답하지 않았다.

보안 절은 제어 지점을 드러낸다. SRF 라인을 삽입한 공격자는 엔드포인트가 필요보다 많거나 적은 예약 흐름을 만들도록 강제할 수 있었다. 너무 많으면 엔드포인트 자원을 소모하고, 너무 적으면 세션 품질이 저하될 수 있었다. 따라서 무결성 보호가 강력히 권장되었고, SIP로 전달되는 SDP에는 S/MIME이 지명되었다.

무결성은 저자십 문제를 해결했다. 그룹핑 지시가 변경되지 않았음을 보여 줄 수 있었다. 그러나 무료 용량을 만들거나, 정책 승인을 강제하거나, 미지원 엔드포인트를 수리하거나, RSVP 소프트 상태를 갱신된 채 유지하거나, 패킷이 필터에 맞도록 하거나, 디코더가 유용한 오디오와 비디오를 렌더링했음을 증명하지는 못했다.

SRF의 IANA 등록은 또 하나의 좁은 역할을 수행했다. 구현들에게 하나의 공유 토큰과 참조를 제공한 것이다. 레지스트리는 살아 있는 오퍼, 수락된 매핑, 설치된 예약 중 어떤 것도 관찰하지 않았다. 공표는 의미를 조율했고, 채택과 실행은 코드를 돌리는 참여자들에게 남았다.

이것이 RFC 3524에 남는 지속적인 역사다. 얇은 공유 표현식이 독립적인 엔드포인트들이 자원 회계 선택을 조율하게 하되, 그 표현식이 네트워크를 소유한다는 환상 없이 말이다. 운영자는 다음 영수증 사다리를 순서대로 보존해야 한다: 유효한 SDP, 해석된 멤버십, 인증된 의도, 선택된 예약 매핑, 요청 전송, 홉별 허가, 설치된 상태, 갱신 생존, 분류된 패킷, 관찰된 미디어. 이들을 "SRF 존재" 하나로 접어 버리면 유용한 설계 힌트가 허구의 용량으로 변한다.

출처