Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

MPLS 트래픽 엔지니어링 구성

MPLS 및 트래픽 엔지니어링

트래픽 엔지니어링을 사용하면 라우팅 테이블을 사용하는 표준 라우팅 모델을 우회하여 데이터 패킷이 따라오는 경로를 제어할 수 있습니다. 트래픽 엔지니어링은 정체된 링크에서 자동 계산된 대상 기반 최단 경로로 선택되지 않은 대체 링크로 플로우를 이동합니다. 트래픽 엔지니어링을 통해 다음을 할 수 있습니다.

  • 고가의 장거리 파이버를 보다 효율적으로 사용할 수 있습니다.

  • 단일 또는 여러 장애 발생 시 트래픽 재지정 방법을 제어합니다.

  • 경로에 따라 중요 트래픽과 일반 트래픽을 분류합니다.

트래픽 엔지니어링 설계의 핵심은 라우터 사이에서 LSP(Label-Switched Path)를 구축하는 데 있습니다. LSP는 프레임 릴레이 또는 ATM의 가상 회로와 같은 연결 지향적입니다. LSP는 안정적이지 않습니다. 우선적으로 처리가 가능하기는 하지만 LSP로 진입하는 패킷은 제공을 보증하지 않습니다. LSP는 경로로 들어오는 패킷이 중간 노드에 의해 접촉되지 않고 전체 경로에 걸쳐 캡슐화되어 전체 경로에서 스위칭되는 한방향 터널과도 유사합니다. LSP는 네트워크에서 패킷이 전달되는 방법에 대한 세분적인 제어 기능을 제공합니다. 안정성을 제공하기 위해 LSP는 기본 및 보조 경로 집합을 사용할 수 있습니다.

LSP는 BGP(Border Gateway Protocol) 트래픽만 구성할 수 있습니다(대상 트래픽은 자율 시스템 [AS]). 이 경우 AS 내의 트래픽은 LSP의 존재에 영향을 받지 않습니다. LSP는 또한 BGP(Border Gateway Protocol)(IGP) 트래픽에 대해 구성할 수 있습니다. 따라서 AS 내 및 AS 간 트래픽은 모두 LSP의 영향을 받습니다.

MPLS 트래픽 엔지니어링 및 신호 전송 프로토콜 개요

트래픽 엔지니어링은 효율적이고 안정적인 네트워크 운영을 지원하는 동시에 네트워크 리소스와 트래픽 성능을 최적화합니다. 트래픽 엔지니어링은 트래픽 흐름을 내부 게이트웨이 프로토콜(IGP)에서 선택한 최단 경로에서 네트워크 전체로 정체된 물리적 경로로 이동하는 기능을 제공합니다. 트래픽 엔지니어링을 지원하기 위해 네트워크는 소스 라우팅 외에도 다음과 같은 작업을 해야 합니다.

  • 대역폭 및 관리 요구 사항과 같은 모든 제약 조건을 고려하여 소스에서 경로를 계산합니다.

  • 경로가 계산된 후 네트워크 전반에서 네트워크 토폴로지 및 링크 속성에 대한 정보를 배포합니다.

  • 네트워크 리소스를 예약하고 링크 속성을 수정합니다.

전송 트래픽이 IP 네트워크를 통해 라우팅되는 경우, MPLS 통과를 엔지니어링하는 데 종종 사용됩니다. 전송 네트워크의 정확한 경로가 트래픽의 발신자 또는 수신자 모두에게 중요하지는 않습니다. 네트워크 관리자는 종종 특정 소스 및 대상 주소 쌍 간에 트래픽을 보다 효율적으로 라우팅하기를 원합니다. 각 패킷에 특정 라우팅 명령이 있는 짧은 레이블을 추가하면 넥스홉 룩업을 기반으로 패킷을 MPLS 라우터에서 라우터로 패킷을 전환할 수 있습니다. 그 결과 라우트는 LSP(Label-Switched Path)라고 불리며, LSP는 네트워크를 통해 트래픽의 통과를 제어하고 트래픽 포워링 속도를 향상합니다.

LSP를 수동으로 만들거나 시그널링 프로토콜을 사용하여 만들 수 있습니다. 시그널링 프로토콜은 전송 네트워크에서 트래픽에 MPLS LSP를 설정하기 위해 네트워크 환경 내에서 사용됩니다. Junos OS LDP 및 RSVP(Resource Reservation Protocol)의 두 가지 시그널링 프로토콜을 지원하며,

MPLS 트래픽 엔지니어링 구성 요소는 다음과 같습니다.

  • MPLS LSP 지원

  • IGP 토폴로지 및 링크 속성에 대한 정보 배포를 위한 확장 기능 확장

  • 경로 계산 및 경로 선택을 위한 CSPF(Constrained Shortest Path First)

  • 경로를 따라 포우링 상태를 설정하고 경로를 따라 리소스를 예약하기 위한 RSVP 확장

Junos OS 지역 전반의 트래픽 엔지니어링도 최단 경로 우선(OSPF) 있습니다.

트래픽 엔지니어링 기능

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

트래픽 엔지니어링은 다음과 같은 기능을 제공합니다.

  • 알려진 병목 또는 네트워크 정체 지점을 중심으로 주요 경로를 라우팅합니다.

  • 주 경로가 단일 또는 여러 장애에 직면할 때 트래픽 재지정 방법을 정밀하게 제어할 수 있습니다.

  • 가용 총 대역폭 및 장거리 파이버를 보다 효율적으로 사용할 수 있도록 함으로써 네트워크 하위 세트가 과도하게 사용되지 않는 동시에 잠재적인 대체 경로를 따라 네트워크의 다른 하위 세트가 활용되지 못하도록 보장합니다.

  • 운영 효율성 극대화.

  • 패킷 손실을 최소화하고, 장장된 혼잡을 최소화하고, 처리 성능을 극대화하여 네트워크의 트래픽 중심 성능 특성을 향상시킵니다.

  • 멀티 서비스 인터넷을 지원하는 데 필요한 네트워크의 통계적 바운드 성능 특성(예: 손실 비율, 지연 변동, 전송 지연)을 향상합니다.

트래픽 엔지니어링의 구성 요소

Junos® 운영 체제에서 트래픽 엔지니어링은 MPLS 및 RSVP를 통해 구현됩니다. 트래픽 엔지니어링은

LSP용 트래픽 엔지니어링 구성

LSP를 구성하면 egress 라우터 쪽의 ingress 라우터에 호스트 경로(32비트 마스크)가 설치됩니다. 호스트 경로의 주소는 LSP의 대상 주소입니다. 계층 수준에서 명령문에 대한 옵션은 기본적으로 활성화됩니다(명시적으로 옵션을 구성할 수도 있습니다), 경로 bgptraffic engineering[edit protocols mpls]bgp 계산에서 LSP만 BGP(Border Gateway Protocol) 허용. 다른 명령문 옵션을 사용하면 마스터 라우팅 인스턴스에서 이러한 동작을 traffic-engineering 변경할 수 있습니다. 이 기능은 특정 라우팅 인스턴스에서는 지원되지 않습니다. 또한 한 번의 명령문 옵션(, 또는) 중 하나의 명령문 옵션만 활성화할 traffic-engineeringbgpbgp-igpbgp-igp-both-ribsmpls-forwarding 있습니다.

주:

모든 명령문 옵션을 활성화 또는 비가동하면 모든 MPLS 루트를 제거한 다음 라우팅 테이블로 traffic-engineering 다시 재설계할 수 있습니다.

섹션에 설명된 최단 경로 우선(OSPF) LSP(Link-State Adverts)에 LSP 메트릭을 표시하도록 트래픽 엔지니어링 및 트래픽 엔지니어링을 구성할 수 LSP 메트릭을 LSAS 요약에 광고 있습니다.

다음 섹션에서는 LSP를 위한 트래픽 엔지니어링 구성 방법을 설명합니다.

트래픽 포링 및 BGP(Border Gateway Protocol) IGP LSP 사용

명령문에 대한 BGP(Border Gateway Protocol) 옵션을 포함하여 egress 라우터로 전달되는 트래픽을 포우팅하기 위해 LSP와 IGP를 구성할 수 bgp-igptraffic-engineering 있습니다. 이 bgp-igp 옵션은 모든 inet.3 경로를 inet.0 라우팅 테이블로 이동합니다.

ingress 라우터에서 bgp-igp 명령문에 대한 옵션을 traffic-engineering 포함합니다.

다음 계층 수준에 이 진술을 포함할 수 있습니다.

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

    주:

    bgp-igp명령문에 대한 traffic-engineering 옵션은 VPN에 구성할 수 없습니다. VPN은 inet.3 라우팅 테이블에 라우트가 추가될 필요가 있습니다.

가상 프라이빗 네트워크에서 포워링에 LSP 사용

VPN은 루트가 inet.3 라우팅 테이블에 유지되어 올바르게 작동해야 합니다. VPN의 경우 명령문 옵션을 구성하여 BGP(Border Gateway Protocol) EGP가 egress 라우터로 전달되는 트래픽을 포우팅할 수 있도록 bgp-igp-both-ribstraffic-engineering IGP와 IGP를 사용합니다. 이 옵션은 inet.0 라우팅 테이블(IPv4 유니캐스트 경로)과 inet.3 라우팅 테이블(경로 정보의 경우 bgp-igp-both-ribs MPLS)에 ingress 경로를 설치합니다.

ingress 라우터에서 다음과 같은 traffic-engineering bgp-igp-both-ribs 명령문을 포함합니다.

다음 계층 수준에 이 진술을 포함할 수 있습니다.

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

명령문을 사용하면 bgp-igp-both-ribs inet.3 테이블의 경로가 inet.0 테이블로 복사됩니다. 복사된 경로는 LDP 신호 또는 RSVP 신호로, inet.0의 다른 라우트보다 기본 설정이 낮을 수 있습니다. 기본 설정이 낮은 라우트는 활성 경로로 선택될 가능성이 높습니다. 라우팅 정책은 활성 경로에만 적용하기 때문에 이는 문제가 될 수 있습니다. 이 문제를 방지하려면 대신 mpls-forwarding 옵션을 사용하십시오.

포우링은 하지만 루트 선택은 하지 않는 RSVP 및 LDP 경로 사용

명령문에 대한 옵션 또는 옵션을 구성하는 경우 우선 순위가 높은 bgp-igpbgp-igp-both-ribstraffic-engineering LSP는 inet.0 라우팅 테이블에서 IGP 라우팅을 대신할 수 있습니다. IGP 더 이상 활성 경로가 아니기 때문에 경로가 재분산되지 않을 수 있습니다.

명령문에 대한 옵션을 구성하는 경우 LSP는 포우링에 사용되지만 경로 선택에서는 mpls-forwardingtraffic-engineering 제외됩니다. 이러한 경로는 inet.0 및 inet.3 라우팅 테이블 모두에 추가됩니다. inet.0 라우팅 테이블의 LSP는 활성 경로가 선택될 때 낮은 기본 설정으로 표시됩니다. 그러나 inet.3 라우팅 테이블의 LSP는 기본 설정이 제공하므로 다음 홉을 포우링하는 데 사용됩니다.

옵션을 활성화하면 기본 설정이 현재 활성 경로보다 낮은 경우에도 포우링에 우선되는 상태를 사용하는 라우트가 mpls-forwardingForwardingOnly 있습니다. 경로의 상태를 검사하기 위해 명령을 show route detail 실행합니다.

포우링에 LSP를 사용하지만 경로 선택에서 제외하기 위해 명령문에 대한 mpls-forwarding 옵션을 traffic-engineering 포함하십시오.

다음 계층 수준에 이 진술을 포함할 수 있습니다.

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

옵션을 구성하면 IGP 바로 가기 경로가 inet.0 라우팅 테이블에만 mpls-forwarding 복사됩니다.

옵션과는 달리, 이 옵션은 포링을 위해 LDP 시그널링 및 bgp-igp-both-ribs RSVP 신호 경로를 사용하고 라우팅 목적으로 BGP(Border Gateway Protocol) IGP 라우팅 정책이 활성화된 경로를 유지할 수 있도록 mpls-forwarding 합니다.

예를 들어 라우터가 BGP(Border Gateway Protocol) 실행되고 다른 BGP(Border Gateway Protocol) 10.10.1/32의 경로가 있는 경우 다른 BGP(Border Gateway Protocol) 라우팅이 실행된다고 가정해 BGP(Border Gateway Protocol) 있습니다. 이 옵션을 사용하면 라우터에 bgp-igp-both-ribs LSP(Label-Switched-Path) ~ 10.10.10.1이 있는 경우 10.10.10.1에 대한 MPLS 경로가 inet.0 라우팅 테이블에서 활성화됩니다. 따라서 라우터가 10.10.10.1 경로를 다른 네트워크 라우터의 라우터에 BGP(Border Gateway Protocol) 방지합니다. 반면, 옵션 대신 옵션을 사용하는 mpls-forwardingbgp-igp-both-ribs 경우, 10.10.10.1/32 BGP(Border Gateway Protocol) 경로는 다른 BGP(Border Gateway Protocol) 스피커에게 광고를 전달하며, LSP는 여전히 트래픽을 10.10.10.1 목적지로 전달하는 데 사용됩니다.

LSP 메트릭을 LSAS 요약에 광고

LSP를 MPLS 구성하고 최단 경로 우선(OSPF) LSP를 취급하도록 구성할 수 있습니다. 이 구성을 통해 네트워크의 다른 라우터가 이 LSP를 사용할 수 있습니다. 이러한 목표를 달성하려면 LSP 메트릭을 요약 LSP MPLS 트래픽 엔지니어링을 최단 경로 우선(OSPF) 트래픽 엔지니어링을 구성해야 합니다.

MPLS, 및 traffic-engineering bgp-igplabel-switched-path 진술을 포함해야 합니다.

다음과 같은 계층 수준에 이러한 진술을 포함할 수 있습니다.

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

최단 경로 우선(OSPF), 다음 lsp-metric-into-summary 진술을 포함해야 합니다.

다음 계층 수준에 이 진술을 포함할 수 있습니다.

  • [edit protocols ospf traffic-engineering shortcuts]

  • [edit logical-systems logical-system-name protocols ospf traffic-engineering shortcuts]

트래픽 엔지니어링에 대한 최단 경로 우선(OSPF) 자세한 내용은 라우팅 디바이스 Junos OS 라우팅 프로토콜 라이브러리 를 참조하십시오.

Interarea 트래픽 엔지니어링 활성화

이 Junos OS 여러 영역에서 연속적인 트래픽 엔지니어링 LSP를 최단 경로 우선(OSPF) 수 있습니다. LSP 시그널링은 RFC 4206, LSP(Label-Switched Paths) GMPLS(Generalized Multi-Protocol Label Switching)트래픽 엔지니어링(트래픽 엔지니어링(TE)) 계층에서 설명한 바와 같이 네스티(nesting) 또는 연속 시그널링을 사용하여 수행되어야 합니다. 그러나 연속적인 시그널링 지원은 기본적인 시그널링에만 국한됩니다. 연속적인 시그널링으로 재구성은 지원되지 않습니다.

다음은 각기 다른 트래픽 엔지니어링 기능에 대해 설명하고 있습니다.

  • 경로 간 트래픽 엔지니어링은 INGRESS 라우터에서 ERO(Explicit Route Object) 계산에 대한 CSPF를 사용하여 ingress 라우터에서 느슨한 홉 영역 경계 라우터(ABRS)를 구성할 때 최단 경로 우선(OSPF) 수 있습니다. ERO 확장은 ABRS에서 완료됩니다.

  • CSPF를 활성화할 때 Interarea 트래픽 엔지니어링을 사용할 수 있지만, ingress 라우터의 LSP 구성에 지정된 ABRS가 없는 경우(ABRS는 자동으로 지정될 수 있습니다).

  • 클래스 유형 매핑이 여러 영역에 걸쳐 통일되는 한 DiffServ(Differentiated Services) 트래픽 엔지니어링이 지원됩니다.

Interarea 트래픽 엔지니어링을 활성화하려면 각 LSP 전송 라우터에 대한 구성 expand-loose-hop 진술을 포함합니다.

다음 계층 수준에 이 진술을 포함할 수 있습니다.

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

LSP를 위한 AS 간 트래픽 엔지니어링 활성화

일반적으로 다음과 같은 조건을 충족하는 LSP에서 트래픽 엔지니어링이 가능합니다.

  • LSP의 두 엔드 모두 동일한 최단 경로 우선(OSPF) 영역 또는 동일한 IS-IS(Intermediate System to Intermediate System) 영역입니다.

  • LSP의 두 엔드는 동일한 AS(autonomous system최단 경로 우선(OSPF) 내에 서로 다른 영역에 있습니다. 서로 다른 수준으로 끝나는 LSP는 IS-IS(Intermediate System to Intermediate System) 지원되지 않습니다.

  • 명시적 경로 LSP의 두 엔드는 서로 다른 최단 경로 우선(OSPF) ASS에 있으며 ASB(Autonomous System Border Router)는 explicit-path LSP에서 지원되는 loose hops로 정적으로 구성됩니다. 자세한 내용은 Explicit-Path LSP 구성을 참조하십시오.

LSP에서 정적으로 정의된 ASB가 없는 경우, 트래픽 엔지니어링이 라우팅 도메인 하나 또는 AS와 다른 도메인 간에 불가능합니다. 그러나 AS가 단일 서비스 제공업체를 제어하는 경우, 일부의 경우 트래픽 엔지니어링 LSP가 AS를 통해 연결되는 최단 경로 우선(OSPF) ASBRS를 동적으로 발견할 수 있습니다(IS-IS(Intermediate System to Intermediate System) 이 기능은 지원되지 않습니다).

특정 네트워크 요구 사항이 충족되는 한 AS 간 트래픽 엔지니어링 LSP가 가능하고 제한 조건이 적용되지 최단 경로 우선(OSPF) 패시브 모드가 EBGP로 구성됩니다. 세부 정보는 다음 섹션에서 제공됩니다.

AS 간 트래픽 엔지니어링 요구 사항

AS 간 트래픽 엔지니어링 LSP의 적절한 설정 및 기능은 다음과 같은 네트워크 요구 사항에 따라 달라지며, 이 모두를 충족해야 합니다.

  • 모든 AS는 단일 서비스 제공업체를 제어합니다.

  • 최단 경로 우선(OSPF) AS 내 라우팅 프로토콜로 사용하며, EBGP는 AS 간의 라우팅 프로토콜로 사용됩니다.

  • ASBR 정보는 각 AS 내부에서 이용할 수 있습니다.

  • EBGP 라우팅 정보는 각 AS 내에 최단 경로 우선(OSPF) IBGP 풀 메시가 있습니다.

  • 전송 LSP는 AS 간 링크에서 구성되지 않지만 각 AS에 있는 진입점과 종료 지점 ASBRS 사이에 구성됩니다.

  • 서로 다른 ASS의 ASB 간의 EBGP 링크는 직접 링크로, 각기 다른 AS에서 패시브 트래픽 엔지니어링 링크로 최단 경로 우선(OSPF). 루프백이나 다른 링크 주소가 아닌 원격 링크 주소 자체가 이 패시브 링크에 대한 원격 노드 식별자로 사용됩니다. 패시브 트래픽 엔지니어링 모드 최단 경로 우선(OSPF) 대한 자세한 내용은 를 수동 최단 경로 우선(OSPF) 모드 구성 트래픽 엔지니어링(TE) 모드 참조하십시오.

또한 패시브 트래픽 엔지니어링 링크의 원격 노드에 사용되는 최단 경로 우선(OSPF) EBGP 링크에 사용된 주소와 동일해야 합니다. 일반적으로 최단 경로 우선(OSPF) 및 BGP(Border Gateway Protocol) 자세한 내용은 라우팅 장비용 Junos OS 프로토콜 라이브러리 를 참조하십시오.

AS 간 트래픽 엔지니어링 제한

LSP 계층형 또는 중첩(nested) 신호 전송만 AS 트래픽 엔지니어링 LSP에서 지원됩니다. 점대점 LSP만 지원됩니다(Point-to-Multipoint 지원 없음).

또한 다음과 같은 제한 사항이 적용됩니다. 이러한 조건 중 하나라도 위의 요구 사항이 충족되는 경우에도 AS 간 트래픽 엔지니어링 LSP가 불가능하게 렌더링하기에 충분합니다.

  • 멀티 HOP BGP(Border Gateway Protocol) 지원되지 않습니다.

  • AS 내부에서 BGP(Border Gateway Protocol) 경로가 알려지지 않도록 하는 policers 또는 토폴로지의 사용은 지원되지 않습니다.

  • EBGP 피어 간의 LAN상에서 다수의 ASBRS는 지원되지 않습니다. EBGP 피어 간의 LAN상에서 오직 하나의 ASBR만 지원됩니다(다른 ASBRS는 LAN에 존재할 수 있지만 광고는 할 수 없습니다).

  • ASBR 정보를 숨기거나 ASBR 정보가 ASBR 내부에 배포되지 못하게 하는 루트 반영기 또는 정책은 지원되지 않습니다.

  • 양방향 LSP는 지원되지 않습니다(LSP는 트래픽 엔지니어링 관점에서 한방향입니다).

  • 동일 대상에 대한 AS 간 및 AS 내 경로에 대한 토폴로지는 지원되지 않습니다.

또한, 모든 LSP가 일상적인 몇 가지 기능은 AS 간 트래픽 엔지니어링과 함께 지원되지 않습니다.

  • 관리 그룹 링크 색상은 지원되지 않습니다.

  • 대기 대기는 지원되지 않습니다.

  • 재구성은 지원되지 않습니다.

  • 전송 라우터의 크랭크백은 지원되지 않습니다.

  • 다양한 경로 계산은 지원되지 않습니다.

  • Graceful Restart는 지원되지 않습니다.

AS 트래픽 엔지니어링 LSP와 함께 지원되지 않는 기능 또는 제한 사항의 목록은 철저하지 않습니다.

수동 최단 경로 우선(OSPF) 모드 구성 트래픽 엔지니어링(TE) 모드

또는 ASS와 같은 내부 라우팅 프로토콜은 최단 경로 우선(OSPF) 링크상에서 실행되지 않습니다. 그러나 AS 간 트래픽 엔지니어링이 올바르게 작동하려면, AS 간 링크, 특히 원격 인터페이스의 주소에 대한 정보를 AS 내부에서 사용할 수 있어야 합니다. 이 정보는 일반적으로 EBGP 도달 능력 메시지 또는 라우팅 광고에 최단 경로 우선(OSPF) 없습니다.

AS 내에서 이 링크 주소 정보를 플러드하고 트래픽 엔지니어링 계산에 사용할 수 있도록하려면 각 AS 인터페이스에서 트래픽 엔지니어링을 위한 최단 경로 우선(OSPF) 패시브 모드를 구성해야 합니다. 또한 트래픽 엔지니어링 데이터베이스에 배포하고 포함할 최단 경로 우선(OSPF) 원격 주소를 제공해야 합니다.

AS 인터페이스 최단 경로 우선(OSPF) 트래픽 엔지니어링을 위한 패시브 모드를 구성하려면, 계층 수준에서 링크에 대한 passive[edit protocols ospf area area-id interface interface-name] 명령문을 포함합니다.

최단 경로 우선(OSPF) 구성해야 합니다. 다음 예제는 AS 간 링크를 구성하여 AS 내에서 트래픽 엔지니어링 정보를 최단 경로 우선(OSPF) so-1/1/0 합니다. 원격 IP 주소는 192.168.207.2 입니다.

패킷 전달 구성 요소

Junos 트래픽 엔지니어링 아키텍처의 패킷 MPLS 구성 요소는 네트워크 전반에서 사전정의된 경로를 따라 IP 패킷 플로우를 지시하는 책임을 담당합니다. 이 경로를 LSP(Label-Switched Path)라고 합니다. LSP는 간단합니다. 즉, 트래픽은 헤드엔드(ingress) 라우터에서 tail-end(egress) 라우터로 한 방향으로 흐르고 있습니다. 양면 트래픽에는 2개의 LSP가 필요합니다. 하나의 LSP를 통해 각 방향으로 트래픽을 전달합니다. LSP는 하나 이상의 레이블 스위칭 홉을 연결하여 생성되므로 패킷을 네트워크 도메인 전체에서 하나의 라우터에서 다른 라우터로 MPLS 있습니다.

수신 라우터가 IP 패킷을 수신하면 패킷에 MPLS 헤더를 추가하고 LSP의 다음 라우터로 전달합니다. 레이블이 지정한 패킷은 각 라우터가 LSP, egress 라우터의 테일 엔드에 도달할 때까지 LSP를 따라 포상됩니다. 이 시점에서 MPLS 헤더가 제거되고 패킷은 IP 대상 주소와 같은 Layer 3 정보를 기반으로 전달됩니다. 이 체계의 가치는 LSP의 물리적 경로가 대상 IP 주소에 도달하기 위한 최단 경로로 IGP LSP가 선택하는 경로에만 국한되지 않는다는 것입니다.

Label Swapping 기반의 패킷 전달

각 라우터의 패킷 포우링 프로세스는 레이블 스왑 개념을 기반으로 합니다. 이 개념은 PVC(Permanent Virtual Circuit)에서 각 ATM(Asynchronous Transfer Mode) 스위치에서 발생하는 현상과 유사합니다. 각 MPLS 20비트 고정 길이 레이블 필드를 포함하는 4 바이트 캡슐화 헤더를 전달합니다. 레이블이 포함된 패킷이 라우터에 도착하면 라우터는 해당 Label을 검사하고 해당 패킷 MPLS 복사합니다. 포울링 테이블의 각 엔트리에는 동일한 인바운드 레이블이 있는 특정 인터페이스에 도착하는 모든 패킷에 적용되는 포울 정보 세트에 매핑된 인터페이스 인바운드 레이블 쌍이 포함되어 있습니다.

패킷이 네트워크 백본을 통과하는 MPLS 방법

이 섹션에서는 IP 패킷이 네트워크 백본 네트워크를 통과할 때 IP 패킷을 어떻게 MPLS 설명합니다.

IP MPLS 엔트리 에지에서 IP 헤더를 ingress 라우터에서 검사합니다. 이러한 분석에 따라 패킷은 분류되어 Label에 할당되어 MPLS 헤더에 캡슐화한 다음, LSP 내 다음 홉으로 전달됩니다. MPLS IP 패킷을 LSP에 할당할 수 있는 방식으로 높은 수준의 유연성을 제공합니다. 예를 들어, Junos 트래픽 엔지니어링 구현에서는 동일한 egress 라우터에서 MPLS 도메인에서 나가는 수신 라우터에 도착하는 모든 패킷이 동일한 LSP를 따라 전달됩니다.

패킷이 LSP를 통과하기 시작하면 각 라우터는 이 레이블을 사용하여 포링 결정을 내릴 수 있습니다. MPLS 결정은 원래 IP 헤더와 독립적으로 결정됩니다. 수신 인터페이스와 레이블은 네트워크 포워더 테이블의 룩업 MPLS 사용됩니다. 오래된 레이블이 새 Label으로 대체되어 패킷이 LSP를 따라 다음 홉으로 전달됩니다. 이 프로세스는 패킷이 egress 라우터에 도달할 때까지 LSP의 각 라우터에서 반복됩니다.

패킷이 egress 라우터에 도착하면 레이블이 제거되고 패킷이 MPLS 도메인으로 나아갈 수 있습니다. 그런 다음 IP 라우팅 프로토콜에서 계산한 기존 최단 경로에 따라 패킷의 원래 IP 헤더에 포함된 대상 IP 주소를 기반으로 패킷이 전달됩니다.

정보 배포 구성 요소

트래픽 엔지니어링은 네트워크 토폴로지와 네트워크 로딩에 대한 동적 정보를 필요로 합니다. 정보 배포 구성 요소를 구현하기 위해 IGP에 대한 단순한 확장이 정의됩니다. 링크 속성은 각 라우터의 링크 상태 알림에 포함되어 있습니다. IS-IS(Intermediate System to Intermediate System) 확장에는 새로운 TLV(Type Length Values)의 정의가 포함되는 반면, 최단 경로 우선(OSPF) 확장은 OAS(opaque Link-State Advertisement)를 통해 구현됩니다. 링크 상태 IGP가 사용하는 표준 플러링 알고리즘은 링크 속성이 라우팅 도메인의 모든 라우터에 분산되도록 보장합니다. 링크 상태 알림에 추가될 트래픽 엔지니어링 확장 중 일부는 최대 IGP 대역폭, 최대 예약 링크 대역폭, 현재 대역폭 예약, 링크 컬러링을 포함합니다.

각 라우터는 특수 트래픽 엔지니어링 데이터베이스에서 네트워크 링크 속성 및 토폴로지 정보를 유지 관리합니다. 트래픽 엔지니어링 데이터베이스는 물리적 토폴로지에서 LSP를 배치하기 위한 명시적 경로를 계산하는 데만 사용됩니다. 후속 트래픽 엔지니어링 컴퓨팅은 네트워크 및 링크 상태 데이터베이스와 IGP IGP 데이터베이스가 유지 관리됩니다. 한편, IGP 변경 없이 계속 작동하여 라우터의 링크 상태 데이터베이스에 포함된 정보를 기반으로 기존 최단 경로 계산을 실행합니다.

경로 선택 구성 요소

네트워크 링크 속성 및 토폴로지 정보가 네트워크 IGP 플러드된 후 트래픽 엔지니어링 데이터베이스에 배치된 후, 각 ingress 라우터는 트래픽 엔지니어링 데이터베이스를 사용하여 라우팅 도메인 전반의 자체 LSP 세트에 대한 경로를 계산합니다. 각 LSP에 대한 경로는 엄격한 또는 느슨한 명시적 경로로 표현될 수 있습니다. 명시적 경로는 LSP의 물리적 경로에 참여해야 하는 사전 구성된 라우터 시퀀스입니다. ingress 라우터가 LSP의 모든 라우터를 지정하면 LSP는 엄격한 명시적 경로로 식별됩니다. ingress 라우터가 LSP의 일부 라우터만 지정하는 경우, LSP는 느슨한 명시적 경로로 설명됩니다. 엄격하고 느슨한 명시적 경로를 지원하기 때문에 가능할 때마다 경로 선택 프로세스가 광범위하게 제공되지만 필요한 경우에는 제약을 받습니다.

ingress 라우터는 트래픽 엔지니어링 데이터베이스의 정보에 CSPF(Constrained Shortest Path First) 알고리즘을 적용하여 각 LSP에 대한 물리적 경로를 확인합니다. CSPF는 네트워크 전반에서 최단 경로가 계산될 때 특정 제한 사항을 고려하여 수정된 최단 경로 우선 알고리즘입니다. CSPF 알고리즘에 대한 입력은 다음과 같습니다.

  • 네트워크에서 학습하여 트래픽 엔지니어링 데이터베이스에 IGP 토폴로지 링크 상태 정보

  • 네트워크 리소스의 상태(총 링크 대역폭, 예약된 링크 대역폭, 가용 링크 대역폭, 링크 색상)와 관련된 속성IGP 확장을 통해 수행되고 트래픽 엔지니어링 데이터베이스에 저장되는 속성

  • 사용자 구성에서 얻은 제안된 LSP를 통해 전달되는 트래픽(예: 대역폭 요구 사항, 최대 홉 카운트 및 관리 정책 요구 사항)을 지원하는 데 필요한 관리 속성

CSPF가 각 후보 노드와 새 LSP 링크를 고려할 때, 리소스 가용성에 따라 특정 경로 구성 요소를 허용 또는 거부하거나 구성 요소를 선택하는 것이 사용자 정책 제약 조건을 위반하는지 여부를 선택합니다. CSPF 계산의 출력은 제약 조건을 충족하는 네트워크에서 최단 경로를 제공하는 일련의 라우터 주소로 구성된 명시적 경로입니다. 이러한 명시적 루트는 LSP를 따라 라우터에서 포링 상태를 설정하는 시그널링 컴포넌트로 전달됩니다.

시그널링 구성 요소

LSP는 시그널링 컴포넌트에 의해 실제로 설정될 때까지는 작동할 수 있는 것으로 알려져 있지 않습니다. LSP 상태 설정 및 레이블 배포를 담당하는 시그널링 컴포넌트는 RSVP에 대한 많은 확장에 의존합니다.

  • Explicit Route 객체는 RSVP 경로 메시지가 전통적인 최단 경로 IP 라우팅과 독립적인 라우터의 명시적인 시퀀스를 전달할 수 있습니다. 명시적 경로는 엄격하거나 느슨할 수 있습니다.

  • Label Request 객체는 RSVP 경로 메시지를 허용하여 중간 라우터가 설정 중 LSP에 대한 레이블 바인딩을 제공하게 요청합니다.

  • Label 객체는 RSVP가 기존 메커니즘을 변경하지 않고도 레이블 배포를 지원할 수 있습니다. RSVP Resv 메시지는 RSVP 경로 메시지의 역방향 경로를 따라가기 때문에 Label 객체는 다운스트림 노드에서 업스트림 노드로 레이블 배포를 지원합니다.

오프라인 경로 계획 및 분석

온라인 경로 계산으로 인한 관리 작업 감소에도 불구하고 트래픽 엔지니어링을 전 세계적으로 최적화하기 위해서는 오프라인 계획 및 분석 도구가 필요합니다. 온라인 계산은 리소스 제약 조건을 고려하여 한 때 하나의 LSP를 계산합니다. 이러한 접근 방식의 과제는 그다지 까다로우며, LSP를 계산하는 순서는 네트워크 전반에서 각 LSP의 물리적 경로를 결정하는 데 중요한 역할을 합니다. 프로세스 초기에 계산된 LSP는 이전 계산된 LSP가 네트워크 리소스를 사용했기 때문에 프로세스 후반에서 계산된 LSP보다 더 많은 가용 리소스를 가용하고 있습니다. LSP가 계산되는 순서가 변경된 경우, LSP에 대한 물리적 경로 세트도 변경할 수 있습니다.

오프라인 계획 및 분석 도구는 각 링크의 리소스 제약 조건과 각 LSP의 요구 사항을 동시에 검사합니다. 오프라인 접근 방식은 완료하는 데 몇 시간이 걸릴 수 있습니다. 하지만 글로벌 계산을 수행하고 각 계산의 결과를 비교한 다음 전체적으로 네트워크에 가장 적합한 솔루션을 선택합니다. 오프라인 계산의 출력은 네트워크 리소스의 활용을 최적화하는 LSP 집합입니다. 오프라인 계산이 완료되면 전역적으로 최적화된 솔루션에 대한 규칙에 따라 각각이 설치되어 있기 때문에 어떤 순서로든 LSP를 설정할 수 있습니다.

유연한 LSP 계산 및 구성

트래픽 엔지니어링에는 물리적 토폴로지로 트래픽 플로우를 매핑하는 과정이 수반됩니다. 제약 기반 라우팅을 사용하여 온라인으로 경로를 결정할 수 있습니다. 물리적 경로를 계산하는 방법에 관계없이 포워더 상태는 RSVP를 통해 네트워크 전반에 설치됩니다.

이 Junos OS LSP의 라우팅 및 구성 방법을 다음과 같은 방식으로 지원합니다.

  • LSP를 오프라인으로 전환하기 위한 전체 경로를 계산하고 필요한 정적 포우링 상태를 사용하여 LSP 내 각 라우터를 개별적으로 구성할 수 있습니다. 이는 일부 ISP(Internet Service Providers)가 IP-over-ATM 코어를 구성하는 방식과 유사합니다.

  • LSP의 전체 경로를 오프라인으로 계산하고 전체 경로로 ingress 라우터를 정적으로 구성할 수 있습니다. 그런 다음 수신 라우터는 RSVP를 동적 시그널링 프로토콜로 사용하여 LSP를 따라 각 라우터에 포우링 상태를 설치합니다.

  • 제약 기반 라우팅을 사용하여 동적 온라인 LSP 계산을 수행할 수 있습니다. 각 LSP에 대한 제약 조건을 구성합니다. 네트워크 자체가 이러한 제약 조건을 가장 잘 충족하는 경로를 결정하게 됩니다. 특히, 수신 라우터는 제약 조건에 따라 전체 LSP를 계산한 다음 네트워크 전반에서 시그널링을 시작됩니다.

  • LSP의 부분 경로를 계산하고 경로에 있는 라우터의 하위 세트로 ingress 라우터를 정적으로 구성할 수 있습니다. 를 사용하면 온라인 계산을 허용하여 전체 경로를 결정할 수 있습니다.

    예를 들어, 미국 전역에 걸쳐 2개의 East-West 경로를 포함하는 토폴로지가 있습니다. 남쪽으로는 시카고를 통과하는 것으로 나타남. 댈러스를 통과하는 남쪽에 있습니다. 뉴욕의 라우터와 샌프란시스코에 있는 라우터 간에 LSP를 구축하려는 경우 LSP에 대한 부분 경로를 구성하여 댈러스의 단일 느슨한 라우터 홉을 포함할 수 있습니다. 그 결과, 남측 경로를 따라 LSP가 라우팅됩니다. ingress 라우터는 CSPF를 사용하여 전체 경로를 계산하고 RSVP를 통해 LSP를 따라 포우링 상태를 설치합니다.

  • 어떤 제약 조건도 없는 ingress 라우터를 구성할 수 있습니다. 이 경우, LSP IGP 최단 경로 라우팅을 사용하는 데 사용됩니다. 이 구성은 트래픽 엔지니어링 측면에서 어떠한 가치도 제공하지 않습니다. 그러나 VPN(Virtual Private Networks)과 같은 서비스가 필요한 경우 쉽고 유용할 수 있습니다.

이러한 모든 경우, 기본 LSP에 대한 백업으로 원하는 수의 LSP를 지정하여 하나 이상의 구성 접근 방식을 결합할 수 있습니다. 예를 들어, 주 경로를 오프라인으로 명시적으로 계산하고 보조 경로를 제약 기반으로 설정한 다음, 3차 경로가 제약되지 않을 수 있습니다. 기본 LSP가 라우팅되는 회로에 장애가 발생하면 수신 라우터는 다운스트림 라우터에서 수신되는 오류 통보 또는 RSVP 소프트 스테이트(soft-state) 정보 만료에 따라 정전을 알 수 있습니다. 그런 다음, 라우터는 핫 스바이 LSP로 동적으로 트래픽을 포워드하거나 RSVP를 호출하여 새로운 백업 LSP를 위한 포워더 상태를 생성합니다.

BGP(Border Gateway Protocol) Classful Transport Plane 개요

클래스 BGP(Border Gateway Protocol) 플레인의 이점

  • 네트워크-Slicing– 서비스 및 전송 레이어가 서로 분리되어 여러 도메인에 걸쳐 엔드-to-엔드 Slicing을 통해 네트워크 Slicing과 가상화를 위한 기반을 마련함으로써 CAPEX를 크게 절감할 수 있습니다.

  • 도메인 간 상호 운용성– 각 도메인에 있는 서로 다른 전송 시그널링 프로토콜이 상호 운용할 수 있도록 공동 운영 도메인 전반에서 전송 클래스 구축을 확장합니다. 각 도메인에서 사용할 수 있는 확장 커뮤니티 네임스페이스 간의 차이점을 확인
  • 폴백을통해 색상 확인 – best-effort 터널 또는 기타 컬러 터널을 통해 유연한 폴백 IS-IS(Intermediate System to Intermediate System) 컬러 터널(RSVP, 유연한 알고리즘)을 통해 해결.

  • 서비스 품질– 네트워크를 맞춤화하고 최적화하여 엔드-to-엔드 SLA 요구 사항을 충족합니다.
  • 기존 구축활용 – 유연한 알고리즘과 같은 새로운 프로토콜과 함께 RSVP와 같은 잘 구축된 터널링 프로토콜을 IS-IS(Intermediate System to Intermediate System), ROI 보존 및 OPEX 절감

클래스 BGP(Border Gateway Protocol) 플레인의 용어

이 섹션에서는 클래스식 전송 플레인을 이해하기 위해 일반적으로 BGP(Border Gateway Protocol) 용어를 요약합니다.

  • 서비스 노드– 서비스 경로(인터넷 및 레이어 3 VPN)를 송수신하는 PE(Ingress Provider Edge) 디바이스.

  • 경계 노드– 여러 도메인의 연결 지점에 있는 디바이스(IGP 영역 또는 AS)

  • 전송 노드– LU(Labeled Unicast) BGP(Border Gateway Protocol) 전송 및 수신하는 장비

  • BGP(Border Gateway Protocol)-VPN– RFC4364 메커니즘을 사용하여 구축된 VPN

  • RT(Route Target)– VPN 멤버십 정의에 사용되는 확장 커뮤니티 유형

  • RD(Route Distinguisher)– 루트가 속한 VPN 또는 VPLS(Virtual Private LAN Service)를 구분하는 데 사용됩니다. 각 라우팅 인스턴스는 연관된 고유의 경로 구분자(route distinguisher)를 가지고 있어야 합니다.

  • 문제 해결 체계– 폴백을 제공하는 해결 RIB에서 PNH(Protocol Next-Hop Address)를 해결하는 데 사용됩니다.

    매핑 커뮤니티를 기반으로 시스템에서 여러 전송 RIB로 경로를 매핑합니다.

  • 서비스 패밀리– BGP(Border Gateway Protocol) 터널이 아니라 데이터 트래픽에 대한 경로 광고에 사용되는 주소 가족입니다.

  • 전송 패밀리 –BGP(Border Gateway Protocol) 어드버타이즈 터널에 사용되어 해결을 위한 서비스 경로에 의해 사용됩니다.

  • 전송 터널– 서비스가 트래픽(예: GRE, UDP, LDP, RSVP, SR-트래픽 엔지니어링(TE), BGP(Border Gateway Protocol)-LU)을 거치는 터널입니다.

  • 터널 도메인– 터널링이 있는 단일 관리 제어 하의 서비스 노드 및 경계 노드가 포함된 네트워크의 도메인입니다. 여러 인접 터널 도메인에 걸쳐 있는 엔드 투 엔드 터널은 레이블을 사용하여 노드를 서로 연계하여 만들 수 있습니다.

  • 전송 클래스– 동일한 서비스를 제공하는 전송 터널 서비스 유형.

  • 전송 클래스 RT– 특정 전송 클래스를 식별하는 데 사용되는 새로운 형식의 루트 대상입니다.

    특정 전송 클래스를 식별하는 데 사용되는 새로운 형식의 Route Target
  • 전송 RIB– 서비스 노드 및 경계 노드에서 전송 클래스에는 터널 경로를 보유한 ASOC(Associted Transport) RIB가 있습니다.

  • 전송 RTI– 라우팅 인스턴스, 컨테이너의 전송 RIB, 관련 전송 클래스 Route Target 및 Route Distinguisher가 있습니다.

  • 전송 플레인– 동일한 전송 클래스 RT를 가져오는 전송 RTIS 세트. 이들은 경계 노드(nexthop-self)에서 레이블을 교체하기 위한 Inter-AS option-b와 유사한 메커니즘을 사용하여 터널 도메인 경계를 넘어 터널 도메인 경계로 스티치되어 엔드투엔드 전송 플레인을 형성합니다.

  • 커뮤니티 매핑– 전송 클래스를 통해 해결을 매핑하는 서비스 경로에 커뮤니티.

클래스 BGP(Border Gateway Protocol) 플레인 이해

클래스 BGP(Border Gateway Protocol) 플레인을 사용하여 트래픽 엔지니어링 특성에 따라 AS 네트워크 내 전송 터널 집합을 분류하기 위한 전송 클래스를 구성하고 이러한 전송 터널을 사용하여 원하는 SLA 및 의도한 폴백을 기준으로 서비스 경로를 매핑할 수 있습니다.

BGP(Border Gateway Protocol) 클래스형 전송 플레인은 이러한 터널을 여러 도메인(AS 또는 IGP 영역)을 아우르는 도메인 간 네트워크로 확장하는 동시에 전송 클래스를 보존할 수 있습니다. 이를 위해 경계 노드와 서비스 노드 BGP(Border Gateway Protocol) 클래스 BGP(Border Gateway Protocol) 계층을 구성해야 합니다.

AS 간 및 AS 간 구현 모두에서 서비스 및 경계 노드에서 생성된 많은 전송 터널(MPLS LSP, IS-IS(Intermediate System to Intermediate System) 유연한 알고리즘, SR-트래픽 엔지니어링(TE))이 생성될 수 있습니다. LSP는 서로 다른 도메인에 있는 서로 다른 시그널링 프로토콜을 사용하여 시그널링될 수 있으며, 서로 다른 트래픽 엔지니어링 특성(클래스 또는 색상)으로 구성될 수 있습니다. 전송 터널 엔드포인트는 서비스 엔드포인트의 역할을 할 수 있으며 서비스 ingress 노드와 동일한 터널 도메인 또는 인접 또는 비 인접 도메인에 존재할 수 있습니다. 클래스 BGP(Border Gateway Protocol) 플레인을 사용하여 단일 도메인 내부 또는 여러 도메인에 걸쳐 특정 트래픽 엔지니어링 기술에 대해 LSP를 통해 서비스를 재구성할 수 있습니다.

BGP(Border Gateway Protocol) 클래스형 전송 플레인은 BGP(Border Gateway Protocol)-VPN 기술을 재사용하여 터널링 도메인을 느슨하게 결합하고 조정합니다.

  • NLRI(Network Layer Reachability Information)는 경로 숨기기에 사용되는 RD:TunnelEndpoint입니다.
  • 경로 대상은 LSP의 전송 클래스를 나타내며 대상 디바이스에서 해당 전송 RIB로 경로를 누설합니다.
  • 모든 전송 터널링 프로토콜은 transport-class.inet.3 라우팅 테이블에 ingress 경로를 설치하고, 터널 전송 클래스를 VPN 경로 대상으로 모델하고, transport-class.inet.3 transport-rib 라우팅 테이블에서 동일한 전송 클래스의 LSP를 수집합니다.
  • 이 라우팅 인스턴스의 경로는 RFC-4364와 유사한 BGP(Border Gateway Protocol) 클래스 기반 전송 플레인(inet transport) AFI-SAFI 다음 절차에 광고됩니다.

  • AS 간 링크 경계를 횡단할 때, 이러한 인접 도메인에서 전송 터널을 스티치하려면 Option-b 절차를 따라야 합니다.

    마찬가지로 AS 영역 간을 교차할 때 다른 도메인 내 전송 터널을 스티치하기 위한 Option-b 절차를 따라야 트래픽 엔지니어링(TE) 합니다.

  • 해결 체계를 정의하여 폴백 순서로 다양한 전송 클래스에 대한 의도를 지정할 수 있습니다.

  • 서비스 경로를 해결하고 해당 전송 클래스를 BGP(Border Gateway Protocol) 대해 매핑 커뮤니티를 캐러링하여 클래스 풀(classful) 전송 경로를 해결할 수 있습니다.

이 BGP(Border Gateway Protocol) 클래스식 전송 패밀리는 BGP(Border Gateway Protocol)-LU 전송 레이어 패밀리와 함께 실행됩니다. BGP(Border Gateway Protocol)-LU를 실행하는 원활한 네트워크에서, 엄격한 5G SLA 요구 사항을 충족하는 것은 터널의 트래픽 엔지니어링 특성이 도메인 경계 전반에서 알려지거나 보존되지 못하기 때문에 도전 과제가 되었습니다. MPLS BGP(Border Gateway Protocol) 클래스형 전송 플레인은 원활한 네트워크 아키텍처에서 전송 클래스 정보와 함께 원격 루프백에 여러 경로를 광고하기 위한 간편하고 확장 가능한 수단을 MPLS 제공합니다. 클래스 BGP(Border Gateway Protocol) 경로에서 여러 SLA 경로는 전송 클래스 색상을 전송하는 Transport Route-Target 확장 커뮤니티를 사용하여 표현됩니다. 이 전송 경로-목표(Transport Route-Target)는 수신 BGP(Border Gateway Protocol) 라우터에서 BGP(Border Gateway Protocol) 클래스에 연결합니다. 동일한 클래스 BGP(Border Gateway Protocol) 경로를 재광고하면 MPLS 경로를 교체하고, 동일한 전송 클래스의 AS 내 터널을 상호 연결하기 때문에 전송 클래스를 보존하는 엔드 투 엔드 터널을 형성할 수 있습니다.

AS 내(Intra-AS) BGP(Border Gateway Protocol) Classful Transport Plane 구현

그림 4 AS 도메인 내 클래스형 전송 플레인을 구현하는 전후 시나리오를 BGP(Border Gateway Protocol) 네트워크 토폴로지에 대해 설명합니다. 디바이스 PE11 및 PE12는 전송 터널로 RSVP LSP를 사용하며 모든 전송 터널 경로가 inet.3 RIB에 설치됩니다. 클래스 BGP(Border Gateway Protocol) 플레인을 구현하면 RSVP 전송 터널이 세그먼트 라우팅 터널과 유사한 색상으로 인식될 수 있습니다.

그림 4: AS 도메인 내: Classful Transport Plane 구현을 위한 BGP(Border Gateway Protocol) 전후 시나리오 AS 도메인 내: Classful Transport Plane 구현을 위한 BGP(Border Gateway Protocol) 전후 시나리오 AS 도메인 내: Classful Transport Plane 구현을 위한 BGP(Border Gateway Protocol) 전후 시나리오

AS 내 설정에서 전송 터널을 BGP(Border Gateway Protocol) 전송 클래스로 분류하려면 다음을 제공합니다.

  1. 예를 들어, 서비스 노드(ingress PE 디바이스)에서 전송 클래스를 정의하고 정의된 전송 클래스에 컬러 커뮤니티 값을 할당합니다.

    샘플 구성:

  2. 전송 터널을 터널의 ingress 노드에서 특정 전송 클래스에 연결합니다.

    샘플 구성:

AS 내 BGP(Border Gateway Protocol) 전송 플레인 기능:

  • BGP(Border Gateway Protocol) 클래스 전송은 지정 전송 클래스(골드 및 브론즈)에 따라 미리 정의된 전송 RIB를 생성하고 매핑 커뮤니티를 색상 값(100 및 200)에서 자동 추출합니다.
  • AS 내 전송 경로는 전송 클래스와 연관된 터널링 프로토콜에 따라 전송 RIB에 채워 습니다.

    이 예에서는 전송 클래스 골드(컬러 100) 및 전송 클래스 브론즈(컬러 200)와 연관된 RSVP LSP 경로가 전송 RIB에 각각 junos-rti-tc-< >.inet.3junos-rti-tc-<200>.inet.3에설치됩니다.

  • 서비스 노드(ingress PES)는 사전 정의한 해결 RIB의 매핑 커뮤니티와 서비스 라우트의 확장된 색 커뮤니티(컬러:0:0:0:200)를 일치하고 해당 전송 RIB(junos-rti-tc-<100>.inet.3에서 PNH(Protocol Next Hop)를 해결합니다. 또는 junos-rti-tc-<200>.inet.3).
  • BGP(Border Gateway Protocol) 매핑 커뮤니티를 수행하여 해결 체계에 연계할 수 있습니다.
  • 각 전송 클래스는 자동으로 2개의 사전 정의된 해결 체계를 생성하고 매핑 커뮤니티를 자동으로 파생합니다.

    한 가지 해결 체계는 Color:0:0:<val> 매핑 커뮤니티로 사용하는 서비스 경로를 해결하기 위한 것입니다.

    다른 해결 체계는 Transport-Target:0:0:<> 매핑 커뮤니티로 사용하는 전송 경로를 해결하기 위한 것입니다.

  • 사전 정의한 해결 체계에 나열된 RIB를 사용하여 서비스 경로 PNH를 해결할 수 없는 경우 inet.3 라우팅 테이블로 폴백할 수 있습니다.
  • 또한 구성 계층에서 사용자 정의 문제 해결 체계를 사용하여 서로 다른 컬러 전송 RIB 간 폴백을 구성할 [edit routing-options resolution scheme] 수도 있습니다.

AS 간 BGP(Border Gateway Protocol) Classful Transport Plane 구현

AS 간 네트워크에서 BGP(Border Gateway Protocol)-LU는 모든 서비스 노드BGP(Border Gateway Protocol) PE 디바이스 및 경계 노드(ABRS 및 ASBRs)에서 최소 2개의 전송 클래스(골드 및 브론즈)를 구성한 후 클래스급 전송 네트워크로 변환됩니다.

전송 터널을 클래스 BGP(Border Gateway Protocol) 변환하는 경우:

  1. 서비스 노드(ingress PE Devices)와 경계 노드(ABRS 및 ASBRs)에서 전송 클래스를 정의합니다. 예를 들어 골드 및 브로즈와 같은 경우를 정의합니다.

    샘플 구성:

  2. 전송 터널을 터널의 ingress 노드(ingress PES, ABRS, ASBRS)에서 특정 전송 클래스에 연결합니다.

    샘플 구성:

    RSVP LSP용

    플렉시블 IS-IS(Intermediate System to Intermediate System) 위한

  3. 네트워크에서 BGP(Border Gateway Protocol) 클래스 전송(inet transport) 및 BGP(Border Gateway Protocol)-LU(inet labeled-unicast)를 위한 새로운 패밀리를 활성화합니다.

    샘플 구성:

  4. 적절한 확장된 색상 커뮤니티로 egress PE 디바이스에서 서비스 경로를 광고합니다.

    샘플 구성:

AS 간 BGP(Border Gateway Protocol) 동급의 전송 플레인 기능:

  1. BGP(Border Gateway Protocol) 클래스형 전송 플레인은 지정 전송 클래스(골드 및 브론즈)에 따라 미리 정의된 전송 RIB를 생성하고 매핑 커뮤니티를 색상 값에서 자동으로 추출합니다.
  2. AS 내 전송 경로는 전송 클래스와 관련된 프로토콜을 터널링하여 전송 RIB에 채워 습니다.

    예를 들어, 전송 클래스 골드 및 브론즈와 연관된 전송 터널 경로는 각각 전송 RIB junos-rti-tc-<100>.inet.3과junos-rti-tc-<>.inet.3에설치됩니다.

  3. BGP(Border Gateway Protocol) 클래스별 전송 플레인은 각 전송 RIB에서 bgp.transport.3 라우팅 테이블로 전송 터널 경로를 복사할 때 고유한 Route Distinguisher 및 Route Target를 사용하게 됩니다.
  4. bgp.transport.3 라우팅 테이블에서 다른 도메인의 피어로 경로를 광고하는 경계 노드는 BGP(Border Gateway Protocol) 세션에서 패밀리 이더리안 전송을 협상합니다.
  5. 수신 경계 노드는 bgp.transport.3 라우팅 테이블에 이러한 bgp-ct 경로를 설치하고 전송 경로 대상을 적절한 전송 RIB로 복사합니다.
  6. 서비스 노드는 서비스 경로의 색상 커뮤니티와 매핑 커뮤니티를 비교하여 해당 전송 RIB(junos-rti-tc-<100>.inet.3또는 junos-rti-tc-<200>.inet.3)에서PNH를 해결합니다.
  7. 경계 노드는 전송 경로 PNH 해결을 위해 사전 정의한 해결 체계를 사용합니다.
  8. 사전 정의되거나 사용자가 정의한 두 가지 해결 체계는 서비스 경로 PNH 해결을 모두 지원합니다. 사전 정의된 inet.3을 폴백으로 활용하고 사용자 정의 해결 체계를 사용하면 PNH를 해결하면서 지정된 순서로 전송 RIB 목록을 사용할 수 있습니다.
  9. 사용자 정의 문제 해결 체계에 나열된 RIB를 사용하여 서비스 경로 PNH를 해결할 수 없는 경우 라우트는 폐기됩니다.

RSVP Patherr 메시지를 통해 트래픽 엔지니어링 데이터베이스 정확성 향상

RSVP 기반 트래픽 엔지니어링의 필수적인 요소는 트래픽 엔지니어링 데이터베이스입니다. 트래픽 엔지니어링 데이터베이스에는 트래픽 엔지니어링에 참여하는 모든 네트워크 노드 및 링크의 전체 목록과 해당 링크가 보유할 수 있는 속성 집합이 포함되어 있습니다. (트래픽 엔지니어링 데이터베이스에 대한 자세한 정보는 Constrained-Path LSP Computation 을 참조하십시오.) 가장 중요한 링크 속성 중 하나는 대역폭입니다.

RSVP LSP가 설정 및 종료되면 링크의 대역폭 가용성이 빠르게 변경됩니다. 트래픽 엔지니어링 데이터베이스가 실제 네트워크와 비일관성으로 발전할 가능성이 있습니다. 이러한 비일관성은 업데이트 속도의 증가로 IGP 수 없습니다.

링크 가용성은 동일한 비일관성 문제를 공유할 수 있습니다. 사용할 수 없는 링크는 기존의 모든 RSVP LSP를 중단할 수 있습니다. 그러나 네트워크에서 이러한 기능을 사용할 수 없는 경우를 쉽게 알 수 없습니다.

명령문을 구성하면, 소스 rsvp-error-hold-time 노드(RSVP LSP의 수신)는 다운스트림 노드에서 전송되는 PathErr 메시지를 모니터링하여 LSP 장애를 학습합니다. PathErr 메시지의 정보는 후속 LSP 연산에 통합됩니다. 이는 LSP 설정의 정확성과 속도를 향상시킬 수 있습니다. 일부 PathErr 메시지는 트래픽 엔지니어링 데이터베이스 대역폭 정보를 업데이트하는 데 사용되어 트래픽 엔지니어링 데이터베이스와 네트워크 간의 비일관성 감소를 제공합니다.

명령문을 사용하여 업데이트 빈도를 IGP 수 update-threshold 있습니다. 인터페이스에서 RSVP 업데이트 임계값 구성을 참조합니다.

이 섹션에서는 다음 주제에 대해 설명합니다.

Patherr 메시지

PathErr 메시지는 서로 다른 코드 및 서브코드 번호를 통해 다양한 문제를 보고합니다. 이러한 PathErr 메시지의 전체 목록을 RFC 2205, RSVP(Resource Reservation Protocol), 버전 1, 기능 사양 및 RFC 3209, RSVP-트래픽 엔지니어링(TE): LSP 터널에 대한 RSVP 확장.

명령문을 구성할 때 링크 장애를 나타내는 두 범주의 PathErr 메시지에 대해 rsvp-error-hold-time 조사합니다.

  • 이 LSP에는 링크 대역폭이 낮습니다. 요청된 대역폭 비가시성—코드 1, 서브코드 2

    이 유형의 PathErr 메시지는 링크를 전송하는 모든 LSP에 영향을 주는 전 세계적인 문제를 대표합니다. 실제 링크 대역폭은 LSP에서 요구하는 대역폭보다 낮을 수 있으며, 트래픽 엔지니어링 데이터베이스의 대역폭 정보가 과도할 것으로 나타났습니다.

    이러한 유형의 오류가 수신될 때, 로컬 트래픽 엔지니어링 데이터베이스에서 가용 링크 대역폭이 줄어어 향후 LSP 계산에 영향을 미치게 됩니다.

  • 이 LSP에 대한 링크 사용 불가:

    • Admission Control 실패—코드 1, 하위 코드 2를 제외한 모든 코드

    • 정책 제어 실패—코드 2

    • 서비스 사전 준비—코드 12

    • 라우팅 문제—목적지로 가용 경로가 없음—코드 24, 서브코드 5

    이러한 유형의 PathErr 메시지는 일반적으로 지정된 LSP에 해당됩니다. 이 LSP 장애가 반드시 다른 LSP에 장애가 발생했다는 의미는 아닐 수 있습니다. 이러한 오류는 최대 전송 장치(최대 전송 단위(MTU)) 문제, 서비스 예비(운영자가 수동으로 시작하거나 우선 순위가 높은 다른 LSP에 의해 수동으로 시작), 넥 홉 링크의 다운, 또는 정책 고려 사항으로 인하여 서비스 거부를 나타낼 수 있습니다. 이 특정 LSP를 링크에서 라우팅하는 것이 가장 좋습니다.

문제 식별 링크

각 PathErr 메시지에는 발신자 IP 주소가 포함되어 있습니다. 이 정보는 ingress 라우터로 전파되지 않습니다. 트래픽 엔지니어링 데이터베이스의 룩업은 PathErr 메시지에서 시작된 노드를 식별할 수 있습니다.

각 PathErr 메시지는 메시지를 트리거한 RSVP 세션을 식별할 수 있는 충분한 정보를 전달합니다. 전송 라우터인 경우 메시지를 전달하기만 합니다. 이 라우터가 ingress 라우터(이 RSVP 세션용)인 경우, 전체 노드 목록이 있으며 세션을 통해 전달해야 하는 링크가 있습니다. 시작 노드 정보와 결합되면 링크를 고유하게 식별할 수 있습니다.

트래픽 엔지니어링 데이터베이스 정확성을 향상시키는 라우터 구성

트래픽 엔지니어링 데이터베이스의 정확성을 향상하려면 명령문을 rsvp-error-hold-time 구성합니다. 이 명령문이 구성된 경우, 소스 노드(RSVP LSP의 수신)는 다운스트림 노드에서 전송되는 PathErr 메시지를 모니터링하여 LSP 장애를 학습합니다. PathErr 메시지의 정보는 후속 LSP 연산에 통합됩니다. 이는 LSP 설정의 정확성과 속도를 향상시킬 수 있습니다. 일부 PathErr 메시지는 트래픽 엔지니어링 데이터베이스 대역폭 정보를 업데이트하는 데 사용되어 트래픽 엔지니어링 데이터베이스와 네트워크 간의 비일관성 감소를 제공합니다.

RSVP PathErr MPLS 메시지를 기억하고 CSPF 계산에 고려해야 하는 기간을 구성하고 진술을 rsvp-error-hold-time 포함하십시오.

다음 계층 수준에 이 진술을 포함할 수 있습니다.

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

시간은 1초에서 240초까지 가치가 있을 수 있습니다. 기본 설정은 25초입니다. 0 값을 구성하면 PathErr 메시지 모니터링이 비활성화됩니다.

출시 내역 표
릴리스
설명
20.4R1
Release Junos OS 릴리스 20.4R1 IPv6 IS-IS(Intermediate System to Intermediate System) IPv6 정보를 IPv4 주소와 함께 TED(Traffic Engineering Database)에 저장하도록 구성할 수 있습니다.
17.4R1
Junos OS Release 17.4R1 시작으로, 트래픽 엔지니어링 데이터베이스는 lsdist.0 라우팅 테이블에 RSVP-트래픽 엔지니어링(TE) 토폴로지 정보와 함께 IGP(Interior Gateway Protocol) 토폴로지 정보를 설치합니다.
17.2R1
JUNOS OS Release 17.2R1 시작으로 BGP(Border Gateway Protocol) 링크 상태 주소 패밀리가 확장되어 SPRING(네트워킹) 토폴로지 정보를 소프트웨어 정의 네트워킹(SDN(Software-Defined Networking)) 컨트롤러로 배포합니다.
17.1R1
릴리스 릴리스 Junos OS 릴리스 17.1R1 스위치에서 BGP(Border Gateway Protocol) 링크 상태 배포가 QFX10000 있습니다.