요약

  • 1992년 1월의 표준 트랙 규격인 RFC 1294는 라우팅 트래픽과 브리징 트래픽을 위한 멀티프로토콜 프레임 릴레이 캡슐화를 정의했다. 그 요약문은 어떤 가상회선이 어떤 캡슐화 방식을 운반하는지 사전에 알아야 함을 요구했고, 이 방식은 그를 위해 명시적으로 구성된 VC로 한정했다.
  • Q.922 프레임의 NLPID 또는 SNAP 정보는 수신자가 하나의 PDU에서 이어지는 내용을 식별하게 해 주었다. 그러나 그 디스패치 정보는 VC를 구성하지 않았고, 양단이 합의했다는 증명도 아니었으며, 올바르게 레이블된 프레임이 실제로 전달·브리징·라우팅되었다는 증명도 아니었다.

RFC 1294 —Multiprotocol Interconnect over Frame Relay의 첫머리 규칙은 패킷 엔지니어링의 세부 사항처럼 보일 수 있다: 지정된 캡슐화는 그를 위해 명시적으로 구성된 가상회선에서만 사용하라. 그러나 이 규칙은 네트워킹 기술 문서가 흔히 하나의 성공적으로 보이는 프레임으로 뭉뚱그리는 두 종류의 지식 사이에 영구적인 선을 긋는다.

한 종류의 지식은 프레임 안에 담겨 도착한다. 수신자는 프레임 릴레이 주소 및 제어 필드 뒤의 바이트를 어떻게 해석할지 알아야 한다. RFC 1294는 그 목적을 위해 네트워크 계층 프로토콜 ID(NLPID)를 사용한다. 프로토콜에 할당된 NLPID가 없으면, SNAP 헤더가 조직 식별자와 프로토콜 식별자를 도입할 수 있다. OUI00-00-00인 경우 마지막 식별자는 EtherType이다. 이들은 이 PDU의 다음 부분을 파싱하기 위한 의미 있는 지시어다.

다른 종류의 지식은 PDU가 전송되기 전에 존재한다. 이 캡슐화와 다른 캡슐화를 모두 처리할 수 있는 두 스테이션은 어떤 가상회선이 이 방식을 운반하는지 알아야 한다. RFC는 사전 지식과 명시적 VC 구성을 요구한다. 프로토콜 레이블은 수신자에게 제시되는 프레임을 기술한다. 구성은 그러한 프레임이 사용될 자격이 있는 범위를 제한한다. 레이블은 자신이 전제하는 구성을 몰래 공급할 수 없다.

DLCI는 로컬 연결 지정이지 완전한 운영 정책이 아니었다

RFC 1294는 가상회선들로 이루어진 프레임 릴레이 그룹으로 시작한다. 그룹은 완전 메시(full mesh)이거나 부분 메시일 수 있다. 각 회선은 각 프레임 릴레이 인터페이스에서 데이터 링크 연결 식별자(DLCI)로 식별되며, RFC는 대부분의 상황에서 DLCI가 엄격하게 로컬 의미만 갖는다고 말한다. 따라서 DLCI는 한 인터페이스에서 정확한 주장을 한다: 여기서 그 가상 연결이 주소 지정되는 로컬 레이블이 이것이다.

그렇다고 같은 숫자 값이 다른 곳에서 같은 회선을 식별하거나, 원격 기계를 지명하거나, 프로토콜 선택을 기록하거나, 피어가 현재 특정 프레임을 처리할 의사가 있음을 증명하는 것은 아니다. RFC 1294는 뒤에서 패킷이 네트워크를 통과할 때 네트워크가 DLCI를 다시 쓸 수 있다고 설명한다. 수신 측의 로컬 번호는 송신 측의 로컬 번호와 다를 수 있다. 주소 필드는 로컬 인계의 일부이지 전체 경로의 휴대 가능한 진술이 아니다.

이것이 중요한 이유는 인터페이스 레이블을 정책 핸들로 오해하기 쉽기 때문이다. 트레이스는 DLCI를 보여줄 수 있다. 운영 기록은 회선을 보고할 수 있다. 프레임은 그것을 통해 주소 지정될 수 있다. 이 진술들은 서로 다른 것을 확립한다. RFC는 그 중 어느 것도 양단이 요구되는 캡슐화 할당을 마쳤다는 증명이나, 구현이 그 회선에서 문법적으로 식별 가능한 모든 프로토콜 유형을 수용한다는 증명으로 만들지 않는다.

프레임은 자신이 무엇을 운반하는지 말해야 했다

규격은 모든 프로토콜이 Q.922 Annex A 프레임으로 캡슐화될 것을 요구했고, 프레임이 그 PDU의 프로토콜을 식별하는 정보를 담을 것을 요구했다. 통상적인 제어 값은 별도 협상이 없는 한 UI0x03이었다. 정렬을 위해 패딩이 있을 수 있었지만 반드시 0이어야 했다. 여기서 작지만 시사하는 배제가 하나 생긴다: NLPID0x00은 패딩과 구별할 수 없고 프레임 릴레이 캡슐화에서 유용한 의미를 갖지 않으므로 무효였다.

이것은 레이블이 자신의 제한된 역할을 수행하는 예다. 식별자는 수신자가 그것을 주변 구조로부터 구별하고 정의된 해석을 부여할 수 있을 때만 유용하다. RFC 1294는 IP 데이터그램의0xCC를 포함한 직접 할당된 NLPID를 위한 자리를 마련했다. 또한 특정 NLPID가 없는 프로토콜을 위한 SNAP 경로도 규정했다: NLPID0x80, OUI00-00-00, 그다음 EtherType. 스테이션은 라우팅된 패킷에 대해 NLPID 형식과 SNAP 형식을 모두 수용할 의무가 있었다.

두 인코딩을 수용하라는 요구는 디코딩에 관한 상호운용성 규칙이다. 요약문에 명시된 사전 할당 없이 어느 형식이든 임의의 VC에 놓을 수 있다는 지시가 아니다. 수용 문법과 회선 허가는 별개의 질문이다. 수신자는 바이트 시퀀스가 스스로를 무엇이라고 주장하는지 알 수 있으면서도, 그 시퀀스를 이 특정 가상회선의 허용된 사용으로 만들 구성은 여전히 결여되어 있을 수 있다.

라우팅됨과 브리징됨은 하나의 주장으로 합쳐지지 않았다

RFC 1294는 라우팅된 패킷과 브리징된 패킷의 형식이 서로 다르기 때문에 이 둘을 구별했다. 그 구별은 NLPID와 SNAP 헤더 정보에 담겨 목적지가 들어오는 프레임을 적절히 해석할 수 있게 한다. 브리징 트래픽의 경우 NLPID0x80이 SNAP을 알리고, OUI00-80-C2가 802.1 조직을 식별하며, 이어지는 PID가 MAC 헤더 형식과 원래 프레임 체크 시퀀스가 보존되었는지를 구별한다.

그 필드들은 정확하면서도 겸손할 수 있다. 수신자가 어떤 프레이밍 절차를 적용할지 판단하도록 돕는다. 그러나 원래 LAN 프레임이 진짜였다든지, 브리지가 그것을 포워딩할 것이었다든지, 다른 브리지가 같은 서비스에 합의했었다든지, 원격 LAN에서 결과가 발생했었다든지는 인증하지 않는다. 분류 토큰은 파싱 경로를 고른다. 경로를 완주하지는 않는다.

이것은 기술이 패킷 캡처에서 운영적 결론으로 이동할 때 특히 중요하다. "브리징된 이더넷으로 표시되어 있었다"는 헤더에 대해 잘 뒷받침된 관찰일 수 있다. "이더넷이 성공적으로 브리징되었다"는 처리와 포워딩에 관한 추가 주장이다. "그 VC는 그 서비스를 위해 구성되어 있었다"는 사전적 양단 정책에 관한 주장이다. RFC 1294는 독자에게 이 명제들을 분리해 두는 도구를 주지, 그것들을 합칠 면허를 주지 않는다.

협상이 모든 구성을 대신하지 않았다

문서는 또한 프레임 릴레이 회선 초기화 시 선택적 교환 식별(XID)을 기술한다. XID는 선택된 데이터 링크 매개변수, 즉 최대 프레임 크기 N201, 재전송 타이머 T200, 미결 I 프레임 최대 수 K를 협상할 수 있다. XID를 사용하지 않으면 이 값들은 데이터 링크 양단의 상호 합의에 따라 정적으로 구성되거나 Q.922 기본값을 사용해야 한다. XID를 지원하는 수신자가 XID 프레임을 받으면 응답해야 하며, 원격 최대 프레임 크기가 더 작으면 로컬 시스템은 응답을 보내기 전에 해당 DLC에서 사용할 크기를 줄여야 한다.

이것은 실제 합의 절차의 좁은 예다. RFC의 앞선 요구, 즉 어떤 VC가 어떤 캡슐화 방식을 운반하는지 알아야 한다는 요구를 지우지 않는다. 또한 성공한 XID 교환 한 번이 패킷의 전달, 상위 계층 프로토콜의 내용, 브리지 결과, 서비스 보장을 확립하지 않는다. 그것은 특정 매개변수에 합의된 또는 기본값에 근거한 기초를 부여한다. 그 정밀성이 교훈이다. RFC는 교환이 무엇을 다루는지 이름을 지을 뿐, 교환의 존재가 다른 모든 운영 결정을 대신하게 하지 않는다.

유용한 기록은 헤더 필드가 아니라 연쇄다

오래된 프레임 릴레이 상호접속을 조사하는 운영자에게 필요한 기록은 별개의 것들이다: 로컬 인터페이스와 DLCI, 그 VC의 캡슐화 할당, XID 또는 정적 매개변수 합의, 캡처된 Q.922 프레임, NLPID/SNAP 해석, 수신 구현의 동작, 그리고 이후의 상위 계층 결과. RFC 1294는 이 기록들 중 일부에 대해 강력한 증거를 제공한다. 나머지를 만들어내지는 않는다.

올바른 NLPID는 "프레임이 자신을 이 프로토콜로 제시했다"를 뒷받침할 수 있다. 일치하는 SNAP OUI/PID는 "이것이 표시된 브리징 프레이밍이었다"를 뒷받침할 수 있다. 구성 기록은 "이 VC에 이 캡슐화가 할당되어 있었다"를 뒷받침할 수 있다. 이후의 카운터나 트레이스는 포워딩 관찰을 뒷받침할 수 있다. 그러나 어느 것도 인접한 단계를 자동으로 증명하지 않는다. 연쇄를 유지하면, 이용 가능한 증거가 레이블된 하나의 프레임에만 관한 것일 수 있는 상황에서 "회선이 동작했다"는 유혹적인 문장을 피하게 된다.

RFC 1294의 기여는 단순히 헤더 레이아웃의 메뉴가 아니었다. 그것은 가독성이 곧 권위라고 가장하지 않으면서 다중 프로토콜 공유 전송을 읽을 수 있게 만들었다. PDU는 수신자에게 단서를 운반했다. VC는 허용된 캡슐화의 명시적이고 사전적인 할당을 운반했다. 양단은 일부 매개변수를 협상하거나 정적으로 합의할 수 있었다. 각 메커니즘에는 경계가 있었고, 상호운용성은 한 경계에 다른 경계의 일을 하도록 요구하지 않는 데 달려 있었다.

출처와 증거의 한계

유일한 출처는RFC 1294 —Multiprotocol Interconnect over Frame Relay이다. 이것은 1992년 1월 표준 트랙 지위, 명시적 구성 요구, DLCI의 로컬 의미, Q.922/NLPID/SNAP 형식, 라우팅/브리징 구별, 선택적 XID 및 정적 매개변수 합의를 뒷받침한다. 현재의 캐리어, PVC, 구성, 피어, 구현, 보안 속성, 포워딩 사건, 전달 또는 서비스 결과를 증명하지는 않는다.