RFC 3186: 숨겨진 운영자 경로 위의 투명 PPP 링크

요약

RFC 3186은 중간 네트워크를 제거하는 대신 양단에서 한두 개의 헤더 옥텟을 다시 써서 공유 MAPOS 네트워크가 투명한 점대점 PPP 링크처럼 보이게 했다.
실제 경로는 두 가지 포트 모드, 사용되지 않는 MAPOS 주소 쌍, 양방향의 안정적인 포워딩, 경로별 격리에 의존했다. OAM 데이터베이스는 경로를 기술하였으나 프레임을 포워딩하지는 않았다.

2001년 12월에 발표된MAPOS/PPP Tunneling mode는 Informational 문서였다. IESG 노트는 이례적으로 직접적이었다. 이 문서는 IETF 워킹그룹 산출물도, Standards Track 문서도 아니며, 표준 트랙 문서에 기대되는 검토 깊이를 반드시 거치지 않았다는 것이었다. 이 메모는 하나의 설계와 하나의 참조 실험을 기록했다. 광범위한 채택을 인증하지는 않았다.

이 설계는 유사성을 이용했다. SONET/SDH 상의 PPP는 프레임 시작부에 고정된 주소 및 제어 값을 놓는다. MAPOS는 자신의 목적지를 거의 같은 공간에 배치했다. 수신 측 스위치는 고정된 PPP 바이트를 원단 고객 포트에 할당된 MAPOS 주소로 교체할 수 있었다. 패브릭은 그 값으로 포워딩했다. 송신 측 스위치는 고정 PPP 값을 복원했다. MAPOS 버전 1은 한 옥텟을, MAPOS 16은 두 옥텟을 다시 썼다.

이것은 고객 프레임을 감싸는 또 다른 캡슐화가 아니었다. RFC 3186은 헤더 오버헤드를 추가하지 않는다고 강조했다. 그러나 "새 헤더 없음"이 "새 상태 없음"을 의미하지는 않았다. 상태는 스위치 안으로 이동했다. 피어 주소, 재작성 함수, 포트 모드, 신호 라벨, 내부 경로, 격리 규칙이 그것이었다.

포트를 PPP 터널링 모드로 전환하는 것은 여러 동작의 묶음이었다. 스위치는 고객 측 포트에서 Node Switch Protocol과 Switch-Switch Protocol의 활동을 비활성화하고, 그 포트에서 MAPOS 브로드캐스트 및 멀티캐스트 포워딩을 비활성화하고, 선택된 스크램블링 모드에 맞춰 SONET/SDH Path Signal Label을 변경하고, 지정된 목적지로의 재작성을 활성화했다. 네이티브 MAPOS로 되돌아가는 것은 이 순서를 역순으로 되감는 것이었다.

설정 화면은 이 순서를 하나의 모드 값으로 압축해서 보여줄 수 있다. 실제 코드는 그렇지 않았다. 각 동작은 각자의 성공과 실패를 가졌다. 라벨은 바뀌었는데 재작성은 바뀌지 않을 수 있고, 한쪽 끝이 먼저 모드에 진입할 수 있으며, 내부 도달 가능성은 여전히 수렴 중일 수 있다. 따라서 역사적으로 유용한 대상은 "PPP 모드 = true"가 아니라 전환 과정과 그 증명 기록이다.

경로 수립은 제어 경계를 명확히 만들었다. 운영자는 두 에지 포트에 해당하는 두 개의 미사용 MAPOS 주소를 골랐다. 양쪽 포트를 설정하고, 경로와 프레임 포워딩이 양방향 모두에서 안정될 때까지 기다린 뒤, 그제서야 고객 측 링크를 올리도록 했다. 그 지점에 도달하기 전까지 PPP LCP 제어 메시지가 투명하게 통과할 수는 없었다. 도달하기 전에는 링크가 다운 상태로 유지되어야 했다.

고객은 링크를 봤다. 운영자는 그 링크를 가능하게 한 주소 쌍을 쥐고 있었다. RFC 3186은 그 쌍을 경로 데이터베이스에서 관리할 것을 권고했는데, 부분적으로는 중복 경로를 막기 위해서였다. 예시 행에는 사용자, 속도, 프레이밍 모드, 주소 쌍, 상태가 기록되어 있었다. 그리고 메모는 오늘날의 제어 패널들이 자주 흐리는 경계를 그었다. 그 데이터베이스는 운영, 관리, 유지보수, 프로비저닝을 위한 것이었다. 프레임 포워딩에는 사용되지 않았다.

따라서 "up" 상태의 행은 서비스에 대한 진술이지, 서비스의 작동 메커니즘이 아니고, 패킷 전달 증명도 아니었다. 내부 SSP 상태가 여전히 도달 가능성을 선택했다. 에지 스위치가 여전히 재작성을 수행했다. 포트는 여전히 활성화되어야 했다. 기록이 정확하더라도 이후 프레임이 유실될 수 있고, 포워딩이 바뀌었는데도 기록이 오래된 채 남을 수 있었다.

제거 과정에서도 선언과 실행은 분리되어 있었다. 운영자는 두 고객 측 포트를 비활성화하고, 경로 데이터베이스를 갱신할 수 있으며, 이후에 분리된 포트를 네이티브 MAPOS 기본값으로 되돌릴 수 있었다. 목적지 포트가 비활성화된 이후 도착한 프레임은 조용히 버려졌다. 그 침묵은 발신자에게 어느 단계가 일어났는지, 인벤토리가 따라잡았는지 알려주지 않았다.

장애 가시성은 설계상 비대칭이었다. 각 고객 광 경로는 자신의 로컬 MAPOS 에지에서 종단되었다. 가까운 CPE-스위치 링크가 끊기면 가까운 쪽은 SONET/SDH 경보를 봤다. 멀리 있는 물리 인터페이스는 그 경보가 클라우드를 통과해 전달되지 않기 때문에 업 상태를 유지할 수 있었다. PPP LCP Echo가 만료된 뒤에야 멀리 있는 종단은 결정적인 분열을 보고했다. 링크 업, 라인 프로토콜 다운.

그 타임아웃은 유용한 증거였지만 한계가 있었다. 기대된 에코 트래픽이 시간 내에 완료되지 않았다는 것만 보여줄 뿐, 절단 위치를 찾아주거나, 스위치를 특정하거나, 일방향 손실과 전체 장애를 구분하거나, 애플리케이션이 무엇을 경험했는지 증명하지는 못했다. 클라우드 내부에서 SSP는 토폴로지 변화에 반응할 수 있었지만 종단은 여전히 자신의 단대단 증상만 알고 있었다.

투명성이 또한 공유 링크를 전용 링크로 만들지는 않았다. MAPOS에는 프로토콜 수준의 품질 제어(QoS)가 없었고, POS에는 흐름 제어가 없었다. RFC 3186은 단대단 처리량을 보장하기 어렵다고 말하고, 운영자에게 충분한 스위치 간 대역폭을 프로비저닝할 것을 요구했으며, 과잉 구독 설계에는 포트별 공정성을 권고했다. 전용선 같은 외관은 공유된 용량과 운영자가 고른 큐잉과 공존할 수 있었다.

참조 구현은 측정된 지연시간을 제공했을 뿐, 보편적 진실이 아니었다. 그 테스트는 명명된 장비, 30% 부하의 단방향 OC12c 트래픽, 고정된 프레이밍 선택, 프레임 크기당 150초짜리 25회 시행, 측정자의 분해능에 맞춰 반올림된 신뢰 구간을 사용했다. 그 조건에서 MAPOS 스위치는 비교 대상 라우터보다 빨랐다. 그 결과가 모든 부하, 손실 패턴, 공정성 정책, 벤더, 애플리케이션을 측정한 것은 아니다.

보안 절은 "투명"이 슬로건으로서 가장 위험해지는 지점이다. 메모는 CPE가 터널링 모드에서 내부 MAPOS 네트워크를 직접 제어할 수 없으며 다른 스트림을 주입하기도 어려울 것이라고 주장했다. 그럼에도 경로별 격리를 극히 중요하다고 부르고, 경로 중복을 경고하며, 모든 스위치가 격리를 구현하기 전까지는 네이티브 MAPOS와 PPP 터널링을 섞지 말라고 조언했다.

기반이 되는 프레이밍에는 발신 주소 필드가 없었다. 혼합 환경에서 그 부재는 격리를 더 어렵게 만들었다. 종단이 패브릭을 볼 수 없다는 것은 패브릭이 두 경로를 절대 혼동하지 않으리라는 증명이 아니었다. 올바른 분리는 참여하는 모든 스위치와 운영자의 구성에 대한 주장으로 남았다.

따라서 RFC 3186은 반복적으로 나타나는 인터넷의 거래를 기록한다. 추상화는 복잡한 공유 네트워크를 익숙한 점대점 링크로 사용 가능하게 만들었다. 동시에 결정적인 증거를 공급자 쪽에 집중시켰다. 무슨 일이 있었는지 재구성하려면 서비스 주문, 주소 쌍, 두 포트 식별자, 전환 단계, 재작성 목적지, 방향별 수렴, 데이터베이스 개정, 격리 상태, keepalive 관측, 프레임 증거가 필요하다. 고객의 깔끔한 인터페이스는 그 역사의 한 층일 뿐이다.