Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

RSVP 개요

RSVP 개요

RSVP 프로토콜은 라우터에서 데이터 플로우 경로에 따라 모든 노드에 QoS(서비스 품질) 요청을 전달하고 요청된 서비스에 대한 상태를 설정 및 유지 관리하기 위해 사용됩니다. RSVP 요청은 일반적으로 데이터 경로를 따라 각 노드에서 리소스 예약을 발생합니다. RSVP에는 다음과 같은 속성이 있습니다.

  • 한방향 데이터 플로우에 대한 리소스 예약

  • 에 표시된와 같이 데이터 플로우의 수신기가 해당 플로우에 사용되는 리소스 예약을 시작하고 유지할 수 그림 1 있습니다.

  • 라우터 및 호스트에서 소프트한 상태를 유지하여 동적 멤버십 변경을 위한 graceful 지원을 제공하며 라우팅 변경에 대한 자동 적응을 제공합니다.

  • 현재 및 미래의 라우팅 프로토콜에 따라 달라지지만 라우팅 프로토콜 자체는 아닙니다.

  • 다양한 애플리케이션에 맞게 여러 예약 모델 또는 스타일 제공

  • RSVP 신호 LSP를 통해 전송할 수 있는 IPv4 및 IPv6 패킷을 모두 지원

그림 1: RSVP 예약 요청 및 데이터 플로우RSVP 예약 요청 및 데이터 플로우

RSVP 작동 개요

RSVP는 각 데이터 플로우를 처리하기 위해 독립 세션을 만듭니다. 대상 주소, 선택 대상 포트 및 프로토콜을 조합하여 세션이 식별됩니다. 세션 내에 하나 이상의 보낸 사람이 있을 수 있습니다. 각 발신은 소스 주소와 소스 포트를 조합하여 식별됩니다. 세션 발표 프로토콜 또는 인적 통신과 같은 대역 외 메커니즘은 모든 발신자 및 수신기에 세션 식별자를 전달하는 데 사용됩니다.

일반적인 RSVP 세션은 다음과 같은 이벤트 순서로 진행됩니다.

  1. 잠재적 발신자는 RSVP 경로 메시지를 세션 주소로 전송하기 시작합니다.

  2. 세션에 참여하기를 원하는 수신기는 필요한 경우 스스로를 등록합니다. 예를 들어 멀티캐스트 애플리케이션의 수신기는 자체 IGMP에 등록할 수 있습니다.

  3. 수신기는 경로 메시지를 수신합니다.

  4. 수신기는 적절한 Resv 메시지를 발신자 쪽으로 전송합니다. 이러한 메시지는 링크 레이어 미디어에서 예약하기 위해 경로를 따라 라우터가 사용하는 플로우 설명자(flow descriptor)를 전달합니다.

  5. 발신자는 Resv 메시지를 수신한 다음 애플리케이션 데이터 전송을 시작합니다.

이러한 이벤트 시퀀스가 반드시 동기화될 필요는 없습니다. 예를 들어, 수신기는 발신자로부터 경로 메시지를 수신하기 전에 스스로 등록할 수 있으며, 발신자가 Resv 메시지를 수신하기 전에 애플리케이션 데이터가 전달될 수 있습니다. Resv 메시지에 포함된 실제 예약 전에 전달되는 애플리케이션 데이터는 일반적으로 CoS 보증이 없는 best-effort, 비실시간 트래픽으로 처리됩니다.

RSVP 신호 전송 프로토콜 이해

RSVP는 네트워크 전반에서 대역폭 할당 및 진정한 트래픽 엔지니어링을 처리하는 MPLS 프로토콜입니다. LDP와 마찬가지로 RSVP는 검색 메시지와 광고를 사용하여 모든 호스트 간에 LSP 경로 정보를 교환합니다. 그러나 RSVP에는 네트워크 전반의 트래픽 흐름을 제어하는 기능 MPLS 포함되어 있습니다. LDP는 네트워크를 통과하는 전송 경로로 구성된 IGP 최단 경로를 사용하도록 제한되는 반면, RSVP는 CSPF(Constrained Shortest Path First) 알고리즘과 EROS(Explicit Route Objects)를 조합하여 네트워크를 통해 트래픽이 라우팅되는 방법을 확인합니다.

기본 RSVP 세션은 LDP 세션이 설정된 방식과 정확히 동일한 방식으로 설정됩니다. 적절한 전송 인터페이스에서 MPLS 및 RSVP를 구성하여 RSVP 패킷을 교환하고 LSP를 설정할 수 있습니다. 그러나 RSVP는 링크 인증, 명시적 LSP 경로 및 링크 컬러링을 구성할 수도 있습니다.

이 주제에는 다음 섹션이 포함되어 있습니다.

RSVP 기본

RSVP는 네트워크를 통해 한방향 및 단순화 플로우를 사용하여 해당 기능을 수행합니다. 인바운드 라우터는 RSVP 경로 메시지를 시작하고 아웃바운드 라우터로 다운스트림을 전송합니다. 경로 메시지에는 연결에 필요한 리소스에 대한 정보가 포함되어 있습니다. 경로를 따라 각 라우터는 예약에 대한 정보를 유지하기 시작됩니다.

경로 메시지가 아웃바운드 라우터에 도달하면 리소스 예약이 시작됩니다. 아웃바운드 라우터는 인바운드 라우터로 예약 메시지 업스트림을 전송합니다. 경로를 따라 각 라우터는 예약 메시지를 수신하고 원래 경로 메시지의 경로를 따라 업스트림으로 전송합니다. 인바운드 라우터가 예약 메시지를 수신하면 한방향 네트워크 경로가 설정됩니다.

RSVP 세션이 활성 상태인 한 설정 경로는 개방 상태로 유지됩니다. 세션 상태를 30초마다 보고하는 추가 경로 및 예약 메시지 전송에 따라 세션이 유지 관리됩니다. 라우터가 3분 동안 유지 보수 메시지를 수신하지 못하면 RSVP 세션이 종료되고 다른 활성 라우터를 통해 LSP로 재라우트합니다.

대역폭 예약 요구 사항

대역폭 예약이 구성된 경우, 예약 메시지는 LSP 전반에 걸쳐 대역폭 값을 전파합니다. 라우터는 특정 LSP에 대해 링크 전체에 지정된 대역폭을 예약해야 합니다. 총 대역폭 예약이 특정 LSP 세그먼트의 가용 대역폭을 초과하는 경우, LSP는 다른 대역폭을 통해 레이블 스위칭 라우터(LSR). 세그먼트가 대역폭 예약을 지원할 수 없는 경우, LSP 설정에 실패하고 RSVP 세션이 설정되지 않습니다.

명시적 경로 객체

EROS(Explicit Route Objects)는 LSP 라우팅을 지정된 LSRS 목록에 제한합니다. 기본적으로 RSVP 메시지는 네트워크에서 최단 경로로 IGP 경로를 따라가게 됩니다. 그러나 구성된 ERO가 있는 경우 RSVP 메시지는 지정된 경로를 따르는 것입니다.

EROS는 두 가지 유형의 지침으로 구성됩니다. 느슨한 홉과 엄격한 홉을 제공합니다. 느슨한 홉이 구성되면 LSP가 라우팅되어야 하는 하나 이상의 전송 LSRS를 식별합니다. 네트워크 IGP 라우터에서 첫 번째 느슨한 홉 또는 한 번의 Loose Hop에서 다음 홉으로의 정확한 경로를 확인합니다. 느슨한 홉은 특정 레이블 스위칭 라우터(LSR) LSP에 포함되어야만 지정합니다.

엄격한 홉이 구성되면 LSP가 라우팅되어야 하는 정확한 경로를 식별합니다. Strict-hop EROS는 RSVP 메시지가 전송되는 라우터의 정확한 순서를 지정합니다.

loose-hop 및 strict-hop EROS를 동시에 구성할 수 있습니다. 이 경우, IGP Loose Hops 간의 경로를 결정하고 Strict-Hop 구성이 특정 LSP 경로 세그먼트에 대한 정확한 경로를 지정합니다.

그림 2 은 EROS를 사용하는 일반적인 RSVP 신호 LSP를 보여줍니다.

그림 2: 일반 RSVP 신호 LSP(EROS 사용)일반 RSVP 신호 LSP(EROS 사용)

표시된 토폴로지에서 트래픽은 호스트 그림 2 C1에서 호스트 C2로 라우팅됩니다. LSP는 라우터 R4 또는 라우터 R7을 통과할 수 있습니다. LSP가 R4를 사용하게 하여, LSP에서 R4를 홉으로 지정하는 loose-hop 또는 Strict-hop ERO를 설정할 수 있습니다. 라우터 R4, R3 및 R6을 통해 특정 경로를 강제로 적용하기 위해 3개의 LSRS를 통해 Strict-hop ERO를 구성합니다.

최단 경로 우선

IGP는 SPF(Shortest Path First) 알고리즘을 사용하여 네트워크 내에서 트래픽이 라우팅되는 방법을 결정하는 데 반해, RSVP는 CSPF(Constrained Shortest Path First) 알고리즘을 사용하여 다음과 같은 제약 조건에 따라야 하는 트래픽 경로를 계산합니다.

  • LSP 속성—링크 컬러링, 대역폭 요구 사항 및 EROS와 같은 관리 그룹

  • 링크 속성—특정 링크의 색상 및 가용 대역폭

이러한 제약 조건은 TED(Traffic Engineering Database)에 유지 관리됩니다. 이 데이터베이스는 CSPF에 최신 토폴로지 정보, 현재의 링크에서 보존 가능한 대역폭 및 링크 색상을 제공합니다.

어떤 경로를 선택할지 결정하는 데 CSPF는 다음 규칙을 따릅니다.

  • 설정 우선 순위가 가장 낮은 LSP로 한 때 LSP를 계산합니다. 우선 순위가 동일한 LSP 중에서 CSPF는 가장 높은 대역폭 요구 사항을 요구하는 LSP에서 시작됩니다.

  • 전이중(full duplex)이 아니고 충분한 보존 대역폭이 없는 링크의 트래픽 엔지니어링 데이터베이스를 관리합니다.

  • LSP 구성에 명령문이 포함되어 있는 경우 포함된 색상을 공유하지 않는 모든 링크를 include prunes 합니다.

  • 명령문이 LSP 구성에 포함된 경우 제외된 색상이 포함된 모든 exclude 링크를 prunes 합니다. 링크에 색상이 없는 경우 허용됩니다.

  • 모든ER을 고려하여 LSP의 아웃바운드 라우터로 향하는 최단 경로를 찾습니다. 예를 들어 경로가 Router A를 통과해야 하는 경우, 2개의 개별 SPF 알고리즘이 계산됩니다. 인바운드 라우터에서 라우터 A로, 그리고 라우터 A에서 아웃바운드 라우터로,

  • 여러 경로에 동일한 비용이 드는 경우, LSP의 목적지와 동일한 라우트 홉 주소가 있는 경로를 선택

  • 몇 개의 동일한 비용 경로가 남아 있는 경우, 최소 홉 수로 경로를 선택합니다.

  • 몇 개의 동일한 비용 경로가 남아 있는 경우 LSP에 구성된 CSPF 로드 밸런싱 규칙을 적용합니다.

링크 컬러링

RSVP를 사용하면 CSPF 경로 선택을 위한 관리 그룹을 구성할 수 있습니다. 관리 그룹은 일반적으로 색으로 지정되고 숫자 값을 지정하며 적절한 링크에 대해 RSVP 인터페이스에 적용됩니다. 숫자가 적을수록 우선 순위가 높을 수 있습니다.

관리 그룹을 구성한 후 TED에서 해당 색의 링크를 제외, 포함 또는 무시할 수 있습니다.

  • 특정 색상을 제외하면 관리 그룹이 있는 모든 세그먼트는 CSPF 경로 선택에서 제외됩니다.

  • 특정 색을 포함하면 적절한 색을 내는 세그먼트만 선택됩니다.

  • 색을 제외하거나 포함하지도 않는다면 관리 그룹과 연관되고 특정 세그먼트에 적용된 메트릭은 해당 세그먼트의 경로 비용을 결정합니다.

총 경로 비용이 최저인 LSP가 TED에 선택됩니다.

FRR을 위한 RSVP-트래픽 엔지니어링(TE) 프로토콜 확장

릴리스 16.Junos OS 시작하여 FRR(Fast Reroute) 보호를 위해 RI-RSVP(Refresh-interval Independent RSVP) 정의 RFC 8370을 지원하는 RSVP 트래픽 엔지니어링(트래픽 엔지니어링(TE)) 프로토콜 확장이 도입되어 LSP(Label-Switched Path)의 확장성이 더욱 빨라지고 주기적인 갱신 시 RSVP 시그널링 메시지 오버헤드를 감소합니다. Junos RSVP-트래픽 엔지니어링(TE) RFC 4090에 원래 지정한 우회 FRR 기능의 RI-RSVP를 지원하기 위한 프로토콜 확장이 포함되어 기본적으로 향상된 FRR aka RI-RSVP 모드에서 실행됩니다.

Junos에 구현된 RI-RSVP 프로토콜 확장은 완벽하게 호환됩니다. 이 기능을 포함하지 않는 LSP의 하위 세트가 이 기능을 포함하지 않는 노드를 경유하는 혼합 환경에서 향상된 FRR 모드에서 실행되는 Junos RSVP-트래픽 엔지니어링(TE) 새 확장 기능을 지원하지 않는 노드와 시그널링 교환에서 새로운 프로토콜 확장을 자동으로 해제합니다.

향상된 FRR 프로필의 일부로 많은 변경이 이월되어 새로운 기본값이 채택됩니다. 여기에 나열되어 있습니다.

  • RSVP-트래픽 엔지니어링(TE) 확장 시나리오를 용이하게 하기 위한 기능 향상을 포함해 기본적으로 "강화된" FRR 또는 RI-RSVP 모드를 실행합니다. 라우터에서 이러한 새로운 프로토콜 확장을 비활성화할 no-enhanced-frr-bypass (Protocols RSVP) 수 있습니다.

  • RFC 2961에 정의된 RSVP 리프레시 리프레시 감소 확장은 기본적으로 지원됩니다. 신뢰할 수 없는 명령어로 비활성화할 수 있습니다(아래 참조).

    주:

    Node-id 기반 Hellos는 기본적으로 고급 FRR 또는 RI-RSVP 확장을 지원하기 때문에 Node-id 기반 Hello 메시지를 교환해야 합니다. Node-id 기반 Hellos는 명령으로 비활성화할 수 node-hello 있습니다. 리프레시 확장과 Node-id 기반 Hello 메시지는 향상된 FRR 또는 RI-RSVP 확장을 위해 필수 요소로, 둘 중 하나를 해제하면 노드에서 향상된 FRR 확장이 자동으로 해제됩니다.

  • RSVP 메시지의 기본 새로 고침 시간이 30초에서 20분으로 증가했습니다.

  • 3인 유지 배수(keep-multiplier)의기본값은 새로운 기본 갱신 시간(default refresh time)에 적용됩니다.

  • 로컬 되전은 기본적으로 비활성화됩니다. Node Hellos를 위한 기존 CLI 구성은 여전히 [edit protocols rsvp node-hello] 제공되지만 작업은 중복됩니다. 활성화하면 향상된 FRR과 함께 구성이 필요하지 않다는 메시지가 표시됩니다.

  • 메시지 안정성을 비활성화하기 위한 기존 명령은 이제 RSVP 리프레시 감소를 비활성화하는 데 사용됩니다. 이전 기본 설정으로 되돌아가서 리프레시 감소를 실행하기 위해 다음 명령어의 delete 버전을 사용하십시오.

    • 해당 인터페이스를 통해 인터페이스를 선회하는 모든 LSP에 대해 FRR 확장성 개선 기능을 자동으로 no-reliable 비활성화합니다. 마찬가지로, FRR 기능 트래픽 엔지니어링(TE) 개선 사항 없이 RSVP-트래픽 엔지니어링(TE) 리프레시 감소 없이 각 인터페이스에서 리프레시 감소를 해제합니다. 여기에 표시된 명령 중 하나를 사용하세요.

      • [edit protocols rsvp interface name no-reliable]

      • [edit logical-systems name protocols rsvp interface name no-reliable]

  • Graceful Restart 및 NSR(NonStop Active Routing)은 지원되지 않는 반면, LSP는 로컬 복구를 수행하거나 백업 LSP 시그널링 동안 LSP를 리프레시합니다. 이러한 제한은 FRR 로컬 수리가 진행 중 GR 또는 NSR 전환이 여러 장애 시나리오를 발생하기 때문에 이미 구현에 존재합니다.

  • FRR 설비 보호를 위해 RSVP 트래픽 엔지니어링(TE) 프로토콜 확장을 위해 도입된 새로운 절차에 대한 새로운 정보를 포함하기 위해 다음과 같은 운영 명령이 업데이트되었습니다.

    • show rsvp version 향상된 FRR 절차를 사용할 수 있는지 여부를 표시됩니다.

    • show rsvp neighbor detail 향상된 FRR 절차가 이웃에 활성화되어 있는지 여부를 표시됩니다.

    • show rsvp interface detail 조건부 PathTear 통계를 표시합니다.

    • show rsvp statistics 조건부 PathTear에 대한 전송 및 수신 통계와 기타 통계를 표시합니다.

    • show rsvp session extensive 노드가 병합 지점인지 여부를 표시하고, 해당 노드가 있는 경우 PLR(Point of Local Repair) 주소를 보여줍니다.

  • 메시지 번들링을 CLI 활성화 또는 활성화하기 위한 이전의 이전 구성 옵션은 사용되지 않았습니다(기존 구성은 허용되지만, 경고가 구성 출력 show에 표시됩니다). 이 명령은 다음과 같습니다.

    • [edit protocols rsvp interface name aggregate]

    • [edit logical-systems name protocols rsvp interface name aggregate]

    • [edit protocols rsvp interface name no-aggregate]

    • [edit logical-systems name protocols rsvp interface name no-aggregate]

  • 다음 CLI 구성 옵션은 현재 변경에 따라 중복되었습니다(기존 구성은 허용되지만, 경고는 구성 출력 show에 표시됩니다).

    • [edit protocols rsvp interface name reliable]

    • [edit logical-systems name protocols rsvp interface name reliable]

Junos OS RSVP 프로토콜 구현

RSVP의 Junos 구현은 RSVP 버전 1을 지원합니다. 이 소프트웨어는 모든 필수 객체 및 RSVP 메시지 유형을 지원하며, Integrity 객체를 통해 메시지 무결성 및 노드 인증을 지원한다.

Junos RSVP 소프트웨어의 주요 목적은 LSP(Label-Switched Path) 내에서 MPLS 시그널링을 지원하는 것입니다. 인터넷을 통해 자원 예약을 지원하는 것은 네트워크 보안 구현의 부차적인 Junos OS 있습니다. 리소스 예약 지원은 보조 소프트웨어이기 때문에 Junos RSVP 소프트웨어는 다음 기능을 지원하지 않습니다.

  • IP 멀티캐스팅 세션.

  • 트래픽 제어. 이 소프트웨어는 실시간 비디오 또는 오디오 세션에 대한 리소스를 예약할 수 없습니다.

지원되는 프로토콜 메커니즘, 패킷 처리 및 RSVP 객체와 관련하여 소프트웨어의 Junos OS 구현은 다른 RSVP 구현과 상호 작용할 수 있습니다.

RSVP 인증

이 Junos OS 은 RFC 2747에 설명된 RSVP 인증 스타일(멀티벤더 호환성 허용)과 인터넷 draft-draft-ietf-rsvp-md5-03.txt에 설명된 RSVP 인증 스타일 모두를 지원합니다. Junos OS 초안-ietf-rsvp-md5-08.txt에 설명된 인증 스타일은 기본적으로 사용됩니다. 라우터가 이웃으로부터 RFC 2747 스타일의 RSVP 인증을 수신하면 해당 이웃에 대한 이 인증 스타일로 전환됩니다. 각 인접 라우터에 대한 RSVP 인증 스타일은 별도로 결정됩니다.

RSVP and IGP Hello Packets and Timers

RSVP는 내부 게이트웨이 프로토콜(IGP)(IS-IS(Intermediate System to Intermediate System) 또는 최단 경로 우선(OSPF)) 이웃의 상태를 모니터링하고 IGP 프로토콜을 사용하여 노드에 장애가 발생하면 이를 탐지합니다. 한 IGP 프로토콜이 이웃(hello 패킷이 더 이상 수신되지 못하기 때문에)을 선언하면 RSVP는 인접한 아래로 내려가게 됩니다. 그러나 인접 IGP 프로토콜과 RSVP는 여전히 독립적으로 운영됩니다.

네트워크 Junos OS RSVP는 일반적으로 IGP hello 패킷 감지를 의존하여 노드 장애를 검사합니다. 네트워크 또는 IS-IS(Intermediate System to Intermediate System) 최단 경로 우선(OSPF) 짧은 시간을 구성하면 이러한 프로토콜에서 노드 장애를 신속하게 탐지할 수 있습니다. 노드에 장애가 발생하거나 노드 장애가 감지되면 경로 오류 메시지가 생성되고 RSVP 세션이 다운되는 동안에는 IGP 이웃이 계속 남아 있습니다.

RSVP hellos는 IGP 특정 neighbor를 인식하지 못하거나(예: 인터페이스에서 IGP 활성화되지 않은 경우) 또는 IGP RIP(IS-IS(Intermediate System to Intermediate System) 또는 최단 경로 우선(OSPF))를 사용할 수 있습니다. 또한, 다른 벤더의 장비는 RSVP hello 패킷을 기반으로 RSVP 세션을 모니터링하도록 구성될 수 있습니다. 이 장비는 RSVP hello 패킷이 손실되어 RSVP 세션이 다운될 수도 있습니다.

짧은 RSVP hello timer를 구성하는 것은 권장하지 않습니다. 실패한 이웃을 신속하게 발견해야 하는 경우 짧은 IGP(최단 경로 우선(OSPF) 또는 IS-IS(Intermediate System to Intermediate System)) hello timers를 구성합니다.

최단 경로 우선(OSPF) 및 IS-IS(Intermediate System to Intermediate System) 라우팅 프로토콜이나 기타 프로세스가 라우터의 프로세싱 성능을 고수하는 경우에도 신속한 Hello 메시지 송수신을 안정적으로 관리할 수 있는 인프라스트럭처를 갖추고 있습니다. 동일한 상황에서도 RSVP Hello는 이웃이 정상적으로 작동 중이라 경우에도 조기 타임아웃될 수 있습니다.

RSVP 메시지 유형

RSVP는 다음과 같은 유형의 메시지를 사용하여 데이터 플로우에 대한 경로를 설정/제거하고, 예약 정보를 설정/제거하고, 예약의 설정을 확인하며 오류를 보고합니다.

경로 메시지

각 발신 호스트는 유니캐스트 및 멀티캐스트 라우팅 프로토콜이 제공하는 경로를 따라 경로 메시지를 다운스트림 전송합니다. 경로 메시지는 애플리케이션 데이터의 정확한 경로를 따라 라우터에서 경로 상태(path states)를 생성하여 라우터가 세션에 대한 이전 홉 및 넥스 홉 노드를 학습할 수 있도록 합니다. 경로 메시지는 경로 상태의 갱신을 위해 주기적으로 전송됩니다.

갱신 간격은 몇 초만에 표현되는 주기적인 갱신 시간(refresh timer)이라는 변수에 따라 refresh-time 제어됩니다. 라우터가 지정된 수의 연속 경로 메시지를 수신하지 않을 경우 경로 상태 타임 아웃(times out)됩니다. 이 숫자는 이라는 변수에 의해 keep-multiplier 지정됩니다. 경로 상태는 keep-multiplier (+ 0.5 x 1.5 x) 초 refresh-time 동안 유지됩니다.

Resv 메시지

각 수신 호스트는 발신자 및 발신자 애플리케이션으로 예약 요청(Resv) 메시지를 업스트림합니다. Resv 메시지는 경로 메시지의 역방향 경로를 정확하게 따라야 합니다. Resv 메시지는 진행 중 각 라우터에서 예약 상태를 생성하고 유지 관리합니다.

Resv 메시지는 예약 상태의 갱신을 위해 주기적으로 전송됩니다. 갱신 간격은 같은 갱신 시간 변수에 따라 제어되어 예약 상태는 keep-multiplier (+ 0.5) x 1.5 x 초 동안 refresh-time 유지됩니다.

PathTear 메시지

PathTear 메시지는 경로를 따라 모든 라우터에서 경로 상태는 물론, 종속적 예약 상태도 제거합니다. PathTear 메시지는 경로 메시지와 동일한 경로를 따르고 있습니다. PathTear는 일반적으로 발신 애플리케이션 또는 경로 상태가 타임아웃될 때 라우터에 의해 시작됩니다.

PathTear 메시지는 필요하지 않지만 네트워크 리소스를 빠르게 릴리스하기 때문에 네트워크 성능을 향상할 수 있습니다. PathTear 메시지가 손실되거나 생성되지 않을 경우, 경로 상태는 업데이트되지 않을 때 타임아웃 되거나 경로와 연관된 리소스가 릴리스됩니다.

ResvTear 메시지

ResvTear 메시지는 경로에 따라 예약 상태도 제거합니다. 이러한 메시지는 세션을 보낸 사람으로 업스트림 전송됩니다. 그 의미에서, ResvTear 메시지는 Resv 메시지의 반대입니다. ResvTear 메시지는 일반적으로 리시버 애플리케이션 또는 예약 상태가 타임아웃될 때 라우터에 의해 시작됩니다.

ResvTear 메시지는 필요하지 않지만, 네트워크 리소스를 빠르게 릴리스하기 때문에 네트워크 성능을 향상할 수 있습니다. ResvTear 메시지가 손실되거나 생성되지 않을 경우, 예약 상태는 업데이트되지 않을 때 타임아웃 되거나 예약과 관련된 리소스가 릴리스됩니다.

Patherr 메시지

경로 오류가 발생하면(일반적으로 경로 메시지의 매개 변수로 인하여), 라우터는 경로 메시지를 발행한 발신자에 유니캐스트 PathErr 메시지를 전송합니다. PathErr 메시지는 권고입니다. 이러한 메시지는 그 어떤 경로 상태도 변경하지 않습니다.

ResvErr 메시지

예약 요청에 실패하면 ResvErr 오류 메시지가 관련된 모든 수신기에 전달됩니다. ResvErr 메시지는 권고입니다. 이러한 메시지는 진행 중 예약 상태를 변경하지 않습니다.

ResvConfirm 메시지

수신기는 예약 요청에 대한 확인을 요청할 수 있으며, 이 확인 메일은 ResvConfirm 메시지와 함께 전송됩니다. 복잡한 RSVP 플로우 전달 규칙 때문에 확인 메시지가 전체 경로에 대한 엔드-to-엔드 확인을 반드시 제공하지는 않습니다. 따라서 ResvConfirm 메시지는 성공을 보장하는 것이 아니라 그렇습니다.

주니퍼 네트웍스 ResvConfirm 메시지를 사용해 확인을 요청하지 않습니다. 그러나 한 주니퍼 네트웍스 다른 벤더의 장비로부터 요청을 받는 경우 ResvConfirm 메시지를 보낼 수 있습니다.

RSVP 자동 메시 이해

RSVP 시그널링을 사용하는 BGP(BORDER GATEWAY PROTOCOL) 및 MPLS VPN에 사이트를 추가하는 경우, 고객 에지(고객 에지(CE)) 디바이스를 추가하는 데 필요한 것보다 더 많은 구성이 필요합니다. RSVP 자동 메시는 이러한 구성 부담을 줄일 수 있습니다.

서비스 프로바이더들은 종종 BGP(Border Gateway Protocol) 및 MPLS VPN을 사용하여 네트워크를 효율적으로 확장하는 동시에 수익 창출 서비스를 제공합니다. 이러한 환경에서는 BGP(Border Gateway Protocol) VPN 라우팅 정보를 서비스 제공업체의 네트워크 전반에 배포하는 데 사용 반면, MPLS VPN 트래픽을 다른 VPN 사이트로 전달하는 데 사용됩니다. BGP(Border Gateway Protocol) MPLS VPN은 피어 모델을 기반으로 합니다. 기존 VPN에 새로운 고객 에지(CE) 디바이스(사이트)를 추가하려면 새 사이트에서 고객 에지(CE) 라우터를 구성해야 합니다. 이 라우터는 고객 에지(CE). VPN에 참여하는 다른 모든 PE 라우터의 구성을 수정할 필요가 없습니다. 다른 PE 라우터는 새로운 사이트와 연관된 경로, 즉 자동 검색(AD)이라는 프로세스에 대해 자동으로 학습합니다.

네트워크에 새로운 PE 라우터를 추가해야 하는 경우 요구 사항은 조금 다릅니다. BGP(Border Gateway Protocol) 및 MPLS VPN은 BGP(Border Gateway Protocol) 풀 메시(BGP(Border Gateway Protocol)) 메시가 필요하며 네트워크의 모든 PE 라우터 사이에 PE 라우터와 LSP(Label-Switched Paths)MPLS 풀 메시가 있을 것을 요구합니다. 네트워크에 새로운 PE 라우터를 추가하면 기존의 모든 PE 라우터를 새로운 PE 라우터와 피어링하기 위해 재구성되어야 합니다. 라우트 리프터(BGP(Border Gateway Protocol) 라우트 리프터)를 구성하고(BGP(Border Gateway Protocol)에 대한 풀 메시 요구 사항 완화)를 구성하고 LDP를 네트워크의 시그널링 프로토콜로 구성하는 경우 MPLS.

그러나 RSVP 신호 LSP의 풀 메시로 구성된 네트워크에 새로운 PE 라우터를 추가해야 하는 경우 각 PE 라우터를 새로운 PE 라우터와 피어 관계를 맺도록 재구성해야 합니다. 이러한 특정 운영 시나리오에 맞게 RSVP 자동 메시를 구성할 수 있습니다. RSVP 자동 메시를 활성화하면 새로운 PE 라우터와 기존 PE 라우터 사이에 RSVP LSP가 동적으로 생성되어 모든 PE 라우터를 수동으로 재구성할 필요가 없습니다. 다이나믹한 LSP 생성이 제대로 작동하려면 BGP(Border Gateway Protocol) PE 라우터 간의 경로를 교환하도록 구성해야 합니다. 두 개의 BGP(Border Gateway Protocol) 피어가 경로를 교환할 수 없는 경우, 이 둘 간의 동적 LSP를 구성할 수 없습니다. 로컬 라우터의 inet.3 라우팅 테이블에는 각 잠재적 IBGP 넥스 홉(미래의 PE 라우터 또는 LSP 대상)에 대한 레이블링된 경로가 포함되어야 합니다.

RSVP에는 고속 재라우트, 단말 지점 제어, 링크 관리 등 LDP에서는 지원되지 않는 많은 기능이 포함되어 있습니다. RSVP 자동 메시는 RSVP의 운영 및 유지 보수 요구 사항을 줄여 보다 복잡하고 크고 복잡한 네트워크에 RSVP를 구축할 수 있습니다.

모든 PE 라우터는 네트워크의 다른 모든 PE 라우터에 도달할 수 있습니다. 이 정보는 네트워크 보안 장치로 IGP. PE 라우터는 LSP가 필요하다는 것을 알고 있는 한 네트워크의 다른 PE 라우터에 점대점(point-to-point) RSVP LSP를 설정할 수 있습니다. PE 라우터 간에 풀 메시 LSP를 구축하려면 각 PE 라우터가 풀 메시를 구성하는 다른 PE 라우터를 알아야 합니다.

주:

이러한 Junos OS 계층 수준에서 구성 명령문을 사용하여 RSVP 자동 rsvp-te[edit routing-options dynamic-tunnels dynamic-tunnel-name] 메시가 구성됩니다. 구성 명령문은 서비스 제공업체-터널 옵션으로 라우팅 rsvp-te 인스턴스에서도 사용할 수 있습니다. 제공업체 터널 옵션으로 구현할 경우, RSVP 자동 메시를 구성하지 말고 멀티프로토콜 BGP(Border Gateway Protocol) 멀티캐스트 VPN을 위해 rsvp-te RSVP 점대다점 LSP를 구성하는 데 사용됩니다.

RSVP 예약 스타일

예약 요청에는 예약 스타일 지정 옵션이 포함됩니다. 예약 스타일은 동일한 세션 내의 여러 발신자에 대한 예약을 처리하는 방법과 발신자 선택 방법을 정의합니다.

두 가지 옵션은 동일한 세션 내의 여러 발신자에 대한 예약이 어떻게 처리되는지 지정합니다.

  • 별도 예약—각 수신기는 각 업스트림 발신자마다 고유의 예약을 수립합니다.

  • 공유 예약—모든 수신기는 여러 발신자들 사이에 공유되는 단일 예약을 합니다.

두 가지 옵션은 발신자 선택 방법을 지정합니다.

  • 명시적 발신자—선택한 모든 발신인을 나열합니다.

  • 와일드카드 발신자—모든 발신자 선택, 그 다음 세션 참여

다음과 같은 예약 스타일이 다음과 같은 4개의 옵션을 결합하여 구성되고 현재 정의됩니다.

  • 고정 필터(FF)—이 예약 스타일은 명시적인 발신자들 사이에서 서로 다른 예약으로 구성됩니다. 고정 필터 스타일의 예약을 사용하는 애플리케이션의 예로는 각 발신자마다 별도의 예약을 하는 플로우가 필요한 비디오 애플리케이션 및 유니캐스트 애플리케이션이 있습니다. 기본적으로 RSVP LSP에서 고정 필터 예약 스타일이 활성화됩니다.

  • 와일드카드 필터(WF)—이 예약 스타일은 와일드카드 발신자들 사이에서 공유 예약으로 구성됩니다. 이 유형의 예약은 모든 발신자에 대한 대역폭을 예약하고 모든 발신자에 업스트림을 전파하여 자동으로 새로운 발신자로 확장됩니다. 와일드카드 필터 예약을 위한 샘플 애플리케이션은 발신 사람이 각각 다른 데이터 스트림을 전송하는 오디오 애플리케이션입니다. 일반적으로, 단 몇 번의 발신자만이 한 번만 전송합니다. 이러한 플로우는 각 발신자마다 별도의 예약을 요구하지 않습니다. 단일 예약으로 충분합니다.

  • 공유된 명시적(SE)—이 예약 스타일은 명시적 발신자 간 공유 예약으로 구성됩니다. 이러한 유형의 예약은 제한된 발신자 그룹에 대한 대역폭을 예약합니다. 샘플 애플리케이션은 와일드카드 필터 예약에 대해 설명한 오디오 애플리케이션과 유사한 것입니다.

RSVP 리프레시 감소

RSVP는 소프트 스테이트(soft-state)에 의존하여 각 라우터에서 경로 및 예약 상태를 유지 관리합니다. 해당 업데이트 메시지가 주기적으로 전송되지 않는 경우 상태는 결국 타임아웃되고 예약은 삭제됩니다. 또한 RSVP는 안정성 보증이 없는 IP 데이터그램으로 제어 메시지를 전송합니다. 주기적인 갱신 메시지에 의존하여 때때로 Path 또는 Resv 메시지가 손실되는 경우를 처리합니다.

RFC 2961에 기반한 RSVP 리프레시 리프레시 확장은 주기적인 갱신 메시지에 따라 메시지 손실을 처리하기 때문에 다음과 같은 문제를 해결합니다.

  • 확장성—RSVP 세션 수가 증가하는 갱신 메시지의 주기적인 전송 및 프로세싱 오버헤드에서 발생합니다.

  • 안정성 및 지연—안정성 및 지연 문제는 비refresh RSVP 메시지가 손실되거나 PathTear 또는 PathErr와 같은 RSVP 메시지가 일회성으로 손실되는 경우 기인합니다. 이와 같은 손실을 복구하는 데 시간(time to recover the time)은 대개 간격과 keepalive timer을 새로 고침하는 데로 묶이게 됩니다.

RSVP 리프레시 감소 기능은 RSVP 공통 헤더에서 RR(Refresh Reduction) 지원 비트를 활성화하여 광고됩니다. 이 비트는 RSVP neighbor 간에만 중요한 역할을 합니다.

RSVP 리프레시 감소에는 다음 기능이 포함되어 있습니다.

  • 번들 메시지를 사용한 RSVP 메시지 번들링

  • 메시지 처리 오버헤드를 줄이는 RSVP Message ID

  • Message ID, Message Ack 및 Message Nack을 사용하여 RSVP 메시지를 안정적으로 전송

  • 매 리프레시 간격마다 전송되는 정보의 양을 줄이는 요약 리프레시

RSVP 갱신 감소 규격(RFC 2961)을 사용하면 라우터에서 위의 기능을 일부 또는 모두 활성화할 수 있습니다. 또한 라우터가 이웃의 리프레시 감소 기능을 탐지하는 데 사용할 수 있는 다양한 절차를 설명하고 있습니다.

이 Junos OS 리프레시 감소 확장을 모두 지원(일부 옵션으로 활성화 또는 비활성화 가능) 또한 Junos OS ID를 지원하기 때문에 경로 및 Resv 메시지에만 안정적인 메시지 전송을 수행할 수 있습니다.

RSVP 리프레시 감소 구성 방법에 대한 자세한 내용은 RSVP 리프레시 단축 구성 을 참조하십시오.

최대 전송 단위(MTU) 시그널링(RSVP)

최대 전송 단위(최대 전송 단위(MTU))는 네트워크에서 전송할 수 있는 가장 큰 크기의 패킷 또는 프레임(bytes)입니다. 최대 전송 단위(MTU) 너무 큰 경우 재전문을 일으킬 수 있습니다. 너무 작게 최대 전송 단위(MTU) 라우터가 비교적 더 많은 헤더 오버헤드와 Acknowledgment를 전송하고 처리하게 될 수 있습니다. 다양한 프로토콜과 연관된 MTUS에 대한 기본값이 있습니다. 인터페이스에서 최대 전송 단위(MTU) 구성할 수 있습니다.

서로 다른 크기의 링크 집합에서 LSP가 최대 전송 단위(MTU) 경우, ingress 라우터는 LSP 경로에서 가장 작은 최대 전송 단위(MTU) 알지 못합니다. 기본적으로 LSP 최대 전송 단위(MTU) 1,500 바트입니다.

이 최대 전송 단위(MTU) 패킷의 최대 전송 단위(MTU) 패킷을 단편화할 수 MPLS 수 있기 때문에 트래픽이 드롭될 수 있습니다. 또한, ingress 라우터는 LSP의 컨트롤 플레인이 정상적으로 작동할 수 있기 때문에 이러한 유형의 트래픽 손실을 인식하지 못합니다.

LSP에서 이러한 유형의 패킷 손실을 방지하기 MPLS RSVP에서 최대 전송 단위(MTU) 시그널링을 구성할 수 있습니다. 이 기능은 RFC 3209에서 설명됩니다. 주니퍼 네트웍스 RSVP에서 전송되는 최대 전송 단위(MTU) 통합 서비스 객체를 지원 통합 서비스 객체는 RFC 2210 및 2215에 설명되어 있습니다. 최대 전송 단위(MTU) 시그널링은 기본적으로 비활성화됩니다.

미스매치로 인한 패킷 최대 전송 단위(MTU) 방지하기 위해 수신 라우터는 다음과 같은 작업을 처리해야 합니다.

  • RSVP LSP의 최대 전송 단위(MTU) 신호—패킷 손실을 최대 전송 단위(MTU) 불일치가 방지하기 위해 수신 라우터는 LSP가 취한 경로에서 가장 작은 최대 전송 단위(MTU) 값을 알아야 합니다. 일단 이 최대 전송 단위(MTU) 값을 획득하면 ingress 라우터가 이를 LSP에 할당할 수 있습니다.

  • 패킷 단편화—할당된 최대 전송 단위(MTU) 값을 사용하여 최대 전송 단위(MTU) 패킷이 RSVP 신호 LSP를 통해 캡슐화되기 전에 수신 라우터의 더 작은 패킷으로 MPLS 수 있습니다.

수신 라우터에서 최대 전송 단위(MTU) 시그널링과 패킷 단편화가 모두 활성화되면 이 라우터에서 RSVP LSP로 재지정하는 모든 루트는 시그널링 최대 전송 단위(MTU) 값을 사용하게 됩니다. 이 기능을 구성하는 방법에 대한 자세한 내용은 RSVP의 최대 전송 단위(MTU) 시그널링 구성을 참조하십시오.

다음 섹션에서는 RSVP의 최대 전송 단위(MTU) 신호 전송 방식에 대해 설명합니다.

RSVP에서 최대 전송 단위(MTU) 올바른 신호 전송 방법

RSVP에서 올바른 최대 전송 단위(MTU) 신호 전송 방식은 네트워크 디바이스(예: 라우터)가 명시적으로 RSVP에서 최대 전송 단위(MTU) 시그널링을 지원하는지 여부에 따라 다릅니다.

네트워크 디바이스가 RSVP에서 최대 전송 단위(MTU) 시그널링을 지원하는 경우 신호 전송을 활성화할 최대 전송 단위(MTU) 발생합니다.

  • 최대 전송 단위(MTU) Adspec 객체를 통해 수신 라우터에서 egress 라우터로 시그널링됩니다. 이 객체를 포워드하기 전에 수신 라우터는 경로 메시지가 최대 전송 단위(MTU) 인터페이스와 연관된 최대 전송 단위(MTU) 값을 입력합니다. 경로의 각 홉에서, adspec 최대 전송 단위(MTU) 내 가치는 수신된 값과 발신 인터페이스의 값으로 업데이트됩니다.

  • ingress 라우터는 Tspec(Traffic Specification) 객체를 사용하여 전송할 트래픽에 대한 매개 변수를 지정합니다. 수신 라우터에서 Tspec 객체를 위해 시그널링된 최대 전송 단위(MTU) 값은 최대 최대 전송 단위(MTU) 값입니다(M Series 및 T 시리즈 라우터의 경우 9192 bytes, PTX 시리즈 라우터에서는 9500 bytes패킷 전송 라우터). 이 값은 egress 라우터로 이동하는 경로를 변경하지 않습니다.

  • Adspec 객체가 egress 라우터에 도착하면 최대 전송 단위(MTU) 경로에 맞습니다(검색된 값 중 최대 전송 단위(MTU) 있는 가장 작음). egress 라우터는 Adspec 객체의 최대 전송 단위(MTU) 값을 Tspec 객체의 최대 전송 단위(MTU) 값과 비교합니다. Resv 메시지에서 Flowspec 최대 전송 단위(MTU) 더 작은 신호가 전송됩니다.

  • Resv 객체가 ingress 라우터에 최대 전송 단위(MTU) 경우, 이 객체의 최대 전송 단위(MTU) 값은 LSP를 사용하는 다음 홉에 대한 최대 전송 단위(MTU) 값으로 사용됩니다.

RSVP에서 최대 전송 단위(MTU) 시그널링을 지원하지 않는 장치가 있는 네트워크에서 다음과 같은 동작이 있을 수 있습니다.

  • egress 라우터가 RSVP에서 최대 전송 단위(MTU) 시그널링을 지원하지 않는 경우, 기본적으로 최대 전송 단위(MTU) 1,500 bytes로 설정됩니다.

  • RSVP에서 최대 전송 단위(MTU) 신호를 지원하지 않는 최대 전송 단위(MTU) 전송 라우터는 기본적으로 Adspec 객체에서 1,500 bytes의 최대 전송 단위(MTU) 값을 설정합니다. 주니퍼 네트웍스

지속적인 가치 최대 전송 단위(MTU) 결정

outgoing 최대 전송 단위(MTU) 값은 Adspec 객체에서 수신된 값보다 더 작고, 최대 전송 단위(MTU) 값보다 작습니다. 최대 전송 단위(MTU) 인터페이스의 가치는 다음과 같이 결정됩니다.

  • 계층 수준에서 최대 전송 단위(MTU) 값을 구성하면 이 값이 [family mpls] 시그널 처리됩니다.

  • 구성하지 않은 경우 최대 전송 단위(MTU) 신호가 최대 전송 단위(MTU) inet 신호가 전송됩니다.

최대 전송 단위(MTU) RSVP 제한으로 시그널링 지원

RSVP에서 최대 전송 단위(MTU) 시그널링에 대한 제한은 다음과 같습니다.

  • 최대 전송 단위(MTU) 변경하면 다음과 같은 상황에서 트래픽이 일시적으로 손실될 수 있습니다.

    • 링크 보호 및 노드 최대 전송 단위(MTU) 우회가 활성화될 때만 우회의 신호가 전송됩니다. 새로운 경로가 전파되는 최대 전송 단위(MTU) 불일치로 인하여 패킷 손실이 발생할 최대 전송 단위(MTU) 있습니다.

    • Fast Reroute의 경우, 최대 전송 단위(MTU) 활성화된 후에 경로의 경로가 업데이트되어 ingress 라우터의 최대 전송 단위(MTU) 업데이트가 지연됩니다. 패킷 최대 전송 단위(MTU) 불일치가 발생할 경우 패킷 손실이 발생할 최대 전송 단위(MTU) 있습니다.

      두 경우 모두 우회 또는 우회보다 큰 패킷만 최대 전송 단위(MTU) 손실됩니다.

  • 소프트웨어가 최대 전송 단위(MTU) 넥스 홉에서 변경을 트리거합니다. 다음 홉에서 변경하면 경로 통계가 손실됩니다.

  • RSVP 최대 전송 단위(MTU) 시그널링을 위해 지원되는 최대 전송 단위(MTU) 최소 1,488비트입니다. 이 값으로 인해 잘못된 값 또는 잘못 구성된 값이 사용되는 것을 방지할 수 있습니다.

  • 단일 홉 LSP의 경우 명령에 최대 전송 단위(MTU) 값을 show RSVP 신호 값입니다. 그러나 이 MPLS 무시되고 올바른 IP 값이 사용됩니다.

출시 내역 표
릴리스
설명
16.1
릴리스 16.Junos OS 시작하여 FRR(Fast Reroute) 보호를 위해 RI-RSVP(Refresh-interval Independent RSVP) 정의 RFC 8370을 지원하는 RSVP 트래픽 엔지니어링(트래픽 엔지니어링(TE)) 프로토콜 확장이 도입되어 LSP(Label-Switched Path)의 확장성이 더욱 빨라지고 주기적인 갱신 시 RSVP 시그널링 메시지 오버헤드를 감소합니다.