요약

  • RFC 3496은 RSVP-TE PATH 메시지에 선택적ATM_SERVICECLASS객체를 추가하여 MPLS LSP가 UBR, VBR-NRT, VBR-RT 또는 CBR 처리를 요청할 수 있게 했다.
  • 이 문서는 LSR이 그 처리를 어떻게 구현할지는 명시적으로 규정하지 않았다. 인식, 경로 상태, 예약, 레이블, 큐 구성, 측정된 동작, 애플리케이션 결과는 각각 별개의 영수증으로 남았다.

RFC 3496은 트래픽 엔지니어링 요청에 더 오래된 전송 시스템의 어휘를 부여했다. ATM 셀을 전달하려는 MPLS 네트워크는 터널이 네 가지 ATM 서비스 클래스 중 하나에 속한다고 말하는 PATH 메시지를 받을 수 있었다. 목표는 기능적 대체였다. 서비스 클래스 구분을 유지하면서 트래픽을 이더넷, Packet over SONET, ATM 또는 그 외의 링크로 옮기는 것이었다.

이 객체는 작았다. 클래스 번호 227과 C-Type 1이 그것을 식별했다. 29비트는 예약되어 0으로 전송되고 수신 시 무시되었다. 마지막 세 비트가 UBR, 비실시간 VBR, 실시간 VBR 또는 CBR을 선택했고, 4부터 7까지의 값은 예약 상태로 남았다. 이 간결함은 의도적인 것이었다. 동시에 이 객체가 말할 수 없는 것도 드러냈다.

스케줄러 알고리즘, 큐 깊이, 버퍼 할당, 폴리싱 레이트, 가중치, 지연 목표 또는 손실 임계값을 기술하는 필드는 없었다. RFC는 그 경계를 직접 밝혔다. 이 문서는 트래픽 엔지니어링 경로가 ATM 클래스를 지원해야 한다는 사실을 신호로 알리는 방법을 규정할 뿐, MPLS LSR이 큐잉과 스케줄링을 통해 그것을 어떻게 에뮬레이션할지는 규정하지 않는다고 명시했다. 제어 평면의 CBR은 요구 사항이었지 설치된 메커니즘이 아니었다.

이 객체는 확장 문법에서 선택적 Diffserv 객체 뒤에 이어져 PATH에 나타났다. 세션은 여전히 레이블 요청을 가진 IPv4 LSP 터널이어야 했다. 유니캐스트 전용 설정을 포함한 기존 RSVP-TE의 한계는 그대로 남았고, 멀티캐스트는 추가 연구 과제로 남겨졌다. 이 추가 사항은 요청의 한 부분을 좁혔을 뿐 RSVP-TE의 나머지를 대체하지 않았다.

LSP가 ATM 서비스 클래스와 연관될 때 발신자는 이 객체를 포함해야 했다. 이를 인식하는 모든 LSR은 경로 상태 블록에 그것을 기록했다. 기록은 유용한 증거였다. 제어 평면이 그 경로에 어떤 클래스가 속한다고 믿는지 보여주었기 때문이다. 그러나 그것이 데이터 평면에 대응하는 큐가 있다는 것, 또는 부하 상태에서 패킷이 요청된 동작을 받고 있다는 것을 증명하지는 않았다.

첫 번째 객체 규칙은 메시지가 누적을 통해 협상하는 것을 막았다. 여러ATM_SERVICECLASS객체가 나타나면 첫 번째 것만 의미가 있었다. 이후 것들은 무시하고 전달하지 않아야 했다. CBR 뒤에 UBR이 담긴 패킷 캡처는 두 개의 클래스, 폴백 순서 또는 다운스트림 재정의를 의미하지 않았다. 첫 번째 값이 지배하고 나머지는 폐기된다는 뜻이었다.

반환 방향은 의도적으로 비대칭이었다. 목적지는 PATH가 그 객체를 실었는지와 무관하게ATM_SERVICECLASS객체 없이 RESV로 응답했다. 따라서 성공적인 RESV는 세 비트 클래스에 대한 반향 영수증이 아니었다. 운영자는 응답만으로 전체 체인을 추론해서는 안 되고, 발신 PATH 상태, 홉별 인식, 예약 상태, 데이터 평면 구성을 상호 대조해야 했다.

선택 사항이라는 성격은 호환성을 미묘하게 만들었다. 클래스 번호 227을 인식하지 못하는 노드는 상위 비트가11인 미지 클래스에 대한 RSVP의 규칙을 따랐다. 객체를 무시하되 변경 없이 전달하는 것이다. 그 바이트들은 그 의미를 이해하지 못하는 소프트웨어를 가진 노드를 통과할 수 있었다. 따라서 객체의 연속성은 홉 수준 지원보다 약한 증거였다.

클래스 번호는 알지만 C-Type을 모르는 노드는 미지 객체 유형에 대해 PathErr를 보냈다. RFC 3496은 지원되지 않는 경우 설정 실패를 초래한다고 밝혔다. 발신자는 관리 시스템에 통지하고 객체 없이 재시도할 수 있었다. 이 재시도는 수리가 아니라 하나의 결정을 만들어냈다. 요청된 ATM 서비스 계약이 제거된 상태에서 범용 연결을 받아들일 수 있는가?

그 두 번째 시도가 성공한다면, 그것은 범용 LSP가 설정될 수 있음을 증명했을 뿐이다. CBR, VBR 또는 UBR 동작을 증명하지는 않았다. 제거된 객체를 기록하지 않은 채 “터널 up”만 축하하는 자동화는 명시적인 서비스 실패를 보이지 않는 다운그레이드로 바꿔버릴 것이다.

Diffserv가 그 간극을 자동으로 메우지는 않았다. RFC 3270은 동작 어그리게이트에 대한 MPLS 매핑을 정의했고, RFC 3564와 RFC 4124는 클래스 유형과 대역폭 제약을 중심으로 Diffserv 인지 트래픽 엔지니어링을 발전시켰다. RFC 5127은 이후 여러 서비스 클래스가 하나의 처리 어그리게이트를 공유하는 방식을 논의했다. RFC 3496이 담당한 것은 더 좁은 이음선이었다. 하나의 ATM 클래스 요청, 그것이 이동하는 방식, 그리고 경로가 요청을 지원할 수 없을 때 무슨 일이 일어나는지였다.

따라서 지속되는 증거 체인은 다음과 같다. PATH 발신, 객체 파싱, 클래스 수용, 홉별 상태 기록, 정책과 자원의 허가, RESV 반환, 레이블 프로그래밍, 큐와 스케줄러 구성, 동작 측정, 애플리케이션 전달. 각 전환마다 소유자와 관찰 가능 항목이 다르다. 3비트 필드는 그 체인을 시작할 수 있다. 그것을 완성할 수는 없다.

출처