요약

  • RFC 3175는 집합(aggregation) 영역이 내부 라우터로부터 종단 간 RSVP 메시지를 숨기고, DSCP에 연관된 하나의 집합 예약 안에 여러 흐름을 실어 나를 수 있게 했다. 이는 코어의 신호 처리와 상태를 줄였지만, 각 흐름의 에지 매핑과 수용(admission)을 증명해야 할 필요를 없애지는 않았다.
  • 디애그리게이터(deaggregator)는 집합을 선택하고, DCLASS에 선택된 DSCP를 반환하며, 흐름의 토큰 버킷을 가용 용량에 대조해 계상했다. 그런 다음 애그리게이터(aggregator)가 패킷에 마킹했다. 예약 블록, DSCP, 성공한 메시지, 전달된 서비스는 서로 다른 기록이었다.
  • 예측 기반 크기 조정은 집합을 의도적으로 부정확하게 만들었고, 잘못 전달된RSVP-E2E-IGNORE메시지는 조용히 사라질 수 있었다. 따라서 안전한 운영에는 양쪽 에지의 영수증, 용량 상태, 내부 처리, 관측된 트래픽이 필요했다. 하나의 녹색 집합에서 빌린 확신만으로는 부족했다.

확장 문제는 모든 라우터에 있었다

RSVP 버전 1은 하나의 흐름에 대한 예약을 정밀하게 기술할 수 있었다. 그 정밀함에는 대가가 따랐다. 모든 예약은 경로상의 각 RSVP 지원 라우터에서 메시지, 연산, 메모리를 요구했다. 흐름 하나에 흐름 수를 곱하고, 그것이 통과하는 라우터 수를 다시 곱하면, 코어는 고객 수요에 비례해 커지는 장부를 떠안게 된다.

RFC 3175는 흐름별 의도를 거부하지 않았다. 그 의도가 어디에서 보여야 하는지를 옮긴 것이다. 동일한 수신 지점과 송신 지점을 공유하는 여러 종단 간 예약은 하나의 더 큰 예약 안에서 집합 영역을 통과할 수 있었다. 내부 라우터들은 각 구성원의 예약 상태를 유지하는 대신 클래스를 스케줄링할 수 있었다. 첫 에지가 애그리게이터가 되고, 마지막 에지가 디애그리게이터가 되었다. 같은 패킷 여정에서 그들 사이의 라우터들은 의도적으로 덜 알도록 했다.

이는 종단 간 서비스로부터의 후퇴가 아니었다. 전송 코어가 에지의 완전한 고객 장부를 재현하지 않으면서도 종단 간 서비스를 유지하려는 시도였다. 이 아키텍처는 필수 공유 상태를 압축했다. 그렇다고 에지가 어떤 흐름이 블록을 소모하는지 잊어도 된다고 승인한 것은 아니다.

프로토콜 134는 무지를 명시했다

일반 RSVP Path 메시지는 RSVP IP 프로토콜 번호와 Router Alert을 사용해 RSVP 인식 라우터들이 이를 검사하도록 한다. 집합화는 내부 라우터가 정확히 그 일을 하지 못하도록 하는 데 의존했다. Path가 영역에 들어오면 애그리게이터는 프로토콜 번호를RSVP-E2E-IGNORE로 바꾼다. IANA는 이 기능을 프로토콜 번호 134로 기록하고 있다. 내부 라우터는 흐름별 RSVP 상태를 만드는 대신 일반 트래픽으로 전달했다. 메시지가 영역을 떠나면 디애그리게이터가 RSVP를 복원했다.

이 재작성은 한정된 지시였다. 즉, 여기서는 이 메시지를 무시하되, 올바른 에지에서 종단 간 의미를 회복하라는 것이었다. 흐름이 더 이상 존재하지 않는다는 선언이 아니었다. 프로토콜 번호 134가 디애그리게이터를 찾을 것이라는 증명서도 아니었다. RFC 3175는 잘못 구성된 경로가 변형된 메시지를 의도된 영역 너머로 운반해, 익숙하지 않은 프로토콜을 무시하는 목적지까지 갈 수 있다고 경고했다. 그 소멸은 탐지하기 어려울 수 있었다.

교훈은 메커니즘보다 날카롭다. 코어가 어떤 객체를 알지 못하도록 설계될 수 있는 것은, 다른 제어 표면이 그것을 관리하는 경우에만 가능하다. 애그리게이터는 디애그리게이터가 숨겨진 메시지를 수신하고 이해했다는 증거를 필요로 한다. 중간의 침묵은 확장 기능이다. 출구에서의 침묵은 실패다.

하나의 DSCP는 클래스 이름이지 고객 약속이 아니었다

영역 내부에서는 하나 이상의 DSCP가 집합 예약으로 커버되는 트래픽을 식별했고, 대응하는 per-hop behaviour가 처리를 제공했다. 여러 Guaranteed Service 예약이 하나의 집합으로 매핑될 수도 있고, 다른 클래스가 다른 집합으로 매핑될 수도 있었다. 문서는 매핑 정책을 네트워크 관리자에게 남겼다.

그러나 책임은 모호하게 남겨 두지 않았다. 디애그리게이터가 매핑을 결정했다. 수신자의 종단 간 Resv와 요구된 서비스 정보를 처음으로 보는 쪽이 바로 그곳이기 때문이다. 디애그리게이터는 선택된 DSCP를 DCLASS 객체로 반환했다. 애그리게이터는 그 매핑을 기록하고, Resv를 상류로 전달하기 전에 DCLASS를 제거하며, 수신에서 일치하는 데이터 패킷에 마킹했다.

이 단계들은 관리(custody) 연쇄를 형성한다. 패킷의 DSCP는 그 지점에서 관측된 비트만을 증명한다. DCLASS 객체는 하나의 신호 메시지가 선택된 매핑을 실었다는 것만 증명한다. 어느 쪽도 에지 분류기가 올바른 5-튜플을 매칭했는지, 집합에 용량이 있었는지, 모든 내부 스케줄러가 의도된 PHB를 설치했는지, 수신자가 요구된 결과를 얻었는지를 증명하지 않는다. 마킹은 좌표일 뿐이다. 권한은 로컬 매핑 정책에서 나오고, 서비스 증거는 나중에 나온다.

디애그리게이터는 수용 장부를 유지했다

충분한 대역폭이 존재하면 디애그리게이터는 종단 간 Resv를 DCLASS와 함께 애그리게이터에게 되돌려 보낼 수 있었다. 또한 흐름의 토큰 버킷을 집합 사용량에 대한 자체 내부 계정에 추가했다. 이것이 하나의 커다란 예약이라는 매력적인 단순함에 가려진 핵심 기록이었다.

1,000단위짜리 집합이 다음 10단위 요청이 수락됨을 의미하지는 않았다. 디애그리게이터는 관련 집합을 식별하고, 현재 약속된 사용량을 확인하고, 정책을 적용하고, 용량이 있는지 판단해야 했다. 집합 Path 상태가 존재하지만 Resv 상태가 없다면 예약을 생성해야 했다. 블록이 너무 작다면, 블록의 존재를 수용으로 간주하는 대신 블록을 확대하거나 흐름을 지연시켜야 했다.

따라서 코어의 상태는 구성원 흐름 수와 무관할 수 있었지만, 에지의 상태는 그럴 수 없었다. 이 비대칭이 핵심이었다. 집합화는 흐름별 책임을 종단 간 요청과 결합될 수 있는 곳에 집중함으로써 공유 기계를 절약했다.

정확한 계상은 이득을 파괴했을 것이다

집합의 명백히 안전한 크기는 모든 구성원 대역폭과 버스트 요구의 합이다. 그러나 도착과 종료 때마다 집합을 다시 크기 조정하면 신호 부하를 다른 형태로 재현할 것이다. 그래서 RFC 3175는 정확한 구성원 계상과 대략적인 집합 프로비저닝을 분리했다.

명세는 현재 합보다 큰 블록과 이를 드물게 변경하는 정책을 논의했다. 과거 시간대별 수요와 최근 추세가 예측에 반영될 수 있었다. 더 미세한 조정은 미사용 용량을 줄이지만 신호를 늘리고, 더 거친 조정은 잦은 변경을 줄이지만 오류와 복구 리스크를 늘렸다. 명세는 하나의 보편적 알고리즘을 정의하지 않았다.

이는 감추어야 할 결함이 아니다. 트래픽, 목표, 여유 용량에 대한 허용도가 로컬이었기 때문에 예측은 운영자의 몫이었다. 그러나 그 자유는 증거 의무를 만들었다. 예측은 가용 대역폭이 아니다. 구성된 블록은 수용된 사용이 아니다. 수용 결정은 큐의 런타임 상태가 아니다. 그리고 올바르게 스케줄된 패킷은 애플리케이션의 결과가 아니다.

집합화는 격리를 규모와 맞바꿨다

개별 예약은 흐름을 더 엄격하게 격리한다. 집합화는 버스트가 공통 클래스 안에서 상호작용하도록 허용한다. RFC 3175는 한 흐름이 다른 흐름으로부터 지연을 받을 수 있고 버스트 동기화가 일어날 수 있음을 인정했으며, 연구된 조건에서 평균 및 꼬리 지연이 유리하다는 연구 결과를 인용했다.

표준 문서는 그 인용된 증거를 25년 뒤 이름 없는 네트워크의 결과로 변환할 수 없다. 관련된 증명은 구현, 토폴로지, 트래픽 조합, 큐 구성, 측정 방법, 관측 구간을 요구할 것이다. 역사적 RFC가 확립한 것은 거래다. 코어의 상태 객체를 줄이는 대가로 개별 격리는 줄어들고 에지의 책임은 늘어난다.

같은 집중이 장애 영역도 확대했다. 집합 예약의 손실 또는 악의적 탈취는 많은 콜을 무예약 상태로 남길 수 있었다. 과잉 예약은 다른 이들의 자원을 거부할 수 있었다. 결함 있는 분류기는 무관한 패킷을 보호 클래스에 넣을 수 있었다. 압축은 제어 객체 수를 줄였지만, 각 객체의 결과적 무게를 늘렸다.

무결성은 메시지를 보호했지 서비스의 진실을 보호한 것이 아니었다

RFC 3175는 서로 다른 두 이웃 구조에서 RSVP 무결성을 유지했다. 숨겨진 종단 간 교환에서 애그리게이터와 디애그리게이터는 내부 라우터가 사이에 있더라도 논리적 RSVP 이웃으로 나타났다. 영역 내부의 집합 메시지는 인접 노드 간 홉별 관계를 유지했다.

유효한 키 기반 다이제스트는 구성된 피어가 변경되지 않은 메시지를 만들었음을 보여줄 수 있다. 그러나 매핑 정책이 올바른지, 비밀키가 여전히 승인된 것인지, 용량이 충분한지, 마킹이 이루어졌는지, PHB가 적용되었는지, 애플리케이션이 성공했는지는 보여줄 수 없다. 암호학적 수용은 연쇄의 영수증 하나일 뿐, 연쇄 자체가 아니다.

프로토콜 번호 재작성은 추가 리스크를 만들었다. 공격자나 잘못된 구성이 값을 바꿔 이후 라우터들이 신호 메시지를 무시하게 하고, 심지어 엔드포인트 앞에서 값을 복원해 간섭을 숨길 수도 있었다. RFC는 IPsec 인증을 논의하고 재작성을 특정 RSVP 메시지 유형으로 한정할 것을 권고했다. 이 경고가 중요한 이유는 운영 편의가 새로운 권한을 열었기 때문이다. 어떤 라우터가 제어 메시지를 알 수 있는지를 결정하는 권한이었다.

후속 명세들은 첫 집합의 한계를 드러냈다

RFC 4804는 집합화를 MPLS TE와 DS-TE 터널에 맞게 조정했다. RFC 4860은 RFC 3175가 동일한 소스 주소, 목적지 주소, PHB 튜플을 가진 복수의 집합을 표현할 수 없었기 때문에, 나중에 일반 집합 예약을 정의했다. RFC 5350은 Router Alert 할당 지침을 개정했다. IANA 레지스트리에는 여전히 프로토콜 134와 집합 IPv4/IPv6 C-Types가 등록되어 있다.

이러한 기록은 명세의 역사를 확립할 뿐, 배포의 역사를 확립하지 않는다. 레지스트리 행은 라우터가 그것을 구현함을 증명하지 않는다. 후속 확장이 운영자가 특정 장애를 만났음을 증명하지 않는다. 현재 코드 포인트는 패킷이 그것을 사용하는지 말해 주지 않는다. RFC 3175의 지속적 기여는 아키텍처적이다. 인터넷이 코어가 흐름별 세부를 잊도록 하려면, 에지의 관리를 더 명시적으로 만드는 수밖에 없었다.

Lu Heng의 running-code 렌즈는 이 거래를 명확히 한다. 최소 공유 계층은 상호운용성이 요구하는 것만을 담아야 하며, 재량적 정책은 로컬에 남아야 한다. 현실 계층(reality-layer) 렌즈는 그다음 로컬 정책, 등록된 코드 포인트, 구성된 예약, 관측된 포워딩, 경제적 결과가 하나로 뭉개지지 않도록 한다. 이들은 후속 분석 프레임이며 RFC 저자들의 주장이 아니지만, 집합화가 증명까지 압축하지 않고 상태만 압축해야 하는 이유를 드러낸다.

출처와 한계

근거는 2026년 10월 2일, Asia/Shanghai 기준으로 고정되었다. RFC 3175의 메커니즘, IANA 할당, 후속 명세 역사를 뒷받침한다. 구현, 채택, 현재 사용, 상태 감소, 트래픽 규모, 성능, 명명된 장애, 운영자 행위, 전달된 애플리케이션 품질을 증명하지는 않는다. 예측 예시는 권고이며 측정값이 아니다.