Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

PCEP 구성

PCEP 개요

PCE(Path Computation Element)는 네트워크 그래프를 기반으로 네트워크 경로 또는 경로를 계산하고 연산 제약을 적용할 수 있는 엔티티(구성 요소, 애플리케이션 또는 네트워크 노드)입니다. PCC(Path Computation Client)는 PCE에 의해 수행되는 경로 계산을 요청하는 모든 클라이언트 애플리케이션입니다. PCEP(Path Computation Element Protocol)는 PCC와 PCE 간에, 또는 2대의 PCE(RFC 5440에서 정의)를 통신할 수 있게 합니다.

PCEP는 IETF(INTERNET ENGINEERING TASK FORCE) WORKING Group에서 정의한 TCP 기반 프로토콜로, PCEP 세션을 관리하고 멀티도메인 트래픽 엔지니어링 LSP(트래픽 엔지니어링(TE) LSP)에 대한 경로를 요청하고 전송하는 데 사용되는 메시지와 객체 집합을 정의합니다. PCE는 PCC의 외부 LSP에 대한 경로 계산을 수행할 수 있는 메커니즘을 제공합니다. PCEP 상호 작용에는 PCC가 PCE로 전송한 LSP 상태 보고서와 외부 LSP에 대한 PCE 업데이트가 포함됩니다.

그림 1 RSVP-MPLS 지원 네트워크의 스테이트FUL PCE 아키텍처의 클라이언트측 구현에서 PCEP의 MPLS 설명하고 트래픽 엔지니어링(TE) 있습니다.

그림 1: PCEP 세션PCEP 세션

TCP 기반 PCEP 세션은 PCC를 외부 PCE에 연결합니다. PCC는 PCEP 세션을 시작하고 PCEP 세션 동안 PCE에 계속 연결됩니다. PCEP 세션이 진행하는 동안 PCC는 stateful PCE에서 LSP 매개 변수를 요청합니다. PCE에서 하나 이상의 LSP 매개 변수를 수신할 때 PCC는 LSP에 트래픽 엔지니어링(TE) 신호를 전송합니다. PCEP 세션이 종료되면, 기저 TCP 연결이 즉시 폐쇄되고 PCC는 PCEP 세션을 다시 설정하려고 시도합니다.

따라서 PCEP 기능은 다음과 같습니다.

  • PCC와 stateful PCE 간의 LSP 터널 상태 동기화—활성 stateful PCE 연결이 탐지되면 PCC가 LSP 상태 동기화라는 프로시저에서 모든 LSP를 이 PCE에 위임합니다. PCEP는 PCC LSP 상태를 PCE에 동기화할 수 있습니다.

  • LSP 터널을 stateful PCE로 제어 위임—Active stateful PCE는 대역폭, 경로(ERO) 및 우선 순위(설정 및 보유)와 같은 컴퓨팅 경로에 대한 하나 이상의 LSP 속성을 제어합니다. PCEP는 경로 계산을 위해 LSP의 이러한 위임 기능을 제공합니다.

  • PCEP 세션 내부 및 전반의 경로 계산의 타이밍 및 시퀀스에 대한 Stateful PCE 제어 – Active stateful PCE는 대역폭, 경로(ERO) 및 우선 순위(설정 및 보유)와 같은 하나 이상의 LSP 속성을 수정합니다. PCEP는 이러한 새로운 LSP 속성을 PCE에서 PCC로 전달한 후, PCC가 지정된 경로에서 LSP에 다시 신호를 전송합니다.

RSVP-트래픽 엔지니어링(TE) 위한 경로 계산 요소 프로토콜 지원 개요

이해 MPLS RSVP-트래픽 엔지니어링(TE)

트래픽 엔지니어링(트래픽 엔지니어링(TE))은 운영 네트워크의 성능 최적화를 다루며 주로 기존 물리적 토폴로지로 트래픽 플로우를 매핑합니다. 트래픽 엔지니어링은 내부 게이트웨이 프로토콜(IGP)에서 선택한 최단 경로에서 네트워크 전체로 트래픽 흐름을 이동하고 네트워크에서 가장 덜 정체된 물리적 경로로 이동하는 기능을 제공합니다.

고밀도의 대규모 네트워크의 트래픽 엔지니어링의 경우, MPLS 모델에서 현재 경쟁 솔루션보다 낮은 비용으로 오버레이 모델에서 사용할 수 있는 대부분의 기능을 통합적으로 제공할 수 있기 때문에 이러한 기능을 구현할 수 있습니다. 네트워크 구현의 주된 MPLS 트래픽 엔지니어링 이유는 네트워크를 통해 흐르는 트래픽 경로를 제어하는 것입니다. 네트워크 구현의 가장 큰 MPLS 트래픽 엔지니어링 ATM의 트래픽 엔지니어링 기능과 함께 IP의 CoS(Class-of-Service) 차별화를 제공했다는 것입니다.

네트워크 MPLS 레이블 스위칭을 사용하여 데이터 플레인 정보가 포워드됩니다. 고객 에지(고객 에지(CE)) 라우터에서 PE(Provider Edge) 라우터에 도착하는 패킷에는 레이블이 적용된 다음, egress PE 라우터로 전달됩니다. 이 레이블은 egress 라우터에서 제거되고 IP 패킷으로 해당 목적지로 전달됩니다. LSRS(Label-Switching Router)는 MPLS 레이블 배포 프로토콜을 사용하여 LSRS 간에 트래픽을 전달하는 데 사용되는 레이블의 의미를 전달합니다. RSVP-트래픽 엔지니어링(TE) 는 표준 피어가 레이블 스위칭 라우터(LSR) 매핑에 대해 학습할 수 있도록 하는 그러한 레이블 배포 프로토콜 중 하나입니다.

라우터에서 MPLS RSVP를 모두 활성화하면 MPLS RSVP의 클라이언트가 됩니다. RSVP 소프트웨어의 주된 Junos OS 목적은 LSP(Label-Switched Path) 내에서 동적 시그널링을 지원하는 것입니다. RSVP는 IP 유니캐스트 및 멀티캐스트 플로우와 같은 리소스를 예약하고 애플리케이션에 대한 QoS(Quality-of-Service) 매개 변수를 요청합니다. 이 프로토콜은 네트워크로 확장되어 MPLS 트래픽 엔지니어링 네트워크의 트래픽 엔지니어링에 사용할 수 있는 LSP를 RSVP가 설정할 MPLS 있습니다.

MPLS RSVP를 결합하면 레이블은 RSVP 플로우와 연결됩니다. LSP가 설정되면, 경로를 통해 트래픽은 LSP의 ingress 노드에 적용된 레이블에 의해 정의됩니다. 레이블과 트래픽의 매핑은 서로 다른 기준을 사용하여 수행됩니다. 특정 노드에 의해 동일한 레이블 값을 할당하는 패킷 세트는 동일한 FEC(Forwarding Equivalence Class)에 속하며 RSVP 플로우를 효과적으로 정의합니다. 이러한 방식으로 트래픽을 LSP에 매핑하면 LSP를 LSP 터널이라고 합니다.

LSP 터널은 한방향 레이블 스위칭 경로를 구축하는 방법을 제공합니다. RSVP-트래픽 엔지니어링(TE) LSP 설정에 대한 PATH 및 RESV 객체에 사용되는 기존 객체를 수정하고 새로운 객체를 수정하여 RSVP 코어 프로토콜을 구축합니다. LRO(LABEL-REQUEST object), RRO(RECORD-ROUTE object), LABEL 객체, ERO(EXPLICIT-ROUTE object)와 같은 새로운 객체는 LSP 터널 구축을 위해 필수인 LRO 및 LABEL 객체를 제외하고 RSVP 프로토콜과 관련해 선택 사항입니다.

일반적으로, RSVP-트래픽 엔지니어링(TE) ingress에서 egress 라우터로의 프레임 전송을 보장하는 레이블 스위칭 경로를 구축합니다. 그러나 새로운 트래픽 엔지니어링 기능을 통해 다음과 같은 MPLS 지원됩니다.

  • 전체 또는 부분 명시적 경로(RFC 3209)를 사용하여 레이블 스위칭 경로를 설정할 수 있는 가능성.

  • 대역폭 및 링크 속성과 같은 요구 사항을 충족하는 링크에 대한 제약 기반 LSP 설정

  • 엔드포인트 제어. ingress 및 egress 라우터에서 LSP 터널을 설정 및 관리하는 데 연관됩니다.

  • 링크 관리 . 링크 리소스를 관리하여 트래픽 엔지니어링 LSP의 리소스 인식 라우팅을 실행하고 레이블을 프로그래밍하는 MPLS 관리.

  • MPLS 보호가 필요한 LSP를 관리하고 이러한 LSP에 백업 터널 정보를 할당하는 FRR(Fast Reroute)을 제공합니다.

현재 MPLS RSVP-트래픽 엔지니어링(TE) 제한

트래픽 엔지니어링을 위한 RSVP 확장은 네트워크 활용도를 향상하고 트래픽 클래스의 요구 사항을 충족할 수 있도록 하지만, 오늘날의 MPLS RSVP-트래픽 엔지니어링(TE) 프로토콜 제품군에는 분산된 특성에 내재된 몇 가지 문제가 있습니다. 이는 특히 LSP 하위 세트가 공통 설정을 공유하고 우선 순위 값을 보유한 LSP 우선 순위 클래스 내에서 양분 용량에 대한 경연 기간 동안 많은 문제를 유발합니다. RSVP-트래픽 엔지니어링(TE)의 한계는 다음과 같습니다.

  • 개별 LSP, 장비당 대역폭 요구에 대한 가시성 부족—네트워크의 대역폭 수요에 대한 글로벌 뷰 없이 MPLS RSVP-트래픽 엔지니어링(TE) 네트워크의 ingress 라우터는 LSP를 구축합니다. 네트워크 리소스 활용에 대한 정보는 인터페이스 1개당 트래픽 클래스에 따라 총 예약 용량만큼만 제공됩니다. 개별 LSP 상태는 자체 LSP에 대해 각 레이블 에지 라우터(LER)에서 로컬에서 사용할 수 있습니다. 그 결과, 특히 공통 설정 내에서 요구 패턴과 관련된 많은 문제가 발생하고 우선 순위가 잡혔습니다.

  • RSVP 시그널링의 비동기 및 독립적 특성—RSVP-트래픽 엔지니어링(TE) 경우 경로 설정에 대한 제약이 관리자가 제어합니다. 따라서 LSP 터널에 예약된 대역폭은 관리자가 설정하며 터널을 통해 전송되는 트래픽에 대한 제한을 자동으로 의미하지는 않습니다. 따라서 트래픽 엔지니어링 링크에서 사용할 수 있는 대역폭은 링크에 대해 구성된 대역폭(링크에 대한 모든 예약의 합계)을 제외합니다. 따라서 LSP 터널에 대한 승인되지 않은 요구는 초과 대역폭을 요구하는 LSP는 물론, 트래픽 엔지니어링 링크의 대역폭 요구 사항을 준수하는 다른 LSP의 서비스 저하로 이어질 수 있습니다.

  • 기본 설정 순서로 동적 또는 명시적 경로 옵션에 따라 설정되는 LSP—MPLS RSVP-트래픽 엔지니어링(TE) 네트워크의 ingress 라우터는 도착 순서에 따라 수요에 대한 LSP를 구축합니다. ingress 라우터는 네트워크의 대역폭 수요에 대한 글로벌 뷰가 아니기 때문에, LSP 설정에 대한 기본 설정을 사용해 트래픽을 떨어뜨리거나 대역폭 요구를 초과하는 경우 LSP가 설정되지 않을 수 있습니다.

예를 들어, 그림 2 A와 G가 레이블 에지 라우터(MPLS RSVP-트래픽 엔지니어링(TE))로 구성됩니다. 이들 ingress 라우터는 요구 순서에 따라 독립적으로 LSP를 구축하며 서로의 LSP에 대한 지식이나 제어가 없습니다. 라우터 B, C 및 D는 egress 라우터 E 및 F에 연결하는 중간 또는 전송 라우터입니다.

그림 2: 트래픽 MPLS 예 트래픽 MPLS 예

ingress 라우터는 수요가 도착하는 순서에 따라 LSP를 구축합니다. Router G가 각각 G-F에 대해 2개의 용량 요구 5를 수신하면 G는 G-B-D-F를 통해 2개의 LSP – LSP1 및 LSP2의 신호를 전송합니다. 동일한 방식으로, 라우터 A가 A-E에 대한 용량 10의 세 번째 요구를 수신하면, A-B-C-E를 통해 LSP, LSP3에 신호를 전송합니다. 그러나 A-E LSP에 대한 요구가 10에서 15로 증가하면 B-C 링크의 용량이 낮기 때문에 라우터 A는 동일한(A-B-C-E) 경로를 사용하여 LSP3에 신호를 전송할 수 없습니다.

라우터 A는 A-B-D-C-E 경로를 사용하여 증가하는 LSP3 수요를 시그널로 전송해야 합니다. LSP1 및 LSP2는 수신된 요구 순서에 따라 B-D 링크를 활용하기 때문에 LSP3는 신호 전송되지 않습니다.

따라서, 적절한 최대 플로우 대역폭이 모든 LSP에 사용 가능하기는 하지만, LSP3은 잠재적으로 서비스 저하가 발생할 수 있습니다. 이는 Router A의 글로벌 수요 가시성 부재 및 ingress 라우터 A 및 G의 수요 배치에 대한 체계적인 조율 부재의 기인입니다.

외부 경로 컴퓨팅 엔티티 사용

RSVP-트래픽 엔지니어링(TE) 경로 계산에 대한 현재의 한계를 극복하기 위한 솔루션인 경우, LSP당 글로벌 뷰를 가지고 있는 외부 경로 컴퓨팅 엔티티는 사용 가능한 용량과 독립적으로 네트워크 내 장치당 수요가 필요합니다. MPLS

현재, 오직 온라인 및 실시간 제약 조건 기반 라우팅 경로 계산만 RSVP-MPLS 네트워크에서 트래픽 엔지니어링(TE) 제공됩니다. 각 라우터는 네트워크의 다른 라우터와 독립적으로 제약 기반 라우팅 계산을 실행합니다. 이러한 계산은 현재 사용 가능한 토폴로지 정보를 기반으로 합니다. 즉, 일반적으로 최신이지만 완전히 정확한 정보는 아님. LSP 배치는 현재 네트워크 상태에 따라 로컬에서 최적화됩니다. MPLS RSVP-트래픽 엔지니어링(TE) 터널이 이 터널을 사용하여 CLI. 운영자는 수신 라우터에서 트래픽 엔지니어링(TE) LSP를 구성합니다.

기존 MPLS 트래픽 엔지니어링 기능 외에도 RSVP-트래픽 엔지니어링(TE) 기능은 PCE(Path Computation Element)라고 하는 외부 경로 컴퓨팅 엔티티를 포함하게 확장됩니다. PCE는 외부 제어를 위해 트래픽 엔지니어링(TE) LSP의 경로에 대한 경로를 계산합니다. PCE에 연결하는 ingress 라우터를 PCC(Path Computation Client)라고 합니다. PCC는 PCE에 의해 외부 경로 컴퓨팅을 용이하게 하기 위해 PCEP(Path Computation Client Protocol)로 구성됩니다.

자세한 내용은 외부 경로 컴퓨팅의 구성 요소 를 참조하십시오.

PCC의 LSP에 대한 외부 경로 컴퓨팅을 활성화하려면 트래픽 엔지니어링(TE) 계층 수준에서 lsp-external-controller pccd[edit mpls] 명령문을 [edit mpls lsp lsp-name] 포함합니다.

외부 경로 컴퓨팅의 구성 요소

외부 경로 컴퓨팅 시스템을 구성하는 구성 요소는 다음과 같습니다.

경로 계산 요소

PCE(Path Computation Element)는 네트워크 그래프를 기반으로 네트워크 경로 또는 경로를 컴퓨팅하고 연산 제약 조건을 적용할 수 있는 엔티티(구성 요소, 애플리케이션 또는 네트워크 노드)가 될 수 있습니다. 그러나 PCE는 외부 제어를 위해 구성된 PCC의 LSP 트래픽 엔지니어링(TE) 해당 경로만 계산할 수 있습니다.

PCE는 스테이트FUL(stateful) 또는 스테이트리스(stateless) 상태(stateful) 상태(stateful) 상태(stateless)일 수 있습니다.

  • Stateful PCE—stateful PCE는 네트워크에서 사용중인 컴퓨팅 경로 및 예약된 리소스 세트와 함께 PCE와 네트워크 상태(토폴로지 및 리소스 정보 측면에서)를 엄격한 동기화를 유지 관리합니다. 즉, stateful PCE는 PCC의 새로운 요청을 처리하는 경우 네트워크의 기존 경로(예: 트래픽 엔지니어링(TE) LSP)의 정보는 물론 트래픽 엔지니어링 데이터베이스의 정보를 활용합니다.

    stateful PCE는 두 가지 유형으로 나타날 수 있습니다.

    • 수동적 stateful PCE—PCC와의 동기화를 유지하고 PCC LSP 상태를 학습하여 경로 계산을 더 최적화하지만 제어가 되지 않습니다.

    • Active stateful PCE—PCC LSP 상태를 학습할 뿐만 아니라 PCC LSP를 적극적으로 수정합니다.

      주:

      기본 및 백업 stateful PCE가 있는 중복 구성에서는 백업 활성 stateful PCE가 장애 복원 시 주 PCE가 될 때까지 위임된 LSP의 속성을 수정할 수 없습니다. 전환 시에는 PCES를 미리 준비할 수 없습니다. 기본 PCE는 백업 PCE로 지원되고 기본 PCE가 다운되는 경우 백업 PCE는 기본 PCE의 역할을 가정하며 이전에는 주 PCE가 다시 작동했던 PCE 후에도 기본 PCE로 남아 있습니다.

    stateful PCE는 다음과 같은 기능을 제공합니다.

    • 오프라인 LSP 경로 계산을 제공합니다.

    • 네트워크를 다시 최적화해야 할 경우 LSP 재라우트가 트리거됩니다.

    • 애플리케이션에 대한 대역폭 수요가 증가할 경우 LSP 대역폭을 변경합니다.

    • ERO, 설정 우선 순위 및 우선 순위 보유 등의 라우터에서 다른 LSP 속성을 수정합니다.

    PCE는 네트워크의 대역폭 수요에 대한 글로벌 뷰를 제공합니다. 그리고 경로 계산을 수행하기 위해 트래픽 엔지니어링 데이터베이스를 유지 관리합니다. SNMP 및 NETCONF를 사용하여 MPLS 도메인의 모든 라우터에서 통계 수집을 수행합니다. 이는 PCC의 LSP에 대한 오프라인 제어를 위한 트래픽 엔지니어링(TE) 제공합니다. 오프라인 LSP 경로 계산 시스템은 네트워크 컨트롤러에 내장될 수 있습니다. PCE는 컴퓨팅 경로뿐만 아니라 PCC의 트래픽 엔지니어링(TE) LSP에 대한 제어를 제공하는 완전한 네트워크 컨트롤러의 역할을 합니다.

    stateful PCE를 사용하면 최적의 경로 계산과 경로 계산 성공을 지원할 수지만, 풀 메시(full 트래픽 엔지니어링(TE) mesh) LSP의 경우와 같은 중요한 컨트롤 플레인 오버헤드와 상태 측면에서 다량의 데이터를 유지 보수하는 안정적인 상태 동기화 메커니즘이 필요합니다.

  • 스테이트리스 PCE—스테이트리스 PCE는 모든 컴퓨팅 경로를 기억하지 못하며 각 요청 세트는 서로 독립적으로 처리됩니다(RFC 5440).

경로 계산 클라이언트

PCC(Path Computation Client)는 PCE에 의해 수행되는 경로 계산을 요청하는 모든 클라이언트 애플리케이션입니다.

PCC는 한 때 최대 10대의 PCES에 연결할 수 있습니다. PCC-PCE 연결은 구성된 정적 경로 또는 연결성을 설정하는 TCP 연결일 수 있습니다. PCC는 연결된 각 PCE에 우선 순위 번호를 할당합니다. LSP 상태 동기화라고 하는 프로세스에서 현재 LSP에 대한 정보가 들어 있는 메시지를 연결된 모든 PCES로 전송합니다. 외부 트래픽 엔지니어링(TE) 활성화된 LSP의 경우, PCC는 이러한 LSP를 기본 PCE로 위임합니다. PCC는 기본 PCE, 우선 순위 번호가 가장 낮은 PCE 또는 우선 순위 번호가 없는 PCE로 선택됩니다.

PCC는 PCE에서 수신된 컴퓨팅 경로를 기반으로 LSP에 다시 신호를 전송합니다. 기본 PCE가 있는 PCEP 세션이 종료되면 PCC는 새로운 기본 PCE를 선택하고 이전의 기본 PCE에 LSP를 위임한 모든 것은 새로 사용 가능한 기본 PCE로 위임됩니다.

경로 계산 요소 프로토콜

PCEP(Path Computation Element Protocol)는 PCC와 PCE 간의 통신(뿐만 아니라 2개의 PCE 간)(RFC 5440)에 사용됩니다. PCEP는 IETF(INTERNET ENGINEERING TASK FORCE) Working Group에서 정의한 TCP 기반 프로토콜로, PCEP 세션을 관리하고 멀티도메인 및 LSP에 대한 경로를 요청하고 전송하는 데 사용되는 메시지와 객체 트래픽 엔지니어링(TE) 정의합니다. PCEP 상호 작용에는 PCC 메시지는 물론, RSVP-MPLS 상황의 PCE 사용과 관련된 특정 상태의 트래픽 엔지니어링(TE). PCE-PCE 통신에 PCEP가 사용된 경우 요청된 PCE는 PCC의 역할을 맡습니다.

따라서 PCEP 기능은 다음과 같습니다.

  • LSP 터널 PCC와 stateful PCE 간의 상태 동기화.

  • LSP 터널에 대한 제어를 stateful PCE로 위임

PCEP를 사용하는 PCE와 PCC 간의 상호 작용

그림 3 RSVP-MPLS PCE, PCC 및 PCEP의 역할을 트래픽 엔지니어링(TE).

그림 3: PCC 및 RSVP-트래픽 엔지니어링(TE) PCC 및 RSVP-트래픽 엔지니어링(TE)

TCP 기반 PCEP를 통해 PCE에서 PCC로의 통신이 가능합니다. PCC는 PCEP 세션을 시작하고 PCEP 세션 동안 PCE에 계속 연결됩니다.

주:

릴리스 16.1을 Junos OS RFC 5440에 따라 TCP-MD5 인증을 사용하여 PCEP 세션을 보호할 수 있습니다. PCEP 세션을 위해 MD5 보안 메커니즘을 활성화하려면, PCEP 세션의 계층 수준에서 MD5 인증 키를 정의하고 연계하는 [edit protocols pcep pce pce-id] 것이 좋습니다. 그러나 계층 수준에서 미리 정의한 키체인을 사용하여 PCEP 세션을 보호할 [edit security authentication-key-chains key-chain] 수 있습니다. 이 경우 사전 정의한 키체인을 계층 수준에서 PCEP 세션에 [edit protocols pcep pce pce-id] 연계해야 합니다.

PCE와 PCC는 동일한 키를 사용하여 PCEP 세션의 TCP 연결에서 전송되는 각 세그먼트의 진위를 검증하기 때문에 공격을 대상이 될 수 있으며 네트워크의 서비스를 중단할 수 있는 장치 간 PCEP 통신을 보호할 수 있습니다.

MD5 인증을 사용하는 PCEP 세션 보안에 대한 자세한 내용은 를 PCEP 세션을 위한 TCP-MD5 인증 참조하십시오.

PCEP 세션이 설정되면 PCC는 다음과 같은 작업을 수행합니다.

  1. LSP 상태 동기화—PCC는 모든 LSP(로컬 및 외부)에 대한 정보를 연결된 모든 PCES로 전송합니다. 외부 LSP의 경우, PCC는 구성 변경, RRO 변경, 상태 변경 등 모든 정보를 PCE로 전송합니다.

    PCE 개시 LSP의 경우, PCC에는 LSP 구성이 없습니다. LSP를 시작하는 PCE는 PCE가 시작된 LSP를 지원하는 기능을 표시한 PCC로 LSP 매개 변수를 전송합니다.

    주:

    PCE 시작 LSP에 대한 지원은 Junos OS 릴리스 13.3 이상에서 제공됩니다.

  2. LSP 위임—LSP 상태 정보가 동기화된 후 PCC는 기본 활성 stateful PCE인 외부 LSP를 하나의 PCE에 위임합니다. 주 PCE만이 외부 LSP에 대한 매개 변수를 설정할 수 있습니다. 기본 PCE가 수정하는 매개 변수에는 대역폭, 경로(ERO), 우선 순위(설정 및 보유)가 포함됩니다. 로컬 구성에 지정된 매개 변수는 기본 PCE에 의해 설정되는 매개 변수에 따라 까다로워지며,

    주:

    기본 PCE가 있는 PCEP 세션이 종료되면 PCC는 새로운 기본 PCE를 선택하고 이전의 기본 PCE에 LSP를 위임한 모든 것은 새로 사용 가능한 기본 PCE로 위임됩니다.

    PCE가 시작된 LSP의 경우, PCC는 PCE에서 수신된 매개 변수를 사용하여 LSP를 생성합니다. PCC는 PCE 시작 LSP에 고유한 LSP-ID를 할당하고 LSP를 PCE에 자동으로 위임합니다. PCC는 활성 PCEP 세션에 대해 PCE 개시 LSP에 대한 위임(delegation)을 취소할 수 없습니다.

    PCEP 세션이 종료되면 PCC는 서비스 중단을 방지하기 위해 PCE 시작 LSP를 즉시 삭제하지 않고 2개의 시간(timers)을 delegation cleanup timeoutlsp cleanup timer 시작합니다. 이 기간 동안 활성 stateful PCE는 LSP에 대한 생성 요청을 전송하여 실패한 PCE가 프로비저닝한 LSP에 대한 제어를 취득할 수 있습니다.

    PCE에서 시작된 LSP에 대한 제어는 의 만료 시 PCC로 다시 delegation cleanup timeout 시작됩니다. 만료되고 다른 PCE가 실패한 PCE로부터 LSP에 대한 제어를 획득하지 못한 경우, PCC는 위임되지 않은 delegation cleanup timeout PCE-시작 LSP에 대한 로컬 제어를 제공합니다. 나중에, 원래 또는 새로운 active stateful PCE가 로컬 제어 PCE에서 시작되는 LSP의 제어를 획득하고자 할 때, PCC는 이러한 LSP를 PCE에 위임하고 타임러가 lsp cleanup timer 중지됩니다.

    PCE는 PCE 간에 LSP 전송을 허용하도록 PCE 시작 LSP의 위임(delegation)을 PCC에 반환할 수 있습니다. PCE 시작 lsp cleanup timer LSP에 대한 트리거입니다. PCC는 LSP 클린업 타임러가 만료될 때까지 기다린 후에 실패한 PCE에서 위임되지 않은 PCE-시작 LSP를 제거합니다.

    만료되고 다른 PCE가 실패한 PCE로부터 LSP를 제어하는 데 인수되지 않은 경우, PCC는 실패한 PCE가 프로비저닝한 모든 lsp cleanup timer LSP를 삭제합니다.

    주:

    draft-ietf-pce-stateful-pce-09를준수하여 PCC에 의해 PCE-시작 LSP 위임의 취소는 LSP가 대체 PCE로 재전전되기 전에 그 전에 발생한다. 릴리스 Junos OS 18.1R1 lsp-cleanup-timer PCC가 LSP 위임(delegations)을 취소하려면, 이보다 높거나 같아야 delegation-cleanup-timeout 합니다. 그렇지 않은 경우, PCC의 재설계 타임아웃 간격은 무한대로 설정될 수 있습니다. 이때 PCC에 의해 특정 조치가 실행되어 PCE가 설정한 매개 변수를 변경하기 전까지는 해당 PCE에 대한 LSP 위임이 그대로 유지됩니다.

  3. LSP 시그널링—기본 활성 stateful PCE에서 하나 이상의 LSP 매개 변수를 수신할 때 PCC는 제공된 경로에 따라 트래픽 엔지니어링(TE) LSP에 다시 신호를 전송합니다. PCC가 LSP 설정에 실패하면, 설정 실패의 PCE에 이를 신호하고 기본 PCE가 해당 LSP에 대한 새로운 매개 변수를 제공한 다음 다시 신호 전송을 기다릴 수 있습니다.

    PCE가 경로 엔드포인트만 지정되는 경우 불완전하거나 느슨한 홉이 있는 경로를 지정하면 PCC는 전체 홉 세트를 찾기 위해 로컬 제약 조건 기반 라우팅을 수행하지 않습니다. 대신, PCC는 시그널링을 위해 RSVP에 PCE 제공 경로를 제공합니다. 그리고 경로는 IGP 홉-홉(hop-by-hop) 라우팅을 사용하여 설정됩니다.

사용된 토폴로지의 그림 2 경우, RSVP-MPLS 기반 네트워크에서 부분 클라이언트측 PCE 구현을 트래픽 엔지니어링(TE) 그림 4 있습니다. ingress 라우터 A 및 G는 TCP 연결을 통해 외부 stateful PCE에 연결하도록 구성된 PCC입니다.

PCE는 네트워크의 대역폭 수요에 대한 글로벌 뷰를 제공합니다. 트래픽 엔지니어링 데이터베이스를 조회한 후 외부 경로 계산을 수행합니다. 활성 stateful PCE는 하나 이상의 LSP 속성을 수정하고 PCC에 업데이트를 전송합니다. PCC는 PCE에서 수신한 매개 변수를 사용하여 LSP에 다시 신호를 전송합니다.

그림 4: RSVP-MPLS PCE를 예로 트래픽 엔지니어링(TE) RSVP-MPLS PCE를 예로 트래픽 엔지니어링(TE)

이를 통해 stateful PCE는 최단 간도 종단 경로 계산의 특정 문제를 해결하기 위해 사용되는 분산 기능의 상호 연동 운영을 제공합니다. 트래픽 스트림이 비효율적으로 가용 리소스에 매핑되는 혼잡 시나리오를 제거하여 네트워크 리소스의 일부를 과도하게 활용하는 반면, 다른 리소스는 여전히 활용되지 않습니다.

외부 컴퓨팅을 위한 LSP 동작

LSP 유형

클라이언트측 PCE 구현에서는 LSP의 세 가지 트래픽 엔지니어링(TE) 있습니다.

  • CLI 제어 LSP—명령문이 구성된 LSP가 없는 LSP를 CLI lsp-external-controller pccd 제어 LSP라고 합니다. 이들 LSP는 로컬 제어를 하에 실행되고 있는 것이지만, PCC는 최초 LSP 동기화 프로세스 동안 CLI 제어되는 LSP에 대한 정보를 사용하여 연결된 PC를 업데이트합니다. 최초 LSP 동기화가 끝난 후, PCC는 PCE에 모든 새 LSP 및 삭제된 LSP도 알 수 있습니다.

  • PCE 제어 LSP—구성된 명령문을 가지는 LSP를 lsp-external-controller pccd PCE 제어 LSP라고 합니다. PCC는 외부 경로 계산을 위해 PCC 시작 LSP를 기본 PCE에 위임합니다.

    PCC는 대역폭, ERO 및 우선 순위와 같은 PCE 제어 LSP의 구성된 매개 변수에 대해 PCE에 알려합니다. 또한 사용 가능한 경우 RRO를 포함하여 LSP를 설정하는 데 이러한 매개 변수에 사용되는 실제 값에 대해 PCE에 알 수 있습니다.

    PCC는 재구성이 발생하거나 ERO, RRO 또는 외부 제어 하에서 PCE 제어 LSP의 상태가 변경된 경우 이러한 LSP 상태 보고서를 PCE에 전송합니다.

    PCE용 LSP 구성의 CLI 매개 변수는

    • PCE에 의해 까다로워지지 않는 매개 변수를 즉시 적용합니다.

    • PCE에 의해 까다로워진 매개 변수. 이러한 매개 변수에는 대역폭, 경로 및 우선 순위(설정 및 보유 값)가 포함됩니다. 컨트롤 모드가 외부에서 로컬로 전환되는 경우, LSP에 다시 CLI 이러한 매개 변수에 대한 CLI 구성된 값이 다음 기회에 적용됩니다. 이 값은 즉시 적용되지 않습니다.

  • 외부 프로비저닝 LSP(또는 PCE-시작 LSP)—구성된 명령문을 있는 LSP는 lsp-provisioning PCE-시작 LSP라고 합니다. PCE 개시 LSP는 외부 PCE에 의해 동적으로 생성됩니다. 따라서 PCC에는 LSP 구성이 존재하지 않습니다. PCC는 PCE에서 제공하는 매개 변수를 사용하여 PCE 시작 LSP를 생성하고 LSP를 PCE에 자동으로 위임합니다.

    주:

    PCE 시작 LSP에 대한 지원은 Junos OS 릴리스 13.3 이상에서 제공됩니다.

CLI 제어 LSP, PCE 제어 LSP 및 PCE 시작 LSP가 PCC에 공존할 수 있습니다.

CLI 제어 LSP 및 PCE 제어 LSP가 PCC에 공존할 수 있습니다.

LSP 제어 모드

클라이언트측 PCE 구현에서는 PCC 제어 LSP를 위한 두 가지 유형의 컨트롤 모드가 있습니다.

  • 외부—기본적으로 모든 PCE 제어 LSP는 외부에서 제어됩니다. LSP가 외부 제어 하에 있는 경우, PCC는 PCE 제공 매개 변수를 사용하여 LSP를 설정합니다.

  • 로컬—PCE 제어 LSP는 로컬 제어를 통해 나올 수 있습니다. LSP 스위치가 외부 제어에서 로컬 제어로 전환되면 경로 계산은 CLI 구성되는 매개 변수와 제약 기반 라우팅을 사용하여 수행됩니다. 이와 같은 전환은 LSP에 다시 신호를 재전시하는 트리거가 있는 경우만 발생합니다. 그때까지는 LSP가 로컬 제어 상태로 남아 있는 것이지만, PCC는 PCE 제공 매개 변수를 사용하여 PCE 제어 LSP에 신호를 전송합니다.

PCE에 대한 연결이 없는 경우나 PCE가 LSP 위임 기능을 다시 PCC로 반환하는 경우, PCE 제어 LSP 스위치를 기본 외부 제어 모드에서 로컬 제어로 전환합니다.

CLI 제어 LSP 및 PCE 제어 LSP에 대한 자세한 내용은 를 LSP 유형 참조하십시오.

외부 컴퓨팅을 위한 구성 명령문 지원

표 1 PCE MPLS LSP에 적용되는 기존 LSP 구성 명령문을 나열합니다.

표 1: PCE 제어 MPLS 기존 LSP 구성에 대한 적용성

PCE 제어 LSP 지원

해당 LSP 구성 명령문

해당 MPLS 구성 정보

이러한 구성 명령문은 PCE 구성과 함께 구성할 수 있습니다. 그러나 로컬 구성이 사용 중일 때만 적용됩니다. PCE 제어 중에 이러한 구성 명령문은 비활성 상태로 유지됩니다.

  • 관리 그룹

  • 자동 대역폭

  • 홉 제한(hop-limit)

  • 최소 채우기

  • 가장 많이 채우기

  • 임의의

  • 관리 그룹

  • 관리 그룹

  • 관리 그룹 확장

  • 홉 제한(hop-limit)

  • cspf 없음

  • 스마트 최적화-타임러

이들 구성 명령문은 PCE 구성과 함께 구성될 수 있지만 PCE 제어 LSP 속성에 따라 까다롭습니다. 그러나 로컬 구성을 사용하는 경우 이러한 구성 명령문에 구성된 값이 적용됩니다.

주:

LSP가 stateful PCE를 제어하는 동안 LSP를 사용하는 로컬 구성은 CLI LSP에 영향을 미치지 않습니다. 이러한 변경은 로컬 구성이 적용된 경우에만 적용됩니다.

  • 대역폭

  • 기본

  • 우선순위

  • 우선순위

이러한 구성 명령문은 PCE 구성과 함께 구성할 수 없습니다.

  • p2mp

  • 템플릿

  • p2mp-lsp-next-hop

나머지 LSP 구성 명령문은 기존 LSP와 동일한 방식으로 적용할 수 있습니다. PCE 제어 LSP에 대한 위 구성 명령문을 구성할 때 구성된 매개 변수가 적용될 MPLS 로그 메시지가 생성됩니다.

PCE 제어 LSP 보호

고속 재라우트 및 LSP 우회를 비롯한 보호 경로는 제약 기반 라우팅을 사용하여 PCC에 의해 로컬 계산됩니다. stateful PCE는 주 경로(ERO)만 지정합니다. 로컬 구성에 LSP 보호를 위한 비 대기 보조 경로가 없는 경우에도 PCE는 비-대기 보조 경로를 트리거할 수 있습니다.

PCE 제어 LSP ERO

PCE 제어 LSP(PCC 위임 LSP 및 PCE Initated LSP)의 경우, 완전한 ERO(Explicit Route Object) 객체만 PCE에서 PCC로 전송해야 합니다. 그렇지 않으면 PCC는 해당 PCEP 세션에 대한 PCUpdate 또는 PCCreate 메시지를 거부합니다.

17.Junos OS 릴리스 17.2부터 PCE 제어 LSP를 위해 다음과 같은 2가지 새로운 경로 계산 유형이 external cspf 소개됩니다. local cspfno cspf및 를 통해

  • local cspf—PCC는 local cspf PC Juniper E가 벤더 TLV(엔터프라이즈 번호: 0x0a4c)의 유형 5입니다.

  • no cspf—PCE나 PCC 모두 경로 계산이 제한적이지 않습니다. 단말 및 제약 조건은 LSP를 기본 경로로 설정하기 위한 RSVP IGP 부여됩니다.

    PCC는 다음 케이스에서 no cspf 연산 유형을 사용합니다.

    • PCE가 TLV를 전송하고 이 LSP에 대한 Junos OS 구성 또는 일치 템플릿이 PCC 위임 local cspfno-cspf LSP에 포함된 경우

    • PCE가 TLV를 전송하고 이 LSP에 대한 Junos OS 구성 템플릿이 local cspfno-cspf PCE-시작 LSP에 포함되는 경우

    • PCE가 빈 ERO 또는 느슨한 local cspf ERO로 TLV를 전송하지 않는 경우(ERO 객체에서 느슨한 비트 세트).

이러한 새로운 연산 유형을 통해 PCC는 ERO 객체를 느슨한 ERO 또는 빈 ERO로 받아들일 수 있습니다. 경로를 컴퓨팅할 수 없는 외부 경로 컴퓨팅 엔티티는 분석을 기반으로 대역폭 및 색상과 같은 매개 변수를 수정할 수 있습니다. 이러한 경우 빈 ERO 객체 또는 느슨한 ERO가 사용되어 PCC에 의해 취해지기 경로가 결정됩니다.

LSP를 위한 PCE 제어 Point-to-Multipoint RSVP-트래픽 엔지니어링(TE) 제어

PCE와 PCC 간에 PCEP 세션이 설정되면 PCC는 시스템의 모든 LSP를 LSP 상태 동기화를 위해 PCE에 보고합니다. 여기에는 PCC 제어, PCE 위임 및 PCE 개시 Point-to-Point LSP가 포함됩니다. Junos OS Release 15.1F6 16.1R1 Point-to-Multipoint LSP로도 확장됩니다. PCE의 경우, Point-to-Multipoint LSP는 RSVP Point-to-Multipoint LSP와 유사하며, 여기서 점대다점 LSP는 점대다점 식별자(point-to-multipoint) ID로 그룹화되는 Point-to-Multipoint LSP의 모음으로 취급됩니다.

기본적으로, 점대다점 LSP에 대한 PCE 제어는 PCC에서 지원되지 않습니다. 이 기능을 추가하기 위해, 명령문 또는 계층 p2mp-lsp-report-capability[edit protocols pcep pce pce-name][edit protocols pcep pce-group group-id] 수준에 명령문을 포함해야 합니다. Point-to-Multipoint 보고서 기능이 PCC에서 구성되면 PCC는 이 기능을 PCE에 알려야 합니다. PCE가 동일한 Point-to-Multipoint 보고서 기능을 반환하여 광고하는 경우, PCC는 LSP 상태 동기화를 위해 완전한 POINT-to-Multipoint LSP 트리를 PCE에 보고합니다.

점대다점(point-to-multipoint) 트래픽 엔지니어링(TE) 기능을 갖추고 있는 PCC는 stateful PCES를 위한 점대다점 LSP트래픽 엔지니어링(TE) Point-to-Multipoint 업데이트, 그리고 핵심으로 점대다점 LSP 이름을 지원하는 LSP 데이터베이스의 점대다점(point-to-multipoint) LSP에 대한 보고를 지원한다. 그러나, 다음 특징 및 기능은 Junos OS Release 15.1F6 16.1에서 지원되지 않습니다.

  • 정적 점대다점 LSP

  • PCE 위임 및 PCE 시작 Point-to-Multipoint LSP

  • 자동 대역폭

  • 트래픽 엔지니어링(TE)++

  • PCE 요청 및 회신 메시지

  • 템플릿을 사용하여 점대다점 LSP 생성

  • PCE 시작 Point-to-Multipoint LSP의 포로 입력 구성

  • 프로비저닝 LSP를 라우터에서 포로 엔트리 구성.

PCE 시작 Point-to-Point LSP

Junos OS Release 16.1부터는 stateful PCE가 PCC를 통해 트래픽 엔지니어링 LSP를 시작 및 프로비저닝할 수 있도록 PCEP 기능이 확장됩니다. 앞서, LSP는 PCC상에서 구성이 났고 PCC는 외부 LSP에 대한 제어를 PCE에 위임했습니다. LSP 상태의 소유권은 PCC에 의해 유지 관리됩니다. PCE 시작 LSP가 도입되면 PCC에서 로컬로 구성된 LSP를 사용할 필요 없이, PCE가 트래픽 엔지니어링 포인트 대 점(point-to-point) LSP를 동적으로 시작하고 프로비저닝할 수 있습니다. PCE에서 PCCreate 메시지를 수신할 때, PCC는 PCE 시작 LSP를 생성하고 LSP를 PCE에 자동으로 위임합니다.

기본적으로 PCC는 PCE에서 PCE 개시 점대점(point-to-point) LSP의 프로비저닝 요청을 거부합니다. PCC에서 PCE에서 LSP를 지원하기 위해, 또는 계층 수준에서 lsp 프로비저닝 명령문을 [edit protocols pcep pce pce-id][edit protocols pcep pce-group group-id] 포함합니다.

PCC는 PCE를 통해 PCE를 통해 PCEP(Path Computation Element Protocol) 세션을 구축하는 동시에 PCE 개시 점대점(point-to-point) LSP를 지원하는 기능을 나타냅니다. PCE는 LSP를 시작하기 위해 이 기능을 탑재한 PCC를 선택합니다. PCE는 PCC에 PCE 시작 LSP 매개 변수를 제공합니다. PCE가 시작된 Point-to-Point LSP 매개변수를 수신할 때, PCC는 LSP를 설정하고, LSP ID를 할당하며, LSP를 PCE에 자동으로 위임합니다.

LSP를 시작하는 PCE가 PCE 시작 지점에서 점대점(point-to-point) LSP 매개변수를 제공하지 않는 경우, PCC는 기본 매개 변수를 사용합니다. LSP 매개 변수가 PCE에 의해 제공되지 않을 경우, 선택적 LSP 템플릿은 PCE 개시 점대점 LSP에 대한 값을 지정하도록 구성될 수도 있습니다. PCC에서 PCE 시작 점대점 LSP에 대한 LSP 템플릿을 구성하기 위해 계층 수준에서 Label-Switched-Path-Template[edit protocols mpls lsp-external-controller lsp-external-controller] 명령문을 포함합니다.

PCEP 세션이 종료되면 PCC는 서비스 중단을 방지하기 위해 PCE 시작LSP를 즉시 삭제하지 않고 2개의 시간(timers)을 delegation cleanup timeoutlsp cleanup timer 시작합니다. 이 기간 동안 활성 stateful PCE는 실패한 PCE에 의해 프로비저닝된 LSP의 제어를 취득할 수 있습니다.

PCE는 PCE 간에 LSP 전송을 허용하도록 PCE 개시 점대점(point-to-point) LSP의 위임(delegation)을 PCC에 반환할 수 있습니다. PCE 시작 LSP에 대한 제어는 위임 클린업 타임아웃 만료 시 PCC로 다시 연결됩니다. 위임 클린업 타임아웃이 만료되고 다른 어떤 PCE도 실패한 PCE로부터 LSP를 제어하지 못한 경우, PCC는 위임되지 않은 PCE-시작 LSP에 대한 로컬 제어를 제공합니다. 나중에, 원래 또는 새로운 active stateful PCE가 로컬 제어 PCE에서 시작된 점대점(point-to-point) LSP에 대한 제어를 획득하고자 할 때, PCC는 이러한 LSP를 PCE에 위임하고 LSP 클린업 타임러가 중지됩니다.

PCC는 LSP 클린업 타임러가 만료될 때까지 기다린 후에 실패한 PCE에서 위임되지 않은 PCE 시작 Point-to-Point LSP를 삭제합니다. LSP 클린업 타임이 만료되고 다른 어떤 PCE도 실패한 PCE로부터 LSP를 제어하지 못하면 PCC는 실패한 PCE에 의해 프로비저닝되는 모든 LSP를 삭제합니다.

주니어는 Junos OS Release 21.1R1부터 PCE 개시 RSVP 기반의 점대점(point-to-multipoint) LSP에 대한 무중단 활성 라우팅(NSR)을 지원하고 있습니다. 주 라우팅 엔진 컨트롤러를 통해 PCEP 세션을 유지 관리합니다. PCE 시작 P2MP LSP에 대한 멀티캐스트 플로우 사양을 포함하여 PCES에서 시작된 모든 RSVP LSP를 백업 장치와 라우팅 엔진. 전환이 진행되는 동안 PCEP 세션은 다운되어 백업 라우팅 엔진 스위치가 주 라우팅 엔진. 이를 통해 전환이 진행되는 동안 PCE 시작 RSVP LSP를 통해 수행된 트래픽의 트래픽 라우팅 엔진 감소합니다. 이 기능은 NSR이 구성되면 활성화됩니다.

PCE 시작 Bypass LSP

PCE 시작 Bypass LSP 이해

네트워크의 백업 보호 경로가 트래픽을 처리하는 데 충분한 대역폭을 확보하지 못하기 때문에 링크 또는 노드 장애 시 트래픽이 정전될 수 있습니다. 이러한 네트워크에서 네트워크 성능을 최적화하기 위해 PCE를 모든 경로를 계산하는 데 PCE를 사용할 수 있는 경우, 로컬 보호 경로도 PCE를 통해 제어해야 합니다.

Junos OS Release 19.2R1 이후 릴리스는 인터넷 draft-cbrt-pce-stateful-local-protection-01(2018년 12월 만료), RSVP-트래픽 엔지니어링(TE) PCE-Stateful를위한 PCEP 확장을 위한 PCEP 확장을 통해 보호된 인터페이스를 위해 stateful PCE가 LSP를 시작, 프로비저닝 및 관리할 수 있도록 PCEP 기능을 확장합니다. 대역폭 예약을 사용하는 다중 우회 LSP는 PCE에 의해 시작되어 링크 또는 노드를 보호할 수 있습니다. 우회 LSP의 대역폭은 보호할 수 있는 기본 LSP의 총 대역폭보다 작을 것으로 예상됩니다.

동적 우회 LSP를 통해 수동 우회 LSP(가용)를 선호하는 기존 우회 선택 메커니즘은 동적 우회 LSP를 통해 PCE 프로비저닝 bypass LSP(가용 경우)를 선호하는 것으로 확장됩니다. PCE 프로비저닝 Bypass LSP는 동적 우회 LSP보다 선호도가 높지만 수동 우회 LSP보다는 선호도가 낮습니다.

이와 같은 모든 운영 우회 LSP에서 수행하는 데 사용되는 작업 집합은 PCE에서 시작된 clear rsvp session bypass LSP에서도 수행할 수 있습니다. 같은 명령을 사용하여 PCE 시작 show path-computation-client status extensiveshow path-computation-client lsp bypass LSP 통계를 볼 수 있습니다.

PCE 시작 우회 LSP의 지원을 통해 다음을 할 수 있습니다.

  • 외부 컨트롤러에서 PCEP를 통해 LSP 우회(bypass) LSP를 생성합니다. 여기서 LSP 우회

    • 링크 또는 노드 보호를 위한 것이 될 수 있습니다.

    • 논-제로 대역폭이 있어야 합니다.

    • 엄격한 ERO를 지정해야 합니다.

  • 기존 PCE에서 생성된 우회 LSP에 대해 대역폭과 ERO를 업데이트합니다.

  • 주요 LSP의 수신 제어를 위해 우회 LSP 대역폭을 오버서브합니다. 이는 우회 매개 변수가 되어야 하며 우회 LSP당 구독 업데이트가 허용되어야 합니다.

PCE 시작 Bypass LSP의 이점

PCE가 시작된 Bypass LSP는 다음과 같은 이점을 제공합니다.

  • 장애 발생 후 트래픽에 대한 제어를 강화하고 보호 경로의 보다 까다로워진 경로 계산을 제공합니다.

  • LSP에 대한 다양한 경로 유지는 물론 로컬 보호 경로 유지와 같은 복잡한 제약 및 다양성 요구 사항을 충족합니다.

  • 장애 이벤트가 진행되는 동안 링크가 오버로드되지 않도록 보장합니다.

PCEP 세션 장애 시 PCE 시작 우회 LSP의 동작

PCEP 세션 장애 시, 상태 타임아웃 타임러가 만료될 때까지 PCE에서 시작된 LSP 우회(bypass)가 고립됩니다. PCE가 시작된 우회 LSP는 상태 타임아웃 타임러 만료 시 정리됩니다. PCE에서 시작된 bypass LSP(PCEP 세션에 장애가 발생한 후), PCE(기본 PCE 또는 보조 PCE)에 대한 제어를 얻기 위해 상태 타임아웃 타임러가 만료되기 전에 PCInitiate 메시지를 전송합니다.

PCE 시작 Point-to-Multipoint LSP

점대다점 PCE 시작 LSP가 도입된 PCE는 PCC에서 로컬 LSP 구성 없이도 점대다점 LSP를 동적으로 시작 및 프로비저닝할 수 있습니다. 이를 통해 PCE는 PCEP(Path Computation Element Protocol) 세션 내 및 그 전반의 Point-to-Multipoint 경로 계산의 타이밍과 시퀀스를 제어함으로써 중앙에서 제어 및 구축되는 다이내믹한 네트워크를 구축할 수 있습니다.

자세한 내용은 PCE 시작 Point-to-Multipoint LSP를 MPLS RSVP-트래픽 엔지니어링(TE) RSVP-트래픽 엔지니어링(TE)대한 이해 경로 계산 요소 프로토콜 을 참조하십시오.

자동 대역폭 및 PCE 제어 LSP

릴리스 Junos OS 릴리스 14.2R4 PCE 제어 LSP에 대한 자동 대역폭 지원이 제공됩니다. 이전 릴리스에서는 자동 대역폭 옵션이 PCE 제어 LSP에 적용되지 않았지만, 자동 대역폭 및 제약 기반 라우팅을 제어하는 LSP는 PCE 제어 LSP와 공존할 수 있습니다. 자동 대역폭에 대한 통계 수집은 PCE 제어 LSP의 제어 모드가 외부에서 로컬로 변경되는 경우에만 적용됩니다. 이는 PCE에 연결되지되거나 PCE가 LSP의 위임 기능을 다시 PCC로 반환하는 경우 발생했습니다.

PCEP 세션을 위한 TCP-MD5 인증

stateful PCE 서버는 네트워크 전반에서 트래픽 엔지니어링 경로 생성을 자동화하여 네트워크 활용도를 높이고 PCC와의 PCEP 통신을 사용하여 사용자 지정 프로그래밍 가능한 네트워킹 환경을 활성화합니다. PCC는 LSP 보고서를 PCE 서버로 전송하고, PCE가 LSP를 업데이트하거나 PCC로 프로비저닝합니다. PCEP 세션을 통해 전송되는 데이터는 PCE 서버가 외부 경로 컴퓨팅을 수행하는 데 매우 중요합니다. 그 결과, PCEP 통신에 대한 공격은 네트워크 서비스를 중단할 수 있습니다. 변경된 PCEP 메시지가 PCC로 전송될 경우 부적절한 LSP를 설정할 수 있습니다. 마찬가지로 변경된 PCEP 메시지가 PCE로 전송될 경우, PCE는 네트워크에 대한 잘못된 보기를 학습합니다.

PCE 기능을 효과적으로 실행하는 PCE와 PCC 간의 PCEP 통신의 중요성을 고려할 때, Junos OS Release 16.1은 RFC 5440에 따라 TCP-MD5 인증을 사용하여 PCEP 세션을 보호하는 기능을 소개합니다. 이 기능은 공격의 대상이 될 수 있으며 네트워크 서비스를 중단할 수 있는 PCEP 세션상에서 PCE와 PCC 간의 통신을 보호합니다.

PCEP 세션을 위해 MD5 보안 메커니즘을 활성화하려면, PCEP 세션의 계층 수준에서 MD5 인증 키를 정의하고 연계하는 [edit protocols pcep pce pce-id] 것이 좋습니다. 그러나 계층 수준에서 미리 정의한 키체인을 사용하여 PCEP 세션을 보호할 [edit security authentication-key-chains key-chain] 수 있습니다. 이 경우 사전 정의한 키체인을 계층 수준에서 PCEP 세션에 [edit protocols pcep pce pce-id] 연계해야 합니다.

PCE를 통해 안전한 PCEP 세션을 구축하기 위해 PCC에서 다음과 같은 구성이 실행됩니다.

  • MD5 인증 키 사용:

  • 사전 정의한 인증 키체인 사용:

안전한 PCEP 세션을 성공적으로 설정하기 위해 MD5 인증은 PCE 서버와 PCC 모두에서 사전 공유된 인증 키로 구성해야 합니다. PCE와 PCC는 동일한 키를 사용하여 PCEP 세션의 TCP 연결에서 전송된 각 세그먼트의 진위를 확인합니다.

주:
  • Junos OS Release 16.1은 도청, 무단 변경 및 메시지 변조와 같은 TLS 및 TCP-AO에 대한 지원을 확장하지 않고도 PCEP 세션을 위한 TCP-MD5 인증만 지원합니다.

  • PCEP 세션에 보안 메커니즘을 최초로 적용하면 세션이 리셋됩니다.

  • MD5가 PCEP 세션의 한 쪽에서 잘못 구성되거나 구성되지 않은 경우 세션이 설정되지 않습니다. PCC 및 PCE의 구성이 일치하는지 확인

  • 이 기능은 모든 세션 인증 메커니즘을 지원하지 않습니다.

  • PCEP 세션에서 사용되는 인증 키체인을 보시고 명령 show path-computation-client statusshow protocols pcep 출력을 사용하십시오.

  • 명령어를 사용하여 인증 오류로 인하여 TCP에 의해 드롭된 패킷 show system statistics tcp | match auth 수를 볼 수 있습니다.

  • 키체인의 작동은 명령 출력을 사용하여 show security keychain detail 검증할 수 있습니다.

클라이언트측 PCE 구현이 네트워크 성능에 미치는 영향

stateful 데이터베이스의 유지 관리는 사소한 작업일 수 있습니다. 중앙 집중화된 단일 PCE 환경에서 stateful PCE는 PCE가 계산한 모든 트래픽 엔지니어링(TE) LSP, 실제로 설정된 트래픽 엔지니어링(TE) LSP(알려진 경우), 트래픽 엔지니어링(TE) LSP가 해체된 경우를 기억해야 합니다. 그러나 이러한 요구 사항은 상태, 네트워크 사용 및 처리, 네트워크 전반의 링크를 최적화하는 측면에서 상당한 제어 프로토콜 오버헤드를 발생하게 됩니다. 따라서 stateful PCE 구현의 우려 사항으로는 다음이 포함됩니다.

  • 신뢰할 수 있는 동기화 메커니즘으로 상당한 컨트롤 플레인 오버헤드가 발생합니다. PCES는 서로 통신하여 상태를 동기화할 수 있지만, 여러 PCE에서 트래픽 엔지니어링(TE) 분산 계산을 사용하여 LSP를 설정하면 동기화 및 경쟁 조건 회피의 문제가 더욱 복잡해지고 복잡해집니다.

  • 대역 외 트래픽 엔지니어링 데이터베이스 동기화는 분산 PCE 계산 모델에 설정된 여러 PCE로 복잡할 수 있으며, 경쟁 조건, 확장성 문제 등에서 쉽게 실행될 수 있습니다.

  • PCE가 모든 경로, 우선 순위 및 레이어에 대한 상세 정보를 제공한 경우에도 전체 네트워크 상태를 통합한 경로 계산은 매우 복잡합니다.

위 우려에도 불구하고 stateful PCE의 부분 클라이언트측 구현은 대규모 트래픽 엔지니어링 시스템에서 매우 효과적입니다. 또한, LSP 상태의 글로벌 가시성을 확보하고 제어되는 시스템 내 장치 전반에서 경로 예약을 순서대로 제어하기 위해 트래픽 엔지니어링(TE) 최적의 리소스 사용 측면에서 신속한 컨버전스와 상당한 이점을 제공합니다.

예를 들면 다음과 같습니다. RSVP-MPLS 위한 경로 트래픽 엔지니어링(TE)

이 예에서는 PCC(Path Computation Client)에서 트래픽 엔지니어링 레이블 스위칭 경로(트래픽 엔지니어링(TE) LSP)에 대해 PCE(Path Computation Element)에 의해 외부 경로 컴퓨팅을 활성화하는 방법을 보여줍니다. 또한 PCC에서 PCE에서 PCC 통신을 지원하기 위해 PCEP(Path Computation Element Protocol)를 구성하는 방법도 보여줍니다.

요구 사항

이 예에서는 다음과 같은 하드웨어 및 소프트웨어 구성 요소를 활용합니다.

  • ACX 시리즈 라우터, M Series 멀티 서비스 에지 라우터, MX 시리즈 5G 유니버설 라우팅 플랫폼, T 시리즈 코어 라우터 또는 PTX 시리즈 전송 라우터를 조합할 수 있는 3개의 라우터가 PCC로 구성될 수 있습니다.

  • PCC의 외부 stateful PCE에 대한 TCP 연결.

  • Junos OS Release 12.3 이상이 JSDN 애드-데이 패키지와 함께 PCC에서 실행됩니다.

주:

JSDN 추가 패키지는 코어 및 설치 패키지와 함께 Junos OS 필요합니다.

시작하기 전에 다음을 할 수 있습니다.

  1. 디바이스 인터페이스를 구성합니다.

  2. 구성 MPLS 및 RSVP-트래픽 엔지니어링(TE).

  3. 모든 IS-IS(Intermediate System to Intermediate System) 또는 기타 모든 IGP 프로토콜을 구성합니다.

개요

Junos OS Release 12.3부터 시작하여 MPLS RSVP-트래픽 엔지니어링(TE) 기능이 확장되어 PCC에서 stateful PCE 아키텍처(draft-ietf-pce-stateful-pce)의 일부 클라이언트측 구현을 제공합니다.

주:

stateful PCE 아키텍처의 부분 클라이언트측 구현은 버전 2의 인터넷 draft-ietf-pce-stateful-pce를 기반으로 합니다. Junos OS Release 16.1부터 시작하여 인터넷 draft-ietf-pce-stateful-pce-07에 정의된 버전 7을 지원할 수 있습니다. 16.1 이전 버전의 PCE 초안을 지원하기 때문에 이전 릴리스를 실행하는 PCC와 인터넷 draft-ietf-pce-stateful-pce-07을 준수하는 stateful PCE 서버 간의 상호 운영성 문제가 발생했습니다.

PCE에 의해 외부 경로 컴퓨팅을 활성화하려면, 계층 수준에서 lsp-external-controller PCC에 [edit mpls][edit mpls lsp lsp-name] 명령문을 포함해야 합니다.

명령문으로 구성된 LSP를 PCE 제어 lsp-external-controller LSP라고하며 기본적으로 PCE의 외부 제어를 실행합니다. 액티브 stateful PCE는 PCC의 이러한 PCE 제어 LSP에 대해 대역폭, 경로(ERO) CLI 우선 순위와 같은 네트워크에서 설정된 매개변수를 능가할 수 있습니다.

PCE가 PCC 통신을 활성화하려면 계층 수준에서 PCC에서 [edit protocols] PCEP를 구성합니다.

PCC에서 PCEP를 구성할 때 다음 고려 사항을 유의하십시오.

  • JSDN 추가 패키지는 코어 및 설치 패키지와 함께 Junos OS 필요합니다.

  • Junos OS Release 12.3은 stateful PCES만 지원

  • PCC는 최대 10개 stateful PCES에 연결할 수 있습니다. 주어진 시점에 PCC가 경로 계산을 위해 LSP를 위임하는 하나의 기본 PCE(우선 순위가 가장 낮은 PCE 또는 우선 순위가 PCE 우선 순위가 없을 때 먼저 PCC에 연결하는 PCE)만 있을 수 있습니다.

  • Junos OS Release 12.3의 경우, PCC는 항상 PCEP 세션을 시작됩니다. 원격 PCES에 의해 시작된 PCEP 세션은 PCC에서 허용하지 않습니다.

  • LSP 보호 및 끊기 전(make-before-break)과 같은 기존 LSP 기능은 PCE 제어 LSP에서 작동됩니다.

  • 자동 대역폭 및 제약 기반 라우팅을 제어하는 LSP가 PCE 제어 LSP와 공존할 수 있습니다. 하지만 자동 대역폭 옵션은 PCE 제어 LSP에 대해 꺼집니다.

  • PCE 제어 LSP는 lsp-nexthop to route CLI Adjacencies, CCC 연결 및 논리적 터널과 같은 다른 네트워크 구성을 통해 지칭될 수 있습니다.

  • PCE 제어 LSP는 GRES를 지원하지 않습니다.

  • 논리적 시스템 하에서 PCE 제어 LSP는 지원되지 않습니다.

  • PCE 제어 LSP는 점대다점 LSP가 될 수 없습니다.

  • 양방향 LSP는 지원되지 않습니다.

  • PCE 제어 LSP는 기본 경로가 없는 보조 경로를 사용할 수 없습니다.

  • PCE 제어 LSP는 외부 경로 계산에 의존하여 전체 설정 시간, 재라우트, 중단 전 기능에 영향을 미치게 됩니다.

  • LSP를 유치하기 위한 설정 시간 및 컨버전스 시간(Reroute, MBB)은 PCE 제어 LSP가 없을 때 이전 릴리스와 동일합니다. 그러나 PCE 제어 LSP의 존재에는 작은 영향이 있습니다.

  • ERO 연산 시간은 로컬 CSPF보다 훨씬 높은 것으로 예상됩니다.

토폴로지

그림 5: RSVP-MPLS PCEP 트래픽 엔지니어링(TE)RSVP-MPLS PCEP 트래픽 엔지니어링(TE)

이 예에서 PCC는 외부 활성 stateful PCE에 연결하는 ingress 라우터입니다.

라우터 PCC의 외부 LSP는 다음과 같이 계산됩니다.

  1. Router PCC는 라우터 라우터를 사용하여 설정된 LSP 터널 구성을 CLI. 수신된 구성이 외부 경로 컴퓨팅을 통해 지원된다고 생각하면, Router PCC는 대역폭, 경로 및 우선 순위와 같은 LSP 속성 중 일부가 stateful PCE의 제어 하에 있으며 LSP를 PCE에 위임하는 것을 인식하게 됩니다.

    이 예에서는 외부 LSP가 호출되고 PCC-to-R2 Router PCC에서 라우터 R2로 설정 중입니다. CLI 구성된 ERO는 PCC-to-R2 PCC-R0-R1-R2입니다. 대역폭은 10m, 설정 및 우선 순위 보유 값 모두 PCC-to-R2 4입니다.

  2. 라우터 PCC가 PCE 제어 LSP 속성을 검색합니다. 이를 위해 Router PCC는 LSP가 구성된 상태 상태의 PCE로 PCRpt 메시지를 전송합니다. PCRpt 메시지는 LSP의 상태를 전달하고 LSP의 로컬 구성 매개 변수를 포함합니다.

  3. stateful PCE는 위임된 LSP 속성을 하나 이상 수정하고 PCUpd 메시지를 통해 라우터 PCC에 새로운 LSP 매개 변수를 전송합니다.

  4. 라우터 PCC는 새로운 LSP 매개 변수를 수신할 때 새 LSP를 설정하고 PCE 제공 경로를 사용하여 신호를 다시 전송합니다.

    이 예에서는 PCE에서 제공하는 ERO가 PCC-to-R2 PCC-R3-R2입니다. 대역폭은 8m, 설정 및 우선 순위 보유 값 PCC-to-R2 모두 3입니다.

  5. Router PCC는 새 RRO가 있는 PCRpt를 stateful PCE로 전송합니다.

구성

CLI 빠른 구성

이 예제를 신속하게 구성하려면 다음 명령을 복사하여 텍스트 파일에 붙여넣기하고, 라인 끊기를 제거하고, 네트워크 구성과 일치하는 데 필요한 세부 정보를 변경한 다음, 명령어를 계층 수준에서 CLI [edit] 붙여넣습니다.

Pcc

R0

R1

R2

R3

절차

단계별 절차

다음 예제에서는 구성 계층의 다양한 수준을 탐색해야 합니다. 네트워크의 네트워크 CLI 대한 자세한 내용은 configuration mode에서 CLI Editor 사용 을 참조하십시오.

라우터 PCC 구성:

주:

각 라우터에 대한 적절한 인터페이스 이름주니퍼 네트웍스 주소 및 기타 매개 변수를 수정한 후 MPLS 도메인의 모든 ingress 라우터에 대해 이 절차를 반복합니다.

  1. 인터페이스를 구성합니다.

    인터페이스를 활성화하려면 MPLS 수신 트래픽을 폐기하지 않을 수 있도록 인터페이스에 프로토콜 MPLS 있습니다.

  2. 관리 인터페이스를 제외한 라우터 PCC의 모든 인터페이스에서 RSVP를 활성화합니다.

  3. 라우터 PCC에서 라우터 R2로 LSP(Label-Switched Path)를 구성하고 PCE에 의해 LSP에 대한 외부 제어를 실행합니다.

  4. 로컬 제어 기능을 가지며 PCE에서 제공하는 LSP 매개 변수를 통해 까다로워하는 라우터 PCC에서 라우터 R2로 LSP를 구성합니다.

  5. 관리 MPLS 제외한 라우터 PCC의 모든 인터페이스에서 데이터 관리를 활성화합니다.

  6. 관리 IS-IS(Intermediate System to Intermediate System) 라우터 PCC의 모든 인터페이스에서 구성할 수 있습니다.

  7. Router PCC가 연결한 PCE를 정의하고 PCE의 IP 주소를 구성합니다.

  8. TCP 기반 PCEP를 사용하여 PCE에 연결하는 라우터 PCC를 위한 대상 포트를 구성합니다.

  9. PCE 유형을 구성합니다.

결과

구성 모드에서 명령어를 입력하여 show interfacesshow protocols 구성을 확인 출력이 의도한 구성을 표시하지 않는 경우 이 예제의 지침을 반복하여 구성을 수정합니다.

디바이스 구성이 완료되면 commit 구성 모드에서 입력합니다.

확인

구성이 제대로 작동하고 있는지 확인합니다.

PCEP 세션 상태 검증

목적

PCE 상태가 설정되어 있는 경우 PCE 및 라우터 PCC 간의 PCEP 세션 상태를 확인합니다.

실행

작동 모드에서 명령을 show path-computation-client active-pce 실행합니다.

의미

출력은 라우터 PCC가 연결된 현재 활성 stateful PCE에 대한 정보를 표시합니다. 출력 필드는 PCE와 라우터 PCC 간의 PCEP 세션의 현재 PCE status 상태를 나타냅니다.

에 대해, PCEP 세션의 상태는 PCEP 피어 사이에 PCEP 세션이 pce1PCE_STATE_UP 설정되었다는 표시입니다.

LSP의 현재 상태를 보고하기 위해 PCRpts Router PCC가 PCE에 전송한 메시지 수를 나타내는 통계 통계는 PCUpdates PCE에서 Router PCC에서 수신한 메시지의 수를 나타냅니다. 메시지에는 PCE 제어 LSP에 대해 수정된 PCE 매개 변수가 PCUpdates 포함됩니다.

LSP 제어가 외부인 경우 PCE 제어 LSP 상태 검증

목적

LSP가 외부 제어 하에 있는 경우, 라우터 PCC에서 라우터 R2로 PCE 제어 LSP의 상태를 확인합니다.

실행

작동 모드에서 명령을 show mpls lsp name PCC-to-R2 extensive 실행합니다.

의미

출력에서 및 LSPtypeLSP Control Status 출력 필드는 LSP가 외부에서 제어되는 것으로 표시됩니다. 출력에는 라우터 PCC와 PCE 간에 전송된 PCEP 메시지 로그도 표시됩니다.

PCE와 Router PCC 간의 PCEP 세션이 설정되어 라우터 PCC는 다음과 같은 PCE 제어 LSP 매개변수를 수신합니다.

  • ERO(경로)—20.31.4.2 및 20.31.5.2

  • Bandwidth—8Mbps

  • 우선 순위—3 3(설정 및 보유 값)

LSP 제어가 로컬인 경우 PCE 제어 LSP 상태 검증

목적

LSP 제어가 로컬 상태가 되는 경우 라우터 PCC에서 라우터 R2로 PCE 제어 LSP의 상태를 확인합니다.

실행

작동 모드에서 명령을 show mpls lsp name PCC-to-R2 extensive 실행합니다.

의미

출력에서 출력 필드는 LSP Control Status LSP가 로컬 제어 중인을 보여줍니다. PCE 제어 LSP가 로컬 제어 중이기는 하지만, Router PCC는 LSP에 다시 신호를 전송할 다음 기회가 될 때까지 PCE 제공 매개 변수를 계속 사용합니다.

출력은 LSP를 실제 사용 값으로 설정하는 데 사용되는 PCE 제공 매개 변수와 함께 CLI 사용하여 구성된 LSP 매개 변수를 나타냅니다.

  • 대역폭—10Mbps(실제Bandwidth: 8Mbps)

  • 우선 순위—4 4(실제Priorities 3 3)

LSP에 다시 신호를 재지정하기 위해 트리거될 때, Router PCC는 로컬 구성 매개변수를 사용하여 PCE 제어 LSP를 설정합니다.

Computed ERO 20.31.1.2, 20.31.2.2 및 20.31.8.2입니다. PCE 제어 LSP는 로컬 구성 매개변수를 사용하여 설정됩니다.

예를 들면 다음과 같습니다. PCE 시작 Point-to-Point LSP를 MPLS RSVP-트래픽 엔지니어링(TE) RSVP-트래픽 엔지니어링(TE) 을 위한 경로 계산 요소 프로토콜 구성

다음 예제에서는 PCE(Path Computation Element)-시작 트래픽 엔지니어링 Point-to-Point 레이블 스위칭 경로(LSP)를 지원하는 기능을 통해 PCC(Path Computation Client)를 구성하는 방법을 보여줍니다.

요구 사항

이 예에서는 다음과 같은 하드웨어 및 소프트웨어 구성 요소를 활용합니다.

  • ACX 시리즈, M Series, MX 시리즈 또는 T 시리즈 라우터.

  • ingress 라우터(PCC)의 2개의 외부 stateful PCES에 대한 TCP 연결.

  • Junos OS Release 16.1 이상이 PCC에서 실행됩니다.

시작하기 전에 다음을 할 수 있습니다.

  • 디바이스 인터페이스를 구성합니다.

  • RSVP-MPLS 및 RSVP-트래픽 엔지니어링(TE)(RSVP-Traffic Engineering)를 구성합니다.

  • 모든 최단 경로 우선(OSPF) 또는 기타 모든 IGP 구성합니다.

개요

Junos OS Release 16.1부터는 stateful PCE가 PCC를 통해 트래픽 엔지니어링 LSP를 시작 및 프로비저닝할 수 있도록 PCEP 기능이 확장됩니다. 앞서, LSP는 PCC상에서 구성이 났고 PCC는 외부 LSP에 대한 제어를 PCE에 위임했습니다. LSP 상태의 소유권은 PCC에 의해 유지 관리됩니다. PCE 시작 LSP가 도입되면 PCC에서 로컬로 구성된 LSP를 사용할 필요 없이, PCE가 트래픽 엔지니어링 포인트 대 점(point-to-point) LSP를 동적으로 시작하고 프로비저닝할 수 있습니다. PCE에서 PCCreate 메시지를 수신할 때, PCC는 PCE 시작 LSP를 생성하고 LSP를 PCE에 자동으로 위임합니다.

PCC를 위한 PCE 시작 Point-to-Point LSP의 지원을 구성할 때 다음 고려 사항을 유의하십시오.

  • Junos OS Release 13.3은 stateful PCES만 지원.

  • Junos OS Release 13.3의 경우, PCC는 항상 PCEP 세션을 시작됩니다. 원격 PCES에 의해 시작된 PCEP 세션은 PCC에서 허용하지 않습니다.

  • LSP 보호 및 끊기 전(make-before-break)과 같은 기존 LSP 기능은 PCE 시작 LSP에서 작동됩니다.

  • PCE 개시 LSP는 GRES(graceful 라우팅 엔진 스위치오버)를 지원하지 않습니다.

  • 논리적 시스템 하에서 PCE 시작 LSP는 지원되지 않습니다.

  • PCE 시작 LSP는 점대다점 LSP가 될 수 없습니다.

  • 양방향 LSP는 지원되지 않습니다.

  • 열지 않은 트래픽 엔지니어링(TE) 대한 RSVP-트래픽 엔지니어링(TE) 지원되지 않습니다. PCE 시작 LSP는 번호가 매기는 링크만 지원합니다.

  • 세그먼트 라우팅 LSP를 시작하는 PCE는 비색 세그먼트 라우팅 LSP와 연관된 바인딩 세그먼트 ID(SID) 레이블을 사용하여 PCE 시작 세그먼트 라우팅 LSP 경로를 프로비저닝할 수 있습니다.

    ingress Junos OS 릴리스 18.2R1 구성되지 않은 세그먼트 라우팅 LSP는 PCEP 세션을 통해 PCE에 보고됩니다. 이러한 비색 세그먼트 라우팅 LSP는 연관된 SID 레이블을 결합할 수 있습니다. 이 기능을 통해 PCE는 Label 스택에서 이 바인딩 SID 레이블을 사용하여 PCE 시작 세그먼트 라우팅 LSP 경로를 프로비저닝할 수 있습니다.

토폴로지

그림 6: RSVP-MPLS PCE에서 유인된 Point-to-Point LSP 트래픽 엔지니어링(TE)RSVP-MPLS PCE에서 유인된 Point-to-Point LSP 트래픽 엔지니어링(TE)

이 예에서 PCC는 2개의 외부 stateful PCES에 연결하는 ingress 라우터입니다. PCE1 및 PCE2의 두 버전으로 나타났습니다.

새로운 요구가 있는 경우, active stateful PCE는 요구 사항을 충족하기 위해 LSP를 동적으로 시작합니다. PCC는 PCE 개시 LSP를 지원하는 기능으로 구성되어 PCC의 경로 계산은 다음과 같이 수행됩니다.

  1. PCE는 LSP를 시작하고 프로비저닝하기 위해 PCC로 PCCreate 메시지를 전송합니다. PCC는 PCE에서 수신된 매개 변수를 사용하여 PCE 시작 LSP를 설정하고 PCE가 시작된 PCE에 자동으로 LSP를 위임합니다.

    이 예에서 PCE1은 PCC에서 PCE 시작 LSP를 시작하고 프로비저닝하는 활성 stateful PCE입니다. PCE 시작 LSP 매개 변수를 수신할 때, PCC는 LSP를 설정하고 PCE 시작 LSP를 PCE1에 자동으로 위임합니다.

  2. PCC와 PCE1 간의 PCEP 세션이 종료되면 PCC는 PCE1-시작 LSP에 대한 2개의 시간(timers)을 시작합니다. 세분화 타임아웃과 LSP 클린업 타임러를 제공합니다. 이 기간 동안 PCE1 또는 PCE2는 PCE 시작 LSP에 대한 제어를 취득할 수 있습니다.

  3. PCE2가 LSP 클린업 타임러 만료 전에 PCE 시작 LSP에 대한 제어를 획득하면 PCC가 PCE 시작 LSP를 PCE2로 위임하고 LSP 클린업 타임러와 위임 클린업 타임아웃이 중지됩니다.

  4. 위임 클린업 타임아웃이 만료되고 PCE1 또는 PCE2가 PCE 시작 LSP에 대한 제어를 획득하지 않은 경우, PCC는 LSP 클린업 타임러가 만료될 때까지 위임되지 않은 PCE-시작 LSP에 대한 로컬 제어를 제공합니다.

  5. LSP 클린업 타임러 만료 후 PCC는 PCE1에서 프로비저닝한 PCE 시작 LSP를 삭제합니다.

구성

CLI 빠른 구성

이 예제를 신속하게 구성하려면 다음 명령을 복사하여 텍스트 파일에 붙여넣기하고, 라인 끊기를 제거하고, 네트워크 구성과 일치하는 데 필요한 세부 정보를 변경한 다음, 명령어를 계층 수준에서 CLI [edit] 붙여넣습니다.

Pcc

R1

R2

절차

단계별 절차

다음 예제에서는 구성 계층의 다양한 수준을 탐색해야 합니다. 네트워크의 네트워크 CLI 대한 자세한 내용은 configuration mode에서 CLI Editor 사용 을 참조하십시오.

PCC 라우터 구성:

주:

각 라우터에 대한 적절한 인터페이스 이름주니퍼 네트웍스 주소 및 기타 매개 변수를 수정한 후 MPLS 도메인의 모든 ingress 라우터에 대해 이 절차를 반복합니다.

  1. 인터페이스를 구성합니다.

    인터페이스를 활성화하려면 MPLS 수신 트래픽을 폐기하지 않을 수 있도록 인터페이스에 프로토콜 MPLS 있습니다.

  2. 관리 인터페이스를 제외한 PCC의 모든 인터페이스에서 RSVP를 활성화합니다.

  3. PCES에 의해 LSP에 대한 외부 제어가 가능

  4. 관리 MPLS PCC의 모든 인터페이스에서 데이터 관리를 활성화합니다.

  5. 관리 최단 경로 우선(OSPF) 제외한 PCC의 모든 인터페이스에서 구성합니다.

  6. PCE 그룹을 정의하고 PCE 그룹에 PCE 시작 LSP를 지원할 수 있습니다.

  7. PCC에 연결하는 PCES를 정의합니다.

결과

구성 모드에서 명령어를 입력하여 show interfacesshow protocols 구성을 확인 출력이 의도한 구성을 표시하지 않는 경우 이 예제의 지침을 반복하여 구성을 수정합니다.

디바이스 구성이 완료되면 commit 구성 모드에서 입력합니다.

확인

구성이 제대로 작동하고 있는지 확인합니다.

PCC 상태 검증

목적

PCC와 연결된 PCES 간의 PCEP 세션 상태 및 LSP 요약을 검증합니다.

실행

작동 모드에서 명령을 show path-computation-client status 실행합니다.

의미

출력은 활성 stateful PCES와 PCC 간의 PCEP 세션 상태를 표시됩니다. 또한 PCC에서 다양한 유형의 LSP와 연결된 PCES가 프로비저닝하고 위임한 LSP 수에 대한 정보도 표시됩니다.

PCE1은 주 활성 PCE로, PCC에 의해 자동으로 위임된 하나의 PCE 시작 LSP를 가집니다.

PCE1 상태 검증

목적

기본 활성 stateful PCE의 상태를 검증합니다.

실행

작동 모드에서 명령을 show path-computation-client active-pce detail 실행합니다.

의미

출력은 PCC가 연결된 현재 Stateful PCE에 대한 정보를 표시합니다. 출력 필드는 PCE와 PCC 간의 PCEP 세션의 현재 PCE status 상태를 나타냅니다.

PCE1의 경우, PCEP 세션의 상태는 PCEP 세션이 PCC에 설정되었다는 PCE_STATE_UP 표시입니다.

LSP가 외부에 프로비저닝될 때 PCE-시작 LSP 상태 검증

목적

PCE 시작 LSP의 상태를 검증합니다.

실행

작동 모드에서 명령을 show mpls lsp externally-provisioned detail 실행합니다.

의미

출력 필드는 LSP가 외부적으로 프로비저닝된 LSPtype 것으로 보여줍니다.

PCC와 PCE1 간의 PCEP 세션이 설정됩니다. PCC는 다음과 같은 PCE 시작 LSP 매개변수를 수신합니다.

  • ERO(경로)—10.0.102.10 및 10.0.101.9

  • 대역폭—8Mbps

  • 우선 순위—7 0(설정 및 보유 값)

PCE 시작 Point-to-Point LSP를 MPLS RSVP-트래픽 엔지니어링(TE) RSVP-을 위한 경로 계산 요소 프로토콜 구성

중앙 집중식 외부 경로 컴퓨팅 엔티티로부터 동적으로 생성된 LSP(Label Switched Path)를 지원할 수 있는 PCC(Path Computation Client)를 구성할 수 있습니다. STATEFUL PATH Computaiton Element(PCE)는 수요가 증가할 때 외부 경로 계산을 수행하고 동적 LSP를 생성하는 데 사용할 수 있습니다.

PCC는 PCE에서 제공하는 LSP 매개변수 또는 PCE가 LSP를 프로비저닝하지 않을 때 사전 구성된 LSP 템플릿에서 매개변수를 사용하여 PCE 개시 점대점 LSP를 생성하고 PCE 개시 점대점 LSP를 해당 PCE에 자동으로 위임합니다. 그 결과, PCE가 시작된 LSP의 경우 PCC에서 로컬로 구성된 LSP가 필요하지 않습니다.

CLI 제어 LSP, PCE 제어 LSP 및 PCE 개시 LSP는 PCC에서 서로 공존할 수 있습니다.

시작하기 전에 다음을 할 수 있습니다.

  • 디바이스 인터페이스를 구성합니다.

  • 구성 MPLS 및 RSVP-트래픽 엔지니어링(TE).

  • 모든 최단 경로 우선(OSPF) 또는 기타 모든 IGP 구성합니다.

PCE 시작 점대점(point-to-point) LSP를 지원하도록 PCC를 구성하기 위해 다음 작업을 완료하십시오.

  1. 구성 모드에서는 다음 계층 수준으로 이동합니다.
  2. PCC가 최대 수신할 수 있는 분당 메시지 수를 지정합니다.
  3. PCC가 최대 허용할 수 있는 모든 연결된 PCES에 대해 외부 프로비저닝 LSP(Label Switched Path)의 수를 지정합니다.
  4. 연결된 PCE가 PCE 매개 변수를 구성할 수 있도록 사용자 정의된 고유 ID를 지정합니다.
  5. PCEP 세션의 연결이 끊어진 후에 PCC가 라우팅 프로토콜 프로세스로 LSP 제어를 반환하기 전에 기다려야 하는 시간(초)을 지정합니다.
  6. 연결할 PCE의 IPv4 주소를 지정합니다.
  7. PCE가 사용하고 있는 TCP 포트 번호 지정

    이 값은 1에서 65535까지, 기본 값은 4189입니다.

  8. PCEP 세션이 종료된 후, PCC가 실패한 PCE에서 위임되지 않은 PCE-시작 LSP를 삭제하기 전에 대기해야 하는 시간(초)을 지정합니다.
  9. 연결된 PCES에 의해 외부적으로 프로비저닝되는 SP를 허용하도록 PCC를 구성합니다. 기본적으로 PCC는 PCE 시작 LSP를 거부합니다.
  10. PCEP 세션이 종료된 이후에 PCC가 최대 수신할 수 있는 분당 알 수 없는 메시지의 수를 지정합니다.

    이 값은 1에서 16384까지, 기본값은 0(비활성화 또는 제한 없음)입니다.

  11. PCEP 세션이 종료된 이후에 최대로 PCC가 수신할 수 있는 알려지지 않은 요청의 수를 지정합니다.

    값은 0에서 16384까지, 기본값은 5입니다. 값 0은 이 명령문을 비활성화합니다.

  12. PCE 유형을 구성합니다.
  13. PCC가 요청을 재전달하기 전에 응답을 기다릴 수 있는 시간(초)을 지정합니다.

    이 값은 0에서 6,5535초까지 다양합니다.

  14. 구성을 검증하고 커밋합니다.

샘플 출력

예를 들면 다음과 같습니다. PCE 제어 점대다점 LSP를 MPLS RSVP-트래픽 엔지니어링(TE) RSVP-트래픽 엔지니어링(TE) 위한 경로 계산 요소 프로토콜 구성

다음 예제에서는 PCC(Path Computation Client)를 PCE(Path Computation Element)에 보고하는 방법을 보여줍니다 트래픽 엔지니어링(TE).

요구 사항

이 예에서는 다음과 같은 하드웨어 및 소프트웨어 구성 요소를 활용합니다.

  • ACX 시리즈, M Series, MX 시리즈 또는 T 시리즈 라우터.

  • VRR(Virtual Route Reflector) 기능으로 구성된 하나의 가상 머신.

  • VRR의 외부 stateful PCE에 대한 TCP 연결.

  • Junos OS Release 16.1 이상이 PCC에서 실행됩니다.

시작하기 전에 다음을 할 수 있습니다.

  • 디바이스 인터페이스를 구성합니다.

  • 구성 MPLS 및 RSVP-트래픽 엔지니어링(TE).

  • 모든 최단 경로 우선(OSPF) 또는 기타 모든 IGP 구성합니다.

개요

PCE와 PCC 간에 PCEP 세션이 설정되면 PCC는 시스템의 모든 LSP를 LSP 상태 동기화를 위해 PCE에 보고합니다. 여기에는 PCC 제어, PCE 위임 및 PCE 개시 Point-to-Point LSP가 포함됩니다. Junos OS Release 15.1F6 16.1R1 Point-to-Multipoint LSP로도 확장됩니다.

기본적으로, 점대다점 LSP에 대한 PCE 제어는 PCC에서 지원되지 않습니다. 이 기능을 추가하기 위해, 명령문 또는 계층 p2mp-lsp-report-capability[edit protocols pcep pce pce-name][edit protocols pcep pce-group group-id] 수준에 명령문을 포함해야 합니다.

토폴로지

그림 7: PCE 제어 포인트 대 멀티포인트 LSP 예PCE 제어 포인트 대 멀티포인트 LSP 예

이 예에서 PCC는 ingress 라우터, Router R1은 전송 라우터, Router R2는 egress 라우터입니다. PCC는 PCE에 연결된 VRR(Virtual Route Reflector)에 연결됩니다. PCC, 라우터 R1, 라우터 R2 간에 다수의 Point-to-Multipoint 인터페이스가 있습니다.

점대다점 LSP에 대한 보고는 다음과 같이 실행됩니다.

  1. 점대점(point-to-multipoint) 보고 기능을 지원하지 않고도 Router PCC가 점대점(point-to-point) 및 점대다점 LSP로 구성된 경우, 점대점(point-to-multipoint) LSP만 연결된 PCE에 보고됩니다. 기본적으로 PCC는 점대다점 LSP 보고 기능을 지원하지 않습니다.

  2. 라우터 PCC가 Point-to-Multipoint LSP 보고 기능으로 구성되면 PCC는 먼저 보고서 메시지를 통해 이 기능을 PCE에 알려야 합니다.

  3. 기본적으로 PCE는 점대다점 LSP 기능을 제공합니다. 점대다점 LSP 기능에 대한 PCC의 광고를 수신하는 경우, PCE는 해당 기능을 PCC에 광고합니다.

  4. Point-to-Multipoint 기능에 대한 PCE의 광고를 수신하는 경우, PCC는 업데이트 메시지를 사용하여 점대다점 LSP의 모든 브랜치에 대해 보고합니다.

  5. 모든 LSP가 PCE에 보고된 후, LSP 상태는 PCE와 PCC 간에 동기화됩니다.

구성

CLI 빠른 구성

이 예제를 신속하게 구성하려면 다음 명령을 복사하여 텍스트 파일에 붙여넣기하고, 라인 끊기를 제거하고, 네트워크 구성과 일치하는 데 필요한 세부 정보를 변경한 다음, 명령어를 계층 수준에서 CLI [edit] 붙여넣습니다.

Pcc

R1

R2

R3

절차

단계별 절차

다음 예제에서는 구성 계층의 다양한 수준을 탐색해야 합니다. 네트워크의 네트워크 CLI 대한 자세한 내용은 configuration mode에서 CLI Editor 사용 을 참조하십시오.

PCC 라우터 구성:

  1. 라우터 PCC의 인터페이스를 구성합니다. 인터페이스를 활성화하려면 MPLS 수신 트래픽을 폐기하지 않을 수 있도록 인터페이스에 프로토콜 MPLS 있습니다.

  2. 라우터 PCC에 대한 자율 시스템 번호를 구성합니다.

  3. 관리 인터페이스를 제외한 라우터 PCC의 모든 인터페이스에서 RSVP를 활성화합니다.

  4. 관리 MPLS 라우터 PCC의 모든 인터페이스에서 데이터 관리를 활성화합니다.

  5. 동적 LSP를 구성하고 LSP에 대한 자동 경로 계산을 비활성화합니다.

  6. 점대다점 LSP를 구성하고 LSP에 대한 외부 경로 컴퓨팅 엔티티를 정의합니다.

  7. LSP에 대한 외부 경로 MPLS 외부 프로비저닝 LSP에 템플릿을 할당합니다.

  8. 로컬 제어가 있는 LSP를 구성하고 PCE 제공 LSP 매개 변수를 통해 까다로워진 LSP를 구성합니다.

  9. 제한 MPLS LSP 계산에 대한 관리 그룹 정책을 구성합니다.

  10. 구성된 관리 그룹 정책을 Router PCC 인터페이스에 할당합니다.

  11. TED(Traffic Engineering Database) 가져오기 정책을 구성합니다.

  12. 내부 BGP(Border Gateway Protocol) 구성합니다.

  13. 트래픽 엔지니어링을 구성하고 BGP(Border Gateway Protocol) 정책을 할당합니다.

  14. 라우터 최단 경로 우선(OSPF)의 모든 점대다점 인터페이스에서 최단 경로 우선(OSPF) 영역 0을 구성합니다.

  15. 라우터 최단 경로 우선(OSPF) 점대점 인터페이스에서 최단 경로 우선(OSPF) 영역 0을 구성합니다.

  16. 트래픽 엔지니어링을 위한 최단 경로 우선(OSPF).

  17. Router PCC가 연결한 PCE를 정의하고 PCE 매개 변수를 구성합니다.

  18. 외부 경로 컴퓨팅에 대한 점대다점 LSP 기능을 지원하도록 라우터 PCC를 구성합니다.

  19. 트래픽 엔지니어링 정책을 구성합니다.

결과

구성 모드에서 명령어를 입력하여 show interfacesshow protocols 구성을 확인 출력이 의도한 구성을 표시하지 않는 경우 이 예제의 지침을 반복하여 구성을 수정합니다.

확인

구성이 제대로 작동하고 있는지 확인합니다.

PCC에서 LSP 구성 검증

목적

점대다점 LSP의 LSP 유형 및 실행 상태를 검증합니다.

실행

작동 모드에서 명령을 show mpls lsp extensive 실행합니다.

의미

출력은 lsp2-pcc LSP를 PCE 제어 LSP로 표시됩니다.

PCC에서 PCE 구성 확인

목적

PCE 매개 변수 구성 및 PCE 상태를 검증합니다.

실행

작동 모드에서 명령을 show path-computation-client active-pce 실행합니다.

의미

출력은 라우터 PCC가 연결된 활성 PCE와 pce1 PCE 매개 변수 및 상태를 나타냅니다.

PCE 시작 Point-to-Multipoint LSP를 MPLS RSVP-트래픽 엔지니어링(TE) RSVP-트래픽 엔지니어링(TE) 경로 계산 요소 프로토콜 이해

점대다점 PCE 시작 LSP가 도입된 PCE는 PCC에서 로컬 LSP 구성 없이도 점대다점 LSP를 동적으로 시작 및 프로비저닝할 수 있습니다. 이를 통해 PCE는 PCEP(Path Computation Element Protocol) 세션 내 및 그 전반의 Point-to-Multipoint 경로 계산의 타이밍과 시퀀스를 제어함으로써 중앙에서 제어 및 구축되는 다이내믹한 네트워크를 구축할 수 있습니다.

PCE 시작 Point-to-Multipoint LSP의 이점

점대다점(point-to-multipoint) LSP의 동적 생성 및 해체로 애플리케이션 요구에 부응하여 점대다점 트래픽 엔지니어링 LSP 배치의 요구 사항을 충족함으로써 중앙에서 제어 및 구축되는 다이내믹한 네트워크를 구축합니다.

PCE 시작 Point-to-Multipoint LSP의 시그널링

PCE 시작 Point-to-Multipoint LSP의 시그널링은 다음과 같습니다.

  • When a new branch is added (Grafting)—오직 새로운 브랜치 서브 LSP만이 신호 전송이 됐을 뿐, 전체 Point-to-Multipoint 트리의 시그널링이 재시그널링되지는 않습니다.

    새로운 서브 LSP를 프로비저닝하기 전에 토폴로지 변경이 발생하면 PCS(Path Computation Server)는 전체 Point-to-Multipoint 트리를 다시 계산하고 PC 업데이트 메시지를 사용하여 Point-to-Multipoint LSP를 업데이트합니다.

  • When a branch is deleted (Pruning)—삭제된 브랜치 하위 LSP가 해소되고 전체 Point-to-Multipoint 트리의 시그널링이 재시그널링되지 않습니다.

  • When a branch sub-LSP parameter is changed—최적화로 인하여 또는 사용자 요청 시 ERO(Explicit Route Object), 대역폭 또는 우선 순위와 같은 하위 LSP 매개 변수의 변경이 일어날 수 있습니다. 하위 LSP에 대한 재시그널링 요청이 있는 경우 전체 Point-to-Multipoint 트리가 다시 신호 전송된 다음, 모든 브랜치의 새 인스턴스가 실행된 후 새 인스턴스로의 전환이 발생합니다.

  • When a branch sub-LSP path fails—브랜치 하위 LSP에 대해 오류가 PCS에 보고됩니다. PCS에서 새로운 ERO를 수신할 때, 전체 Point-to-Multipoint 트리는 실패한 브랜치 하위 LSP와 함께 다시 신호가 전송됩니다. 새로운 인스턴스로의 전환은 MBB(Make-Before-Break) 스타일로 실행됩니다.

PCEP 세션 장애 이후 PCE 시작 Point-to-Multipoint LSP의 동작

PCEP 세션에 장애가 발생하면, PCE가 시작된 Point-to-Multipoint LSP는 타임러 만료될 때까지 state timeout 고조됩니다. state timeout타임러가 만료되면 PCE 시작 LSP가 정리됩니다.

PCEP 세션 장애가 발생하면 PCE가 시작되는 점대다점 LSP에 대한 제어를 얻기 위해 기본 또는 보조 PCE는 타임러가 만료되기 전에 메시지를 PCInitiatestate timeout 전송합니다.

PCE 시작 Point-to-Multipoint LSP 기능 구성

기본적으로 PCE에 의해 점대다점 LSP를 생성하고 프로비저닝하는 것은 PCC에서 지원되지 않습니다. 이 기능을 활성화하려면, 또는 계층 수준에서 p2mp-lsp-init-capabilityp2mp-lsp-update-capability[edit protocols pcep pce pce-name] 명령문을 [edit protocols pcep pce-group group-id] 포함합니다.

p2mp-lsp-init-capability 명령문은 PCE에 의해 점대다점(point-to-multipoint) RSVP-트래픽 엔지니어링(TE) 기능을 제공합니다. 이 명령문은 PCE에 의해 점대다점 p2mp-lsp-update-capability RSVP-트래픽 엔지니어링(TE) LSP 매개 변수를 업데이트하는 기능을 제공합니다.

PCE 시작 Point-to-Multipoint LSP를 위한 지원 및 지원되지 않는 기능

PCE 시작 Point-to-Multipoint LSP를 통해 지원되는 기능은 다음과 같습니다.

  • 인터넷 draft-ietf-pce-stateful-pce-p2mp(2018년 10월 만료), P2MP(Point-to-Multipoint)트래픽 엔지니어링 레이블 스위칭 경로에 대한 Stateful PCE 사용을 위한 PCE(Path Computation Element) 프로토콜 확장

  • 주니어는 Junos OS Release 21.1R1부터 PCE 시작 RSVP 기반의 점대다점 LSP를 위한 무중단 활성 라우팅(NSR)을 지원하고 있습니다. 주 라우팅 엔진 컨트롤러를 통해 PCEP 세션을 유지 관리합니다. PCE 시작 P2MP LSP에 대한 멀티캐스트 플로우 사양을 포함하여 PCES에서 시작된 모든 RSVP LSP를 백업 장치와 라우팅 엔진. 전환이 진행되는 동안 PCEP 세션은 다운되어 백업 라우팅 엔진 스위치가 주 라우팅 엔진. 이를 통해 전환이 진행되는 동안 PCE 시작 RSVP LSP를 통해 수행된 트래픽의 트래픽 라우팅 엔진 감소합니다. 이 기능은 NSR이 구성되면 활성화됩니다.

PCE 시작 Point-to-Multipoint LSP에서는 다음 기능이 지원되지 않습니다.

  • 로컬 제어 LSP의 점대다점(point-to-multipoint) 위임

  • LSP 제어 위임.

  • 라우팅 도메인 내에서 PCE IGP 위한 내부 게이트웨이 프로토콜(IGP) 확장.

  • 요청/응답 메시징

  • 한 지점에서 멀티포인트 트리로 브랜치 하위 LSP를 직접 이동합니다.

    첫 번째 점대다점 트리에서 브랜치 하위 LSP를 삭제하고 메시지가 장비에서 LSP 제거를 표시한 후에 다른 포인트에 다시 추가하면 동일한 결과를 얻을 수 PCReport 있습니다.

  • IPv6는 지원되지 않습니다.

  • SERO 기반 시그널링은 지원되지 않습니다.

  • 비어 있는 ERO 기능은 지원되지 않습니다.

  • 링크 보호는 지원되지 않습니다.

PCE 시작 Point-To-Multipoint LSP를 MVPN에 매핑

단일 또는 범위의 MVPN 멀티캐스트 플로우(S,G)를 동적으로 생성된 PCE 개시 점대다점 LSP(Point-to-Multipoint Label-Switched Path)에 연결할 수 있습니다. 이 기능이 작동할 플로우의 선택적 유형만 지정할 수 있습니다. 여기에는 다음이 포함됩니다.

  • MVPN 라우팅 인스턴스에 매핑되는 RD(Route Distinguisher).

  • (S,G)은 멀티캐스트 패킷 및 대상 멀티캐스트 그룹 주소의 소스입니다. 이는 터널에 매핑하기 위해 수신 트래픽을 필터링하는 데 사용됩니다.

  • 위에서 언급한 플로우 규격과 일치하는 트래픽을 전송하는 데 사용되는 Point-to-Multipoint LSP

자세한 내용은 인터넷 draft-ietf-pce-pce-flowspec-05(2020년 2월 16일 만료) Flow Specification용 PCEP Extension을 참조하십시오.

이 기능의 현재 구현은 초안의 다음 섹션을 구현하지 않습니다.

  • 섹션 3.1.2—에서 PCE 용량을 광고하는 IGP

  • 섹션 3.2—PCReq 및 PCRep 메시지

  • 섹션 7—루트 디스터루(route distinguu)를 제외하고 대부분의 플로우 규격이 현재 구현되어 있는 서퍼리시(supporisher)가 아니며 IPv4 멀티캐스트 플로우 사양은 지원되지 않습니다.

PCE 시작 점대다점 LSP의 매핑을 MVPN에 활성화하려면 다음을 제공합니다.

  • PCC에 의해 플로우 규격 기능(트래픽 스티어링이라고도도)에 대한 지원을 표시하는 계층 수준에서 pce_traffic_steering[edit protocols pcep pce pce-id] 명령문을 포함합니다.

  • 계층 external-controller 수준에서 [edit routing-instances routing-instance-name provider-tunnel] 명령문을 포함합니다.

    MVPN에 대한 제공업체-터널 구성의 존재는 이 MVPN 인스턴스에 대한 점대다점 LSP 및 (S,G) 외부 컨트롤러에 의해 제공될 수 있는 것으로 나타남을 external-controller 나타냅니다. 이를 통해 외부 컨트롤러가 MVPN을 위해 동적으로 구성(S,G) 및 Point-to-Multipoint LSP를 구성할 수 있습니다.

PCE 시작 Point-to-Multipoint LSP를 MVPN에 매핑할 때 다음을 고려합니다.

  • 특정 MVPN 인스턴스에 대한 명령문을 활성화하지 않은 경우 PCCD 프로세스가 동적으로 external-controller pccd 구성되지 않습니다.

  • 구성을 CLI 경우 특정 MVPN 인스턴스에 대한 동적 학습된 멀티캐스트 플로우(S,G)가 삭제되어 외부 컨트롤러에 external-controller pccd 보고됩니다.

  • (S,G)가 이미 에지에서 CLI 경우, PCC는 로컬 구성에 대한 우선 순위가 높기 때문에 동적으로 (S,G)를 구성할 수 없습니다.

  • 외부 컨트롤러에서 특정(S,G)를 동적으로 학습한 후 동일한 MVPN 인스턴스에 대해 동일한 (S,G)를 구성하면 동적 학습(S,G)이 삭제되고 PCC를 통해 외부 컨트롤러에 보고됩니다.

  • 라우팅 프로토콜 프로세스가 재부팅된 경우 PCCD 프로세스가 모든 (S,G)를 다시 구성합니다.

  • PCCD 프로세스가 재부팅되면 MVPN은 구성된 모든 PCCD 구성(S,G)을 외부 컨트롤러에 보고합니다.

  • 사용자가 특정 MVPN 인스턴스를 사용하도록 설정하면 external-controller pccd MVPN이 PCCD 프로세스를 요청하여 구성(S,G)(있는 경우)을 요청합니다.

  • 특정 MPVN 인스턴스에 대한 주요 구성 변경이 있는 경우 MVPN은 PCCD 프로세스를 요청하여 특정 MVPN 인스턴스에 대한 모든(S,G)를 재구성합니다.

  • 모든 PCE 시작 Point-to-Multipoint LSP와 관련된 모든 플로우 사양은 동일한 RD를 있어야 합니다. 모든 플로우 규격이 동일한 RD가 없는 경우 PC 시작 중에 오류로 PC 시작 메시지가 드롭됩니다.

  • 선택적 플로우 규격 유형과만 Point-to-Multipoint LSP를 연관할 수 있습니다. 그렇지 않은 경우 PC 시작 메시지가 오류로 드롭됩니다.

  • 새로운 플로우 사양으로 인해 모든 플로우 규격이 RD를 동일하지 못하거나 기존 플로우 사양 업데이트로 인해 PCC가 업데이트 메시지를 드롭합니다.

  • 새로운 플로우 사양으로 인해 선택적 조건을 충족하지 못하거나 기존 플로우 사양 업데이트로 인해 PCC가 업데이트 메시지를 삭제합니다.

  • MVPN 라우팅 인스턴스와 PCE 시작의 점대다점 LSP 매핑과 정적(로컬 구성) MVPN 인스턴스를 사용하는 점대다점 LSP의 매핑은 사용자 레벨에서 동일합니다.

  • 플로우 규격 ID는 1개 점대다점 LSP에만 연결될 수 있습니다. 동일한 RD 및 (S,G)를 여러 Point-to-Multipoint LSP에 연결하기 위해 서로 다른 ID와 동일한 RD & (S,G)를 사용하여 여러 플로우 사양을 추가할 수 있습니다.

  • PCEP-mapped Dynamic(S,G)의 경우 임계값은 항상 0의 기본값입니다.

  • 단일 PCE 개시 Point-to-Multipoint LSP에 매핑된 플로우 규격의 수에는 제한이 없습니다.

  • 이 기능의 현재 구현은 다음을 지원하지 않습니다.

    • Point-to-Multipoint LSP와 연관된 포링 상태 보고

    • 포괄적 제공업체 터널 동적 구성

    • MVPN ingress 복제 터널에 대한 매핑

    • 프로그래밍 가능한 라우팅 프로토콜 프로세스(prpd)

    • MVPN CLI(S,G)에 매핑된 M2M(Point-to-Multipoint) LSP에 대한 리포팅

경로 계산 요소 프로토콜을 위한 세그먼트 라우팅 지원

SUMMARY 트래픽 스티어링을 위한 PCEP(Path Computation Element Protocol)를 사용하여 SPRING(Segment Routing) 트래픽 엔지니어링(SR-트래픽 엔지니어링(TE))에서 세그먼트 라우팅 또는 소스 패킷 라우팅을 사용할 수 있습니다. 이러한 지원으로 세그먼트 라우팅의 이점은 PCE(Path Computation Element)에 의해 외부적으로 제어되는 레이블 스위칭 경로(LSP)로 확장됩니다.

경로 계산 요소 프로토콜을 위한 세그먼트 라우팅 개요

PCEP를 위한 세그먼트 라우팅의 이점

  • 외부 컨트롤러를 통해 LSP를 설정하면 네트워크에서 LSP 및 디바이스당 대역폭 수요에 대한 글로벌 뷰를 제공함으로써 온라인 및 실시간 제약 조건 기반 경로 계산이 가능하게 됩니다.

    세그먼트 라우팅의 이점은 PCE(Path Computation Element)라고도 하는 외부 컨트롤러가 시작한 LSP로 확장되어 네트워크 내 외부 경로 컴퓨팅의 MPLS 확장됩니다.

  • 위임 기능을 갖추고 있는 ingress MX Series 라우터인 PCC(Path Computation Client)는 PCEP 세션이 다운될 때 PCE에서 위임된 세그먼트 라우팅 LSP에 대한 제어를 다시 사용할 수 있습니다. LSP는 그렇지 않으면 PCC에서 삭제됩니다. 따라서 패킷이 자동으로 폐기 또는 삭제되는 상황을 방지하여 LSP 데이터 보호를 보장할 수 있습니다(null 경로 조건).

트래픽 엔지니어링을 위한 세그먼트 라우팅

세그먼트 라우팅은 IPv4 또는 IPv6 데이터 플레인에서 작동할 수 있으며 ECMP(Equal-Cost Multipath)를 지원 세그먼트 IGP 확장 기능을 통해 세그먼트 라우팅은 Layer 3 VPN, VPWS(Virtual Private Wire Service), VPLS(Virtual Private LAN Service) 및 EVPN(Ethernet VPN)을 비롯한 다양한 멀티서비스 기능과 MPLS 통합됩니다.

세그먼트 라우팅–트래픽 엔지니어링(SR-트래픽 엔지니어링(TE)) 솔루션의 개략적인 구성 요소는 다음과 같습니다.

  • 광고 링크 특성을 IGP 사용 이 기능은 RSVP-트래픽 엔지니어링(TE).

  • ingress 디바이스 또는 PCE에서 CSPF(Constrained Shortest Path First)를 사용합니다.

  • 링크에 IGP 광고 라벨에 대한 광고용 광고용 광고(IGP) 사용

    SR-트래픽 엔지니어링(TE) 기능:

    1. ingress 장치는 전달하려는 링크의 레이블을 스택하여 LSP를 구성합니다.

    2. 링크당 IGP 광고는 Label Stacking과 결합되어 ingress 장비에서 소스 라우팅 LSP를 생성하기 때문에 전송 장비는 전체 LSP를 인식하지 못합니다.

    3. 전송 디바이스에 LSP당 메모리 요구 사항을 배치하지 않고도 에지 노드 간에 LSP가 생성됩니다. (SR-트래픽 엔지니어링(TE)에서 LSP당 시그널링이 지원되지기 때문에 이러한 LSP의 생성이 트래픽 엔지니어링(TE).

    4. 이웃당 레이블이 스택되어 많은 수의 레이블을 관리하여 컨트롤 플레인 확장을 이루게 됩니다.

Junos OS PCEP를 위한 세그먼트 라우팅 구현

Junos OS 두 가지 LSP(PCE 시작 LSP 및 PCE 위임 LSP)를 위해 PCEP를 위한 세그먼트 라우팅을 구현합니다.

PCE 시작 세그먼트 라우팅 LSP

PCE 시작 세그먼트 라우팅 LSP는 PCE가 Adjacency Segment와 Node Segment에 대해 생성하는 LSP입니다.

PCE는 다음과 같은 기능을 수행합니다.

  1. 세그먼트 라우팅 LSP의 경로를 계산합니다.

  2. PCEP 세그먼트 라우팅 확장을 사용하여 PCC(Path Computation Client)에서 LSP를 프로비저닝합니다.

  3. PCEP 세그먼트 라우팅 확장을 구문 분석합니다.

  4. PCC에서 자체 기본 설정 값을 가지고 있으며 inet.3 라우팅 테이블에서 사용할 수 있는 터널 경로를 생성하여 다른 터널 경로와 같은 IP 트래픽 및 서비스를 해결합니다.

PCC는 다음과 같은 기능을 수행합니다.

  1. 소스 S-ERO(Explicit Route Object)에서 첫 번째 NAI(Network Access Identifier)를 기반으로 나가는 인터페이스를 선택합니다.

    Junos OS 엄격한 홉으로 첫 번째 홉을 포함하는 S-EROS를 지원 Junos OS SID(Loose-Hop Node Segment ID)를 기준으로 PCC에서 아웃고가 인터페이스 선택을 지원하지 않습니다. 그러나 나머지 홉은 느슨할 수 있습니다. 단순히 넥스 홉(next-hop) 생성을 위해 라벨을 사용하는 것 이외에는 S-EROS에 대해 특정 프로세싱이 수행되지 않습니다.

  2. 다음 경우 S-ERO 거부

    • S-ERO에는 레이블이 없습니다.

    • S-ERO는 6홉 이상을 제공합니다.

    PCC는 동일한 메트릭을 통해 동일한 목적지에 여러 LSP가 있을 때 동일한 ECMP(Equal-Cost Multipath) 경로를 생성합니다.

  3. 예를 들어, 레이블이 변경되거나 철회되거나 LSP를 통해 전달된 인터페이스 중 하나가 다운될 경우, PCE가 프로비저닝된 후 세그먼트 라우팅 LSP에서 변경이 이루어지는 이벤트를 처리하기를 기다릴 수 있습니다.

PCEP 세션이 다운된 경우 PCE 시작 세그먼트 라우팅 LSP:

  1. 300초 동안 계속 유지.

  2. 300초 후에 PCC에서 삭제됩니다.

자세한 내용은 인터넷 초안-ietf-pce-lsp-setup-type-03.txt(2015년 12월 25일 만료), PCEP메시지 내 경로 설정 유형 전달을 참조합니다. 및 draft-ietf-pce-segment-routing-06.txt(2016년 2월 10일 만료), 세그먼트 라우팅을위한 PCEP 확장

PCE 위임 세그먼트 라우팅 LSP

PCE 위임 세그먼트 라우팅 LSP는 PCC가 로컬로 구성한 다음 PCE 컨트롤러에 위임하는 LSP입니다.

주:

Junos OS 릴리스 20.1R1 지원:

  • IPv4 대상을 사용하여 비수도 세그먼트 라우팅 LSP에 한해 PCE 위임 기능

  • 세그먼트 목록의 첫 번째 세그먼트만 외부 컨트롤러에 위임 및 보고 PCE 위임에는 여러 세그먼트가 지원되지 않습니다.

PCC는 다음과 같은 방법으로 세그먼트 라우팅 LSP를 외부 컨트롤러(PCE)에 위임할 수 있습니다.

  • Initial delegation—로컬 LSP는 아직 PCC에서 구성되지 않았고 LSP가 구성될 때 LSP의 위임이 발생합니다.

  • Delegation of existing LSP—로컬 LSP가 PCC에서 구성되면 소스 라우팅 경로가 구성된 후에 LSP의 위임이 실행됩니다. 즉, 위임 기능은 기존 세그먼트 라우팅 LSP에서 활성화됩니다.

세그먼트 라우팅 LSP를 위임한 후, PCE는 위임된 LSP를 제어하고 경로 계산을 위한 LSP 속성을 수정할 수 있습니다. LSP 제어는 PCC와 PCE 간의 PCEP 세션이 다운된 경우 PCC로 되락합니다. PCE 위임 LSP는 PCEP 세션이 다운된 경우 PCE 개시 LSP의 이점을 제공합니다. PCE가 시작된 LSP의 경우, PCEP 세션이 다운되면 PCC에서 LSP를 삭제합니다. 그러나 PCE 위임 LSP의 경우, PCEP 세션이 다운된 경우 PCC는 PCE에서 위임된 LSP에 대한 제어를 다시 제어합니다. 그 결과, PCE에 위임된 LSP를 통해 세션이 중단될 때 패킷이 자동으로 폐기되는 경우(null 경로 조건으로도 알려진) 상황을 미연에 지우지 않습니다.

세그먼트 라우팅 LSP는 PCE 위임 기능을 지원하는 다음과 같은 유형의 세그먼트 라우팅 기능을 제공합니다.

  • Static LSPs—전체 Label 스택이 정적으로 구성된 정적으로 구성된 소스 라우팅 경로입니다.

  • Auto-translated LSPs—정적으로 구성된 소스 라우팅 경로가 자동으로 변환됩니다.

  • Computed LSPs—분산형 CSPF(Shortest Path First)로 계산되는 정적으로 구성된 소스 라우팅 경로입니다.

  • Dynamic LSPs—동적 터널 모듈을 통해 트리거된 동적으로 생성된 터널은 마지막 홉 ERO 해결을 제공합니다.

세그먼트 라우팅 LSP의 소스에 따라 PCC에서 위임 기능을 구성할 수 있습니다. 세그먼트 라우팅 LSP의 위임 기능을 활성화하려면 계층 아래에 적절한 수준으로 명령문을 lsp-external-controller pccd[edit protocols source-packet-routing] 포함해야 합니다.

표 2 위임 기능이 활성화되는 해당 구성 계층 수준에 LSP 소스에 대한 매핑을 표시합니다.

주:

PCC에서 위임 기능을 구성하기 전에 명령문과 계층 수준에 명령문을 포함해야 lsp-external-controller pccd[edit protocols source-packet-routing][edit protocols mpls] 합니다.

표 2: 구성 계층을 사용하는 세그먼트 라우팅 LSP 소스 매핑

세그먼트 라우팅 LSP 소스

구성 계층

  • 자동 변환 LSP

  • 정적 LSP

기본 세그먼트 목록은 [edit protocols source-packet-routing source-routing-path lsp-name primary path-name]

컴퓨팅 LSP(분산 CSPF)

소스 라우팅 경로의 기본 세그먼트 목록:

  • [edit protocols source-packet-routing source-routing-path lsp-name primary path-name compute profile-name]

  • [edit protocols source-packet-routing source-routing-path lsp-name primary path-name]

동적 LSP

소스 라우팅 경로 템플릿의 기본 세그먼트 목록:

  • [edit protocols source-packet-routing source-routing-path-template template-name primary primary-segment-list-name]

  • [edit protocols source-packet-routing source-routing-path-template template-name]

spring 트래픽 엔지니어링 명령 출력에서 SR-트래픽 엔지니어링(TE) LSP의 제어 상태를 수 있습니다.

표 3 명령문이 소스 라우팅 경로에 대해 구성되면 PCEP 상호 lsp-external-controller 작용을 표시됩니다.

표 3: PCEP 상호 작용 LSP 위임

lsp-external-controller 구성 계층

소스 라우팅 경로 위임 상태

PCC와 PCE 간의 PCEP 상호 작용

소스 라우팅 경로의 주요 세그먼트 목록

최초 위임

  1. PCReport 메시지는 위임 을 위해 PCE로 전송됩니다. PCReport에는 제약 조건 및 경로 세부 정보(예: ERO)만 포함되어 있습니다.

  2. PCE는 LSP에 대한 경로를 계산하고 다운 상태로 경로를 보고합니다.

  3. 컨트롤러가 ERO를 계산하고 PCUpdate을 통해 PCC에 결과를 리포지트할 때까지 로컬 LSP에 의해 그 어떤 라우트도 프로그래밍되지 않습니다.

라우팅 프로토콜 프로세스(rpd)가 재시작되거나 스위치오버가 발생하면 동일한 라우팅 엔진 표시됩니다.

소스 라우팅 경로의 주요 세그먼트 목록

기존 경로 위임

  1. PCReport는 위임 을 위해 PCE로 전송됩니다. PCReport에는 제약 조건 및 경로 세부 정보(예: ERO)만 포함되어 있습니다.

  2. 해당 기본 세그먼트가 PCE에 위임됩니다.

  3. PCE는 LSP에 대한 경로를 계산합니다.

  4. 주 세그먼트는 PCE로부터 PCUpdate이 수신될 때까지 로컬 구성 또는 계산에 따라 경로에 계속 기여합니다.

    • 원활한 BFD(S-BFD)가 기본 세그먼트에 구성되지 않은 경우 경로에 대한 추가 업데이트가 없는 경우 LSP 상태도 모니터링되어 PCE에 보고되지 않습니다. 이 시점에서 경로 계산이 성공한지 여부에 따라 이 시점의 LSP 상태는 업 또는 다운으로 보고됩니다.

    • S-BFD가 기본 세그먼트에 대해 구성되면 기본 세그먼트의 상태를 추적하여 PCE에 보고합니다. BFD가 기본 세그먼트의 다운을 탐지하면 해당 기본 경로가 경로에서 제거됩니다. 이전에 계산된 동일한 경로가 지금 설정된 경우 재프로그램됩니다.

  5. PCE에서 PCUpdate 메시지가 수신되는 경우 SR-트래픽 엔지니어링(TE) 매개 변수를 사용하여 PCReport 메시지가 전송된 경로를 설정합니다. 프로그래밍된 경로는 PCE에서 수신된 세그먼트 리스트만 포함하며 앞서 프로그래밍된 다른 모든 세그먼트 목록은 제거됩니다. 경로의 이러한 재프로미션은 중단이 발생하기 전에 발생합니다.

소스 라우팅 경로의 기본 세그먼트

위임이 구성되지거나 삭제되었습니다.

PCE의 세그먼트 목록(가능한 경우)은 더 이상 사용 안 되어 로컬 구성의 연산 결과가 사용됩니다. 세그먼트 리스트에 대한 로컬 결과가 사용 가능한 경우 해당 세그먼트 목록은 브레이크가 가능한(make-before-break) 스타일로 경로를 프로그래밍하는 데 사용됩니다.

소스 라우팅 경로 세그먼트 목록

LSP가 구성되면 위임이 활성화됩니다.

위임 기능은 소스 라우팅 경로 하의 기본 세그먼트 목록에 대해 트리거됩니다.

소스 라우팅 경로 세그먼트 목록

위임이 구성되지거나 삭제되었습니다.

위임 기능은 소스 라우팅 경로의 기본 세그먼트 목록에서 제거됩니다.

소스 라우팅 경로 템플릿의 기본 세그먼트 목록

LSP가 구성되면 위임이 활성화됩니다.

  • 소스 라우팅 경로 템플릿에서—위임 기능은 전체 소스 라우팅 경로에 대해 트리거됩니다.

    템플릿 구성은 Dynamic Tunnel Module에만 적용할 수 있습니다.

  • 소스 라우팅 경로 템플릿의 기본 경로 하에서—위임 기능은 구성에 따라 특정 기본 경로에 대해 트리거됩니다.

소스 라우팅 경로 템플릿의 기본 세그먼트 목록

위임이 구성되지거나 삭제되었습니다.

위임 기능은 템플릿 구성에 일치하는 모든 소스 라우팅 경로 및 기본 경로에서 제거됩니다.

PCEP 제한 및 무중단 기능을 위한 세그먼트 라우팅

PCEP를 위한 세그먼트 라우팅이 지원된다 해서도 시스템의 성능 부담이 가중되지는 않습니다. 그러나 다음과 같은 제한이 있습니다.

  • SR-트래픽 엔지니어링(TE) LSP는 PCC에서 로컬 보호되지 않습니다. LSP가 6홉 이상인 경우 일반 IP 트래픽을 전달하는 것 이외에는 LSP상에서 서비스가 제공되지 않습니다.

  • GRES(Graceful 라우팅 엔진 Switchover) 및 통합 ISSU(In-Service Software Upgrade)는 지원되지 않습니다.

  • NSR(Nonstop Active Routing)은 지원되지 않습니다.

  • IPv6는 지원되지 않습니다.

  • PCE 위임 LSP는 다음을 지원하지 않습니다.

    • 컬러 SR-트래픽 엔지니어링(TE) LSP

    • IPv6 LSP

    • 소스 라우팅 경로의 보조 세그먼트 목록. 세그먼트 목록의 한 경로만 위임할 수 있습니다.

    • 멀티세그멘트 표준. 세그먼트 목록의 첫 번째 세그먼트만 위임 및 컨트롤러에 보고됩니다.

예를 들면 다음과 같습니다. 경로 계산 요소 프로토콜을 위한 세그먼트 라우팅 구성

이 예에서는 PCEP(Path Computation Element Protocol)를 위해 네트워킹(SPRING) 트래픽 엔지니어링(SR-트래픽 엔지니어링(TE))에서 세그먼트 라우팅 또는 소스 패킷 라우팅을 구성하는 방법을 보여줍니다. 효율적인 트래픽 엔지니어링을 위해 외부 경로 컴퓨팅의 이점과 세그먼트 라우팅의 이점을 활용합니다.

요구 사항

이 예에서는 다음과 같은 하드웨어 및 소프트웨어 구성 요소를 활용합니다.

  • 4개의 MX 시리즈 5G 유니버설 라우팅 플랫폼 ingress MX 시리즈 라우터가 PCC(Path Computation Client)입니다.

  • PCC에서 외부 상태 저장 경로 계산 요소(PCE)로의 TCP 연결

  • Junos OS 릴리스 17.2 이상은 PCE 시작 LSP 구현을 위해 PCC에서 실행됩니다.

    PCE 위임 기능의 경우 릴리스 Junos OS 릴리스 또는 20.1R1 릴리스를 실행해야 합니다.

시작하기 전에 다음을 할 수 있습니다.

  • 디바이스 인터페이스를 구성합니다.

  • 구성 MPLS.

  • 구성 IS-IS(Intermediate System to Intermediate System).

개요

PCEP를 Junos OS 세그먼트 라우팅의 새로운 구현에는 PCE 시작 및 PCE 위임 SR-트래픽 엔지니어링(TE) LSP가 포함됩니다.

  • PCE 시작 LSP의 구현은 세그 Junos OS 릴리스 17.2R1 PCE에서 시작된 LSP에 대한 PCEP 세션에서 세그먼트 라우팅의 트래픽 엔지니어링 기능이 지원되는 릴리스(Release) 에서 소개됩니다. PCE는 인접 및 노드 세그먼트에 대한 LSP를 생성합니다. 터널 경로는 PCE가 시작되는 SR-트래픽 엔지니어링(TE) LSP에 해당하는 PCC의 inet.3 라우팅 테이블에서 트래픽 엔지니어링(TE) 생성됩니다.

  • PCE 위임 LSP의 구현은 Junos OS Release 20.1R1 릴리스에서 소개됩니다. 여기서 PCC 상의 로컬 구성된 IPv4 비수준 세그먼트 라우팅 LSP를 PCE 컨트롤러에 위임할 수 있습니다. 그런 다음, PCE는 LSP를 제어하고 경로 계산을 위해 LSP 속성을 수정할 수 있습니다.

PCE 위임 LSP는 PCEP 세션이 다운된 당시 PCE 개시 LSP의 이점을 제공합니다. PCE가 시작된 LSP의 경우, PCEP 세션이 다운되면 PCC에서 LSP를 삭제합니다. 그러나 PCE 위임 LSP의 경우, PCEP 세션이 다운된 경우 PCC는 PCE에서 위임된 LSP에 대한 제어를 다시 제어합니다. 그 결과, PCE에 위임된 LSP를 사용할 경우, PCEP 세션이 중단될 때 패킷이 자동으로 폐기되는 경우(null 경로 조건으로도 알려진) 상황을 미연에 지우지 않습니다.

PCEP를 위한 세그먼트 라우팅 지원:

PCE 시작 세그먼트 라우팅 LSP의 경우:

  1. 계층 수준에서 명령문을 MPLS 외부 경로 lsp-external-controller 컴퓨팅을 [edit protocols mpls] 활성화합니다.

    이 구성은 RSVP-트래픽 엔지니어링(TE) PCEP에 필요합니다. PCEP를 위한 세그먼트 라우팅을 활성화하면 RSVP-트래픽 엔지니어링(TE) PCEP를 비활성화할 수 없습니다.

  2. 계층 수준에서 명령문을 트래픽 엔지니어링(TE) SR-트래픽 엔지니어링(TE) 외부 경로 lsp-external-controller pccd[edit protocols spring-traffic-engineering] 컴퓨팅을 활성화합니다.

  3. 계층 수준에서 명령문을 포함해 PCE에 세그먼트 spring-capability[edit protocols pcep pce pce-name] 라우팅을 활성화합니다.

  4. 선택적으로 계층 수준에서 명령문을 포함하도록 PCE에 최대 SID max-sid-depth number[edit protocols pcep pce pce-name] 깊이를 구성합니다.

    최대 SID 깊이는 노드 또는 노드의 링크에서 지원되는 SID 수입니다. 구성되지 않은 경우 기본 최대 SID 값 5가 적용됩니다.

  5. 선택적으로 계층 수준에서 세그먼트 라우팅에 대한 기본 설정 preference preference-value[edit protocol spring-te] 값을 구성합니다.

    기본 설정 값 은 후보 경로 간 활성 경로 양식으로 경로가 선택되는 순서를 나타냅니다. 여기서 가치가 더 높은 경우. 구성되지 않은 경우 기본 설정값 8이 적용됩니다.

  6. 선택적으로 계층 수준에서 명령문을 포함해 문제 해결을 위해 traceoptions 세그먼트 라우팅 로깅을 [edit protocols spring-te] 구성할 수 있습니다.

세그먼트 라우팅 LSP의 PCE 위임의 경우, 아래와 같은 단계를 수행합니다.

  1. Label 매개 변수가 있는 세그먼트 목록을 정의합니다. 그러면 PCC에서 로컬로 세그먼트 라우팅 LSP가 생성됩니다.

  2. 세그먼트 라우팅 LSP 소스에 따라 다음과 같은 계층에 명령문을 포함해 PCC에서 로컬로 구성된 LSP의 위임 기능을 lsp-external-controller pccd 활성화합니다.

    • 분산형 CSPF 및 계층 수준으로 계산되는 정적으로 구성된 소스 라우팅 [edit protocols source-packet-routing source-routing-path lsp-name primary path-name compute profile-name][edit protocols source-packet-routing source-routing-path lsp-name primary path-name] 경로의 경우

    • 정적으로 구성된 소스 라우팅 경로의 경우 전체 Label 스택이 정적으로 구성되고 소스 라우팅 경로가 자동으로 변환되어 계층 [edit protocols source-packet-routing source-routing-path lsp-name primary path-name] 수준이 지정됩니다.

    • 마지막 홉 ERO 해결 수준과 계층 수준이 있는 Dynamic Tunnel Module을 통해 트리거된 동적으로 생성된 [edit protocols source-packet-routing source-routing-path-template template-name primary primary-segment-list-name][edit protocols source-packet-routing source-routing-path-template template-name] 터널의 경우

토폴로지

그림 8 은 PCE와 PCC(ingress MX Series 라우터) 간에 실행되는 PCEP 세션을 가지는 샘플 네트워크 토폴로지의 예입니다. 라우터 R1, R2 및 R3은 네트워크의 다른 MX 시리즈 라우터입니다. 이 예에서는 PCC의 PCEP에 대한 세그먼트 라우팅을 구성합니다. 또한 PCC에서 Router R3로의 정적 경로를 구성하여 트래픽을 라우팅할 때 SR-트래픽 엔지니어링(TE) 터널 경로의 사용을 검증합니다.

그림 8: PCEP를 위한 세그먼트 라우팅PCEP를 위한 세그먼트 라우팅

구성

CLI 빠른 구성

이 예제를 신속하게 구성하려면 다음 명령을 복사하여 텍스트 파일에 붙여넣기하고, 라인 끊기를 제거하고, 네트워크 구성과 일치하는 데 필요한 세부 정보를 변경하고, 계층 수준에서 명령어를 CLI 입력한 다음 구성 모드에서 [edit]commit 입력합니다.

이 섹션에서 모든 장치(PCC 및 3개의 라우터)의 구성을 제시하고 있습니다. 단계별 절차는 PCC 구성만 문서화합니다.

Pcc

라우터 R1

라우터 R2

라우터 R3

절차
단계별 절차

이 예에서는 PCC만 구성합니다.

다음 단계에서는 구성 계층의 다양한 레벨을 탐색해야 합니다. 네트워크의 네트워크 CLI 대한 자세한 내용은 CLI 사용자 가이드의 CLI 편집기사용 CLI 참조하십시오.

PCC 구성:

  1. PCC의 인터페이스를 구성합니다.

  2. 라우터 ID를 구성하고 PCC에 자율 시스템 번호를 할당합니다.

  3. PCC에서 라우터 R3로의 정적 경로를 구성합니다.

    정적 경로는 검증 목적으로만 생성될 뿐 기능 기능에 영향을 미치지 않습니다.

  4. 관리 인터페이스를 제외한 PCC의 모든 인터페이스에서 RSVP를 구성합니다.

  5. 관리 MPLS PCC의 모든 인터페이스에서 구성할 수 있습니다.

  6. 데이터 보호를 위한 외부 경로 컴퓨팅 MPLS.

  7. 관리 IS-IS(Intermediate System to Intermediate System) 루프백 인터페이스를 제외한 PCC의 모든 인터페이스에서 레벨 2를 구성합니다.

  8. 세그먼트 라우팅을 위해 세그먼트 라우팅 글로벌 블록(SRGB) 속성을 구성합니다.

  9. SR-트래픽 엔지니어링(TE) 외부 경로 컴퓨팅 기능을 트래픽 엔지니어링(TE).

  10. PCE 매개 변수를 구성하고 PCE 및 세그먼트 라우팅 기능에 따라 LSP 프로비저닝을 활성화합니다.

  11. PCE에 의해 세그먼트 라우팅 LSP 프로비저닝을 활성화합니다.

  12. PCE를 위한 세그먼트 라우팅 기능을 활성화합니다.

  13. 정적 세그먼트 목록 static_seg_list_1 매개변수를 정의합니다.

  14. PCE 위임에 대해 PCC에서 라우터 R3로의 정적 세그먼트 라우팅 LSP를 구성합니다.

  15. 소스 라우팅 경로에 대한 위임 기능을 static_srte_lsp_1 활성화합니다.

    13, 14 및 15 단계를 완료하면 PCC에서 세그먼트 라우팅 LSP를 PCE에 위임할 수 있습니다.

  16. 구성을 커밋합니다.

결과

구성 모드에서 , 및 명령어를 입력하여 show interfacesshow routing-optionsshow protocols 구성을 확인 출력이 의도한 구성을 표시하지 않는 경우 이 예제의 지침을 반복하여 구성을 수정합니다.

장비(PCC) 구성이 완료되면 commit 구성 모드에서 입력합니다.

확인

구성이 제대로 작동하고 있는지 확인합니다.

Adjacency IS-IS(Intermediate System to Intermediate System) 레이블 확인
목적

PCC의 IS-IS(Intermediate System to Intermediate System) Adjacency를 검증합니다. SRGB 레이블 범위, Adjacency 및 Node Segment 값, SPRING 기능 출력 필드에 주목하십시오.

실행

작동 모드에서 , show isis adjacency extensiveshow isis database extensiveshow isis overview 명령어를 실행합니다.

의미

PCC IS-IS(Intermediate System to Intermediate System) PCC와 PCE 간의 인접한 연결과 PCC와 라우터 R1 간의 연결은 가동되고 작동됩니다. 출력은 인접한 노드 세그먼트에 대한 레이블 할당도 표시됩니다.

트래픽 엔지니어링 데이터베이스 검증
목적

PCC의 트래픽 엔지니어링 데이터베이스 항목을 검증합니다.

실행

작동 모드에서 명령을 show ted database extensive 실행합니다.

의미

트래픽 엔지니어링 데이터베이스에는 PCC의 외부 경로 컴퓨팅에 PCE가 사용하는 라우터 R1, R2 및 R3에서 광고된 항목이 포함되어 있습니다.

SR-트래픽 엔지니어링(TE) LSP 검증
목적

PCC에서 SR-트래픽 엔지니어링(TE) LSP를 생성하는지 검증합니다.

실행

작동 모드에서 , show path-computation-client lspshow spring-traffic-engineering lsp detailshow route protocol spring-te 명령어를 실행합니다.

의미

출력은 2개의 SR-트래픽 엔지니어링(TE) LSP와 인접 노드 세그먼트에 대해 adj_sid_lspnode_sid_lsp 각각 PCE에 의해 생성되었습니다.

세그먼트 라우팅 LSP는 위임 static_srte_lsp_1 기능을 통해 활성화됩니다. 이 필드는 PCE에서 위임된 LSP의 제어 및 라우팅 상태를 Delegation info 보여줍니다. PCE가 LSP를 제어했다는 의미입니다. PCE가 소스 라우팅 경로에 Externally controlled 대해 ERO를 제공했다는 Externally routed 의미입니다.

터널 경로 생성 확인
목적

PCC의 inet.3 라우팅 테이블에 트래픽 엔지니어링(TE) SR-트래픽 엔지니어링(TE) 대해 생성된 터널 경로를 검증합니다.

실행

작동 모드에서 명령을 show route table inet.3 extensive 실행합니다.

의미

터널 경로는 프로토콜 레이블로 SR-트래픽 엔지니어링(TE) PCE 제어 LSP 대상에 대해 생성되었습니다.

포우링 테이블 항목 검증
목적

SR-트래픽 엔지니어링(TE) 라우터 R3에 대한 SR-트래픽 엔지니어링(TE) 대상이 PCC의 포우링 테이블에 설치되어 있는지 확인합니다.

실행

작동 모드에서 명령을 show route forwarding-table destination ip-address extensive 실행합니다.

의미

라우터 R3에 대한 SR-트래픽 엔지니어링(TE) LSP 대상 IP 주소는 포우링 엔트리로 설치됩니다.

정적 경로 포우링을 위한 터널 경로 사용 검증
목적

정적 경로가 SR-트래픽 엔지니어링(TE) 터널 경로를 취하고 있는지 검증합니다.

실행

작동 모드에서 명령 및 show route ip-addressshow route forwarding-table destination ip-address 명령을 실행합니다.

의미

출력에 따르면 라우터 R3에 대한 정적 경로가 SR-트래픽 엔지니어링(TE) 터널 경로를 사용하는 것을 알 수 있습니다.

정적 세그먼트 라우팅 레이블 스위칭 경로

세그먼트 라우팅 아키텍처는 코어 네트워크의 ingress 디바이스가 명시적 경로를 통해 트래픽을 스티어링할 수 있습니다. 세그먼트 목록을 사용하여 이러한 경로를 구성하여 수신 트래픽이 취해야 하는 경로를 정의할 수 있습니다. 수신 트래픽은 레이블링되거나 IP 트래픽이 될 수 있습니다. 이를 통해 수신 장비에서 포워링 작업은 Label 스왑 또는 대상 기반 룩업이 됩니다.

네트워크에서 정적 세그먼트 라우팅 LSP MPLS 이해

소스 패킷 라우팅 또는 세그먼트 라우팅은 수신 라우터가 네트워크의 중간 노드에 대한 액세스 없이 네트워크의 특정 노드 및 링크를 통해 패킷을 스티어링할 수 있도록 하여 실제 경로를 결정할 수 있는 컨트롤 플레인 아키텍처입니다.

세그먼트 라우팅 LSP 소개

세그먼트 라우팅은 소스 라우팅 패러다임을 활용합니다. 디바이스는 세그먼트라는 명령 목록을 통해 패킷을 스티어링합니다. 세그먼트는 모든 명령, 토호화 또는 서비스 기반을 표현할 수 있습니다. 세그먼트는 세그먼트 라우팅 노드 또는 세그먼트 라우팅 도메인 내의 글로벌 노드에 대한 로컬 시만틱을 할 수 있습니다. 세그먼트 라우팅은 모든 토목 경로 및 서비스 체인을 통해 플로우를 적용하는 동시에 ingress 디바이스에서 세그먼트 라우팅 도메인으로의 플로우당 상태를 유지 관리합니다. 세그먼트 라우팅은 포우링 플레인에서 변경하지 않고 MPLS 아키텍처에 직접 적용할 수 있습니다. 세그먼트는 표준 레이블로 MPLS 있습니다. 순서가 정해진 세그먼트 목록은 레이블 스택으로 인코딩됩니다. 처리해야 하는 세그먼트는 스택 맨 위에 있습니다. 세그먼트가 완료된 후, 관련 레이블은 스택에서 핑(popped)됩니다.

세그먼트 라우팅 LSP는 본질적으로 동적이거나 정적일 수 있습니다.

Dynamic segment routing LSPs—세그먼트 라우팅 LSP가 외부 컨트롤러에 의해 생성되어 PCEP(Path Computation Element Protocol) 확장을 통해 ingress 장비로 다운로드되거나 BGP(Border Gateway Protocol) 세그먼트 라우팅 확장을 통해 BGP(Border Gateway Protocol) 세그먼트 라우팅 정책에서 LSP가 동적으로 프로비저닝됩니다. 동적 세그먼트 라우팅 LSP의 세그먼트 리스트는 PCEP ERO(Explicit Route Object) 또는 LSP의 BGP(Border Gateway Protocol) 세그먼트 라우팅 정책에 포함되어 있습니다.

Static segment routing LSPs—로컬 구성을 통해 ingress 디바이스에서 세그먼트 라우팅 LSP가 생성되면 LSP가 정적으로 프로비저닝됩니다.

정적 세그먼트 라우팅 LSP는 계층 수준에서 명령문의 구성에 따라 색과 비색 LSP로 더 color[edit protocols source-packet-routing source-routing-path lsp-name] 분류할 수 있습니다.

몇 가지 예를 들면 다음과 같습니다.

[edit protocols]
    source-packet-routing {
    source-routing-path lsp_name {
        to destination_address;
        color color_value;
        binding-sid binding-label;
        primary segment_list_1_name weight weight;
        ...
        primary segment_list_n_name weight weight;
        secondary segment_list_n_name;
        sr-preference sr_preference_value;
    }
}

여기에서 각 기본 명령문과 보조 진술은 세그먼트 목록을 참조합니다.

[edit protocols]
source-packet-routing {
    segment-list segment_list_name {
        hop_1_name label sid_label;
        ...
        hop_n_name label sid_label;
    }
}

세그먼트 라우팅 LSP 사용의 이점

  • 정적 세그먼트 라우팅은 전송 라우터의 LSP 포우링 상태별로 사용되지 않습니다. 따라서 코어에서 LSP 포우링 상태당 프로비저닝 및 유지 관리가 필요하지 않습니다.

  • 네트워크 확장성 향상을 MPLS.

컬러 정적 세그먼트 라우팅 LSP

명령문으로 구성된 정적 세그먼트 라우팅 LSP를 컬러 color LSP라고 합니다.

색의 정적 세그먼트 라우팅 LSP 이해

세그먼트 라우팅 BGP(Border Gateway Protocol) 정책과 마찬가지로, IP 트래픽 매핑을 위한 키로 색의 LSP의 ingress 경로가 라우팅 테이블에 inetcolor.0inet6color.0destincation-ip-address, color 설치됩니다.

정적 색 세그먼트 라우팅 LSP는 라우팅 테이블에 루트가 설치된 바인딩 mpls.0 SID를 사용할 수 있습니다. 이 바인딩 SID 레이블은 세그먼트 라우팅 LSP에 레이블된 트래픽을 매핑하는 데 사용됩니다. 경로의 게이트웨이는 기본 및 보조 경로의 세그먼트 목록 구성에서 파생됩니다.

세그먼트 라우팅 LSP의 세그먼트 목록

색의 정적 세그먼트 라우팅 LSP는 LSP를 최초로 홉 레이블 모드로 전환할 수 있는 지원을 이미 예고했습니다. 그러나 우선 홉 IP 모드는 컬러 세그먼트 라우팅 LSP에서는 지원되지 않습니다. Junos OS Release 19.1R1 시작으로, 색 경로에 기여하는 모든 세그먼트 목록이 모든 홉에 최소 Label 표시를 하도록 보장하는 커밋 검사 기능이 도입됩니다. 이 요구 사항이 충족되지 않을 경우 커밋이 차단됩니다.

비색 정적 세그먼트 라우팅 LSP

명령문 없이 구성된 정적 세그먼트 라우팅 LSP는 비색 color LSP입니다. PCEP 세그먼트 라우팅 터널과 마찬가지로 ingress 경로가 또는 라우팅 inet.3inet6.3 테이블에 설치됩니다.

Junos OS 라우터에서 비색의 정적 세그먼트 라우팅 LSP를 지원 하나의 소스 라우팅 경로와 하나 이상의 세그먼트 목록을 구성하여 비색의 정적 세그먼트 라우팅 LSP를 프로비저닝할 수 있습니다. 이러한 세그먼트 목록은 여러 개의 비색 세그먼트 라우팅 LSP에서 사용할 수 있습니다.

비색 세그먼트 라우팅 LSP 이해

비색 세그먼트 라우팅 LSP에는 고유한 이름과 대상 IP 주소가 있습니다. 대상에 대한 ingress 경로는 기본 설정 8 및 1 지표를 사용하는 inet.3 라우팅 테이블에 설치됩니다. 이 라우트는 비색 서비스를 대상에 해당하는 세그먼트 라우팅 LSP에 매핑할 수 있습니다. 비색 세그먼트 라우팅 LSP가 ingress 루트를 요구하지 않는 경우, ingress 루트를 비활성화할 수 있습니다. 비색 세그먼트 라우팅 LSP는 세그먼트 라우팅 LSP 스티치(stitching)를 달성하기 위해 SID 레이블을 결합합니다. 세그먼트 라우팅 LSP를 계층형 방식으로 다른 세그먼트 라우팅 LSP를 구축하는 데 더 사용할 수 있는 세그먼트로 모델링하는 데 사용할 수 있는 이 레이블입니다. 바인딩 SID 레이블의 전송은 기본적으로 기본 설정 8과 메트릭 1을 기본 설정하고 있습니다.

Junos OS Release 18.2R1 시작하여, ingress 장비에 정적으로 구성된 비색 세그먼트 라우팅 LSP는 PCEP(Path Computation Element Protocol) 세션을 통해 PCE(Path Computation Element)에 보고됩니다. 이러한 비색 세그먼트 라우팅 LSP는 연관된 SID(Service Identifier) 레이블을 결합할 수 있습니다. 이 기능을 통해 PCE는 Label 스택에서 이 바인딩 SID 레이블을 사용하여 PCE 시작 세그먼트 라우팅 LSP 경로를 프로비저닝할 수 있습니다.

비색 세그먼트 라우팅 LSP는 최대 8개 기본 경로를 구성할 수 있습니다. 여러 운영 기본 경로가 있는 경우 PFE(패킷 포워딩 엔진)는 경로에서 구성된 가중치와 같은 로드 밸런싱 요인을 기반으로 경로상에서 트래픽을 분배합니다. 경로 중 하나 이상이 경로에 0이 아닌 가중치가 구성된 경우 경로에 가중치가 설정되지 않은 경우 ECMP(Cost Multi Path)와 동일합니다. 두 경우 모두, 경로 중 일부에 장애가 발생하면 PFE는 트래픽을 나머지 경로에서 재조정하여 자동으로 경로 보호를 달성합니다. 비색 세그먼트 라우팅 LSP는 전용 경로 보호를 위한 보조 경로를 사용할 수 있습니다. 기본 경로에 장애가 발생하면 PFE는 트래픽을 나머지 기능의 기본 경로로 재조정합니다. 그렇지 않으면 PFE는 트래픽을 백업 경로로 전환하여 경로 보호를 달성합니다. 비색 세그먼트 라우팅 LSP는 ingress 및 바인딩-SID 경로에 대한 메트릭을 [edit protocols source-packet-routing source-routing-path lsp-name] 지정할 수 있습니다. 여러 비색 세그먼트 라우팅 LSP는 ingress 경로의 다음 홉에 기여하는 대상 주소가 동일합니다.

여러 비색 세그먼트 라우팅 LSP는 ingress 경로의 다음 홉에 기여하는 대상 주소가 동일합니다. 경로가 기능적이고 세그먼트 라우팅 LSP가 이러한 모든 세그먼트 라우팅 LSP를 가장 선호하는 경우 각 세그먼트 라우팅의 기본 경로 또는 보조 경로가 게이트웨이 후보로 간주됩니다. 그러나 넥스홉이 보유할 수 있는 최대 게이트웨이 개수는 RPD 다중 경로 제한(기본적으로 128개)을 초과할 수 없습니다. 추가 경로는 먼저 보조 경로, 그리고 기본 경로로 이어지며, 주어진 세그먼트 리스트는 이러한 세그먼트 라우팅 LSP에 의해 주 또는 보조 경로로 여러 번 언급될 수 있습니다. 이 경우 각각 고유한 세그먼트 라우팅 LSP 터널 ID를 갖는 여러 게이트웨이가 있습니다. 이들 게이트웨이는 서로 다른 것으로, 동일한 Outgoing Label Stack 및 Interface를 가지고 있습니다. 비색 세그먼트 라우팅 LSP 및 컬러 세그먼트 라우팅 LSP도 동일한 대상 주소를 지을 수 있습니다. 그러나, 색의 세그먼트 라우팅 LSP의 대상 주소가 대상 주소와 색상 모두로 생성될 경우, ingress 경로에 대한 여러 대상 주소에 대응합니다.

주:

정적 비색 세그먼트 라우팅 LSP와 PCEP에서 생성한 세그먼트 라우팅 LSP가 공존하고 동일한 ingress 경로에 기여하는 주소가 동일한 경우 기본 설정이 동일한 경우 그렇지 않으면 라우트에 대해 최상의 기본 설정이 있는 세그먼트 라우팅 LSP가 설치됩니다.

비색 세그먼트 라우팅 LSP의 세그먼트 목록

세그먼트 목록은 홉 목록으로 구성됩니다. 이들 홉은 SID 레이블 또는 IP 주소를 기반으로 합니다. 세그먼트 리스트의 SID 레이블 수는 최대 세그먼트 목록 제한을 초과하지 않습니다. LSP 터널에 대한 최대 세그먼트 목록 바인딩이 8개에서 128개로 증가하고 시스템당 최대 1000개 터널로 증가합니다. 최대 128개 기본 경로는 정적 세그먼트 라우팅 LSP당 지원됩니다. 계층 수준에서 최대 세그먼트 목록 [edit protocols source-packet-routing] 제한을 구성할 수 있습니다.

Junos OS Release 19.1R1 사용할 수 있는 비색 정적 세그먼트 라우팅 LSP를 사용하기 전에 세그먼트 목록의 첫 번째 홉은 발신 인터페이스의 IP 주소가 됐고, 두 번째 홉에서 nth 홉까지 SID 레이블이 될 수 있습니다. Junos OS Release 19.1R1 시작으로 이 요구 사항은 적용되지 않습니다. 비색 정적 LSP의 첫 번째 홉은 이제 IP 주소 외에도 SID 레이블에 대한 지원을 제공합니다. 첫 번째 홉 레이블 지원을 통해 FRR(MPLS Fast Reroute) 및 가중치가 지정된 정적 비색 세그먼트 라우팅 LSP(정적 정적 LSP)와 유사한 가중치가 동등한 비용 다중 경로가 활성화됩니다.

첫 번째 홉 레이블 모드가 적용하려면 세그먼트 리스트에 대해 전역적으로 또는 개별적으로 명령문을 포함해야 합니다. 세그먼트 목록의 첫 번째 홉에는 IP 주소와 Label이 모두 포함되어야 inherit-label-nexthops 합니다. 첫 번째 홉에 IP 주소만 포함하는 경우, inherit-label-nexthops 명령문은 영향을 없습니다.

다음 계층 중 하나에서 inherit-label-nexthops 구성할 수 있습니다. 세그먼트 목록 첫 번째 홉에 IP 주소와 Label이 모두 포함된 경우 명령문이 inherit-label-nexthops 적용됩니다.

  • Segment list level—계층 [edit protocols source-packet-routing segment-list segment-list-name] 수준에서.

  • Globally—계층 [edit protocols source-packet-routing] 수준에서.

명령문이 전역적으로 구성되면 세그먼트 목록 수준 구성보다 우선 순위가 설정되고 구성이 모든 세그먼트 목록에 inherit-label-nexthopsinherit-label-nexthops 적용됩니다. 명령문이 전역적으로 구성되지 않으면 첫 번째 홉에 레이블과 IP 주소가 모두 있는 세그먼트 목록만 있으며 inherit-label-nexthops 명령문으로 inherit-label-nexthops 구성은 SID Label을 사용하여 해결됩니다.

동적 비색 정적 LSP의 경우 PCEP 기반 세그먼트 라우팅 LSP인 경우 세그먼트 수준 구성이 적용되지 않을 때 명령문을 전역적으로 활성화해야 inherit-label-nexthops 합니다.

표 4 첫 번째 홉 사양을 기반으로 하는 세그먼트 라우팅 LSP 해결 모드를 설명합니다.

표 4: 첫 번째 홉 규격에 기반한 비색 정적 LSP 해상도

First Hop 사양

LSP 해결 모드

IP 주소만 해당

몇 가지 예를 들면 다음과 같습니다.

segment-list path-1 {
    hop-1 ip-address 172.0.12.2;
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

세그먼트 목록은 IP 주소를 사용하여 해결됩니다.

SID만 해당

몇 가지 예를 들면 다음과 같습니다.

segment-list path-2 {
    hop-1 label 1000011;
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

세그먼트 목록은 SID 레이블을 사용하여 해결됩니다.

IP 주소 및 SID(구성 inherit-label-nexthops 미포장)

몇 가지 예를 들면 다음과 같습니다.

segment-list path-3 {
    hop1 {
        label 801006;
        ip-address 172.24.1.2;
    }
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

기본적으로 세그먼트 목록은 IP 주소를 사용하여 해결됩니다.

IP 주소 및 inherit-label-nexthops SID(구성)

몇 가지 예를 들면 다음과 같습니다.

segment-list path-3 {
    inherit-label-nexthops;
    hop1 {
        label 801006;
        ip-address 172.24.1.2;
    }
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

세그먼트 목록은 SID 레이블을 사용하여 해결됩니다.

이 명령을 사용하여 inet.3 라우팅 테이블에 여러 세그먼트 목록을 설치하는 비색 세그먼트 라우팅 트래픽 엔지니어링 show route ip-address protocol spring-te active-path table inet.3 LSP를 볼 수 있습니다.

몇 가지 예를 들면 다음과 같습니다.

주:

정적 세그먼트 라우팅 LSP의 세그먼트 목록의 첫 번째 홉 유형은 다음의 경우 커밋 실패를 일으킬 수 있습니다.

  • 터널의 여러 세그먼트 리스트에는 서로 다른 첫 번째 홉 해결 유형이 있습니다. 이는 색과 비색의 정적 세그먼트 라우팅 LSP에 모두 적용 가능합니다. 그러나 이는 PCEP 기반 LSP에는 적용되지 않습니다. 시스템 로그 메시지는 경로를 계산할 때 첫 번째 홉 해결 유형에서 불일치에 대해 생성됩니다.

    몇 가지 예를 들면 다음과 같습니다.

    경로-1이 IP 주소 모드인 경우, 경로-2는 Label 모드이기 때 터널 lsp1의 커밋이 실패합니다.

  • 바인딩 SID는 세그먼트 목록 유형이 SID 레이블인 정적 비색 LSP에 대해 활성화됩니다.

    몇 가지 예를 들면 다음과 같습니다.

    레이블 세그먼트 목록에서 바인딩 SID 구성은 색상이 없는 정적 LSP가 아니라 컬러 정적 LSP에서만 지원됩니다.

정적 세그먼트 라우팅 LSP 프로비저닝

세그먼트 프로비저닝은 라우터별로 수행됩니다. 라우터의 특정 세그먼트의 경우, 인접 SID 레이블에 대한 동적 레이블 풀 또는 Prefix SID 또는 노드 SID의 세그먼트 라우팅 글로벌 블록(SRGB)에서 원하는 레이블 풀에서 고유한 SID(Service Identifier) 레이블을 할당합니다. Adjacency SID Label은 동적으로 할당될 수 있으며, 기본 동작은 로컬 정적 레이블 풀(SRLB)에서 할당될 수 있습니다. 그런 다음, SID 레이블에 대한 경로가 mpls.0 테이블에 설치됩니다.

Junos OS 레벨에서 명령문을 구성하여 정적 세그먼트 라우팅 LSP를 segment[edit protocols mpls static-label-switched-path static-label-switched-path] 허용합니다. 정적 세그먼트 LSP는 정적 레이블 풀에 속하는 고유 SID Junos OS 식별됩니다. 계층 수준에서 명령문을 Junos OS 정적 레이블 풀을 static-label-range static-label-range[edit protocols mpls label-range] 구성할 수 있습니다.

정적 세그먼트 라우팅 LSP 제한

  • Junos OS 최대 세그먼트 리스트 깊이 레이블 이상을 푸시하기 위해 다음 홉을 구축할 수 없다는 제한이 있습니다. 따라서 최대 SID 레이블을 초과하는 세그먼트 목록(포워딩 넥스 홉을 해결하는 데 사용되는 첫 번째 홉의 SID 레이블 제외)은 색 또는 비색 세그먼트 라우팅 LSP에 사용할 수 없습니다. 또한, MPLS 서비스가 세그먼트 라우팅 LSP에 상주하거나 세그먼트 라우팅 LSP가 링크 또는 노드 보호 경로에 있는 경우, 해당 세그먼트 라우팅 LSP에 허용되는 실제 수가 최대 한도보다 훨씬 낮을 수 있습니다. 모든 경우, 총 서비스 레이블, SID 레이블, 링크 또는 노드 보호 레이블의 수는 최대 세그먼트 목록 깊이를 초과하지 않습니다. 계층 수준에서 최대 세그먼트 목록 [edit protocols source-packet-routing] 제한을 구성할 수 있습니다. 최대 SID 레이블에 미만 또는 동등한 여러 비색 세그먼트 라우팅 LSP를 함께 연계하여 더 긴 세그먼트 라우팅 LSP를 구성할 수 있습니다. 이를 세그먼트 라우팅 LSP 스티치라고 합니다. 바인딩-SID 레이블을 사용하여 구현할 수 있습니다.

  • 세그먼트 라우팅 LSP 스티치(stitching)는 실제로 경로 수준에서 수행됩니다. 비색 세그먼트 라우팅 LSP에 여러 세그먼트 목록이 있는 여러 경로가 있는 경우, 각 경로는 스티치 포인트에서 다른 비색 세그먼트 라우팅 LSP로 독립적으로 연계될 수 있습니다. 스티치 전용 비색 세그먼트 라우팅 LSP는 계층 수준에서 명령문을 구성하여 ingress Route 설치를 no-ingress[edit protocols source-packet-routing source-routing-path lsp-name] 비활성화할 수 있습니다.

  • 비색 정적 세그먼트 라우팅 LSP당 최대 12개 8개 기본 경로와 1개 보조 경로가 지원됩니다. 구성을 위반하는 경우 커밋 검사 오류가 발생하여 실패합니다.

  • LSP 터널에 대한 최대 세그먼트 목록 바인딩이 8개에서 128개로 증가하고 시스템당 최대 1000개 터널로 증가합니다. 최대 128개 기본 경로는 정적 세그먼트 라우팅 LSP당 지원됩니다. 제한 사항으로, LSP 경로에 대한 최대 센서 지원은 32000입니다.

  • 최대 세그먼트 목록 깊이보다 많은 Label로 세그먼트 목록이 구성된 경우, 구성 커밋 검사는 오류로 실패합니다.

세그먼트 라우팅 LSP의 동적 생성

각 PE(Provider Edge) 디바이스가 다른 모든 PE 디바이스에 연결되어 있는 세그먼트 라우팅 네트워크에서는 세그먼트 라우팅 레이블 스위칭 경로(LSP)를 설정하는 데 많은 양의 구성이 필요합니다. 일부 세그먼트 라우팅 트래픽 엔지니어링(SR-트래픽 엔지니어링(TE)) 경로만 사용할 수 있습니다. 이러한 LSP를 BGP(Border Gateway Protocol) 생성하여 이와 같은 구축에서 구성의 양을 줄일 수 있습니다.

동적 세그먼트 라우팅 LSP 템플릿 구성

세그먼트 라우팅 LSP의 동적 생성을 지원하기 위한 템플릿을 구성하려면 계층에 spring-te 명령문을 포함해야 [edit routing-options dynamic-tunnels] 합니다.

  • 다음은 컬러 동적 세그먼트 라우팅 LSP 템플릿을 위한 샘플 구성입니다.

  • 비색(non-color) 동적 세그먼트 라우팅 LSP 템플릿을 위한 샘플 구성은 다음과 같습니다.

동적 세그먼트 라우팅 LSP의 해소
컬러드 다이내믹 세그먼트 라우팅 LSP(Colored Dynamic Segment Routing) 해소

BGP(Border Gateway Protocol) 프리픽스가 컬러 커뮤니티에 할당되면 먼저 catch-all-route-for-that-particular-color 정책에 따라 해결된 다음, SR-트래픽 엔지니어링(TE) 템플릿이 BGP(Border Gateway Protocol) 확인됩니다. 대상 SID는 그 다음, BGP(Border Gateway Protocol) 페이로드 prefix Next-hop 속성에서 파생됩니다. 예를 들어, BGP(Border Gateway Protocol) 페이로드 prefix의 다음 홉이 Device A에 속하는 IP 주소인 경우, Device A의 Node-SID가 취해진 후 해당 레이블을 준비하여 스택의 맨 아래에 푸시합니다. BGP(Border Gateway Protocol) 페이로드 prefix는 컬러 전용 모드로 해결됩니다. 여기서 디바이스 A의 노드-SID가 최종 Label 스택의 맨 아래에 있으며 SR-트래픽 엔지니어링(TE) 경로 레이블이 상단에 있습니다.

최종 LSP 템플릿 이름은 prefix, color 및 tunnel 이름의 조합입니다. 예를 들어, 를 예로 들어 <prefix>:<color>:dt-srte-<tunnel-name> 보겠습니다. LSP 이름의 색상은 양분(hexadecimal) 형식으로 표시되고, 터널 이름의 형식은 o RSVP 트리거 터널 LSP 이름과 유사합니다.

색의 대상 네트워크를 성공적으로 해결하기 위해 색상은 유효한 템플릿 매핑을 특정 색으로 또는 템플릿을 통해야 color-any 합니다. 유효한 매핑이 없는 경우 터널이 생성되지 않고 BGP(Border Gateway Protocol) 경로 요청은 해결되지 않습니다.

비개조적인 동적 세그먼트 라우팅 LSP의 해소

비색 LSP에 대한 catch-all 경로는 inet.3 라우팅 테이블에 추가됩니다. 비색 터널 대상은 매핑 목록에 단 하나의 템플릿 이름만 있는 다른 spring-te 구성으로 구성해야 합니다. 이 템플릿 이름은 동일한 구성 하에서 구성된 모든 대상 네트워크와 일치하는 모든 터널 경로에 spring-te 사용됩니다. 이러한 터널은 기능의 RSVP 터널과 유사합니다.

최종 LSP 템플릿 이름은 Prefix 및 tunnel 이름의 조합입니다. 예를 들어, 를 예로 들어 <prefix>:dt-srte-<tunnel-name> 보겠습니다.

동적 세그먼트 라우팅 LSP 샘플 구성

동적 세그먼트 라우팅 LSP 템플릿은 항상 부분 경로를 제공합니다. 마지막 홉 노드 SID는 PNH(Protocol Next-Hop Address) 노드 SID에 따라 터널 생성 시 자동으로 파생됩니다. 서로 다른 대상에 대한 여러 터널에서 동일한 템플릿을 사용할 수 있습니다. 이러한 경우 부분 경로는 동일하며 PNH에 따라 마지막 홉 변경만 남아 있습니다. 동적 세그먼트 라우팅 LSP 템플릿은 단일 터널과 공통적이지 않습니다. 따라서 전체 경로를 이행할 수 없습니다. 전체 경로를 사용할 경우 세그먼트 목록을 사용할 수 있습니다.

컬러 다이내믹 세그먼트 라우팅 LSP

컬러 다이내믹 세그먼트 라우팅 LSP를 위한 샘플 구성:

위의 샘플 구성의 경우 경로 엔트리는 다음과 같습니다.

  1. inetcolor.0 tunnel route: 22.33.44.0-0/24 --> RT_NH_TUNNEL

  2. inetcolor6.0 tunnel route: ffff:22.33.44.0-0/120 --> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping:

    R1(prefix) -> 22.33.44.55-101(PNH) LSP 터널 이름 = 22.33.44.55:65:dt-srte-tunnel1

    R1(prefix) -> ffff::22.33.44.55-101(PNH) LSP 터널 이름 = 22.33.44.55:65:dt-srte-tunnel1

    R1(prefix) -> ff::22.33.44.55-124(PNH) LSP 터널 이름 = 22.33.44.55:7c:dt-srte-tunnel1

  4. inetcolor.0 tunnel route:

    22.33.44.55-101/64 --><next-hop>

    22.33.44.55-124/64 --><next-hop>

  5. inetcolor6.0 tunnel route:

    ffff:22.33.44.55-101/160 --><next-hop>

    ffff:22.33.44.55-124/160 --><next-hop>

비색 동적 세그먼트 라우팅 LSP

비색 동적 세그먼트 라우팅 LSP를 위한 샘플 구성:

위의 샘플 구성의 경우 경로 엔트리는 다음과 같습니다.

  1. inet.3 tunnel route: 22.33.44.0/24 --> RT_NH_TUNNEL

  2. inet6.3 tunnel route: ffff:22.33.44.0/120 --> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping:

    R1(prefix) -> 22.33.44.55(PNH) LSP 템플릿 이름 = LSP1 --- 22.33.44.55:dt-srte-tunnel2

    R1(prefix) -> ffff::22.33.44.55(PNH) LSP 템플릿 이름 = LSP1 --- 22.33.44.55:dt-srte-tunnel2

  4. inet.3 tunnel route: 22.33.44.55/32 --><next-hop>

  5. inet6.3 tunnel route: ffff:22.33.44.55/128 --><next-hop>

해결되지 않은 동적 세그먼트 라우팅 LSP

해결되지 않은 동적 세그먼트 라우팅 LSP를 위한 샘플 구성:

위의 샘플 구성의 경우 경로 엔트리는 다음과 같습니다.

  1. inetcolor.0 tunnel route: 22.33.44.0 - 0/24 --> RT_NH_TUNNEL 1.1.1.0 - 0/24 --> RT_NH_TUNNEL

  2. inetcolor6.0 tunnel route: ffff:22.33.44.0 - 0/120 --> RT_NH_TUNNEL ff::1.1.1.0 - 0/24 --> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping: R1(prefix) -> 22.33.44.55-124(PNH) 터널이 생성되지 않습니다. (색상은 템플릿이 찾을 수 없습니다).

세그먼트 라우팅 LSP의 동적 생성을 위한 고려 사항

세그먼트 라우팅 LSP의 동적 생성을 구성할 때 다음을 고려합니다.

  • 템플릿은 컬러 객체에 할당될 수 있습니다. 동적 터널 구성에 컬러 객체가 있는 템플릿이 포함되어 있는 경우 다른 모든 템플릿에 색상 객체도 spring-te 구성해야 합니다. 모든 대상은 이 구성 내에서 색으로 표시됩니다.

  • 템플릿에 정의된 색상 목록을 리스트에 리스트를 만들거나 해당 옵션을 사용하여 구성할 수 color-any 있습니다. 두 옵션 모두 동일한 구성으로 공존할 수 spring-te 있습니다. 이러한 경우 특정 색상을 지정하는 템플릿의 선호도가 높아지기 때문에

  • 구성에서 오직 하나의 템플릿만 이 spring-te 옵션으로 정의할 수 color-any 있습니다.

  • 색과 템플릿 매핑은 일대일로 수행됩니다. 하나의 컬러로는 여러 템플릿에 매핑할 수 없습니다.

  • 템플릿 이름은 계층의 명령문에서 spring-te[edit protocols] 구성해야 합니다. 옵션을 primary 활성화해야 합니다.

  • 컬러 및 비색 대상은 동일한 구성에 공존할 수 spring-te 없습니다.

  • 서로 다른 구성 명령문에 따라 동일한 대상 네트워크를 색으로 구성할 spring-te 수 없습니다.

  • 비색 구성에서는 컬러 객체 없이 하나의 템플릿만 spring-te 구성할 수 있습니다.

동적 세그먼트 라우팅 LSP를 통해 지원되는 서비스

색의 동적 세그먼트 라우팅 LSP를 통해 지원되는 서비스는 다음과 같습니다.

  • 레이어 3 VPN

  • BGP(Border Gateway Protocol) EVPN

  • 수출 정책 서비스

비색(non-colored) 동적 세그먼트 라우팅 LSP에서 지원되는 서비스는 다음과 같습니다.

  • 레이어 3 VPN

  • Layer 2 VPN

  • 다중 경로 구성

세그먼트 라우팅에서 여러 터널 소스를 사용하는 동작

두 소스가 세그먼트 라우팅(예: 정적 및 동적 소스 터널)에서 동일한 목적지로 경로를 다운로드하면 세그먼트 라우팅 기본 설정이 활성 경로 엔트리 선택에 사용됩니다. 가치가 높을수록 선호도가 올라가게 됩니다. 기본 설정이 동일하게 유지되는 경우 터널 소스가 경로 엔트리를 결정하는 데 사용됩니다.

동적 세그먼트 라우팅 LSP 제한

동적 SR-트래픽 엔지니어링(TE) LSP는 다음과 같은 기능 및 기능을 지원하지 않습니다.

  • IPv6 세그먼트 라우팅 터널.

  • 정적 터널.

  • 6PE는 지원되지 않습니다.

  • 분산형 CSPF.

  • sBFD 및 LDP 터널링은 동적 SR-트래픽 엔지니어링(TE) LSP 및 템플릿에서 지원되지 않습니다.

  • 템플릿으로 B-SID 경로를 설치하고,

VPN 서비스의 색상 기반 매핑

정적 색의 전송 터널을 해결하기 위한 프로토콜 다음 홉 제약 조건(IPv4 또는 IPv6 주소)으로 색을 지정할 수 있으며 BGP(Border Gateway Protocol) 세그먼트 라우팅 트래픽 엔지니어링(SRTE) LSP를 통해 문제를 해결할 수 있습니다. 이를 Color-IP 프로토콜 다음 홉 해상도라고 합니다. 여기서 해결 맵을 구성하고 VPN 서비스에 적용해야 합니다. 이 기능을 사용하면 레이어 2 및 레이어 3 VPN 서비스의 색상 기반 트래픽 스티어링을 활성화할 수 있습니다.

Junos OS 단일 색상의 SRTE LSP를 지원 VPN 서비스 기능의 색 기반 매핑은 정적 색의 LSP 및 SRTE LSP에서 BGP(Border Gateway Protocol) 지원됩니다.

VPN 서비스 컬러링

일반적으로 VPN 서비스는 VPN NLRI가 광고되는 egress 라우터나 VPN NLRI가 수신 및 처리되는 수신 라우터에 색을 할당할 수 있습니다.

다양한 수준에서 VPN 서비스에 색상을 지정할 수 있습니다.

  • 라우팅 인스턴스당.

  • 그룹 BGP(Border Gateway Protocol)당.

  • 이웃 BGP(Border Gateway Protocol)당.

  • Prefix당.

색상을 할당하면 컬러 확장 커뮤니티의 형태로 VPN 서비스에 BGP(Border Gateway Protocol) 됩니다.

VPN 서비스에 다중 색 VPN 서비스(multi-color VPN services)를 할당할 수 있습니다. 이 경우, 마지막 색상은 VPN 서비스의 색으로 간주되고 다른 모든 색은 무시됩니다.

다음과 같은 순서로 여러 정책을 통해 egress 및/또는 ingress 장비에 의해 여러 색상이 할당됩니다.

  • BGP(Border Gateway Protocol) 디바이스에서 내보내기 정책을 수출하지 않습니다.

  • BGP(Border Gateway Protocol) 디바이스에서 정책을 가져올 수 있습니다.

  • ingress 디바이스에서 VRF 가져오기 정책.

VPN 서비스 컬러링의 두 가지 모드는

발신 색 할당

이 모드에서, egress 장비(즉, VPN NLRI의 광고주)는 VPN 서비스를 색칠하는 업무를 담당합니다. 이 모드를 활성화하려면 라우팅 정책을 정의하고 VPN 서비스의 라우팅 인스턴스, 그룹 내보내기 또는 계층 수준에서 그룹 이웃 내보내기에 vrf-export[edit protocols bgp] 적용할 수 있습니다. VPN NLRI는 특정 색 확장 커뮤니티에 BGP(Border Gateway Protocol) 광고합니다.

몇 가지 예를 들면 다음과 같습니다.

또는

주:

라우팅 정책을 BGP(Border Gateway Protocol) 또는 BGP(Border Gateway Protocol) 그룹의 내보내기 정책으로 적용하는 경우 정책이 VPN NLRI에 영향을 미치기 위해 BGP(Border Gateway Protocol)BGP(Border Gateway Protocol) 그룹 또는 BGP(Border Gateway Protocol) neighbor 수준으로 명령문을 포함해야 vpn-apply-export 합니다.

라우팅 정책은 Layer 3 VPN Prefix NLRIS, Layer 2 VPN NRIS 및 EVPN NLIS에 적용됩니다. Color Extended Community는 하나 또는 여러 개의 ingress 장비에 있는 대상 VRF에 모든 VPN 경로가 가져와 설치됩니다.

Ingress Color 할당

이 모드에서 수신 장비(즉, VPN NLRI의 수신기)는 VPN 서비스의 색을 정합니다. 이 모드를 활성화하려면 라우팅 정책을 정의하고 VPN 서비스의 라우팅 인스턴스, 그룹 가져오기 또는 계층 수준에서 그룹 이웃 가져오기(group neighbor)에 vrf-import[edit protocols bgp] 적용할 수 있습니다. 라우팅 정책과 일치하는 모든 VPN 경로는 지정된 색 확장 커뮤니티에 첨부됩니다.

몇 가지 예를 들면 다음과 같습니다.

또는

VPN 서비스 매핑 모드 지정

유연한 VPN 서비스 매핑 모드를 지정하려면 명령문을 사용하여 정책을 정의하고 VPN 서비스의 라우팅 인스턴스, 그룹 가져오기 또는 계층 수준에서 그룹 이웃 가져오기에서 정책을 resolution-mapvrf-import[edit protocols bgp] 참조해야 합니다. 라우팅 정책과 일치하는 모든 VPN 경로는 지정된 해결 맵과 함께 연결됩니다.

몇 가지 예를 들면 다음과 같습니다.

VPN 서비스의 라우팅 인스턴스에 가져오기 정책을 적용할 수 있습니다.

또한 가져오기 정책을 BGP(Border Gateway Protocol) neighbor에 적용할 BGP(Border Gateway Protocol) 있습니다.

주:

각 VPN 서비스 매핑 모드는 해결 지도에 정의된 고유의 이름을 가지고 있습니다. IP 컬러의 단일 엔트리만이 해결 맵에서 지원됩니다. 여기서 VPN 경로는 의 형태로 색 IP 프로토콜 다음 홉을 사용하여 ip-address:color 해결됩니다.

Color-IP Protocol Next Hop Resolution

프로토콜 다음 홉 해결 프로세스는 Colored-IP 프로토콜의 다음 홉 해결을 지원할 수 있습니다. 컬러 VPN 서비스의 경우, 프로토콜 다음 홉 해결 프로세스는 색과 해결 맵을 소요하고, IP-address:color의형태로 컬러 IP 프로토콜 다음 홉을 구축하고, inet6color.0 라우팅 테이블에서 프로토콜 다음 홉을 해결합니다.

컬러 레이어 2 VPN, 레이어 3 VPN 또는 EVPN 서비스의 다중 경로 해결을 지원하는 정책을 구성해야 합니다. 그런 다음, 정책은 관련 RIB 테이블과 함께 resolver 가져오기 정책으로 적용되어야 합니다.

몇 가지 예를 들면 다음과 같습니다.

IP Protocol Next Hop Resolution로의 폴백

색의 VPN 서비스에 해결 맵이 적용되지 않는 경우, VPN 서비스는 색을 무시하고 IP 프로토콜 다음 홉 해결로 다시 떨어지게 됩니다. 반대로, 비색 VPN 서비스에 해결 맵이 적용된 경우 해결 맵이 무시되고 VPN 서비스는 IP 프로토콜 다음 홉 해결을 사용합니다.

폴백은 색색의 SRTE LSP에서 LDP LSP로의 간단한 프로세스입니다. LDP용 RIB 그룹을 사용하여 inet{6}color.0 라우팅 테이블에 루트를 설치합니다. 컬러 IP 프로토콜 넥스트 홉에 대한 가장 긴 Prefix 일치는 컬러 SRTE LSP 경로가 없는 경우 일치하는 IP 주소가 있는 LDP 경로가 반환되도록 보장합니다.

BGP(Border Gateway Protocol) SR-트래픽 엔지니어링(TE) 라벨링된 유니캐스트 컬러 기반 매핑

Junos OS Release 20.2R1부터 BGP(Border Gateway Protocol)-LU(Labeled Unicast BGP(Border Gateway Protocol)-LU)는 IPv4 및 IPv6 주소군 모두에 대해 세그먼트 라우팅–트래픽 엔지니어링(SR-트래픽 엔지니어링(TE))을 통해 IPv4 또는 IPv6 경로를 해결할 수 있습니다. BGP(Border Gateway Protocol)-LU는 커뮤니티 색상과 BGP(Border Gateway Protocol) resolution map SR-트래픽 엔지니어링(TE). 다음 홉의 컬러 프로토콜이 생성되어 또는 테이블의 색색 SR-트래픽 엔지니어링(TE) 터널에서 inetcolor.0inet6color.0 해결됩니다. BGP(Border Gateway Protocol) 기반 매핑을 위해 사용 inet.3inet6.3 및 테이블을 사용합니다. 이를 통해 IPv6 전용 네트워크에서 IPv6 넥스트 홉 주소와 BGP(Border Gateway Protocol)-LU IPv6 및 IPv4 프리픽스에 IPv4 주소가 구성된 것을 알 수 있습니다. 현재 이 기능을 통해 SR-BGP(Border Gateway Protocol) IPv6 LU와 트래픽 엔지니어링(TE) 언더레이를 IS-IS(Intermediate System to Intermediate System) 있습니다.

에서 그림 9 컨트롤러는 SR-트래픽 엔지니어링(TE) 구성된 IPv6 코어 네트워크에서 4색 터널을 트래픽 엔지니어링(TE). 각 컬러 터널은 정의된 해결 맵에 따라 대상 라우터 D로 경로가 다릅니다. 컨트롤러는 라우터 D에서 abcd:3701:2d05 인터페이스에 트래픽 엔지니어링(TE) 색의 SR-트래픽 엔지니어링(TE) 터널을 구성합니다. BGP(Border Gateway Protocol) abcd:3700:6/128에 컬러 및 해결 맵을 할당하기 위해 정책을 가져오습니다. 할당된 커뮤니티 색상을 기반으로 BGP(Border Gateway Protocol)-LU는 할당된 해결 맵 정책에 따라 IPv6 LU BGP(Border Gateway Protocol) 위한 컬러 넥스 홉을 해결합니다.

그림 9: BGP(Border Gateway Protocol) IPv6 LU 오버 컬러 IPv6 SR-트래픽 엔지니어링(TE)BGP(Border Gateway Protocol) IPv6 LU 오버 컬러 IPv6 SR-트래픽 엔지니어링(TE)

BGP(Border Gateway Protocol)-LU는 다음과 같은 시나리오를 지원합니다.

  • BGP(Border Gateway Protocol) IPv4 LU 오버 컬러 BGP(Border Gateway Protocol) IPv4 SR-트래픽 엔지니어링(TE) ISIS/최단 경로 우선(OSPF) SR 확장이 있습니다.

  • BGP(Border Gateway Protocol) 정적 색의 및 비색 IPv4 SR-트래픽 엔지니어링(TE), ISIS/최단 경로 우선(OSPF) IPv4 SR 확장을 통해 IPv4 LU를 제공합니다.

  • BGP(Border Gateway Protocol) IPv6 LU 오버 컬러 BGP(Border Gateway Protocol) IPv6 SR-트래픽 엔지니어링(TE) ISIS IPv6 SR 확장을 사용할 수 있습니다.

  • BGP(Border Gateway Protocol) IPv6 LU 오버 정적 색과 비색 IPv6 SR-트래픽 엔지니어링(TE) ISIS IPv6 SR 확장을 사용할 수 있습니다.

  • IPv6 로컬 주소 및 IPv6 이웃 주소가 있는 IPv6 레이어 3 VPN 서비스.

  • ISIS IPv6 SR 확장을 통해 IPv6 BGP(Border Gateway Protocol) SR-트래픽 엔지니어링(TE) IPv6 레이어 3 VPN 서비스.

  • ISIS IPv6 SR 확장을 통해 정적 색의 비색 IPv6 SR-트래픽 엔지니어링(TE) IPv6 레이어 3 VPN 서비스.

VPN 서비스의 색 기반 매핑을 위한 지원 및 지원되지 않는 기능

VPN 서비스의 색상 기반 매핑으로 지원되는 기능은 다음과 같습니다.

  • BGP(Border Gateway Protocol) Layer 2 VPN(Kompella Layer 2 VPN)

  • BGP(Border Gateway Protocol) EVPN

  • 단일 IP 컬러 옵션을 통해 해결 맵.

  • 컬러 IPv4 및 IPv6 프로토콜 다음 홉 해상도.

  • 라우팅 정보 베이스(라우팅 테이블) 그룹 기반 inetcolor.0 라우팅 테이블에서 LDP LSP로의 폴백

  • 컬러 SRTE LSP.

  • 가상 플랫폼.

  • 64비트 Junos OS.

  • 논리적 시스템.

  • BGP(Border Gateway Protocol) 유니캐스트로 분류됩니다.

VPN 서비스의 색상 기반 매핑에는 다음 기능이 지원되지 않습니다.

  • 컬러 MPLS LSP(예: RSVP, LDP, BGP(Border Gateway Protocol)-LU, 정적)

  • 레이어 2 서킷

  • FEC-129는 BGP(Border Gateway Protocol) 및 LDP 신호 Layer 2 VPN을 자동으로 검색합니다.

  • VPLS

  • MVPN

  • 해결 지도를 사용한 IPv4 및 IPv6.

PCE 시작 세그먼트 라우팅 LSP를 위한 터널 템플릿

PCE 시작 세그먼트 라우팅 LSP를 위한 터널 템플릿을 구성하여 이들 LSP에 대한 2개의 추가 매개 변수인 BFD(Bidirectional Forwarding Detection) 및 LDP 터널링을 전달할 수 있습니다.

PCE-Initiated Segment Routing LSP가 생성되고 있는 경우 정책문(있는 경우)과 LSP가 검사되고 일치되는 경우 정책은 해당 LSP에 대해 구성된 템플릿을 적용합니다. 템플릿 구성은 LSP 소스(PCEP)를 통해 제공되지 않는 경우만 상속됩니다. 예를 들어 메트릭을 들 수 있습니다.

템플릿 구성:

  1. 계층 수준에서 소스 라우팅-경로-템플릿[edit protocols source-packet-routing] 명령문을 포함합니다. 여기에서 추가적인 BFD 및 LDP 터널링 매개변수를 구성할 수 있습니다.

  2. 계층 수준에서 소스 라우팅-경로-템플릿-맵 명령문을 포함해 PCE-시작 LSP를 검사해야 하는 정책문을 [edit protocols source-packet-routing] 나열합니다.

  3. 템플릿이 적용될 LSP를 나열하는 정책을 정의합니다.

    명령문은 일치 조건을 사용하여 LSP 이름 또는 LSP 정규 표현식을 from 포함할 수 lsplsp-regex 있습니다. 이들 옵션은 서로 배타적이기 때문에 특정 시점에 단 하나의 옵션만 지정할 수 있습니다.

    then진술서에는 sr-te-template 수락 조치가 포함된 옵션이 포함되어야 합니다. 이는 PCE-시작 LSP에 템플릿을 적용합니다.

PCE 시작 LSP에 대한 템플릿 구성 시 다음을 고려합니다.

  • 템플릿 구성은 정적으로 구성된 세그먼트 라우팅 LSP 또는 다른 클라이언트의 세그먼트 라우팅 LSP에는 적용되지 않습니다.

  • PCEP 제공 구성은 템플릿 구성보다 우선 순위가 있습니다.

  • PCEP LSP는 템플릿 세그먼트 목록 구성을 상속하지 않습니다.

예를 들면 다음과 같습니다. 정적 세그먼트 라우팅 레이블 스위칭 경로 구성

이 예에서는 네트워크에서 정적 세그먼트 라우팅 LSP(Label Switched Path)를 구성하는 MPLS 보여줍니다. 이러한 구성은 네트워크 확장성을 MPLS 데 도움이 됩니다.

요구 사항

이 예에서는 다음과 같은 하드웨어 및 소프트웨어 구성 요소를 활용합니다.

  • 7개의 MX 시리즈 5G 유니버설 라우팅 플랫폼

  • Junos OS Release 18.1 이상이 모든 라우터에서 실행됩니다.

시작하기 전에 디바이스 인터페이스를 구성해야 합니다.

개요

Junos OS 정적 세그먼트 라우팅 터널의 ingress 라우터에서 계층 수준에서 명령문을 구성하여 segment-list [edit protocols source-packet-routing] 구성합니다. 계층 수준에서 명령문을 구성하여 세그먼트 라우팅 터널을 source-routing-path[edit protocols source-packet-routing] 구성할 수 있습니다. 세그먼트 라우팅 터널에는 대상 주소와 하나 이상의 기본 경로와 세그먼트 목록을 참조하는 보조 경로가 있습니다. 각 세그먼트 목록은 일련의 홉으로 구성됩니다. 비색 정적 세그먼트 라우팅 터널의 경우 세그먼트 목록의 첫 번째 홉은 즉각적인 다음 홉 IP 주소를 지정하며, 두 번째 홉은 경로가 선회하는 링크 또는 노드에 해당하는 세그먼트 식별(SID) 레이블을 지정합니다. 세그먼트 라우팅 터널의 대상 경로는 inet.3 테이블에 설치됩니다.

토폴로지

이 예에서는 제공업체 에지 라우터 PE1 및 PE5에서 레이어 3 VPN을 구성합니다. 모든 MPLS 프로토콜을 구성합니다. 세그먼트 라우팅 터널은 라우터 PE1 및 라우터 PE5에 구성된 기본 경로를 통해 라우터 PE1에서 라우터 PE5로 구성됩니다. 라우터 PE1도 경로 보호를 위한 보조 경로로 구성됩니다. 전송 라우터 PE2에서 PE4로 구성됩니다. 이 레이블은 Label pop 및 Outgoing Interface가 있는 Adjacency SID Label로 구성됩니다.

그림 10: 정적 세그먼트 라우팅 레이블 스위칭 경로정적 세그먼트 라우팅 레이블 스위칭 경로

구성

CLI 빠른 구성

이 예제를 신속하게 구성하려면 다음 명령을 복사하여 텍스트 파일에 붙여넣기하고, 라인 끊기를 제거하고, 네트워크 구성과 일치하는 데 필요한 세부 정보를 변경하고, 계층 수준에서 명령어를 CLI 입력한 다음 구성 모드에서 [edit]commit 입력합니다.

PE1

PE2

PE3

PE4

PE5

CE1

CE2

디바이스 PE1 구성
단계별 절차

다음 예제에서는 구성 계층의 다양한 수준을 탐색해야 합니다. 네트워크의 네트워크 CLI 대한 자세한 내용은 CLI 사용자 가이드의 CLI 편집기사용 CLI 참조하십시오.

Device PE1을 구성하려면:

  1. 인터페이스를 구성합니다.

  2. 자율 시스템 번호 및 옵션을 구성하여 패킷 포우링 라우팅 옵션을 제어합니다.

  3. 표준 프로토콜과 인터페이스를 MPLS 레이블 범위를 MPLS 구성합니다.

  4. 업데이트 시 피어 그룹 유형, 로컬 주소, 업데이트 시 NLR을 위한 프로토콜 패밀리, 피어 그룹에 대한 이웃의 IP 주소를 구성합니다.

  5. 프로토콜 영역 인터페이스를 구성합니다.

  6. SPRING(Protocol Source Packet Routing)의 소스 라우팅 트래픽 엔지니어링(트래픽 엔지니어링(TE)) 정책을 위해 IPv4 주소와 기본 및 보조 경로 레이블을 구성합니다.

  7. 대상 IPv4 주소를 구성하고 프로토콜 SPRING에 대한 SID Label, 기본 및 보조 소스 라우팅 경로에 바인딩합니다.

  8. 정책 옵션을 구성합니다.

  9. 커뮤니티 BGP(Border Gateway Protocol) 구성합니다.

  10. 인스턴스 유형, 인터페이스, 라우터 구분자, VRF 가져오기, 내보내기 및 테이블 레이블이 있는 라우팅 인스턴스 VRF1을 구성합니다. 프로토콜 데이터 처리를 위해 내보내기 정책 및 영역 인터페이스를 최단 경로 우선(OSPF).

결과

구성 모드에서 , , 및 명령어를 입력하여 show interfacesshow policy-optionsshow protocolsshow routing-optionsshow routing-instances 구성을 확인 출력이 의도한 구성을 표시하지 않는 경우 이 예제의 지침을 반복하여 구성을 수정합니다.

디바이스 PE2 구성
단계별 절차

다음 예제에서는 구성 계층의 다양한 수준을 탐색해야 합니다. 네트워크의 네트워크 CLI 대한 자세한 내용은 CLI 사용자 가이드의 CLI 편집기사용 CLI 참조하십시오.

  1. 인터페이스를 구성합니다.

  2. 프로토콜 및 프로토콜에 대한 정적 LSP를 MPLS.

  3. 프로토콜 및 프로토콜에 대한 인터페이스와 정적 레이블 범위를 MPLS.

  4. 프로토콜 및 프로토콜을 위한 인터페이스를 최단 경로 우선(OSPF).

결과

라우터 PE2의 구성 모드에서 명령어를 입력하여 show interfacesshow protocols 구성을 확인합니다. 출력이 의도한 구성을 표시하지 않는 경우 이 예제의 지침을 반복하여 구성을 수정합니다.

확인

구성이 제대로 작동하고 있는지 확인합니다.

라우터 PE1의 라우팅 테이블 inet.3의 경로 입력 검증
목적

라우터 PE1의 라우팅 테이블 inet.3의 경로 입력을 검증합니다.

실행

작동 모드에서 명령어를 show route table inet.3 입력합니다.

의미

출력은 세그먼트 라우팅 터널의 ingress 경로를 표시합니다.

라우터 PE1의 라우팅 테이블 mpls.0의 경로 테이블 항목 검증
목적

라우팅 테이블 mpls.0의 경로 엔트리 확인

실행

작동 모드에서 명령어를 show route table mpls.0 입력합니다.

의미

출력은 세그먼트 라우팅 터널의 SID 레이블을 표시합니다.

SPRING 트래픽 엔지니어링 라우터 PE1의 LSP 검증
목적

ingress 라우터에서 SPRING 트래픽 엔지니어링 LSP를 검증합니다.

실행

작동 모드에서 명령어를 show spring-traffic-engineering overview 입력합니다.

의미

출력은 ingress 라우터에서 엔지니어링된 SPRING 트래픽 엔지니어링 LSP의 개요를 표시합니다.

라우터 PE1의 Ingress 라우터에서 SPRING 트래픽 엔지니어링 LSP 검증
목적

ingress 라우터에서 SPRING 트래픽 엔지니어링 LSP를 검증합니다.

실행

작동 모드에서 명령어를 show spring-traffic-engineering lsp detail 입력합니다.

의미

출력은 ingress 라우터에서 엔지니어링된 SPRING 트래픽 엔지니어링 LSP의 세부 정보를 표시합니다.

라우터 PE2의 라우팅 테이블 mpls.0의 라우팅 테이블 항목 검증
목적

라우터 PE2의 라우팅 테이블 mpls.0의 라우팅 테이블 항목을 검증합니다.

실행

작동 모드에서 명령어를 show route table mpls.0 입력합니다.

라우터 PE2의 LSP MPLS 정적 상태 검증
목적

라우터 PE2의 LSP MPLS 상태를 검증합니다.

실행

작동 모드에서 명령어를 show mpls static-lsp 입력합니다.

의미

출력은 라우터 PE2의 LSP MPLS 정적 상태 표시

세그먼트 라우팅 LSP를 위한 분산형 CSPF 활성화

Junos OS Release 19.2R1S1을 사용하기 전에 세그먼트 라우팅 경로의 트래픽 엔지니어링을 위해 정적 경로를 명시적으로 구성하거나 외부 컨트롤러의 컴퓨팅 경로를 사용할 수 있습니다. 세그먼트 라우팅 LSP 기능을 위한 분산형 CSPF(Shortest Path First)를 사용하면 구성한 제약 조건에 따라 ingress 디바이스에서 로컬로 세그먼트 라우팅 LSP를 계산할 수 있습니다. 이 기능을 통해 LSP는 구성된 제약 조건 및 메트릭 유형(트래픽 엔지니어링 또는 IGP)을 기반으로 최적화됩니다. LSP는 세그먼트 라우팅 Label 스택 압축을 활성화하거나 비활성화하여 대상에 가용 ECMP 경로를 활용하기 위해 계산됩니다.

분산형 CSPF 컴퓨팅 제약 조건

구성된 모든 제약 조건이 충족되면 세그먼트 라우팅 LSP 경로가 계산됩니다.

분산형 CSPF 컴퓨팅 기능은 인터넷 초안, draft-ietf-spring-segment-routing-policy-03.txt, 트래픽엔지니어링을 위한 세그먼트 라우팅 정책에 지정된 다음과 같은 하위 세트를 지원합니다.

  • 관리 그룹의 포함 및 제외.

  • 느슨하거나 엄격한 홉 IP 주소 포함.

    주:

    느슨하거나 엄격한 홉 제약 조건에서 라우터 아이디만 지정할 수 있습니다. Label 및 기타 IP 주소는 release Junos OS 릴리스에서 느슨하거나 엄격한 홉 제약 조건으로 19.2R1 수 없습니다.

  • 세그먼트 목록에서 세그먼트 아이디(SID)의 최대 개수.

  • 후보 세그먼트 라우팅 경로당 최대 세그먼트 목록 개수.

세그먼트 라우팅 LSP를 위한 분산형 CSPF 컴퓨팅 기능은 다음과 같은 유형의 제약 및 구축 시나리오를 지원하지 않습니다.

  • IPV6 주소.

  • 도메인 간 세그먼트 라우팅 트래픽 엔지니어링(SRTE) LSP

  • 수 없는 인터페이스.

  • 동시에 최단 경로 우선(OSPF), ISIS 및 BGP(Border Gateway Protocol)-LS와 같은 여러 프로토콜 라우팅 프로토콜을 사용할 수 있습니다.

  • 프리픽스 또는 모든캐스트 주소를 목적지로 연산합니다.

  • 인터페이스 IP 주소를 제약 조건으로 포함 및 제외합니다.

분산형 CSPF 계산 알고리즘

세그먼트 라우팅 LSP를 위한 분산형 CSPF 컴퓨팅 기능은 CSPF와 함께 Label 스택 압축 알고리즘을 사용합니다.

Label Stack 압축 지원

압축된 Label 스택은 소스에서 대상에 대한 경로 집합을 나타 내포합니다. 일반적으로 노드 SID와 Adjacency SID로 구성됩니다. Label Stack 압축이 활성화되면, 연산의 결과는 제약 조건을 준수하면서 스택의 최소 SI 수를 유지하면서 ECMP를 대상까지 극대화하는 경로 집합입니다.

Label Stack 압축 비활성화

Label 스택 압축이 비활성화된 다중 경로 CSPF 계산은 다음을 통해 목적지에 대한 N 세그먼트 목록을 찾을 수 있습니다.

  • 모든 세그먼트 목록의 비용은 대상에 도달하는 최단 트래픽 엔지니어링 메트릭과 동일합니다.

  • 각 세그먼트 목록은 Adjacency SID로 구성됩니다.

  • N의 값은 구성에 따라 후보 경로에 허용되는 세그먼트 목록의 최대 개수입니다.

  • 두 세그먼트 목록이 동일하지 않습니다.

  • 각 세그먼트 목록은 구성된 모든 제약 조건을 충족합니다.

분산형 CSPF 컴퓨팅 데이터베이스

SRTE 컴퓨팅에 사용되는 데이터베이스에는 트래픽 엔지니어링이 이러한 광고 노드에서 활성화되어 있는지 여부와 무관하게 모든 링크, 노드, 프리픽스 및 특성이 있습니다. 다시 말해, 컴퓨팅 노드가 학습한 모든 도메인의 TED(Traffic-Engineering Database)와 IGP 링크 상태 데이터베이스가 조합된 것입니다.

분산 CSPF 컴퓨팅 제약 조건 구성

컴퓨팅 프로필을 사용하여 계산 제약을 논리적으로 그룹화할 수 있습니다. 이러한 컴퓨팅 프로파일은 기본 및 보조 세그먼트 라우팅 LSP를 컴퓨팅하기 위한 세그먼트 라우팅 경로에 의해 참조됩니다.

컴퓨팅 프로파일을 구성하려면 계층 수준에서 컴퓨팅 프로파일[edit protocols source-packet-routing] 명령문을 포함합니다.

지원되는 컴퓨팅 제약 조건의 구성은 다음과 같습니다.

  • Administrative groups

    계층 수준에서 관리 그룹을 [edit protocols mpls] 구성할 수 있습니다. Junos OS 세그먼트 라우팅 트래픽 엔지니어링(SRTE) 인터페이스에 관리 그룹 구성을 적용합니다.

    연산 제약 조건을 구성하기 위해 관리 그룹 집합에 대해 3개의 범주를 지정할 수 있습니다. 연산 제한 조건 구성은 모든 후보 세그먼트 라우팅 경로에 공통적으로 적용될 수 있습니다. 또는 개별 후보 경로에 있을 수도 있습니다.

    • include-any—목록에 구성된 관리 그룹 중 하나 이상이 있는 링크가 경로를 통해 허용될 수 있는지 지정합니다.

    • include-all—목록에서 구성된 관리 그룹이 모두 있는 링크가 경로를 통해 허용될 수 있는지 지정합니다.

    • exclude—목록에 구성된 관리 그룹이 없는 링크가 경로를 통해 전달될 수 있도록 허용하도록 지정합니다.

  • Explicit path

    컴퓨팅 프로파일에서 일련의 라우터 신원을 SRTE 후보 경로의 컴퓨팅 제약 조건으로 지정할 수 있습니다. 각 홉은 IPv4 주소로, 엄격한 유형 또는 느슨한 유형이 될 수 있습니다. 홉 유형이 구성되지 않은 경우 엄격한 것이 사용됩니다. 명시적 경로 제약 조건을 지정할 때 computeSegment-list statement에 옵션을 포함해야 합니다.

  • Maximum number of segment lists (ECMP paths)

    여러 동적 세그먼트 목록과 후보 경로를 연관할 수 있습니다. 경로는 ECMP 경로입니다. 여기서 각 세그먼트 목록이 활성 가중치를 가지는 다음 홉 게이트웨이로 변환됩니다. 이러한 경로는 압축 유무에 따라 경로 계산의 결과입니다.

    컴퓨팅 프로파일 구성 명령문에 있는 옵션을 사용하여 이 속성을 maximum-computed-segment-lists maximum-computed-segment-lists 구성할 수 compute-profile 있습니다. 이 구성은 해당 기본 및 보조 LSP에 대해 계산된 이러한 세그먼트 목록의 최대 개수를 결정합니다.

  • Maximum segment list depth

    최대 세그먼트 리스트 깊이 계산 매개 변수는 관리 그룹과 같은 다른 모든 제약 조건을 충족하는 ECMP 경로 사이에서 최대 세그먼트 리스트 깊이보다 작거나 같은 세그먼트 목록이 있는 경로만 사용되도록 보장합니다. 컴퓨팅 프로파일에서 제약 조건으로 이 매개 변수를 구성할 경우, 해당 매개 변수가 있는 경우 계층 수준에서 구성을 maximum-segment-list-depth[edit protocols source-packet-routing] 위반합니다.

    컴퓨팅 프로파일 구성 명령문에 있는 옵션을 사용하여 이 속성을 maximum-segment-list-depth maximum-segment-list-depth 구성할 수 compute-profile 있습니다.

  • Protected or unprotected adjacency SIDs

    보호되거나 보호되지 않는 Adjacency SID를 컴퓨팅 프로파일 compute-profile 하에서 제약 조건으로 구성하여 지정된 SID 유형과의 링크를 피할 수 있습니다.

  • Metric type

    연산에 사용할 링크에서 메트릭의 유형을 지정할 수 있습니다. 기본적으로 SR-트래픽 엔지니어링(TE) LSP는 연산을 위해 링크의 트래픽 엔지니어링 메트릭을 사용하게 됩니다. 링크에 대한 트래픽 엔지니어링 메트릭은 트래픽 엔지니어링 프로토콜의 트래픽 엔지니어링 확장에 IGP 광고됩니다. 그러나 컴퓨팅 프로파일에서 메트릭 유형 IGP 지표를 사용하여 계산을 위한 IGP 지표를 사용할 수도 있습니다.

    컴퓨팅 프로파일 구성 명령문에 있는 옵션을 사용하여 이 속성을 metric-type (igp | te) 구성할 수 compute-profile 있습니다.

분산형 CSPF 컴퓨팅

SRTE 후보 경로는 로컬로 계산하여 구성된 제약 조건을 충족합니다. Label 스택 압축이 해제된 경우 다중 경로 CSPF 연산 결과는 Adjacency SID 스택 집합입니다. Label 스택 압축이 활성화되면, 인접한 SID 및 노드 SI로 구성된 압축 레이블 스택 세트가 생성됩니다.

보조 경로가 계산되는 경우 기본 경로에서 취해진 링크, 노드 및 SRG를 연산으로 회피할 수 없습니다. 기본 및 보조 경로에 대한 자세한 내용은 기본 및 보조 LSP구성을 참조하십시오.

연산에 실패한 LSP의 경우, 연산은 TED(Traffic-Engineering Database)의 변경에 따라 재시도됩니다.

분산형 CSPF 컴퓨팅과 SRTE 기능 간의 상호 작용

SRTE 정책 경로와 관련된 가중치

라우팅의 다음 홉에 기여하는 컴퓨팅 및 정적 SRTE 경로에 대해 가중치를 구성할 수 있습니다. 그러나 연산을 활성화한 단일 경로는 여러 세그먼트 목록으로 이어될 수 있습니다. 이러한 컴퓨팅 세그먼트 목록은 그 자체로도 ECMP로 취급됩니다. 구성된 각 프리머리에 할당된 가중치를 고려하여 이들 세그먼트에 계층형 ECMP 가중치를 할당할 수 있습니다.

BFD 활기 감지

계산된 주 또는 보조 경로에 대해 BFD의 활력 감지를 구성할 수 있습니다. 모든 컴퓨팅된 기본 또는 보조 경로는 여러 세그먼트 목록이 나타날 수 있습니다. 그 결과 세그먼트 리스트에 대해 구성된 BFD 매개 변수가 모든 컴퓨팅 세그먼트 목록에 적용됩니다. 모든 활성 기본 경로가 다운된 경우 사전 프로그래밍된 보조 경로(제공된 경우)가 활성화됩니다.

상속-Label-Nexthops

기본 동작이기 때문에 계산된 주 또는 보조 경로에 대한 계층 하의 구성을 명시적으로 활성화할 inherit-label-nexthops[edit protocols source-packet-routing segment-list segment-list-name] 필요가 없습니다.

자동 변환 기능

세그먼트 목록에서 자동 변환 기능을 구성할 수 있으며, 자동 변환 기능을 사용하여 기본 또는 보조 경로를 이러한 세그먼트 목록을 참조로 구성할 수 있습니다. 한편, 컴퓨팅 기능이 활성화된 주 또는 보조 항목은 세그먼트 리스트를 참조할 수 없습니다. 따라서, 주어진 기본 경로 또는 보조 경로에 대해 컴퓨팅 기능 및 자동 변환 기능을 사용할 수 없습니다. 그러나 컴퓨팅 유형이 있는 기본 경로와 자동 변환 유형이 있는 다른 경로로 구성된 LSP가 있을 수 있습니다.

분산형 CSPF 컴퓨팅 샘플 구성

예 1

예를 들어, 1

  • 비 컴퓨팅 기본 경로는 구성된 세그먼트 목록을 참조합니다. 이 예에서는 구성된 세그먼트 static_sl1 리스트를 참조하며, 이 기본 경로의 이름로도 사용할 수 있습니다.

  • 컴퓨팅된 기본에는 이름을 구성해야 합니다. 이 이름은 구성된 세그먼트 목록을 참조하지 않습니다. 이 예에서는 compute_segment1 세그먼트 목록이 없습니다.

  • compute_profile_red-profile은 의 이름과 함께 기본 경로에 compute_segment1.

  • compute_profile_red 컴퓨팅 프로파일은 연산에 대한 명시적 경로 제약 조건을 지정하는 데 사용되는 유형의 세그먼트 목록을 compute 포함합니다.

컴퓨팅 경로 넥스 홉과 정적 넥스 홉에 대한 가중치는 각각 2와 3입니다. 컴퓨팅 경로의 다음 홉이 comp_nh1,comp_nh2 및 comp_nh3 정적 경로의 넥스 홉이 static_nh 가중치를 다음과 같이 적용합니다.

다음 홉

중량

comp_nh1

2

comp_nh2

2

comp_nh3

2

static_nh

9

예제 2

예를 들어 2에서는 기본 경로와 보조 경로 모두 컴퓨팅 유형이 될 수 있으며 자체 컴퓨팅 프로필을 소유할 수 있습니다.

예 3

예를 들어 3차 또는 보조 경로에 컴퓨팅이 언급된 경우, 그 어떤 제약 조건이나 연산에 대한 다른 매개 변수 없이도 대상에 대한 경로의 로컬 연산을 계산하게 됩니다.

예를 들면 다음과 같습니다. SR-트래픽 엔지니어링(TE) CoS 기반 포우링 및 정책 기반 라우팅 구성

SUMMARY CoS 기반 포워더(CBF) 및 정책 기반 라우팅(PBR(필터 기반 포워더라고도 명명된)은 비색 세그먼트 라우팅-트래픽 엔지니어링(SR–트래픽 엔지니어링(TE)) LSP에 활성화되어 명시적인 SR-트래픽 엔지니어링(TE) 경로에서 선택적 트래픽을 전달할 수 있으며, 이를 통해 서비스 등급 또는 정책을 기반으로 트래픽을 지원할 수 있습니다.

SR-트래픽 엔지니어링(TE) 위한 CoS 기반 포우링 및 정책 기반 라우팅 개요

SR-트래픽 엔지니어링(TE) LSP에 대한 CBF(CoS-Based Forwarding) 및 PBR(Policy-Based Routing)의 트래픽 엔지니어링(TE) 이점

CBF 및 PBR을 사용하면 다음을 할 수 있습니다.

  • 세그먼트 라우팅-트래픽 엔지니어링(SR-트래픽 엔지니어링(TE)) 경로를 조합하여 코어에서 서비스 트래픽을 스티어링합니다.

  • 선택한 SR-트래픽 엔지니어링(TE) 경로를 통해 해결할 지원 트래픽 엔지니어링(TE) 선택.

CBF 및 PBR을 지원하는 세그먼트 라우팅 경로 소스

다음 세그먼트 라우팅 경로 소스는 CoS 기반 포우링 및 정책 기반 라우팅을 제공합니다.

  • Static SR–TE paths—전체 Label 스택이 정적으로 구성된 정적으로 구성된 소스 라우팅 경로입니다.

  • PCEP—컨트롤러에서 생성된 소스 라우팅 경로를 동적으로 프로비저닝하고 PCEP 세그먼트 라우팅 확장을 통해 또는 BGP(Border Gateway Protocol) 세그먼트 라우팅 확장을 통해 ERO에서 ingress 라우터에 BGP(Border Gateway Protocol) 있습니다.

  • Dynamic LSPs—동적 터널 모듈을 통해 트리거된 동적으로 생성된 터널은 마지막 홉 ERO 해결을 제공합니다.

  • Auto-translated paths—정적으로 구성된 소스 라우팅 경로가 자동으로 변환됩니다.

SR-트래픽 엔지니어링(TE) CBF 및 PBR 구성을 위한 고려 사항

기억:

  • CBF 및 PBR은 정적 또는 동적으로 트래픽 엔지니어링(TE) 비색 SR-트래픽 엔지니어링(TE) LSP에서만 활성화됩니다.

  • SR-트래픽 엔지니어링(TE) 위한 CBF 및 PBR 구성 모두 디바이스에 공존할 수 있습니다. 구성 순서는 라우팅이 전달되는 유형을 결정합니다.

  • PBR의 경우, SR-트래픽 엔지니어링(TE) LSP의 첫 번째 홉이 레이블인 경우, 계층 수준에서 명령문을 resolution preserve-nexthop-hiearchy[edit routing-options] 포함해야 합니다.

  • CBF에 대한 클래스 기반 포우링은 경로가 아닌 포우링 테이블에서만 볼 수 있습니다.

  • PBR에 대한 정책 기반 포우링은 경로에서 수행하며 명령 show route 출력에 표시된다.

SR-트래픽 엔지니어링(TE) LSP에 대한 CoS 기반 포우링 및 정책 기반 라우팅 구성

SUMMARY CBF(CoS-based Forwarding) 및 PBR(정책 기반 라우팅,필터 기반 포링 FBF라고도 명명된 세그먼트 라우팅-트래픽 엔지니어링) LSP(Label-트래픽 엔지니어링(TE) swtiched Path)를 사용하여 선택적 트래픽을 스티어링하는 데 사용할 수 있습니다. 첫 번째 홉 레이블 또는 IP 주소로 구성된 다음 홉이 CBF 및 PBR을 지원하는 비색 세그먼트 라우팅 LSP만이 해당됩니다.

시작하기 전

  • 비색 SR-Junos OS LSP에 대해 CBF 및 PBR을 활성화하려면 릴리스 20.1 이상에서 트래픽 엔지니어링(TE) 실행해야 합니다.

  • 디바이스 인터페이스를 구성하고 디바이스가 네트워크에 연결되도록 보장합니다.

  • 세그먼트 목록을 정의하고 SR-트래픽 엔지니어링(TE) LSP 및 관련 매개 변수를 구성합니다.

SR-트래픽 엔지니어링(TE) LSP를 구성하기 위해 다음을 실행하십시오.

  1. Label 매개 변수가 있는 세그먼트 목록을 정의합니다.

    몇 가지 예를 들면 다음과 같습니다.

  2. SR-트래픽 엔지니어링(TE) 대한 소스 라우팅 경로를 구성하고 경로에 대한 기본 트래픽 엔지니어링(TE) 세그먼트를 지정합니다.

    몇 가지 예를 들면 다음과 같습니다.

이제 구성된 SR-트래픽 엔지니어링(TE) CBF 및 PBR을 구성할 수 있습니다.

CBF를 구성하기 위해 다음을 실행하십시오.

  1. 수신 IPv4 패킷, 포링 클래스 및 옵션 값을 처리하기 위한 DSCP(Differentiated Services Code Point) 분류자 정의

    몇 가지 예를 들면 다음과 같습니다.

  2. 전송을 위해 패킷을 그룹화하기 위한 FC(Forwarding Classes)를 정의하고, 출력 큐에 패킷을 할당합니다.

    몇 가지 예를 들면 다음과 같습니다.

  3. 장비 인터페이스에 구성된 분류자를 할당합니다.

    몇 가지 예를 들면 다음과 같습니다.

  4. LSP 넥스홉을 SR-트래픽 엔지니어링(TE) CoS 기반 포우링 정책 옵션을 정의합니다.

    몇 가지 예를 들면 다음과 같습니다.

  5. 넥스트 홉 맵에서 포워드 클래스를 충족하지 않는 트래픽을 폐기합니다.

    몇 가지 예를 들면 다음과 같습니다.

  6. 경로 필터와 일치하는 라우트가 map-name에 의해 지정된 CoS 넥스 홉 매핑의 적용을 지정하는 정책문을 구성합니다.

    몇 가지 예를 들면 다음과 같습니다.

  7. 라우팅 테이블에서 포링 테이블로 내보낼 경로에 정책을 적용합니다. 이를 통해 SR-트래픽 엔지니어링(TE) CBF가 지원됩니다.

    몇 가지 예를 들면 다음과 같습니다.

  8. 구성을 커밋합니다.

Verify CBF Configuration

이 명령을 사용하여 CBF 구성을 확인할 수 show route forwarding-table destination ip-address vpn vpn-name extensive 있습니다.

CBF의 경우, 필터링된 라우트가 명령 출력에 표시되는 PBR과 달리 클래스 기반의 라우팅 포우링은 PBR과 달리 포우링 테이블에서만 show route 표시됩니다.

PBR을 구성하기 위해 다음을 실행하십시오.

  1. 프로토콜 및 라우트 필터와 일치하는 라우트가 LSP 넥스 홉에 적용되거나 포딩 테이블에서 ECMP(Equal-Cost Multipath)로 로드 균형을 이루도록 지정하는 정책문을 구성합니다.

    몇 가지 예를 들면 다음과 같습니다.

  2. 프로토콜 다음 경로 홉에서 사용자 지정 경로 확인을 수행하도록 디바이스를 구성합니다.

    주:

    resolution preserve-nexthop-hierarchySR-트래픽 엔지니어링(TE) LSP가 레이블일 때 PBR이 작동해야 합니다.

  3. 라우팅 테이블에서 포링 테이블로 내보낼 경로에 정책을 적용합니다. 이를 통해 SR-트래픽 엔지니어링(TE) PBR을 지원할 수 있습니다.

    몇 가지 예를 들면 다음과 같습니다.

  4. 구성을 커밋합니다.

Verify PBR Configuration

이 명령을 사용하여 PBR 구성을 확인할 수 show route destination-prefix 있습니다.

출력은 대상 프리픽스(4.0.0.1)에 대한 모든 넥스 홉을 표시됩니다. 옵션은 출력 필드에서 필터링된 expanded-nh extensive 넥스홉을 Krt_inh 표시합니다.

PBR의 show route 경우, 명령 출력은 경로의 정책 기반 필터링을 실행합니다.

출시 내역 표
릴리스
설명
21.R1
Junos OS Release 21.1R1부터 Junos OS PCE 개시 RSVP 기반 Point-to-Point 및 Point-to-Multipoint LSP를 위한 무중단 활성 라우팅(NSR)을 제공합니다.
21.R1
Junos OS Release 21.1R1부터 Junos OS PCE 시작 RSVP 기반의 점대다점 LSP에 대한 NSR(Nonstop Active Routing)을 지원한다.
20.2R1
Junos OS Release 20.2R1부터 BGP(Border Gateway Protocol)-LU(Labeled Unicast BGP(Border Gateway Protocol)-LU)는 IPv4 및 IPv6 주소군 모두에 대해 세그먼트 라우팅–트래픽 엔지니어링(SR-트래픽 엔지니어링(TE))을 통해 IPv4 또는 IPv6 경로를 해결할 수 있습니다.
19.4R1
단일 또는 범위의 MVPN 멀티캐스트 플로우(S,G)를 동적으로 생성된 PCE 개시 점대다점 LSP(Point-to-Multipoint Label-Switched Path)에 연결할 수 있습니다.
19.4R1
PCE 시작 세그먼트 라우팅 LSP를 위한 터널 템플릿을 구성하여 이들 LSP에 대한 2개의 추가 매개 변수인 BFD(Bidirectional Forwarding Detection) 및 LDP 터널링을 전달할 수 있습니다.
19.1R1
Junos OS Release 19.1R1 시작으로, 색 경로에 기여하는 모든 세그먼트 목록이 모든 홉에 최소 Label 표시를 하도록 보장하는 커밋 검사 기능이 도입됩니다.
19.1R1
Junos OS Release 19.1R1 시작으로 이 요구 사항은 적용되지 않습니다. 비색 정적 LSP의 첫 번째 홉은 이제 IP 주소 외에도 SID 레이블에 대한 지원을 제공합니다. 첫 번째 홉 레이블 지원을 통해 FRR(MPLS Fast Reroute) 및 가중치가 지정된 정적 비색 세그먼트 라우팅 LSP(정적 정적 LSP)와 유사한 가중치가 동등한 비용 다중 경로가 활성화됩니다.
18.2R1
Junos OS Release 18.2R1 시작하여, ingress 장비에 정적으로 구성된 비색 세그먼트 라우팅 LSP는 PCEP(Path Computation Element Protocol) 세션을 통해 PCE(Path Computation Element)에 보고됩니다.
17.2R1
17.Junos OS 릴리스 17.2부터 PCE 제어 LSP를 위해 다음과 같은 2가지 새로운 경로 계산 유형이 external cspf 소개됩니다. local cspfno cspf및 를 통해
16.1
릴리스 16.1을 Junos OS RFC 5440에 따라 TCP-MD5 인증을 사용하여 PCEP 세션을 보호할 수 있습니다.
16.1
Junos OS Release 16.1은 RFC 5440에 따라 TCP-MD5 인증을 사용하여 PCEP 세션을 보호하는 기능을 제공합니다.
14.2R4
릴리스 Junos OS 릴리스 14.2R4 PCE 제어 LSP에 대한 자동 대역폭 지원이 제공됩니다.