요약

  • RFC 1483은 각 PDU가 LLC/SNAP 식별자를 실을 때 여러 프로토콜이 하나의 ATM 가상 회선을 공유하도록 허용했다. 그 대안인 VC 기반 멀티플렉싱은 PDU별 유형 레이블을 생략하고 가상 회선당 하나의 프로토콜을 요구했다.
  • VC 멀티플렉싱은 헤더와 처리 오버헤드를 줄였지만, 구성이나 호출 협상이 페이로드의 의미에 속하게 만들었다. 유효한 AAL5 PDU는 재조립을 증명할 뿐, 수신자가 올바른 회선 바인딩, 파서 또는 응용 결과를 가지고 있다는 것을 증명하지 않았다.

수신자는 완전한 봉투를 받았지만 아직 끝나지 않은 질문이 남아 있었다

마지막 ATM 셀이 도착한 뒤 AAL5는 가변 길이 PDU를 재구성하고 트레일러를 검사할 수 있었다. 수신자는 봉투의 길이를 알았다. CRC가 커버하는 손상은 감지할 수 있었다. 어떤 가상 회선이 그 순서대로 정렬된 셀들을 전달했는지도 알았다. 그럼에도 어떤 파서가 페이로드를 처리할지는 여전히 결정해야 했다.

RFC 1483(1993년 7월 발표)은 의도적으로 서로 다른 두 가지 방법으로 답했다. LLC 캡슐화는 전달되는 PDU 앞에 IEEE 802.2 헤더를 놓고, 경우에 따라 SNAP이 뒤따랐다. 선두 바이트들이 프로토콜 또는 브리지된 매체를 명명했다. 따라서 여러 프로토콜이 동일한 가상 회선을 공유할 수 있었는데, 모든 PDU가 수신자가 이를 분배할 만큼 충분한 유형 정보를 실어 왔기 때문이다.

VC 기반 멀티플렉싱은 정반대 길을 갔다. AAL5 페이로드는 일반 멀티프로토콜 레이블을 실지 않았다. 회선 자체가 그 회선에서 허용되는 단일 프로토콜을 식별했다. 두 종단이 여러 프로토콜을 실고 싶다면 각각에 대해 별도의 VC가 필요했다.

두 방법 모두 동일한 IP 데이터그램을 IP 계층으로 전달할 수 있었다. 그러나 그 해석의 근거를 담는 대상은 같지 않았다. LLC/SNAP에서는 PDU 자체가 자신의 유형을 증언했다. VC 멀티플렉싱에서는 PDU가 회선에 대한 사전 진술에 의존했다.

RFC Editor 기록은 이 선택을 "하나의 VC에 여러 프로토콜 대 각 VC에 하나의 프로토콜"이라는 한 문장으로 압축한다. 운영상 이 문장은 시스템의 상태 대장을 나누는 기준이었다.

더 작은 헤더가 더 적은 상태를 의미하지는 않았다

라우팅된 비-ISO 트래픽에 대해 RFC 1483은 LLCAA-AA-03과 SNAP OUI, 그리고 프로토콜 식별자를 사용했다. OUI가 0이면 뒤따르는 값은 EtherType이고,0x0800은 IP를 식별했다. 수신자는 처리 중인 페이로드 안에서 그 시퀀스를 읽을 수 있었다.

브리지된 트래픽에서 레이블은 더 많은 일을 했다. SNAP OUI와 PID는 원본 매체 계열과 원본 프레임 체크 시퀀스가 보존되었는지를 식별했다. 따라서 깨끗한 AAL5 봉투는 외부 영수증일 뿐이었다. 브리지는 내부 프레임을 어떻게 재구성하고 처리할지 알기 위해 캡슐화 필드를 여전히 필요로 했다.

VC 멀티플렉싱은 그 일반 분배 바이트들을 제거했다. 이는 대역폭과 파싱 작업을 절약했고, 일부 패킷 크기에서는 추가 ATM 셀 단편화를 피할 수 있었다. 그러나 프로토콜 연관 관계는 어딘가에 존재해야 했다. 영구 가상 회선(PVC)에서는 운영자가 양쪽 끝에서 구성했다. 스위치드 가상 회선(SVC)에서는 신호 절차가 호출 설정 중에 협상했다.

이것은 되풀이되는 시스템 오류다. 없는 바이트를 없는 복잡성으로 다루는 것이다. RFC 1483은 유형 필드를 폐지하지 않았다. 유형을 제어 평면 테이블 안의 관계로 표현되도록 허용했을 뿐이다. 이 VC는 IP를 의미하고, 저 VC는 브리지된 이더넷 프레임을 의미한다. 헤더 조회가 상태 조회가 된 것이다.

이 거래는 실패의 형태도 바꿨다. 잘못된 LLC/SNAP 레이블은 하나의 PDU 안에서 거부될 수 있었다. 잘못된 VC 바인딩은 그 회선의 모든, 다른 면에서 유효한 PDU를 잘못된 파서로 보낼 수 있었다. 표준은 형식과 선택을 정의했지만, 실제 설치된 모든 종단이 일관되게 구성되었다는 증거는 제공하지 않았다.

영구 회선과 스위치드 회선은 합의 시점이 달랐다

RFC 1483은 영구 회선이 수동 구성을 사용할 것으로 기대했다. 트래픽이 도착하기 전에 양쪽 종단은 그 VC가 LLC 캡슐화를 쓰는지 VC 멀티플렉싱을 쓰는지, 그리고 VC 멀티플렉싱이라면 회선이 어떤 프로토콜을 나타내는지 합의해야 했다.

스위치드 회선은 그 합의를 호출 제어로 옮겼다.RFC 1755는 이후 브로드밴드 저계층 정보(Broadband Low Layer Information)가 캡슐화를 제안하고 선택하는 방식을 규정했다. 한 종단은 VC 멀티플렉싱을 선호하면서 LLC/SNAP도 함께 제안할 수 있었다. 피호측은 지원되는 선택을 고르거나, 제안이 호환되지 않으면 호출을 해제했다.RFC 1755 정보 기록은 이 문서를 Classical IP over ATM 신호 절차의 구현자 안내서로 설명한다.

이 교환은 중요했지만 데이터 평면의 성공 영수증은 아니었다. SETUP 메시지가 잘 형성될 수 있었다. CONNECT가 캡슐화를 선택할 수 있었다. 경로를 따라 자원이 할당될 수 있었다. 그 어떤 사실도 이후 PDU가 도착했는지, 그 CRC가 통과했는지, 회선 바인딩이 여전히 올바른지, IP가 이를 수용했는지, 응용이 유용한 작업을 완료했는지 증명하지 않았다.

RFC 1755는 B-LLI 정보 요소가 IP 캡슐화를 지정하는 데 필수였기 때문에 이 의존성을 보이게 만들었다. 또한 필요한 정보가 없거나 지원되는 방식이 없을 때의 명시적 거부도 정의했다. 다시 말해 협상은 트래픽 이전에 한 부류의 모호성을 막을 수 있었다. 그러나 이후의 연쇄를 보증할 수는 없었다.

Classical IP는 기본값을 선택하되 기본값을 관찰인 양하지 않았다

RFC 2225는 다른 지식이나 합의가 없을 때 LLC/SNAP을 Classical IP 및 ARP over ATM의 기본 패킷 형식으로 삼았다. 이 결정은 독립적으로 구축된 종단들에게 공통의 출발점을 주었다.RFC Editor 기록은 이를 Classical IP and ARP over ATM의 안정 기준선에 위치시킨다.

같은 문서는 다른 사실들을 각 셀 밖에 신중히 배치했다. VC에 연관된 AAL 유형은 PVC의 경우 관리적으로 구성되고 SVC의 경우 설정 중에 전달되며, ATM 셀 헤더에는 실리지 않았다. PVC를 지원하는 스테이션은 어떤 회선이 LLC/SNAP을 쓰는지 알 방법이 필요했다. 이 아키텍처는 이미 대역 내 데이터와 외부 연관 관계의 혼합에 의존하고 있었다.

또한 AAL5를 과대평가하지 않았다. 셀 순서는 VC에서 보존되고 적응 계층이 오류를 감지하지만, 그 서비스는 무보증(non-assured)이었다. 재전송은 상위 계층이 담당했다. 올바른 트레일러는 하나의 조립된 봉투에 대한 증거일 뿐, 종단 간 전달의 약속이 아니었다.

PPP는 인증이 영수증들을 융합하지 않음을 보여주었다

RFC 2364는 이후 두 선택을 PPP over AAL5에 적용했다. 이 문서는 VC 멀티플렉싱 페이로드 유형이 프로비저닝 또는 제어 평면 절차를 통해 회선에 대해 암묵적으로 합의되는 반면, LLC 캡슐화는 각 PDU에 대해 대역 내에서 명시적으로 유형을 식별한다고 분명히 말했다.RFC 2364 정보 기록은 이 설계를 PPP 협상, 인증 및 압축을 사용할 수 있는 점대점 서비스에 위치시킨다.

그곳에서도 영수증들은 분리되어 있었다. PPP 인증은 PPP 세션에 관한 것이었다. RFC 2364는 같은 가상 연결을 공유하는 다른 LLC 캡슐화 흐름을 보호하지 않는다고 경고했다. 공통의 캐리어와 공통의 외부 봉투가 내부 대화들의 권위를 하나로 합치지 않았다.

이 구분은 유혹적이지만 거짓인 추론을 막는다. 회선이 프로비저닝되고, 프로토콜이 협상되고, 하나의 세션이 인증되었다 해도, 운영자는 그 연쇄를 근거로 VC의 모든 흐름이 인증되었거나, 모든 PDU가 올바르게 해석되었거나, 응용 트랜잭션이 완료되었다고 주장할 수 없었다.

대체 표준은 선택을 보존하되 주장을 좁혔다

RFC 2684는 1999년에 RFC 1483을 대체했다. 구현자들이 발견한 모호성을 명확히 하면서 동일한 두 방법 아키텍처를 유지했다. LLC는 일반적으로 멀티프로토콜 환경에서 더 적은 VC를 의미했다. VC 멀티플렉싱은 일반적으로 더 적은 PDU별 오버헤드를 의미했다.RFC Editor 기록은 대체 사실만을 표시하며, 이전 구현이 모두 사라졌다는 주장은 하지 않는다.

이후 이 문서의 조사는 가장 유용한 한계를 제시했다. 멀티프로토콜 캡슐화는 ATM을 통한 라우팅 및 브리징에 필요하지만 일반적으로 불충분하다는 것이다. Classical IP는 여전히 주소 해석과 논리적 서브넷 모델을 필요로 했다. 다른 환경들은 자신들의 제어 서비스를 필요로 했다. PPP는 자신의 점대점 계약을 사용했다. 캡슐화는 PDU를 인식하고 전달하는 방법에 답했을 뿐, 그 위의 네트워크를 운영하는 데 필요한 모든 질문에 답하지는 않았다.

출처