요약

  • RFC 1618은 ISDN 접속 시설에서 착신자 식별자를 사용해 PPP를 선택할 수 있었지만, 이 식별자는 로컬 스위치에서 제공된 것이며 서비스를 운영할 권한을 부여하지 않았다.
  • LCP가 행정적Open이벤트를 받지 못했다면, 호출은 거부되어야 했다. 회선을 수락한 뒤 닫거나 패킷을 무시하는 것은 명시적으로 금지되었다.
  • 접속 허용은 첫 번째 수신 증거일 뿐이었다. 인코딩, 프레이밍, 하위 계층 준비 상태, LCP 협상, 인증, NCP 상태 및 응용 결과는 별개의 사실로 남았다.

하나의 물리적 시설에 붙은 번호가 매겨진 문

1994년 5월,RFC 1618은 ISDN 교환 회선 위의 PPP를 기술했다. 이 문서의 적용성 선언은 건축적 환상에 대한 경고로 시작했다: 하나의 모놀리식 전 세계 ISDN이 존재할 가능성은 거의 없었다. 그리하여 이 문서는 다양하게 설치된 환경에서 몇 가지 공통 기본값을 선택했다. 상호 운용성은 모든 스위치, 가입 및 단말이 똑같이 동작한다는 주장이 아니라 공유된 출발점을 필요로 했다.

물리적 배치에는 이미 여러 계층이 들어 있었다. B채널은 PPP에 적합한 점대점 베어러였다. 프라이머리 레이트 인터페이스는 여러 개의 동시 B채널을 노출할 수 있었다. D채널은 때때로 프레이밍된 PPP 패킷을 운반할 수 있었지만 대역폭이 제한적이었고 통신은 종종 로컬 스위치 내부에 머물렀다. R, S, T, U 기준점의 장치들은 결합될 수도 있어 어느 책임이 끝나고 다른 책임이 시작되는지를 가렸다.

하나의 접속 시설은 한 가지 이상의 목적에 쓰일 수 있었다. RFC 1618은 여러 개의 디렉터리 번호가 동일한 물리적 시설에 종착하고, 각 번호가 행정적으로 특정 서비스에 묶이는 구성을 기술했다. 따라서 로컬 스위치가 제공하는 착신자 식별자는 좁은 질문에 답할 수 있었다: 발신자는 어떤 광고된 문을 선택했는가?

그것은 유용한 증거였다. 명령이 아니었다.

네트워크를 건너지 못한 신호

ISDN은 더 서술적으로 보이는 가능성, 즉 LLC 정보 요소(LLC Information Element)도 제공했다. 이러한 대역외 필드가 데이터 링크가 시작되기 전에 프레이밍이나 인코딩을 알려줄 것이라 기대할 수 있다. RFC 1618은 그 지름길을 거부했다. 경험상 이 요소는 종단 간에 안정적으로 전달되지 않았다: 호환되는 스위치의 배포가 너무 드물었고, 사업자마다 가입 정책이 달랐다.

발표 당시 PPP용 LLC-IE 값은 아직 할당되지 않았다. 다른 값들은 PPP 링크에 유효하지 않았으며 PPP 서비스에 대해서는 무시할 수 있었다. 더 일반적으로, 이 문서는 프레이밍이나 인코딩을 결정하는 데 이 요소를 신뢰해서는 안 된다고 말했다.

이것은 공유된 지능에 대한 정확한 한계다. 중간 신호 시스템은 관련된 모든 스위치와 가입 정책이 그 의미를 보존하는 곳에서만 레이블을 운반할 수 있다. 사라지거나, 범위가 바뀌거나, 다른 사업자 정책 아래 도착하는 필드는 엔드포인트의 로컬 동작 모드를 결정할 수 없다. 이 사양은 더 큰 보편 레이블로 그 제도적 다양성을 수리하려 하지 않았다. 대신 신뢰할 수 있는 결정을 수신 시설 쪽으로 옮겼다.

착신자 식별자는 로컬 스위치가 안정적으로 제공하는 것으로 기술되었다.로컬이라는 단어가 중요하다. 이 필드는 해당 번호에 붙은 구성된 서비스를 선택할 수 있었다. 발신자를 인증하거나, 원격 네트워크의 의도를 증명하거나, 종단 간 신호 체인을 확립하거나, PPP가 준비되었음을 보여주지는 않았다.

Open은 행정적 이벤트였다

RFC 1618은 서비스 선택에 엄격한 결과를 붙였다. 수신 측이 착신자 식별자를 사용했거나—또는 미래의 PPP 전용 LLC 값이 도착했는데—LCP가 행정적Open이벤트를 겪지 않았다면, 호출은거부되어야 했다. 수신 측은 회선을 닫거나 패킷을 무시할 목적으로 착신 호출을 수락해서는안 되었다.

당대의 PPP 사양인RFC 1548과 1994년 7월의 후속 문서RFC 1661은 이 상태 이름을 설명한다.Open은 링크가 트래픽에 대해 행정적으로 사용 가능하다는 외부 결정이다: 네트워크 관리자—사람이든 프로그램이든—가 링크가 열리도록 허용했다. 이는 하위 계층이 가용성을 보고하는Up과 같지 않다. 구성 교환 이후에 도달하는 이후의 오토마톤 상태인Opened와도 같지 않다.

이 구분은 대시보드에서 잃기 쉽다. 스위치는 베어러를 전달했다. 번호는 PPP에 매핑된다. 하위 계층은 물리적으로 가용할 수 있다. 그러나 로컬 운영자가 서비스를 비활성화했거나, 일정이 문을 닫았거나, 정책이 접속을 보류했거나, 프로그램이Open을 발행하지 않았을 수 있다. 처음 세 사실 중 어느 것도 네 번째를 가장할 수 없다.

수락 전 거부는 그 거부를 올바른 경계에서 보존했다. 이미 실행하지 않기로 결정한 서비스를 위해 교환 회선을 소모하는 것을 피했다. 또한 늦은 침묵이 프레이밍 오류, 무응답 피어 또는 패킷 손실로 위장하는 것을 막았다. 발신자는 조용히 시도를 버리는 겉보기에 수락된 경로가 아니라 회선 수준의 거부를 받았다.

수락은 발견을 시작했을 뿐, 끝내지 않았다

행정적으로 열린 서비스조차 착신 링크의 모든 속성을 알지 못했다. PPP의 관점에서 ISDN 채널은 전이중 동기 링크였고, 인코딩과 스크램블링은 DTE/DCE 장비에 속하며 PPP 자체 밖에 있었다. RFC 1618은 T 기준점에서 NRZ를 기본값으로, 구성된 경우 NRZI를 대안으로 권고했다. 일부 구현이 역사적으로 사용한 반전 NRZ(Inverted NRZ)는 더 이상 권고되지 않았다.

여러 단순 인코딩과 상호 운용하려는 장비에 대해 기술된 유일한 신뢰할 수 있는 탐지 방법은 능동 순환이었다. 한 모드로 LCP Configure-Request를 두 번 보내고, 응답을 기다릴 만큼 충분히 기다린 뒤, 다음을 시도했다. 결합된 시도는 59초 이내에 종료되어야 했고, 보통의 30초 상한이 선호되었다.

그 절차는 하나의 패킷에서 숨겨진 진실을 "인식"하지 않았다. 한계가 있는 실험을 수행했다. 교환 회선은 과금될 수 있고 희소할 수 있으며 여러 채널 중 하나를 점유할 수 있으므로, 각각의 부정적 구간에는 비용이 있었다. 무한한 호기심은 자원 소비가 되었을 것이다.

프레이밍에도 자체 기본값이 있었다. 사전 구성이 없으면 B채널은 비트 동기 HDLC로 시작해야 했다. 옥텟 동기 HDLC는 옥텟 경계가 사용 가능하고 구성된 경우에만 권고되었다. 명목상 구별되는 방식들—HDLC, LAPB, LAPD, LAPF—은 여러 프레이밍을 동시에 실행하고 PPP가 모두를 추론하도록 기대할 권한이 아니었다.

이 문서는 그 프레이밍이 프레임 릴레이와 구별하기 어려울 수 있어 이 용도로 V.120을 더 이상 권고하지 않았고, 대신 프레임 릴레이 안에서 PPP를 운반할 것을 권고했다. 그 선호는 한계가 있는 상호 운용성 선택이었으며, 어느 방법이 특정 호출에 배치되었다는 증거가 아니었다.

동반 문서RFC 1549는 비트 수준의 선택이 명명을 넘어선 결과를 왜 갖는지 보여준다. NRZI는 16비트 FCS의 일부 오류 검출 특성을 약화시켰고, 이는 협상된 32비트 FCS 권고로 이어졌다. 따라서 성공적인 캐리어 표시는 양단이 동일한 프레이밍이나 오류 검출 자세를 공유한다고 인증할 수 없었다.

실패에는 끝이 필요했다

RFC 1618은 패킷 크기와 재시도에도 동일한 절제를 적용했다. 피어가 특별히 2048 이상의 MRU를 협상하지 않는 한 네트워크 계층 MTU는 1500을 넘지 않을 것을 권고했다. 또한 250밀리초에서 3초까지의 지수 재시작 백오프를 권고했다. 지속 다이얼 또는 재다이얼 기능에는 한계가 있어야 했다. 링크 설정 완료에 실패한 후 구현은 전송 큐를 폐기할 수 있었다; 그렇게 하면 재다이얼을 유지하는 트래픽 자극을 일시적으로 제거할 수 있었다.

이것은 하나의 타이머 정책이 모든 네트워크에 맞는다는 약속이 아니었다. 자동 생성된 시도가 그 자체의 원인이 될 수 있음을 인식한 것이다. 큐에 담긴 패킷이 호출을 유발하고; 설정 실패가 패킷을 큐에 남기고; 패킷이 또 다른 호출을 유발한다. 명시적 상한과 정리 책임자 없이 시스템은 응답받지 못한 응용 요청을 교환 네트워크의 반복적 사용으로 바꾼다.

이 문서는 BONDING보다 PPP 멀티링크를 선호했는데, BONDING은 자체 초기화를 도입하고 채널별 광범위한 구성을 요구할 수 있었기 때문이다.RFC 1990은 이후 ISDN 대역폭 온디맨드 등의 경우에 대한 멀티링크 PPP를 규정했다. 그 경우조차 여러 물리적 링크는 LCP 기능 교환 후에야 하나의 번들로 합쳐졌다. 병렬 베어러는 스스로 합쳐지지 않았다.

접속 허용 이후의 수령 증명들

호출이 행정적Open으로 수락되면 증거 체인은 계속되었다. 선택된 인코딩과 프레이밍이 동작해야 했다. 하위 계층은Up이 되어야 했다. LCP 피어는 구성을 교환하고Opened에 도달해야 했다. 인증이 선택되었다면 성공해야 했다. 각 네트워크 계층 프로토콜은 자체 NCP가Opened에 도달해야 했다. 그제서야 관련 데이터그램이 통과할 수 있었고, 패킷 운반조차 응용 결과를 확립하지 않았다.

이후 단계들은 RFC 1618의 접속 허용 규칙이 아니며, 그것으로 다시 접어서는 안 된다. 거부된 호출은 끊어진 회선이 아니라 의도된 정책을 반영할 수 있다. 수락된 호출은 여전히 프레이밍이나 협상에서 실패할 수 있다. LCPOpened는 닫힌 IP 제어 프로토콜과 공존할 수 있다. 수신된 패킷은 유용한 작업을 결코 산출하지 못할 수 있다.

RFC 에디터 기록은 발표, 저작 및 현재의 Proposed Standard 지위를 확립한다. 그것은 배치 현황 조사, 명명된 제품 추적 또는 현재의 ISDN 실무를 제공하지 않는다. RFC 1618 자체는 보안 쟁점을 논의하지 않는다고 말한다. 따라서 그 착신자 식별자는 발신자 신원이나 권한 부여의 증거가 아니다.

Lu Heng의Running-Code Primacy는 분석적 규율을 제공한다: 필드, 구성된 번호, 표준 레이블은 입력이고; 수신자의 실제 결정과 이후 링크 동작은 다른 현실 계층이다.Minimum Initial Specification은 접속 허용이 로컬에 남는 동안 공통 계층이 좁게 유지될 수 있는 이유를 설명한다.

스위치는 서비스의 이름을 불렀다. 엔드포인트는 여전히 그 서비스가 이 호출에서 존재하도록 허용될지를 결정해야 했다. RFC 1618은 거부를 이르고, 보이고, 귀속 가능하게 만들었으며—착신 회선이 관리자를 대변하는 것을 거부했다.

출처