RFC 3084: 정책 전달은 상태 합의가 아니었다

요약

RFC 3084는 각 COPS-PR Decision 메시지를 전부 성공하거나 전부 실패하는 트랜잭션으로 만들었다. PEP는 요청된 성공 또는 실패 보고서를 반환했고, 실패한 트랜잭션은 마지막 정상 상태로 롤백했다.
그 영수증이 이후의 모든 사실을 확정하지는 않았다. 연결이 끊긴 동안 장치는 캐시된 정책을 유지할 수 있었고, 로컬 상태가 바뀔 수 있었으며, 재연결에는 명시적 동기화 절차가 필요했다. 아니면 양쪽이 여전히 합의했다고 가정해야 했다.

밀어 넣은 규칙은 다른 기계의 현실로 들어갔다

정책 서버가 이전 분류기를 제거하고 그 대체물을 설치하는 하나의 Decision 메시지를 보낸다고 상상해 보자. TCP가 바이트를 전달한다. 네트워크 장치는 Success로 응답한다. 그 트랜잭션에 대해 COPS-PR은 유용한 영수증을 만들어 낸 것이다.

이제 연결을 끊어 보자. 장치는 활성 Request-State를 계속 사용한다. 보드가 교체되거나, 로컬 기능이 바뀌거나, 캐시된 상태가 수명에 도달할 수 있다. 연결이 돌아왔을 때 어느 사실이 권위 있는가? 서버가 의도한 Policy Information Base인가, 마지막 성공 보고인가, 아니면 장치 안에 여전히 존재하는 구성인가?

2001년 3월에 발표된 RFC 3084는 정책 프로비저닝을 위한 COPS 사용법, 즉 COPS-PR을 정의했다. Policy Decision Point는 모델링된 정책을 Policy Enforcement Point에 공급했다. Policy Information Base는 프로비저닝 클래스와 인스턴스의 이름을 정했고, PRID는 개별 인스턴스를 식별했다. 이 문서는 하나의 보편적 정책 모델을 정의하지 않았다. QoS나 보안 같은 영역을 위한 모델을 운반하는 트랜잭션과 동기화 기계를 정의했다.

그 구분은 이 역사를 RFC 3060과 분리해 둔다. PCIM은 재사용 가능한 정책 정보를 설명하면서 평가 알고리즘은 구현에 맡겼다. COPS-PR은 또 다른 경계를 다뤘다. 서버와 장치가 프로비저닝된 상태를 어떻게 설치하고, 승인하고, 캐시하고, 제거하고, 조정하는가였다.

하나의 메시지는 결과가 아니라 트랜잭션이었다

DEC에는 여러 결정이 들어갈 수 있었다. 제거는 설치보다 먼저 왔다. 이는 타이밍이 아니라 우선순위를 해결하기 위해서였다. 전체 DEC는 하나의 트랜잭션으로 성공하거나 실패해야 했다. 요청된 실패가 나면 PEP는 Failure 보고를 반환하고 트랜잭션이 일어나지 않은 것처럼 롤백했다. 이로써 서버는 대체 정책을 설치할 수 있을 때만 이전 정책을 제거할 수 있었다.

모든 DEC에는 요청에 따른 Report State 메시지가 필요했다. Success는 PEP가 요청된 조치를 취했음을 보고했다. Failure는 거부를 보고하고 마지막 성공 트랜잭션을 복원했다. 이는 단순히 명령을 보낸 것보다 강한 증거였다. 그래도 집행 지점에서 멈췄다. 패킷 추적도, 큐 측정도, 애플리케이션이 의도된 서비스를 받았다는 증명도 아니었다.

RFC 3084는 이전에 설치된 구성이 나중에 실패할 때 더 어려운 한계를 드러냈다. 그런 비요청 실패는 깔끔한 요청-응답 트랜잭션에 속하지 않았다. 문서는 비동기 조건에서는 올바른 상태가 모호하기 때문에 롤백이 불가능할 수 있다고 경고했다. 즉시 실패한 DEC에는 알려진 정상 체크포인트가 있었지만, 시간과 로컬 변경이 그 확실성을 지울 수 있었다.

호환성에는 비대칭 실패 규칙이 있었다

PIB는 진화하도록 설계되었다. 새 PDP가 이전 PEP가 이해하지 못하는 프로비저닝 클래스를 보내면, PEP는 오류를 보고하고 이전 정상 상태로 돌아가야 했다. PEP가 새 클래스를 알지만 PDP가 모르면 그 클래스는 그냥 비어 있는 채로 도착했다. 사용 중단된 클래스에는 또 다른 규칙이 따랐다.

이 규칙들은 피해를 제한했지만 버전을 동등하게 만들지는 않았다. 성공한 트랜잭션은 교환된 객체에 대한 합의를 증명했다. 양쪽이 같은 미사용 클래스를 보유하는지, 장치 기능을 동일하게 해석하는지, 같은 로컬 포워딩 메커니즘을 만들 것인지는 증명하지 않았다.

이 아키텍처는 권한을 의도적으로 집중시켰다. Client-Type으로 식별되는 각 정책 영역마다 하나의 연결은 하나의 서버가 구성을 갱신한다는 뜻이었다. RFC 3084는 PEP가 연결된 동안 구성이 로컬 콘솔 변경조차 사실상 잠겼다고 말했다. 이는 경쟁하는 작성자를 줄였다. 또한 연결, 서버 신원, 상태 데이터베이스를 제어 경계의 일부로 만들었다.

연결 끊김은 정책을 캐시된 권위로 바꿨다

통신이 실패하면 PEP는 마지막 PDP를 시도하고, 그다음 설정된 보조 PDP를 시도했다. 그동안 활성 Request-State는 계속 정책을 지배했다. 재연결 시 LastPDPAddr 객체가 어느 서버의 결정이 캐시된 채 남아 있는지 알려 줄 수 있었다. 서버는 Synchronize State Request를 발행해 PEP가 알려진 모든 Request-State에 대한 요청을 다시 내도록 할 수 있었다. 그러면 PDP는 일관된 알려진 상태를 세우기 위해 필요한 개별 PRID나 접두사에 대한 삭제를 보냈다.

서버가 동기화를 요청하지 않으면 클라이언트는 서버가 자신을 인식하고 있으며 현재 PEP 상태가 올바르다고 가정할 수 있었다. 그것은 운영상의 지름길이지 독립적 증명이 아니었다. 연결이 끊긴 동안 이루어진 변경은 여전히 보고되어야 했다. 관리적 타임아웃이 지나면 양쪽은 각자의 연결 손실 타이머에 따라 오래된 Request-State를 삭제했다.

후대의 기록은 프로토콜을 다시 쓰지 않으면서 관점을 더한다. SPPI는 PIB를 위한 언어를 제공했고, 이후 RFC들은 COPS-PR을 둘러싼 QoS, 프레임워크, 사용 피드백 모델을 구축했다. 2016년 IETF는 제한된 배포와 구성 관리 작업이 NETCONF와 YANG으로 이동한 점을 들어 RFC 3084와 관련 문서를 Historic으로 옮겼다. “제한적”은 존재하지 않았다는 뜻이 아니며, Historic 지위는 살아남은 어떤 장치가 무엇을 실행했는지 식별하지 않는다.

RFC 3084의 오래 남는 교훈은 영수증 연쇄의 형태다. PDP의 의도, PEP의 원자적 수용, 요청된 RPT, 캐시된 Request-State, 재동기화, 설치된 로컬 메커니즘, 트래픽 결과는 서로 관련된 사실이지 하나의 사실이 아니다. 신뢰할 수 있는 전달은 정책 트랜잭션을 움직일 수 있다. 네트워크가 어떤 정책을 유지했는지는 오직 조정과 관찰을 통해서만 보여 줄 수 있다.

정책 서버는 규칙을 밀어 넣었다. 재연결은 장치가 유지한 것을 조정해야 했다: RFC 3084

왜 중요한가

요약

밀어 넣은 규칙은 다른 기계의 현실로 들어갔다

하나의 메시지는 결과가 아니라 트랜잭션이었다

호환성에는 비대칭 실패 규칙이 있었다

연결 끊김은 정책을 캐시된 권위로 바꿨다

출처

프로필 심층 컨텍스트

Strategic Circle

Leadership Alliance

Strategic Circle 브리핑

Leadership Alliance 브리핑

요약

밀어 넣은 규칙은 다른 기계의 현실로 들어갔다

하나의 메시지는 결과가 아니라 트랜잭션이었다

호환성에는 비대칭 실패 규칙이 있었다

연결 끊김은 정책을 캐시된 권위로 바꿨다

출처

프로필 심층 컨텍스트

Strategic Circle

Leadership Alliance

추천 읽을거리