요약

  • RFC 9938은 흐름 요청을 수신하고, 실현 가능한 경로를 계산하고, 최적 경로를 선택하고, 자원을 예약하고, 홉별 동작을 설치할 수 있는 DetNet 컨트롤러 플레인(제어 평면)을 기술한다. '최적'은 결코 스스로 정의되지 않는다. 지연, 손실, 지터, 대역폭, 보호, 공동 위험, 도메인, 공존 제약에 대해 권한을 부여받은 순위 체계에 따라 달라진다.
  • 부족한 근거는 '제약 소유권 영수증'이다. 민감한 토폴로지, 일정, 흐름 목적을 노출하지 않으면서, 요청과 버전화된 목표를 이 트레이드오프의 순위를 매길 수 있는 행위자, 각 도메인이 약속한 자원, 계산 스냅샷, 모니터링 트리거, 예외 만료, 해제 담당자와 묶는 것이다.

결정은 솔버가 시작되기 전에 이루어진다

컨트롤러가 두 개의 경로를 반환하는 상상을 해보자. 두 경로 모두 요청된 최대 지연을 충족한다. 하나는 대역폭을 덜 사용하지만 기존 보호 흐름과 위험 그룹을 공유한다. 다른 하나는 더 많은 버퍼를 소비하면서 이중화된 분리 경로를 추가로 예약하지만, 일반 트래픽에 남는 용량은 줄어든다. 컨트롤러는 지표를 비교하고, 실현 불가능한 후보를 기각하고, 선택된 동작을 인상적인 정밀도로 설치할 수 있다.

그러나 지표만으로는 자신이 어떤 희생을 할 수 있도록 승인받았는지 알아낼 수 없다.

그것이 '최적 경로'라는 표현 속의 숨은 단계다. 최적화는 계산으로 끝나기 때문에 수학적 행위처럼 보인다. 그러나 계산 전에 누군가 목표를 정하고, 경성 한계와 선호를 구분하며, 가중치를 부여하고, 누구의 용량을 소비할 수 있는지 결정하고, 모든 조건을 만족하는 후보가 없을 때 무엇을 할지 정해야 한다. 솔버는 그 선택을 실행할 수 있다. 그 선택에 정당성을 부여할 수는 없다.

RFC 9938은 이 경계를 유난히 뚜렷하게 보여준다. 이 문서는 결정적 네트워킹(Deterministic Networking) 컨트롤러 플레인을 위한 프레임워크를 기술한다. 요구 사항을 정리하고, 훗날의 프로토콜 솔루션을 지원할 수 있는 분산형·중앙집중형·하이브리드 아키텍처를 개관한다. 이는 표준 트랙 프로토콜 사양이 아니라 정보(Informational) 문서이며, 솔루션 세부사항을 미래의 작업에 명시적으로 남겨둔다.

그 범위 안에서 컨트롤러 플레인은 실질적인 일을 한다. 흐름을 생성·수정·삭제하고, 명시적 경로를 결정하고, 대역폭·버퍼 등 노드 자원을 예약하고, 큐잉 규율을 배치하고, 복제·제거·순서 지정을 구성하고, 레이블을 배포하고, 토폴로지와 역량을 학습하고, 결과 서비스가 목표를 충족하는지 모니터링할 수 있다. 요청은 애플리케이션, 정적 프로비저닝, SDN 컨트롤러 또는 분산 시그널링 프로세스에서 올 수 있다.

이것들은 사무적 행위가 아니다. 요청된 서비스를 공유 네트워크에 대한 독점적 혹은 희소한 자원 클레임으로 변환한다. 아키텍처는 그 변환이 어떻게 일어나는지는 기술할 수 있지만, 모든 기관의 권한 모델을 정하지 않는다. 거버넌스 오류는 아키텍처가 요청을 전달할 수 있다는 사실을, 요청자가 트레이드오프를 정의할 자격이 있었다는 증명으로 취급하는 것이다.

서비스 요청은 아직 목적 함수가 아니다

RFC 9938의 중앙집중형 예시는 깔끔하다. 컨트롤러가 토폴로지 정보와 DetNet 역량을 수집하고, 흐름 설정 요청을 받고, 하나 이상의 유효한 경로를 계산하고, 최적 경로를 선택하고, 경로상의 장치들을 구성한다. 각 동사는 운영적으로 이해 가능하다. 간극은 '요청'과 '최적' 사이에 있다.

애플리케이션은 최대 종단 간 지연, 손실 상한, 제한된 지연 편차, 특정 대역폭이 필요하다고 진술할 수 있다. RFC 9016은 흐름과 서비스 정보를 기술하는 방법을 제공한다. RFC 9938은 트래픽 사양이 평균이 아니라 최악의 경우라는 점을 언급한다. 이러한 입력은 컨트롤러가 실현 가능성을 검증하는 데 도움을 준다. 그러나 요청된 값들이 계약상 구속력 있는 것인지, 엔지니어링 선호인지, 진단적 희망인지, 우연히 남은 오래된 기본값인지는 말해주지 않는다.

이 구분이 경로를 바꾼다. 경성 지연 상한은 더 길지만 더 안전한 경로를 배제할 수 있다. 소프트 지연 선호는 더 나은 장애 격리에 양보할 수 있다. 보호 요구는 여러 경로에 걸쳐 패킷 복제를 유발해 다른 흐름이 쓸 수 있었던 자원을 소비할 수 있다. 재정렬 금지 제약은 추가 버퍼링이나 순서 지정 기능을 요구할 수 있다. 요청된 유효 구간은 영구 예약을 임시 예약으로 바꿀 수 있다.

정확한 모델조차 잘못된 위임을 담을 수 있다. YANG은 의도된 상태를 인코딩할 수 있다. NETCONF나 PCE 기반 제어가 그것을 설치할 수 있다. BGP-LS는 토폴로지와 역량 정보를 제공할 수 있다. 그 어떤 프로토콜도 값을 선택한 사람이나 시스템이 네트워크를 그 값에 구속할 권한이 있었는지 추론할 수 없다.

질문은 API 호출자가 좁은 보안 의미에서 인증되었는지가 아니다. 인증은 자격 증명이 인식된 주체에 속함을 보여줄 수 있다. 권한 부여는 주체가 특정 등급의 작업을 호출할 수 있음을 보여줄 수 있다. 더 어려운 질문은 그 특정 작업이 결정 위임 내에 머무는지 여부다: 이 서비스, 이 제약, 이 자원 상한, 이 도메인, 이 구간, 이 대체 규칙.

그 연결이 없으면 '요청 수락됨'이 '트레이드오프 승인됨'의 대체물이 될 수 있다.

예약된 용량은 선호를 분배적 문제로 만든다

일반적인 경로 선택은 단순한 이야기를 부른다: 최저 비용을 찾아 전달하라. DetNet의 약속은 더 까다롭다. 포워딩 계층은 대역폭과 버퍼를 예약하고, 명시적 경로를 사용하고, 큐를 구성하고, 서비스 보호를 추가할 수 있다. RFC 8938은 '최선' 경로가 최대 대역폭, 최소 지터 또는 지표의 조합으로 최적화될 수 있으며 최단 경로일 필요는 없다고 말한다.

컨트롤러가 자원을 예약하는 순간 경로 선호는 분배적이 된다. 선택된 흐름은 다른 흐름이 가정할 수 없는 보호된 기회를 얻는다. 복제는 여러 경로의 용량을 소비할 수 있다. 버퍼 할당은 다른 트래픽에 남는 여유에 영향을 줄 수 있다. 해제가 이루어졌어야 할 시점 이후에도 오래된 예약을 유지하면 새 흐름의 수용이 막힐 수 있다.

RFC 8655는 공유 환경을 인정한다. DetNet 도메인은 대역폭의 높은 비율을 결정적 흐름에 할애할 수 있지만, 스케줄링은 비(非)DetNet 트래픽에 충분한 기회를 남겨야 하며 기아 상태를 피해야 한다. 사용하지 않는 DetNet 기회는 일반 패킷에 사용 가능할 수 있지만, 반드시 다른 DetNet 흐름이 청구할 수 있는 용량이 되는 것은 아니다. 경계는 기술적으로도 미묘하고 기관적으로도 중요하다.

그렇기에 '최적'은 선택된 애플리케이션 이상에 대한 진술이다. 네트워크가 다른 결정적 서비스와 비DetNet 트래픽을 어떻게 평가하는지도 말해준다. 한 요청자에게 이상적인 경로가, 상위 우선순위 목적을 위해 예약된 보호 구간을 소비하거나, 승인 없이 트래픽을 이중화하거나, 일반 트래픽 클래스를 인정된 서비스 하한선 이하로 밀어낸다면 좋은 기관적 선택이 아닐 수 있다.

컨트롤러에게는 제약이 필요하다. 운영자에게는 누가 그 제약을 소유했는지에 대한 근거가 필요하다.

세 가지 아키텍처는 같은 질문을 제거하지 않는다

RFC 9938은 분산형, 완전 중앙집중형, 하이브리드 컨트롤러 플레인을 제시한다. 어느 하나가 항상 우월하다고 주장하지 않는다. 각 아키텍처는 계산, 시그널링, 구성을 다르게 배치한다.

분산형에서는 진입 노드와 네트워크 노드가 정보를 교환하고, 시그널링이 경로와 예약을 설정할 수 있다. 전체 결정을 보는 단일 장치가 없을 수 있다. 그렇다고 책임 소재가 사라지는 것은 아니며, 위임이 조합적(compositional)이 된다는 뜻이다. 개시 요청, 각 노드의 로컬 수용 결정, 그 결과인 종단 간 상태는 여전히 연결되어 있어야 한다.

완전 중앙집중형에서는 하나의 컨트롤러가 토폴로지를 수집하고 후보를 계산하고 노드를 구성할 수 있다. 감사 추적은 하나의 논리적 지점을 통과하므로 단순해 보일 수 있다. 그러나 집중은 자체적인 모호성을 만든다. 모든 노드를 구성할 기술적 권한을 가진 컨트롤러는 여러 애플리케이션 소유자와 서비스 클래스를 담당할 수 있다. 그 광범위한 자격 증명은 자신이 받는 모든 목표가 동등한 우선순위나 무제한의 자원 권한을 갖는다는 증거가 아니다.

하이브리드에서는 컨트롤러가 경로 정보를 계산·배포하고 RSVP-TE 등 다른 프로토콜이 시그널링과 예약을 수행할 수 있다. 이제 뒤늦게 검토하는 이는 유효한 계산과 유효한 시그널링 교환을 보고도 두 가지가 동일한 제약 버전에 근거했는지 알 수 없을 수 있다. 계산과 수용 사이의 토폴로지 갱신은 이전 후보 집합을 낡게 만들 수 있다. 로컬 노드는 중앙 기록이 보존하지 않는 이유로 예약을 거부하거나 변경할 수 있다.

아키텍처는 근거가 생산되는 지점을 옮길 뿐, 권한의 질문을 없애지 않는다.

도메인을 넘으면 약속이 곱해진다

RFC 9938의 다중 도메인 절은 짧지만 시사하는 바가 크다. 흐름 관리 개체(Flow Management 주체)의 요청을 흐름별·홉별 동작으로 번역하기 위해 여러 컨트롤러 플레인 기능이 협력해야 할 수 있다. 다른 도메인의 컨트롤러들은 서로를 발견하고 인증하고 동작을 협상할 수 있다. 애플리케이션 플레인 자체가 책임을 도메인들 사이에 나눌 수 있다.

이것은 협력의 메커니즘이다. 아직 약속(commitment)에 대한 완전한 설명은 아니다.

도메인은 피어 컨트롤러를 인증하고도 그 피어가 무엇을 요청할 권한이 있는지 알아야 할 수 있다. 홉별 동작을 협상하고도 유효 구간, 용량 상한, 해제 규칙을 알아야 할 수 있다. 로컬 구간을 수용하면서도 원시 토폴로지나 내부 스케줄링을 노출하는 것은 거부할 수 있다. 다른 도메인은 자기 구간을 정확히 수행하면서도 경계 조건이 정렬되지 않아 종단 간 약속이 실패할 수 있다.

따라서 유용한 근거는 하나의 전역 경로 덤프도, 서로 호환되지 않는 아홉 개의 로컬 티켓도 아니다. 조합 가능한 약속들의 집합이다. 각 도메인은 자신이 수용한 제약 부분집합, 예약한 자원 등급, 시간 창, 로컬 모니터링 조건, 예약을 해제하는 사건을 증명할 수 있어야 한다. 종단 간 검토자는 정확한 내부 경로를 알지 못한 채로도 이 약속들이 연속적인 서비스를 이루는지 검증할 수 있어야 한다.

이 분리는 자율성과 정정 모두에서 중요하다. 도메인은 조건이 바뀌면 약속을 철회하거나 수정할 수 있다. 그러면 종단 간 결정은 재평가가 필요하다. 다른 경로를 조용히 대체하면 패킷 전달은 유지되면서, 원래 서비스 소유자가 경성이라 여겼던 공동 위험, 지연 또는 관할 제약을 위반할 수 있다.

인증은 '이것이 진짜 그 피어인가?'에 답한다. 약속 기록은 '그 피어가 누구를 위해, 어떤 한도 아래, 언제까지 무엇을 하기로 합의했는가?'에 답한다.

보안은 정당해 보이는 초과 행위를 가능하게 만든다

RFC 9055는 컨트롤러 무결성이 왜 중요한지 보여준다. 제어 패킷의 수정과 주입은 경로와 자원 할당을 조작할 수 있다. 침해된 컨트롤러는 노드들에게 정당해 보이며 자신이 명령을 발행할 권한이 있다고 믿게 만들 수 있다. 위조된 컨트롤러 메시지는 대역폭을 바꾸고, 종단점을 추가·제거하고, 흐름을 삭제하거나, 자원을 고갈시키는 가짜 예약을 만들 수 있다. 해제 지연은 새 흐름이 수용되지 않을 때까지 용량을 누출시킬 수 있다.

자명한 대응은 강력한 인증, 무결성 보호, 신중한 시스템 설계다. 이 통제들은 불가결하다. 그러나 여전히 위임 근거보다는 작다.

진짜이고, 현재 유효하며, 침해되지 않은 컨트롤러 자격 증명을 생각해보자. 컨트롤러가 인식된 서비스를 위한 자원 예약 명령을 통사적으로 유효하게 발행한다. 모든 보안 검사를 통과한다. 그럼에도 그 명령은 정책 밖일 수 있다. 요청된 대역폭이 해당 서비스의 상한을 초과했거나, 보호 모드가 승인되지 않았거나, 시간 창이 만료되었거나, 경로가 요청자가 구속할 수 없는 도메인을 지나기 때문이다.

이것을 인증 실패라고 부르면 해결책이 흐려진다. 자격 증명을 교체해도 낡은 목표는 고쳐지지 않는다. 계산 실패라고 부르는 것도, 솔버가 받은 입력을 충실히 최적화했다면 마찬가지로 오해를 낳는다. 실패는 그 시스템이 실질적인 제약을 누가 소유했는지, 명령이 그 소유권 경계 안에 있었는지를 재구성할 수 없다는 것이다.

반대로 모든 토폴로지 에지, 일정, 종단점, 산업 목적을 저장하는 감사 시스템은 정찰 자산이 된다. RFC 9055는 흐름 수, 대역폭, 타이밍에 대한 지식이 공격자에게 도움이 될 수 있음을 지적한다. 거버넌스 기록은 민감한 운영 지도를 재현하지 않으면서 결정이 승인되었음을 보여야 한다.

모니터링은 결정 후의 판정이 아니라 결정의 일부다

RFC 9938은 성능과 장애 관측을 컨트롤러 플레인의 관리 측에 배정한다. 능동 측정과 수동 측정의 구분은 실질적이다. 능동 OAM은 트래픽을 주입하며 그 자체로 지연과 처리량에 영향을 줄 수 있으므로, 프레임워크는 일반 운영에 능동 방식을 권장하지 않고 운영 도메인에서는 수동 모니터링을 선호한다.

즉 '최적' 경로는 근거 방법에 조건 지어진다. 수동 측정으로 계산된 경로는 능동 테스트로 위탁된 경로와 다른 신선도와 신뢰도 가정을 사용할 수 있다. 컨트롤러는 완전한 구성 상태를 갖고도 성능 근거는 늦을 수 있다. 어떤 지표는 기술적으로 유효하더라도 안전이 중요한 재할당에는 너무 오래되었을 수 있다.

따라서 모니터링은 그것에 의존하는 제약과 묶여야 한다. 경성 목표가 종단 간 지연이라면, 기록은 측정 창, 집계 규칙, 신선도 한계를 명명해야 한다. 서비스가 분리 경로에 의존한다면 시스템은 공동 위험 근거의 변화를 추적해야 한다. 예외가 일시적으로 축소된 보호를 허용한다면, 만료는 대시보드 경고가 아니라 새 결정을 유발해야 한다.

컨트롤러는 전지(全知)를 약속할 필요가 없다. 승인된 행위자가 재사용, 재계산, 성능 저하 중 무엇이 정당한지 결정할 수 있을 만큼 자신의 지식 상태를 가시화하면 된다.

경로 계산이 증명하는 것

재현 가능한 계산은 유용한 것들을 증명할 수 있다. 명시된 토폴로지/역량 스냅샷, 특정 제약 집합, 이름이 주어진 알고리즘 버전이 주어지면, 어떤 후보가 실현 가능하다고 간주되었는지, 어떤 지표가 계산되었는지, 왜 한 후보가 1순위였는지 보여줄 수 있다. 설치 근거는 노드들이 해당 구성을 받았음을 보여줄 수 있다. OAM은 관측 구간 동안 서비스가 어떻게 동작했는지 보여줄 수 있다.

그러나 그 근거만으로는 다음을 증명할 수 없다:

  • 요청자가 서비스 목표를 소유했는지;
  • 목표 버전이 최신이었는지;
  • 소프트 선호가 실수로 경성 한계로 취급되지 않았는지;
  • 선택된 경로의 자원 비용이 승인된 상한 안이었는지;
  • 복제나 버퍼 소비가 정당화되었는지;
  • 비DetNet 공존 규칙이 정책 안에 유지되었는지;
  • 참여한 모든 도메인이 동일한 종단 간 의미를 수용했는지;
  • 장애 모드 완화에 소유자와 만료가 있었는지;
  • 위임이 끝났을 때 예약이 해제되었는지.

이것들은 계산을 불신하라는 이유가 아니다. 계산에게 입력 이외의 사실을 증명하라고 요구하지 말라는 이유다.

제약 소유권 영수증

빠져 있는 동반 기록은 간결할 수 있다. 민감한 페이로드 대신 흐름 요청의 안정적인 다이제스트로 시작한다. 요청자 역할, 서비스 소유자, 흐름 관리 개체 경계, 요청된 유효 구간을 기록하고, 그 식별성을 버전화된 제약 집합에 묶는다.

각 제약마다 출처와 상태를 기록한다. 최대 지연은 경성 서비스 약속인가, 계획 목표인가, 모니터링 트리거인가? 경로 분리성은 필수인가, 선호인가, 일시 면제인가? 대역폭은 피크 최악의 경우 예약인가, 관측된 평균인가? 어떤 공존 하한이 비DetNet 트래픽을 보호하는가? 솔버가 필드 이름으로 그 구분을 추론해야 해서는 안 된다.

다음으로 결정 권한을 명명한다. 기록은 누가 소프트 제약의 순위를 매기고, 자원 상한을 승인하고, 저하된 모드를 수용하고, 추가 도메인을 약속하고, 해제를 명령할 수 있는지 보여야 한다. 권한은 전능한 컨트롤러 자격 증명에서 추론되지 않고 범위가 지정되어야 한다.

계산 근거는 프라이버시를 보존한 채 남을 수 있다: 토폴로지/역량 스냅샷의 다이제스트와 신선도 진술, 알고리즘과 평가기 버전, 후보 집합의 다이제스트, 선택된 경로의 다이제스트, 기각된 제약의 이유, 남아 있던 불확실성. 검토자는 보통 승인된 절차가 따랐음을 확립하는 데 원시 경로를 필요로 하지 않는다.

각 도메인은 자신이 수용한 부분집합, 자원 등급, 활성화 결과, 유효 구간, 해제 조건을 다루는 약속 토큰을 추가할 수 있다. 종단 간 영수증은 도메인이 내부 토폴로지를 노출하도록 강요하지 않고 그 토큰들을 결합한다.

마지막으로 수명 주기를 기록한다: OAM 근거 창, 재평가 트리거, 예외 만료, 롤백 대상, 해제 담당자, 정정 상태. 근거가 바뀌면 연결된 대체 영수증을 발행한다. 어제의 근거를 오늘의 토폴로지로 덮어쓰고, 원래 선택이 아직 존재하지 않았던 정보로 이루어졌다고 가장하지 마라.

근거의 한계

인용된 RFC들은 실패한 DetNet 배치를 보고하지 않는다. 특정 컨트롤러가 부적절한 할당을 했다거나, 어떤 도메인이 약속을 깼다거나, 일반 트래픽이 기아 상태에 놓였다는 것을 보여주지 않는다. 거버넌스 경계를 검토할 수 있는 아키텍처, 정보 모델, 보안 분석, 운영 요구 사항을 제공할 뿐이다.

RFC 9938은 완성된 컨트롤러 프로토콜을 약속하지도 않는다. 훗날의 작업에 정보를 주기 위한 프레임워크다. 제안된 영수증은 문장 사이에서 발견된 숨은 요구가 아니다. 기계가 조직이 나중에 누가 그 결정을 내릴 자격이 있었는지 설명할 수 있는 것보다 더 정밀하게 결정을 적용하는, 되풀이되는 기관 문제에 대한 편집적 응답이다.

실천적 결론은 소박하다. 경로 계산, 시그널링, 구성, OAM을 계속 개선하라. 컨트롤러를 인증하고 메시지를 보호하라. 그러나 그 결과 경로를 최적이라 부르기 전에 더 앞선 질문에 대한 답을 보존하라: 누구의 제약 아래, 누구의 자원을 쓰며, 얼마 동안의 최적인가?

출처

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://www.rfc-editor.org/info/rfc9938/
  5. https://www.rfc-editor.org/rfc/rfc9938.html
  6. https://www.rfc-editor.org/rfc/rfc8655.html
  7. https://www.rfc-editor.org/rfc/rfc8938.html
  8. https://www.rfc-editor.org/rfc/rfc9016.html
  9. https://www.rfc-editor.org/rfc/rfc9055.html
  10. https://www.rfc-editor.org/rfc/rfc9551.html
  11. https://www.rfc-editor.org/rfc/rfc9633.html
  12. https://www.rfc-editor.org/rfc/rfc7426.html
  13. https://www.rfc-editor.org/rfc/rfc8283.html
  14. https://www.rfc-editor.org/rfc/rfc9552.html