요약

  • RFC 10066은 PCEP LSP 하나에서 여러 경로를 신호로 전달하도록 한다. 각 세그먼트 목록에는 식별자와 선택적인 가중치를 붙일 수 있다.
  • PCE는 자신의 계산 능력과 PCC가 밝힌 설치 능력 중 낮은 유효 한도를 지켜야 한다. 헤드엔드는 초과 경로에 오류를 반환한다.

제어기 화면에서 선을 하나 더 긋는 일은 쉽다. 라우터가 그 선을 상태로 보관하고 실제 흐름을 보내는 일은 다르다. IETF가 2026년 10월 Proposed Standard로 발행한 RFC 10066은 SR Policy 후보 경로의 한계를 바꾼다. 기존 PCEP 신호는 후보 경로에 세그먼트 목록 하나만 실었지만, 이제 한 LSP가 여러 목록을 담을 수 있다.

PATH-ATTRIB 객체가 각각의 경로를 구분하고 경로 ID를 부여한다. 가중치는 선택 사항이며 빠지면 1로 처리한다. 가중치 0은 지시 내용을 남긴 채 해당 목록의 트래픽을 빼는 데 쓸 수 있다. 전부 0이면 후보 경로가 무효다. 3 대 1이라는 비율은 목표로 한 흐름 배분이지, 실제 바이트의 75%가 한쪽으로 갔다는 측정 결과가 아니다.

핵심 협상은 MULTIPATH-CAP에서 이뤄진다. PCE는 계산 가능한 정방향 경로 수를, PCC는 전달면에 설치 가능한 수를 알린다. 두 피어가 세션에서 지원 여부를 먼저 합의하면 개별 LSP가 다른 한도를 둘 수 있다. PCE는 두 유효 수치 중 작은 값을 넘기지 못한다. 0은 무제한을 뜻하지만 RFC의 보안 절은 운영자가 0이 아닌 상한을 정하라고 권한다. 고장 나거나 탈취된 제어기가 헤드엔드의 상태를 지나치게 늘릴 수 있기 때문이다.

PCC가 자신이 알린 수보다 많은 경로를 받으면 PCErr 유형 19, 값 36을 보내야 한다. 다중 경로 협상 없이 PATH-ATTRIB이 오면 유형 10, 값 45다. 한편 PCC가 이미 설치된 경로를 PCRpt로 보고할 때, PCE는 그 수가 자신의 계산 한도를 넘는다는 이유로 보고를 버릴 수 없다. 현장의 상태 보고와 새로운 경로 계산 요청은 같은 명령이 아니다.

경로가 늘면 PCEP 메시지와 LSP별 상태도 커진다. 각 경로의 MTU와 지연 시간이 다를 수 있고, 가중치 변경은 흐름을 다시 배치해 혼잡 제어와 경로 MTU 탐색을 흔든다. RFC는 운영자가 협상 한도, 경로 ID, 가중치, 역방향 연결과 오류를 볼 수 있어야 한다고 적는다. 이 문서에는 실사용 장비 수나 측정된 성능 개선치가 없다. 다음으로 필요한 자료는 부하가 걸린 제어기와 헤드엔드가 실제로 무엇을 교환하고 설치했는지 보여주는 기록이다.

출처