서비스에 이름이 있었다. 그 이름은 거의 아무것도 증명하지 못했다: RFC 2216

요약

• RFC 2216은 '서비스'를 애플리케이션이 경험하는 종단 간 결과가 아니라 단일 네트워크 요소의 조율된 동작으로 정의했다.
• 이 템플릿은 작성자에게 호출 데이터, 트래픽 적합성, 폴리싱, 내보내는 증거, 순서 지정 및 병합 규칙을 공개하도록 요구했기 때문에, 이름이나 승인된 요청이 실행 증거를 대신할 수 없었다.
• 내구성 있는 증거 사슬은 명세에서 시작해 요청, 입장 허가, 적합성, 설치된 동작, 경로 조합, 전달, 애플리케이션 결과로 이어진다. 앞선 기록만으로 다음 단계를 증명하지 못한다.

번호는 계약을 식별할 수는 있어도 수행할 수는 없다

RFC 2216에서 가장 매력적인 부분은 숫자 네임스페이스다. 공개 사용을 위해 정의된 서비스는 정해진 형식을 따르는 RFC가 발행된 후에야 IETF 범위의 번호를 받을 수 있었다. 파라미터에도 번호가 부여되어, 설정 프로토콜·라우터·관리 시스템이 교환할 수 있는 두 단계의service.parameter이름이 만들어졌다.

이는 제도적 완성처럼 들린다. 이름이 배정되고, 대상이 인식되고, 상호운용성이 달성된 것이다. 그러나 RFC 2216은 오히려 명명을 책임의 시작점으로 만들었다. 번호는 올바른 의미적 계약의 위치를 알려줄 뿐이다. 특정 라우터가 그 계약을 구현했는지, 호출자가 이를 호출할 권한이 있는지, 자원이 입장 허가를 받았는지, 패킷이 약속된 처리를 받았는지는 보여주지 않는다.

이 구분은 문서의 이례적으로 좁은 서비스 정의에 근거한다. 서비스는 라우터, 서브넷 또는 단말 시스템 구성 요소 같은 단일 네트워크 요소가 제공하는 명명된 품질보장(QoS) 기능 집합이었다. '동작(behavior)'은 다른 것이었다. 즉, 경로상의 모든 요소의 서비스가 조합된 이후 애플리케이션이 보는 종단 간 성능이었다. 서비스들이 섞인 경로나 QoS 제어가 없는 요소를 포함한 경로는 특징을 기술하기 어렵거나 정의되지 않은 동작을 낳을 수 있었다.

따라서 '서비스'라는 단어는 요소 경계에서 멈춘다. 애플리케이션의 결과는 그 위에 있다.

템플릿은 기계에 대한 공개 체제였다

RFC 2216은 하나의 스케줄러를 강제하지 않았고 새로운 하나의 약속을 발명하지도 않았다. 대신 진지한 약속이 공개해야 할 사항을 정했다. 적합한 서비스 명세에는 종단 간 동작과 동기 부여에 대한 필수 섹션이 필요했지만, 규범적 핵심은 다른 곳에 있었다. 네트워크 요소의 데이터 처리, 호출 정보, 내보내는 정보, 폴리싱, 그리고 순서 지정과 병합이 그것이다. 평가 기준도 필수였으며, 구현 지침과 예시는 선택 사항이었다.

패킷 처리 섹션은 요소가 어떤 변수를 얼마나 강하게 제어하는지, 그리고 그 주장이 어떤 가정에 의존하는지를 명시해야 했다. 요구 사항은 수학적 상한일 수도, 대부분의 조건에서 기대되는 목표일 수도 있었다. 명세는 모든 구현을 하나의 스케줄링 알고리즘에 묶지 않으면서 최대 지연이나 최소 대역폭 점유율 같은 성능을 표현하도록 권장되었다.

이 선택은 지역 공학 자유를 보존하면서 공개 주장을 검증 가능하게 만들었다. 두 구현은 서로 다른 내부 경로를 택하면서도 동일한 외부 의무에 대해 평가될 수 있었다. 반대로 동일한 제품 라벨이 두 구현을 동등하게 만들지는 않았다. 하나가 정의된 동작을 충족하지 못하면 그렇지 않았다.

데이터 계약도 마찬가지로 명시적이었다. 서비스 모듈이 수입하거나 내보내는 모든 수량은 유형, 범위, 정밀도를 명시해야 했다. 선호하는 패킷 형식이 권장되었지만, 공통의 추상적 의미가 모든 운반 프로토콜에 동일한 구체적 표현을 요구하지는 않았다. 의미와 와이어 인코딩은 연관된 별개의 기록이었다.

호출자는 서로 다른 두 개체를 가져왔다

호출 정보는 일반적으로 트래픽 명세(TSpec)와 서비스 요청 명세(RSpec)로 나뉜다. TSpec은 서비스를 구하려는 트래픽 패턴을 기술하고, RSpec은 요소에 요청하는 품질을 기술한다. RFC 2216은 서로 다른 주체가 이를 생성할 수 있으므로 별도로 명시하도록 요구했다.

승인은 조건부 계약을 형성했다. 요소는 흐름이 TSpec으로 정확히 기술되는 동안 RSpec의 서비스를 제공하기로 합의한다. TSpec은 실제 트래픽의 측정이 아니라 허용 트래픽을 표현한다. 따라서 문법적으로 유효한 TSpec은 호출자가 선언한 내용만 증명한다. 흐름이 적합한지는 관찰만이 확립할 수 있다.

이 간극은 폴리싱을 서비스 명세로 강제했다. 작성자는 부적합 패킷의 처우를 말해야 했다. 폐기, 지연, 표시 또는 최선 노력(best effort)으로 강등될 수 있었다. 또한 대체 조치가 적법한지, 그리고 폴리싱이 어디에서 일어나는지 — 가장자리에서만, 매 홉마다, 멀티캐스트 분기점에서, 또는 출발지가 병합되는 지점에서 — 를 밝혀야 했다.

위치가 중요한 이유는 트래픽이 네트워크를 통과하며 더 버스티(bursty)해질 수 있기 때문이다. 경로 내부에서 원래의 가장자리 TSpec을 적용하면 진입 시점에는 적합했던 트래픽을 처벌할 수 있었다. 따라서 유효한 폴리싱 이벤트는 '패킷이 프로필을 초과했다' 이상을 요구했다. 프로필 버전, 관찰 지점, 토폴로지상의 역할, 경로 이력, 그리고 봉투(envelope)를 갱신하는 명세의 규칙이 필요했다.

신호 전달은 주장을 운반했을 뿐, 주장이 되지 않았다

서비스 모듈은 설정·라우팅·관리 시스템에 개념적 인터페이스를 노출했다. 그러나 RFC 2216은 명확한 아키텍처 선을 그었다. 서비스 정의는 상태를 설정하는 데 쓰이는 프로토콜을 지정하지 않는다는 것이었다.RSVP, ST-II, 관리 프로토콜 또는 다른 메커니즘이 호출 데이터를 운반할 수 있었다. 서비스 명세는 파라미터의 운반과 요소가 생성한 오류의 전달을 요구할 수는 있었지만, 설정 프로토콜에 무관한 의무를 몰래 부여할 수는 없었다.

이 구분이 RSVP 객체, 구성 기록, 성공적인 API 응답이 불완전한 증거인 이유를 설명한다. 그것은 특정 바이트가 제어 표면에 도달했음을 증명할 수 있다. 그러나 그것만으로 모든 요소가 자원을 입장 허가했는지, 설치된 요청이 병합 후 원래 요청과 일치했는지, 패킷이 적합했는지, 포워딩 경로가 약속된 동작을 전달했는지 증명할 수 없다.RFC 2210은 Integrated Services 객체가 RSVP를 통해 이동하는 방식을 정의했고, RFC 2216은 서비스가 여전히 답해야 하는 독립적인 의미론적 질문을 정의했다.

동일한 규율이 내보내는 정보에도 적용되었다. 모듈은 예약된 대역폭, 활성 흐름, 또는 경로를 추정하는 데 쓰인 특성화(characterization) 파라미터를 보고할 수 있었다. 각 특성화에는 조합 함수(composition function)가 필요했다. 결과는 요소가 조합되는 순서에 의존해서는 안 되었다. 어떤 요소가 필요한 파라미터를 제공할 수 없다면 유효성 플래그를 설정하고 하류로 보존해야 했다. 이후의 유능한 요소가 이전 증거 구멍을 지울 수는 없었다.

완전히 채워진 특성화조차 조건부였다. RFC 2216은 설정이나 라우팅 메커니즘이 이를 단말 시스템에 사용할 수 있게 한다는 절대적 보장은 없다고 밝혔다. 서비스는 그것 없이도 유용할 수도, 그것 없이 오해를 낳을 수도 있었다. 어느 쪽이 참인지 작성자가 말해야 했다.

병합은 새로운 결정이지 서류 압축이 아니었다

여러 요청이 같은 흐름을 덮을 수 있었다. 여러 멀티캐스트 수신자가 서로 다른 처리를 요청할 수도 있고, 고정 구성이 동적 요청과 만날 수도 있었다. 그 기록들을 하나의 설치된 요청으로 접는 것은 데이터베이스 중복 제거가 아니었다. 이는 요소가 보는 계약, 때로는 상류로 보내지는 정보를 바꾸었다.

따라서 RFC 2216은 다섯 가지 연산을 요구했다. 순서 지정(ordering)은 TSpec과 RSpec을 비교한다. 합산(summation)은 여러 흐름에 충분한 요청을 만든다. 최소(minimum)는 요청된 트래픽 기술을 관찰되거나 적용 가능한 기술과 조정한다. RSVP 병합은 지역 호출과 적절한 상류 파라미터를 함께 만든다. 최소 공통 요청(least common request)은 RSVP 고유의 동작 전체를 재현하지 않으면서 모든 입력만큼은 유능한 요청을 찾는다.

순서는 부분적일 수 있다. 일부 요청은 비교 불가능할 수 있다. 상한은 최소 상한일 필요가 없었고, 서로 다른 요소가 서로 다른 적합한 상한을 선택할 수 있었다. 한 파라미터는 가장 큰 분기 값을 안전하게 취할 수 있었지만, 다른 파라미터 — 최대 패킷 크기 같은 — 는 모든 분기에서 수용 가능한 가장 덜 공격적인 값을 선택해야 했다.

이는 유효한 설치된 요청을 출처가 있는 파생적 결정으로 만든다. 감사하려면 입력 요청, 서비스별 비교 관계, 병합 함수, 분기 맥락, 상류로 전달된 출력이 필요하다. 장치에서 '서비스 2 활성'을 발견하는 것만으로는 충분하지 않다.

템플릿을 둘러싼 예시들은 그 한계를 증명한다

다른 Integrated Services 문서들은 템플릿이 왜 중요했는지 보여주지만, 이 글의 주제가 되지는 않는다.RFC 2211은 Controlled-Load 서비스를 정성적 언어로 정의했다.RFC 2212는 계산 가능한 Guaranteed Service 상한을 명세했다.RFC 2213과RFC 2214는 Integrated Services와 RSVP를 위한 관리 객체를 노출했다.RFC 2215는 공유 특성화 파라미터를 제공했다.

각각은 서로 다른 계층을 점유했다. 서비스 명세는 의미를 정의한다. 설정 프로토콜은 요청을 운반한다. 구현은 패킷을 스케줄링한다. MIB는 선택된 상태를 노출한다. 측정은 어떤 결과를 관찰한다. 어느 하나도 다른 모든 것을 대행할 수 없다.

RFC 2216의 평가 섹션은 이 경계를 명시했다. 그 테스트는 고립된 단일 네트워크 요소를 위한 것으로, 구현의 트레이드오프를 비교하는 데 유용했다. 실제 운영 사용자들은 종단 간 동작을 신경 썼고, 그것은 링크, 설정 프로토콜, 다른 요소에도 의존했다. 템플릿은 표준화된 종단 간 측정 도구를 정의하지 않았다.

따라서 증거 사다리는 이름보다 길다.

1. 발행된 명세와 그 지위;
2. 서비스 및 파라미터 식별자;
3. 요청자와 그 권한;
4. 출처가 있는 TSpec과 RSpec 값;
5. 설정 프로토콜의 운반과 반환된 오류;
6. 요소별 입장 허가와 자원 에포크(epoch);
7. 실제 적합성과 폴리싱 조치;
8. 설치된 처리와 병합 결정;
9. 특성화 값과 유효성 플래그;
10. 경로 연속성과 패킷 관찰;
11. 애플리케이션 처리와 사용자 결과.

모든 단계는 다음 단계를 뒷받침할 수 있다. 그러나 어느 단계도 그것을 관찰해야 할 필요를 없애지 않는다.

이곳이 바로런닝 코드 우선주의의 편집 렌즈가 유용한 지점이다. 발행은 최소 상호운용 가능한 계약을 정의할 수 있다. 그러나 지역 구현과 운영자는 입장 허가, 스케줄링, 폴리싱에 대해 제한된 결정을 내린다. 호환되는 시스템이 그 계약을 구현하고 사용할 때 비로소 채택이 운영화된다. 이는 증거 경계에 대한 해석이며, RFC 2216이 이후 거버넌스 결과를 일으켰다는 주장이 아니다.

RFC 2216의 지속적 성과는 서비스 이름을 권위적으로 만든 것이 아니었다. 이름의 권위를 작게 만든 것이다. 번호는 규율된 명세를 가리켰다. 명세 위의 세계는 여전히 자신만의 증명을 만들어야 했다.

출처와 한계

1차 출처는RFC 2216이며, 아키텍처적 맥락은RFC 1633과 위에 링크된 인접 프로토콜 및 서비스 명세에서 나온다. 이 문서들은 1997년의 명세 아키텍처를 확립한다. 그러나 배포 보급률, 특정 라우터의 동작, 현재의 예약, 측정된 성능, 패킷 전달 또는 애플리케이션 성공은 확립하지 않는다.

RFC Editor 기록과IETF Datatracker 기록은 발행 지위를 고정한다.최소 초기 명세에 대한 편집 렌즈는 공통 계약과 이후의 구현·채택·사용 사이의 경계를 정밀하게 조명한다.