요약

  • IPv4는 처음에 권고적인 우선순위와 서비스 선호를 담았습니다. 나중에 DiffServ는 6비트 코드포인트로 홉별 동작을 선택하게 했지만, 분류·미터링·폴리싱·셰이핑·재마킹은 정책 경계에 집중된 채 남았습니다.
  • DSCP는 예약도 여권도 아닙니다. AF와 EF는 로컬 자원과 계약을 통해서만 실질적 의미를 얻으며, 수신 도메인은 존중할 의무가 없는 표시를 수용하거나, 변환하거나, 초기화하거나, 거부할 수 있습니다.

패킷이 헌법적 경계에 도달했다

한 회사 네트워크에서 Expedited Forwarding으로 표시되어 나오는 음성 패킷을 상상해 보십시오. 그 네트워크 내부에서 이 표시는 할당된 서비스 속도에 의해 뒷받침되는 짧은 큐를 선택합니다. 공급자 경계에서 같은 6비트가 그대로 보입니다. 그 비트 안에는 발신자가 서비스를 구매했는지, 트래픽 프로파일을 준수하는지, 공급자의 희소한 저지연 용량을 소비할 권리가 있는지 증명하는 것은 아무것도 없습니다.

따라서 수신 라우터는 읽는 데 그치지 않습니다. 패킷을 분류하고, 트래픽을 정책과 대조하며, 표시를 유지하거나 교체하거나 지울 수 있습니다. 1미터 전에는 특권을 누리던 패킷이 다음 링크에서 베스트 에포트가 되어도 이 아키텍처를 위반하지 않습니다.

이 경계가 Differentiated Services의 핵심 발명입니다. 코드포인트는 이동하지만, 큐에 대한 권한은 이동하지 않습니다.

첫 옥텟은 소망을 표현했다

역사는 IPv4 헤더에서 시작했습니다. 1981년 9월에 발행된RFC 791은 8비트 Type of Service 필드를 정의했습니다. 3비트는 우선순위를 나타냈고, 다른 비트들은 낮은 지연, 높은 처리량, 높은 신뢰성에 대한 선호를 표현했습니다. 이 필드는 서로 능력이 다른 네트워크들 사이에서 데이터그램의 처리와 경로를 안내하기 위한 것이었습니다.

원문조차 겉으로 보이는 위계를 억제했습니다. Network Control 우선순위는 한 네트워크 내부에서 사용하도록 되어 있었고, 실제 사용과 통제는 그 네트워크에 맡겨졌습니다. 특권 지정에 대한 접근을 관심 있게 다루는 네트워크는 스스로 그것을 단속해야 했습니다. 발신자가 설정할 수 있다는 이유만으로 표시가 스스로 인증되는 것은 아니었습니다.

이 추상화는 매력적이었습니다. 애플리케이션이 모든 하위 기술을 알지 못한 채 어떤 서비스를 원하는지 말하게 하자는 것이었습니다. 그러나 그 약점도 근본적이었습니다. 선호는 다른 경로를 만들거나, 남는 대역폭을 만들거나, 협조적인 운영자를 만들어 낼 수 없었습니다.

1992년RFC 1349는 이 한계를 뼈아프게 말했습니다. TOS는 철저히 권고적이며 보장을 요청하는 용도로 적합하지 않다고 했습니다. 어떤 네트워크들은 더 나은 경로가 없어서 이를 무시할 것이고, 이 필드는 초당 메가바이트 같은 수량을 표현할 수도 없었습니다. 헤더는 선호의 방향을 서술할 수는 있었지만 자원을 묶어 둘 수는 없었습니다.

DiffServ는 이 한계를 아키텍처로 만들었다

1990년대 말, 인터넷은 모든 코어 라우터가 모든 애플리케이션 흐름이나 고객에 대해 상태를 유지하도록 강요하지 않는 차별화를 필요로 했습니다. 1998년 12월에 발행된RFC 2474와RFC 2475가 DiffServ의 답을 제공했습니다.

기존 IPv4 TOS 옥텟과 IPv6 Traffic Class 옥텟의 최상위 6비트가 Differentiated Services 필드가 되었습니다. 여기에 인코딩된 값이 Differentiated Services Codepoint, 즉 DSCP입니다. 남은 2비트는 나중에 Explicit Congestion Notification에 속했으며, 추가적인 DiffServ 권한이 아닙니다.

DSCP는 노드에서 홉별 동작(PHB)을 선택합니다. 값과 동작의 구분이 결정적입니다. 여러 코드포인트가 같은 PHB로 이어질 수 있고, 어떤 값은 순전히 로컬 의미만 가질 수 있습니다. 동작 자체는 한 노드에서 패킷 집합에 적용되는 외부에서 관찰 가능한 포워딩 처리로, 큐 스케줄링, 버퍼 할당, 드롭 정책으로 구현되는 것입니다.

이것은 종단 간 서비스가 아닙니다. 네트워크가 서비스를 구성할 수 있는 구성 요소입니다.

복잡성을 에지로 옮겨 코어를 작게 유지했다

DiffServ의 확장성 거래는 풍부한 의사결정을 네트워크 경계에 두었습니다. 수신 노드는 여러 필드를 검사하고, 스트림을 프로파일과 대조해 미터링하고, 패킷을 마킹·재마킹하고, 타이밍을 셰이핑하고, 초과 트래픽을 드롭으로 폴리싱할 수 있습니다. 내부 노드는 각 마이크로흐름을 기억하는 대신 집합 단위로 동작하면 됩니다.

이 아키텍처는 공통의 프로비저닝 정책과 PHB 정의를 가진 연속된 영역을 DS 도메인이라 부릅니다. 이 용어는 토폴로지만큼이나 행정적 사실을 표시합니다. 도메인 내부 노드들은 구성된 동작을 전달할 만큼 충분히 일관되게 수용 가능한 코드포인트를 해석해야 합니다. 경계에서 도메인은 어떤 외부 진술이 그 신뢰된 맥락에 들어올지 결정합니다.

그래서 패킷 헤더가 컴팩트하게 유지될 수 있었습니다. 6비트가 고객 신원, 계약, 트래픽 프로파일, 큐 속도, 초과에 대한 제재까지 담을 필요는 없었습니다. 그 사실들은 자원을 책임지는 주체들이 보유한 분류기, 구성, 계약 속에 존재했습니다.

Assured Forwarding은 보장 자체를 표준화하지 않았다

RFC 2597은 1999년 Assured Forwarding PHB 그룹을 정의했습니다. AF는 각각 3개의 드롭 우선순위 수준을 가진 4개 클래스를 제공합니다. 한 클래스 안에서 더 높은 드롭 우선순위로 표시된 패킷은 혼잡 시 더 높은 손실 확률에 직면해야 하며, 같은 마이크로흐름의 패킷은 드롭 우선순위가 다르다는 이유만으로 재정렬되어서는 안 됩니다.

익숙한 라벨은 전 세계 서비스 메뉴처럼 보일 수 있습니다. 그렇지 않습니다. 이 문서는 각 AF 클래스가 다른 클래스에 비해 얼마나 많은 대역폭과 버퍼를 받아야 하는지 규정하지 않습니다. 실질적 보장은 공급자가 할당하는 자원, 현재 부하, 패킷의 드롭 우선순위에 달려 있습니다. DS를 준수하는 노드는 AF를 구현할 의무조차 없습니다.

에지에서 공급자는 AF 트래픽을 셰이핑하거나, 폐기하거나, 드롭 우선순위를 바꾸거나, 다른 클래스로 옮길 수 있습니다. 결과가 예측 가능한 것은 마킹과 트래픽 프로파일이 도메인의 프로비저닝과 일치할 때뿐입니다. 패킷의 숫자가 그것이 명명하는 할당을 만들어 내지는 않습니다.

Expedited Forwarding은 한 노드에서 멈췄다

Expedited Forwarding이라는 이름은 훨씬 더 약속처럼 들립니다. 2002년 최초의 EF 사양을 대체한RFC 3246은 신중하게 그 의미를 좁힙니다. EF를 주장하는 노드는 구성된 속도 이상의 서비스를 제공해야 하고, 한정된 운영 조건에서의 동작을 정량화할 수 있어야 합니다. 그러나 이 RFC는 한 노드를 정의합니다. 노드 집합의 동작은 그 범위 밖이며, DiffServ를 준수하는 노드는 EF를 전혀 구현하지 않아도 됩니다.

따라서 경로 전체의 낮은 지연은 관련된 모든 노드가 프로비저닝되고, 제공되는 트래픽이 큐를 짧게 유지하는 조건 안에 머무는 것을 요구합니다. 하나의 정직한 EF 구현은 다음 라우터를 강제할 수 없고, 과부하 도메인을 수리할 수 없으며, 없는 상업적 계약을 용량으로 바꿀 수 없습니다.

이것은 표준화의 실패가 아닙니다. 검증 가능한 포워딩 프리미티브와 여러 제어 표면에 걸쳐 조립되는 서비스 사이의 정직한 구분입니다.

계약은 코드포인트 안에 들어가지 않았다

RFC 2475는 서비스 주장과 경계 규칙을 연결하는 준비를 위해 Service Level Agreement와 Traffic Conditioning Agreement라는 용어를 사용했습니다. 이후RFC 3260은 프로토콜이 그 용어를 완전히 소유할 수 없는 이유를 명확히 했습니다. 계약에는 DiffServ를 넘어서는 요금, 가용성 같은 상업적 사항이 포함될 수 있습니다. RFC 3260은 더 좁은 기술적 매개변수를 위해 Service Level Specification과 Traffic Conditioning Specification을 도입했습니다.

이 어휘는 헌법적 한계를 기록합니다. IETF는 필드와 PHB 요건, 준수 노드의 동작을 표준화할 수 있었습니다. 그러나 어떤 고객이 어떤 서비스를 구매했는지, 두 사업자가 어떻게 의무를 정산하는지, 운영자가 얼마나 많은 용량을 설치하는지는 표준화할 수 없었습니다.

수용 불가능한 코드포인트를 받은 수신 측은 패킷을 폐기하거나 수용 가능한 값으로 바꿀 수 있습니다. 강화된 서비스 계약이 없는 도메인의 트래픽은 Default로 초기화될 수 있습니다. 경계 조건화 이후, 인식되지 않은 매핑은 일반적으로 임의의 특권 대신 Default 동작을 받습니다. 수신 네트워크는 자신의 버퍼와 스케줄러의 주체로 남습니다.

누구나 설정할 수 있는 표시에는 문이 필요하다

DSCP는 인증 필드가 아닙니다. 엔드포인트의 소프트웨어는 높은 우선순위 값을 설정할 수 있고, 공격자는 인증되지 않은 외부 헤더를 변경할 수 있습니다. 따라서 DiffServ RFC들은 서비스 도용을 아키텍처적 위협으로 다룹니다. 위조된 특권 트래픽이 강화된 클래스를 위해 예약된 자원을 소비하면, 그 도용은 서비스 거부가 됩니다.

경계 조건화가 1차 방어입니다. 에지가 표시가 트래픽과 정책에 적합한지 판단하고, 내부 노드는 정화된 집합에 의존합니다. 터널 엔드포인트는 보호된 내부 헤더가 새 정책 도메인에 등장할 때 같은 의무를 지닙니다. 암호적 무결성은 표시가 어디에서 왔는지를 확립할 수 있어도, 다음 운영자가 이를 존중하기로 약속했다는 것까지 증명하지는 못합니다.

이 보안 모델은 더 큰 교훈을 강화합니다. 공유 헤더에 놓인 주장은 복종해야 할 권한이 아니라 평가해야 할 증거입니다.

새로운 링크는 변환 문제를 계속 드러냈다

이후의 운영 지침은 DSCP를 보편 언어로 만들지 않았습니다.RFC 7657은 2015년에 엔드포인트가 특정 네트워크에서 클래스 선택자 코드포인트가 어떤 PHB를 선택하는지, 더군다나 전체 경로에 걸쳐 알 수 없다고 지적했습니다. 낮은 노력 서비스와 흔히 연관되는 CS1조차 Default 또는 더 나은 처리를 받을 수도 있고, 재마킹되거나, 그 서비스가 없는 곳에서 드롭될 수 있습니다.

RFC 8325는 IP가 Wi-Fi를 만나는 지점에서 같은 한계를 보여주었습니다. DiffServ DSCP와 IEEE 802.11 User Priority는 서로 다른 분류 공간입니다. 액세스 포인트가 이들 사이를 변환할 수 있고, 대응하는 서비스가 없는 값은 Default가 될 수 있습니다. 경계는 해석해야 하며, 비트를 복사하는 것만으로는 부족합니다.

얇은 조율은 로컬 통제가 살아남았기에 살아남았다

DiffServ의 지속 가능한 발상은 6비트가 인터넷을 지배할 수 있다는 것이 아니었습니다. 6비트가 전체 거래를 담고 있다고 가장하지 않으면서 가동 중인 시스템을 조율할 수 있다는 것이었습니다. 표준은 공유 어휘와 검증 가능한 노드 동작을 제공했습니다. 운영자는 자원, 허용 규칙, 매핑을 제공했습니다. 고객과 인접 도메인은 프로파일과 계약을 제공했습니다. 경계 장치가 그 계층들을 만나게 했습니다.

이 아키텍처는 표시를 타인의 용량에 대한 휴대 가능한 청구로 바꾸기를 거부함으로써 확장 가능해졌습니다. 공통 계층을 작게 유지하고, 더 강한 서비스를 가시적이고 로컬적인 행위에 조건부로 만들었습니다. 패킷은 물을 수 있었습니다. 구성된 노드는 답할 수 있었습니다. 어떤 헤더 필드도 다음 네트워크를 자기 자신의 주권자로 임명할 수는 없었습니다.

출처와 한계

연대기와 원래 TOS 의미론은RFC 791과RFC 1349에서 나옵니다. DS 필드와 아키텍처는 RFC 2474와 RFC 2475에서, AF와 EF는 RFC 2597과 RFC 3246에서, 이후의 명확화와 배포 경계는 RFC 3260, RFC 7657, RFC 8325에서 나옵니다. 이 표준들은 어떤 현재 운영자의 큐 구성, 고객 권리, 상업적 계약, 배포 점유율, 측정된 종단 간 성능도 드러내지 않습니다.