요약

  • RFC 3429는 사용자 평면 OAM 패킷을 식별하기 위해 예약된 MPLS 레이블 값 14를 할당하면서, 상세 기능은 ITU-T 권고 Y.1711에 맡겼다.
  • PHP(최종 이전 홉 팝핑)를 사용하면 OAM 레이블과 페이로드가 일반 최상위 레이블이 제거된 후 OAM 가능한 MPLS 이그레스에 도달할 수 있었다. MPLS가 아닌 엔드포인트는 다른 사례로, 당시 Y.1711 범위에서 명시적으로 제외되어 있었다.
  • 살아남은 TTSI는 수신 LSR(라벨 스위치 라우터)을 식별하는 데 도움을 주었다. 그러나 LSP가 정상이거나, 고객 패킷이 도달했거나, 운영자가 경보에 대응했다는 것을 입증하지는 않았다.

MPLS 경로의 마지막 라우터는, 마지막 라우터라는 이유만으로 더 적은 일을 하도록 요청받을 수 있었다. 이그레스가 선속(line rate)에서 두 번의 레이블 조회를 수행할 수 없다면 PHP를 요청할 수 있었다. 즉, 업스트림 라우터가 포워딩 전에 최상위 레이블을 제거하는 것이다. 일반 트래픽의 경우, 이그레스가 처리할 레이블이 하나 줄어든다는 의미였다. 운영과 유지보수(OAM)의 관점에서는 더 정확한 질문이 제기되었다. 외부 레이블이 사라진 후, 무엇이 진단 패킷을 사용자 트래픽과 구별해 주는가?

RFC 3429의 답은 새로운 모니터링 시스템이 아니었다. 예약된 코드포인트였다. 이 문서는RFC 3032가 예약한 값 중 하나인 레이블 값 14를 "OAM Alert Label"에 할당했다. 그 레이블을 실은 패킷은 MPLS OAM 패킷으로 인식될 수 있었다. 할당 범위는 좁았다. MPLS 계층에서 패킷 클래스를 식별할 뿐, 모든 페이로드 기능을 정의하거나, 구현을 강제하거나, 경로를 인증하지 않았다.

레이블이 남아 있어야 했던 이유

이 설계는 서로 다른 세 가지 작업을 연결했다.ITU-T Y.1711은 사용자 평면 MPLS OAM 기능과 그 페이로드 맥락을 규정했다.RFC 3031은 PHP를 포함한 MPLS 아키텍처를 제공했다. RFC 3429는 OAM 패킷이 그 아키텍처 안에서 계속 식별 가능하도록 하는 레이블 값을 할당했다.

PHP를 요청하기 위해 사용되는 제어 평면 값은 implicit-null, 즉 레이블 3이었다. 이 값은 시그널링으로 배포되지만 패킷 자체에는 절대 나타나지 않는다. 최종 이전 LSR에 최상위 레이블을 대체하지 말고 팝하라고 알려주는 것이다. OAM Alert Label은 달랐다. OAM 패킷에 실린 실제 인밴드 레이블이었다. 따라서 RFC 3429의 사례 1은 PHP가 제거된 포워딩 레이블을 계속 전달하도록 요구하지 않았다. 최종 이전 LSR은 그 최상위 레이블을 제거하고 OAM Alert Label과 OAM 페이로드를 그대로 포워딩했다.

이그레스에서는 남은 최상위 레이블이 중요했다. 최종 노드가 OAM을 지원하는 MPLS LSR이라면, 원래 최상위 레이블이 사라졌음에도 도착한 패킷을 OAM으로 인식할 수 있었다. 패킷의 TTSI, 즉 Trail Termination Source Identifier는 그 엔드포인트에게 이를 발생시킨 수신 LSR을 알려 주었다. 정체성은 PHP가 제거하는 외부 포워딩 레이블에서 진단 패킷 내부에 실린 식별자로 이동한 것이다.

이것은 유용하지만 한정된 연속성이다. TTSI는 OAM 메커니즘이 지정한 송신원을 식별할 뿐, 그 자체로 모든 중간 홉이 올바르게 포워딩했는지, 고객 데이터가 동일한 조건을 따랐는지, 원격 애플리케이션이 무엇이든 수신했는지를 인증하지 않는다. 레이블 14가 CV, FDI, BDI 등 Y.1711 기능 중 하나가 수신자에 의해 처리되었다는 뜻도 아니다. 레이블은 인식 경계이지 결과 영수증이 아니다.

"목적지가 PHP를 요청했다"의 두 가지 의미

RFC 3429는 레이블 분배 교환에서 비슷하게 보일 수 있는 두 가지 사례를 구분했다. 첫 번째 사례에서 최종 노드는 여전히 제어 평면과 데이터 평면을 갖춘 MPLS LSR이었다. 선속에서 두 번의 조회를 수행할 수 없어 PHP를 요청한 것이다. 최종 이전 LSR이 일반 최상위 레이블을 팝한 후에도 이 노드는 OAM 레이블과 페이로드를 읽을 수 있었다. 이 경우 Y.1711 OAM이 작동할 수 있었다.

두 번째 사례에서 최종 노드는 MPLS 레이블 조회나 처리 능력이 전혀 없고 레이블이 붙은 패킷을 전혀 인식하지 못했다. 이 노드도 implicit-null/PHP를 요청할 수 있었지만, 그렇다고 OAM 엔드포인트가 되지는 않았다. RFC 3429는 당시의 Y.1711 기능이 첫 번째 사례에만 적용되며, 두 번째 사례에 대한 적용은 추가 연구가 필요하다고 명시했다. 또한 이 RFC는 통신사 지원 통신사(carrier-supporting-carrier) 시나리오도 향후 연구 과제로 남겨 두었다. 따라서 동일한 제어 평면 요청이 동일한 데이터 평면 능력을 의미하지는 않았다.

이 구분은 운영상 중요하다. 진단이 능력이 없는 엔드포인트에서 멈춘다면, 운영자는 그 침묵을 정상 경로의 증거나 PHP 자체의 실패 증거로 안전하게 재해석할 수 없다. 명세는 MPLS OAM을 지원하지 않는 최종 LSR이 패킷을 폐기한다고 말한다.RFC 3031의 무효 레이블 규칙도 알 수 없는 레이블을 무심코 제거하고 그 결과를 일반 IP로 포워딩하는 것을 막는다. 그렇게 하면 패킷의 의미가 바뀌거나 트래픽이 노출될 수 있기 때문이다. 가시적인 폐기가 지어낸 해석보다 안전할 수 있지만, 그래도 증거 공백을 남긴다.

레지스트리 항목은 설치된 능력이 아니다

IANA MPLS Label Values 레지스트리는 여전히 값 14를 OAM Alert Label로 기록하고 RFC 3429를 가리킨다. 이 연속성 덕분에 프로토콜 문서는 안정적인 의미를 참조할 수 있다. 그러나 이는 오늘날 어떤 라우터가 그 레이블을 구현하는지, 어떤 OAM 프로파일이 활성화되어 있는지, 특정 LSP에서 PHP가 사용되는지, 운용 중인 장치가 폐기를 어떻게 보고하는지에 대해서는 아무것도 말해 주지 않는다.

RFC 3429는 2002년 11월의 정보성(Informational) RFC이지 배포 보고서가 아니다. 그 역사적 의의는 역할 분담에 있다. ITU-T가 OAM 메커니즘을 정의하고, IETF가 그 패킷을 식별하기 위한 MPLS 레이블을 예약했으며, 본문은 엔드포인트가 MPLS/OAM 인지 상태를 유지해야 하는 PHP 경계를 명시했다. 표준화의 결과는 패킷을 위한 공유 어휘였지, 네트워크를 위한 보증 서비스가 아니었다.

실제 경로를 평가하려면 운영자는 별도의 근거가 필요하다. 시그널링된 레이블 동작, PHP 전후의 스택, 이그레스의 지원 여부, OAM 페이로드의 수신과 파싱, TTSI 해석, 해당 OAM 기능의 결과 등이다. 데이터 평면 서비스 근거는 다시 별도로 남는다. 이러한 연결점 없이는, "OAM 활성화됨", "레이블 14 등록됨", "LSP 작동 중"은 서로 다른 계층의 세 가지 진술이지, 고객 트래픽이 도달했다고 말하는 세 가지 서로 바꿔 쓸 수 있는 방식이 아니다.

출처