RSVP 개요

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

• 일방향 데이터 흐름에 대한 리소스 예약이 이루어집니다.

• 그림 1에서 보여지는 것과 같이 데이터 플로우의 수신자가 해당 플로우에 사용되는 리소스 예약을 시작하고 유지하도록 허용합니다.

• 라우터와 호스트에 소프트 상태를 유지하며 동적 회원 변경 및 라우팅 변경에 대한 자동 적응이 원활하도록 지원합니다.

• 이는 현재 및 향후 라우팅 프로토콜에 따라 다르지만 라우팅 프로토콜 자체는 아닙니다.

• 다양한 응용 프로그램에 적합한 몇 가지 예약 모델 또는 스타일을 제공합니다.

• RSVP-signed LSP에서 전송할 수 있는 IPv4와 IPv6 패킷을 모두 지원합니다.

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

RSVP는 각 데이터 플로우 처리를 위해 독립적인 세션을 만듭니다. 세션은 대상 주소, 선택적 대상 포트 및 프로토콜의 조합에 의해 식별됩니다. 세션 내에서 하나 이상의 발신자가 있을 수 있습니다. 각 발신자는 발신자 주소 및 포트의 조합으로 식별됩니다. 세션 공표 프로토콜 또는 인간 커뮤니케이션과 같은 대역 외 메커니즘은 세션 식별자를 모든 발신자 및 수신자에게 전달합니다.

전형적인 RSVP 세션은 다음과 같은 이벤트의 시퀀스가 포함됩니다:

1. 잠재적 발신자는 RSVP 경로 메시지를 세션 주소로 보냅니다.

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

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

4. 수신자는 발신자에게 적절한 Resv 메시지를 보냅니다. 이러한 메시지는 링크 계층 미디어에 예약하기 위해 경로를 따라 라우터에 의해 사용되는 플로우 서술자를 전달합니다.

5. 발신자는 Resv 메시지를 수신하고 애플리케이션 데이터를 보내기 시작합니다.

이 이벤트 시퀀스는 반드시 동기화되지는 않습니다. 예를 들어, 수신자는 발신자로부터 경로 메시지를 받기 전에 자신을 등록할 수 있으며, 애플리케이션 데이터는 발신자가 Resv 메시지를 받기 전에 플로우 할 수 있습니다. Resv 메시지에 포함된 실제 예약에 앞서 전달되는 애플리케이션 데이터는 일반적으로 CoS(class of service) 보장이 없는 비실시간 최선의 트래픽으로 처리됩니다.

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

기본 RSVP 세션은 LDP 세션을 설정한 것과 정확히 동일한 방식으로 설정됩니다. 적절한 전송 인터페이스에 MPLS 및 RSVP를 구성함으로써 RSVP 패킷과 LSP 설정을 교환할 수 있습니다. 그러나 RSVP를 통해 링크 인증, 명시적인 LSP 경로, 링크 색상을 구성할 수 있습니다.

이러한 주제에는 다음 섹션이 포함됩니다.

• RSVP 기본 사항
• 대역폭 예약 요구 사항
• ERO(Explicit Route Objects)
• CSPF(Constrained Shortest Path First)
• 링크 색상 지정

ERO(Explicit Route Objects)

ERO(Explicit Route Objects)는 LSP의 특정 목록에 대한 LSR 경로를 제한합니다. 기본적으로 RSVP 메시지는 네트워크 IGP의 가장 짧은 경로에 의해 결정되는 경로를 따릅니다. 그러나 구성된 ERO가 있는 경우, RSVP 메시지는 지정된 경로를 따릅니다.

ERO는 두 가지 유형의 지침으로 구성됩니다. 느슨한 홉 및 엄격한 홉. 느슨한 홉을 구성한 경우, 하나 이상의 전송 LSR을 식별하며 이를 통해 LSP가 라우팅되어야 합니다. 네트워크 IGP는 인바운드 라우터에서 첫 번째 느슨한 홉까지 또는 느슨한 홉에서 다음 홉까지 정확한 경로를 결정합니다. 느슨한 홉은 특정 LSR이 LSP에 포함되도록 지정합니다.

엄격한 홉을 구성할 경우, 정확한 경로를 식별하며 이를 통해 LSP가 라우팅되어야 합니다. 엄격함 홉 ERO는 라우터의 정확한 순서를 지정하며 이를 통해 RSVP 메시지가 전송됩니다.

느슨한 홉과 엄격한 홉 ERO를 동시에 구성할 수 있습니다. 이 경우에서, IGP는 느슨한 홉 간의 경로를 결정하고 엄격한 홉 구성은 특정 LSP 경로 세그먼트에 대한 정확한 경로를 지정합니다.

그림 2은(는) ERO를 사용하는 표준 RSVP 신호 LSP를 보여줍니다.

그림 2: ERO가 있는 표준 RSVP 신호 LSP

그림 2에 제시되어 있는 토폴로지에서, 호스트 C1로부터 호스트 C2까지 트래픽이 라우팅됩니다. LSP는 라우터 R4 또는 라우터 R7을 통과할 수 있습니다. LSP가 R4를 사용하도록 하면 느슨한 홉이나 LSP에서 R4를 홉으로 지정하는 엄격한 홉 ERO 중 하나를 설정할 수 있습니다. 라우터 R4, R3 및 R6을 통해 특정 경로를 강제로 지정하면 3개의 LSR을 통해 엄격한 홉 ERO를 구성할 수 있습니다.

Junos OS 릴리스 16.1부터 Fast Reroute(FRR) 시설 보호를 위해 RI-RSVP(리프레시 간격 독립 RSVP) 정의 RFC 8370을 지원하기 위한 RSVP 트래픽 엔지니어링(TE) 프로토콜 확장이 도입되어 레이블 스위치 경로(LSP)의 확장성이 더 커지고 컨버전스 시간이 더 빨라지며, 주기적인 리프레시의 RSVP 신호 메시지 오버헤드가 감소합니다. Junos RSVP-TE는 원래 RFC 4090에서 지정된 FRR 시설 바이패스의 RI-RSVP를 지원하기 위한 프로토콜 확장을 포함하는 향상된 FRR, 일명 RI-RSVP 모드에서 실행되는 것이 기본값입니다.

Junos에서 구현된 RI-RSVP 프로토콜 확장은 양방향으로 호환 가능합니다. LSP 하위 집합이 이 기능을 포함하지 않는 노드를 트래버스하는 혼합 환경에서, 향상된 FRR 모드에서 실행되는 Junos RSVP-TE는 새로운 확장을 지원하지 않는 노드와의 신호 교환에서 새 프로토콜 확장을 자동으로 끕니다.

향상된 FRR 프로필의 일환으로, 여러 변경이 이루어지고 새로운 기본값이 채택되었습니다. 그 내용은 다음과 같습니다.

• RSVP-TE는 확장 시나리오를 용이하게 하는 개선이 포함된 "향상된" FRR 또는 RI-RSVP 모드를 기본적으로 실행합니다. 이 새로운 프로토콜 확장은 no-enhanced-frr-bypass 명령으로 라우터에서 비활성화될 수 있습니다.

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

  주:

  향상된 FRR 또는 RI-RSVP 확장에서 Node-id 기반 Hello 메시지 교환이 필요하기 때문에, Node-id 기반 Hello는 기본적으로 활성화됩니다. Node-id 기반 Hello는 node-hello 명령으로 비활성화될 수 있습니다. 리프레시 감소 확장 및 node-id 기반 Hello 메시지는 향상된 FRR 또는 RI-RSVP 확장에 필수이며, 이들 중 하나를 비활성화하면 노드에서 향상된 FRR 확장이 자동으로 꺼집니다.

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

• keep-multiplier의 기본 값은 3으로 새로운 기본 리프레시 시간에 적용됩니다.

• 로컬 복귀는 기본적으로 비활성화됩니다. 노드 Hello에 대한 기존 CLI 구성인 [edit protocols rsvp node-hello]은(는) 여전히 사용할 수 있지만 동작이 중복됩니다. 활성화되면, 구성이 향상된 FRR과 연동하지 않아도 된다는 메시지가 표시됩니다.

• 메시지 신뢰성을 비활성화하는 기존 명령은 이제 RSVP 리프레시 감소를 비활성화하는 데 사용됩니다. 이전의 기본 활성화 리프레시 기간 감소로 되돌리려면, 다음 명령의 delete 버전을 사용합니다:

  • 주어진 인터페이스에 no-reliable을(를) 설정하여 인터페이스를 트래버스하는 모든 LSP에 대한 자동 FRR 확장 개선을 비활성화합니다. 마찬가지로 FRR 시설 보호 개선과 리프레시 감소 없이 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) 주소를 보여줍니다.

• 메시지 묶음을 활성화하거나 비활성화하는 이전 CLI 구성 옵션이 사용되지 않습니다(기존 구성은 수락되지만, 표시 구성 출력에 경고가 나타납니다). 이러한 명령은 다음과 같습니다:

  • [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 구성 옵션은 현재 변경에 의해 중복되었습니다(기존 구성은 수락되지만, 표시 구성 출력에 경고가 나타납니다):

  • [edit protocols rsvp interface name reliable]

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

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

Junos RSVP 소프트웨어의 주요 목적은 MPLS LSP(Label-Switched Path) 내에서 동적 신호를 지원하는 것입니다. 인터넷을 통한 리소스 예약 지원은 Junos OS 구현의 보조 목적일 뿐입니다. 리소스 예약 지원은 보조이므로, Junos RSVP 소프트웨어는 다음 기능을 지원하지 않습니다:

• IP 멀티캐스팅 세션.

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

지원되는 프로토콜 메커니즘, 패킷 처리 및 RSVP 객체와 관련해서, 소프트웨어의 Junos OS 구현은 다른 RSVP 구현과 상호 운용됩니다.

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

RSVP는 내부 게이트웨이 프로토콜(IGP) (IS-IS 또는 OSPF) 이웃의 상태를 모니터링하고, IGP 프로토콜에 의존하여 노드 실패를 감지합니다. IGP 프로토콜이 이웃의 중단을 선언하면(Hello 패킷이 더 이상 수신되지 않기 때문에), RSVP 또한 해당 이웃을 중단합니다. 그러나 이웃이 중단되어도 IGP 프로토콜과 RSVP는 여전히 독립적으로 작동합니다.

Junos OS에서 RSVP는 일반적으로 노드 실패를 확인하는 IGP 헬로 패킷 감지에 의존합니다. IS-IS 또는 OSPF 헬로 타이머에 대해 짧은 시간을 구성하면 이러한 프로토콜이 노드 실패를 신속하게 감지할 하도록 허용합니다. 노드가 실패하거나 노드 실패가 감지되면 경로 오류 메시지가 생성되고 RSVP 세션이 다운되더라도 IGP 이웃은 유지됩니다.

IGP가 특정 이웃을 인식하지 않을 때(예: IGP가 인터페이스에서 활성화되지 않은 경우) 또는 IGP가 RIP인 경우(IS-IS 또는 OSPF가 아님) RSVP Hello에 의존할 수 있습니다. 또한 다른 공급자의 장비를 구성하여 RSVP Hello 패킷에 따라 RSVP 세션을 모니터링할 수도 있습니다. 이 장비도 RSVP Hello 패킷의 손실으로 인해 RSVP 세션을 다운시킬 수 있습니다.

짧은 RSVP Hello 타이머를 구성하는 것을 권장하지 않습니다. 실패한 이웃을 빨리 발견해야 할 경우, 짧은 IGP (OSPF 또는 IS-IS) 헬로 타이머를 구성하십시오.

최단 경로 우선(OSPF) 및 IS-IS(Intermediate System to Intermediate System)는 라우팅 프로토콜 또는 일부 다른 프로세스가 라우터 처리 능력을 제한하는 경우라도 안정적으로 신속한 헬로 메시지 송수신을 관리하는 인프라를 가지고 있습니다. 같은 상황에서, RSVP Hello는 이웃이 정상적으로 작동하더라도, 조기에 시간 초과될 수 있습니다.

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

• 경로 메시지
• Resv 메시지
• PathTear 메시지
• ResvTear 메시지
• PathErr 메시지
• ResvErr 메시지
• ResvConfirm 메시지

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

네트워크에 새로운 라우터를 추가해야 하는 경우 요구 사항이 조금 다릅니다. BGP 및 MPLS VPN은 BGP 세션의 풀 메시와 네트워크의 모든 PE 라우터 간 PE 라우터-투-PE 라우터 MPLS 레이블 스위치 경로(LSP)의 풀 메시를 요구합니다. 네트워크에 새로운 라우터를 추가하는 경우, 기존 PE 라우터는 모두 새로운 PE 라우터의 피어로 재구성되어야 합니다. MPLS의 신호 프로토콜로 BGP 경로 리플렉터를 구성하면(BGP 풀 메시 요구 사항 완화) 구성 노력의 많은 부분을 줄일 수 있습니다.

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

RSVP는 Fast reroute, 엔드포인트 제어 및 링크 관리를 포함해 LDP에서 가능하지 않은 수많은 기능을 포함합니다. RSVP 자동 메시는 RSVP의 운영 및 관리 요구 사항을 줄이는 데 도움을 제공해, 더 크고 복잡한 네트워크에서 RSVP를 구축할 수 있습니다.

이 정보는 IGP에 의해 배포되므로, 모든 PE 라우터는 네트워크 내 다른 모든 PE 라우터에 도달할 수 있습니다. PE 라우터는 LSP가 필요하다는 것을 아는 한 네트워크의 다른 PE 라우터로 포인트 투 포인트 RSVP LSP를 설정할 수 있습니다. PE 라우터 간에 LSP의 풀 메시를 구축하려면 각 PE 라우터가 다른 PE 라우터 중 어떤 것이 풀 메시를 구성하는지 알아야 합니다.

예약 요청에는 예약 스타일을 지정하는 옵션이 포함됩니다. 예약 스타일은 동일한 세션 내에서 다양한 발신자에 대한 예약이 어떻게 처리되고 발신자가 어떻게 선택되는지를 정의합니다.

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

• 개별 예약 - 각 수신자가 각 업스트림 발신자와 자체 예약을 설정합니다.

• 공유 예약 - 모든 수신자가 여러 발신자 사이에 공유되는 단일 예약을 만듭니다.

두 옵션은 발신자가 어떻게 선택되는지 지정합니다.

• 명시적 발신자 - 선택된 모든 발신자를 나열합니다.

• 와일드카드 발신자 - 모든 발신자를 선택하고, 이들이 세션에 참여합니다.

이러한 네 가지 옵션의 조합에 의해 형성된 다음 예약 스타일은 현재 다음과 같이 정의됩니다.

• 고정 필터(FF) - 이 예약 스타일은 명시적 발신자 간의 개별 예약으로 구성됩니다. 고정 필터 스타일 예약을 사용하는 응용 프로그램의 예는 비디오 응용 프로그램 및 유니캐스트 응용 프로그램이며, 두 가지 모두 각 발신자에 대해 별도의 예약을 가진 흐름이 필요합니다. 고정 필터 예약 스타일은 기본적으로 RSVP LSP에서 활성화됩니다.

• 와일드카드 필터(WF) - 이 예약 스타일은 와일드카드 발신자 간의 공유 예약으로 구성됩니다. 이러한 유형의 예약은 모든 발신자에 대한 대역폭을 예약하고, 모든 발신자에게 업스트림을 전파하여 새로운 발신자가 나타날 때 이들로 확장됩니다. 와일드카드 필터 예약에 대한 샘플 응용 프로그램은 각 발신자가 개별 데이터 스트림을 전송하는 애플리케이션 오디오 응용 프로그램입니다. 일반적으로 소수의 발신자가 한 번에 전송합니다. 이러한 플로우는 각 발신자가 별도의 예약을 하지 않아도 되며, 단일 예약이면 충분합니다.

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

RSVP는 각 라우터에서 경로 및 예약 상태를 유지하는 데 소프트 상태에 의존합니다. 해당되는 새로 고침 메시지가 주기적으로 전송되지 않으면 상태는 결국 시간 초과되고 예약이 삭제됩니다. RSVP는 또한 제어 메시지를 안정성이 보장되지 않는 IP 데이터그램으로 보냅니다. 가끔 발생하는 경로 또는 예약 메시지 손실을 처리하는 데 주기적인 새로 고침 메시지에 의존하고 있습니다.

RFC 2961을 기반으로 하는 RSVP 새로 고침 감소 확장은 주기적인 새로 고침 메시지에 의존하여 메시지 손실을 처리하는 데서 비롯되는 다음과 같은 문제를 해결해 줍니다.

• 확장성 - 확장성 문제는 RSVP 세션이 늘어나면서 증가하게 되는 새로 고침 메시지의 주기적인 전송 및 처리 오버헤드에서 발생합니다.

• 안정성 및 지연 - 안정성 및 지연 문제는 PathTear나 PathErr와 같은 일회성 RSVP 메시지 또는 새로 고침이 아닌 RSVP 메시지의 손실에서 유발됩니다. 이러한 손실에서 회복하는 시간은 보통 새로 고침 간격 및 킵얼라이브 타이머와 연관되어 있습니다.

RSVP 새로 고침 감소 기능은 RSVP 공통 헤더에서 새로 고침 감소(RR) 가능 비트를 활성화하여 광고됩니다. 이 비트는 RSVP 이웃 간에만 중요합니다.

RSVP 새로 고침 감소에는 다음과 같은 기능이 포함됩니다.

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

• 메시지 처리 오버헤드를 줄이기 위한 RSVP 메시지 ID

• 메시지 ID, 메시지 ACK 및 메시지 NACK를 사용하는 안정적인 RSVP 메시지 전달

• 모든 새로 고침 간격마다 전송되는 정보의 양을 줄이기 위한 요약 새로 고침

RSVP 새로 고침 감소 사양(RFC 2961)을 사용하면 라우터에서 위와 같은 기능의 일부 또는 전부를 활성화하실 수 있습니다. 또한 라우터가 이웃의 새로 고침 감소 기능을 탐지하는 데 사용할 수 있는 다양한 절차도 설명되어 있어 유용합니다.

Junos OS는 모든 새로 고침 감소 확장을 지원하며, 이중 일부를 선택적으로 활성화 또는 비활성화할 수 있습니다. Junos OS는 메시지 ID를 지원하므로 경로 또는 예약 메시지에 대해서만 안정적인 메시지 전달을 수행할 수 있습니다.

RSVP 새로 고침 감소를 구성하는 방법에 대한 자세한 정보는 RSVP 새로 고침 감소 구성을 참조하십시오.

최대 전송 단위(MTU)는 네트워크에서 전송할 수 있는 바이트 단위의 가장 큰 크기의 패킷 또는 프레임입니다. MTU가 너무 크면 재전송이 발생할 수 있습니다. MTU가 너무 작으면 라우터가 상대적으로 더 많은 헤더 오버헤드와 확인을 전송하고 처리하게 될 수 있습니다. 다양한 프로토콜과 관련된 MTU에 대한 기본 값이 있습니다. 또한 인터페이스에 최대 전송 단위(MTU)를 명시적으로 구성할 수도 있습니다.

다양한 최대 전송 단위(MTU) 크기를 가진 일련의 링크에 걸쳐 LSP가 생성되면, 수신 라우터는 LSP 경로에 있는 최소 MTU를 모릅니다. 기본적으로 LSP의 MTU는 1,500바이트입니다.

MTU가 중간 링크 중 하나의 MTU보다 크다면, MPLS 패킷이 단편화될 수 없기 때문에 트래픽 누락이 발생할 수 있습니다. 또한 수신 라우터는 LSP에 대한 컨트롤 플레인이 여전히 정상적으로 작동하기 때문에 이러한 유형의 트래픽 손실을 인식하지 않습니다.

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

MTU 불일치로 인한 패킷 손실을 피하려면 수신 라우터가 다음을 수행해야 합니다.

• RSVP LSP에서 MTU 시그널링 - MTU 불일치로 인한 패킷 손실을 방지하기 위해 수신 라우터는 LSP가 취한 경로를 따라 가장 작은 MTU 값이 무엇인지 알아야 합니다. 이 MTU 값이 구해지면 수신 라우터는 이를 LSP에 할당할 수 있습니다.

• 패킷 단편화 - 할당된 MTU 값을 사용하면 MTU 크기를 초과하는 패킷은 MPLS 내에 캡슐화되어 RSVP 시그널링 LSP를 통해 전송되기 전에 수신 라우터 내에서 작은 패킷으로 단편화될 수 있습니다.

수신 라우터에서 MTU 시그널링 및 패킷 단편화가 모두 활성화되면, 이 라우터에서 RSVP LSP로 해결되는 모든 경로는 시그널링된 MTU 값을 사용합니다. 이 기능을 구성하는 방법에 대한 정보는 RSVP에서 MTU 시그널링 구성을 참조하십시오.

다음 섹션은 RSVP에서 MTU 시그널링이 어떻게 작동하는지 설명합니다:

• RSVP에서 정확한 최대 전송 단위(MTU)가 시그널링되는 방법

• 나가는 최대 전송 단위(MTU) 값 결정

• RSVP 제한에서의 최대 전송 단위(MTU) 시그널링

RSVP에서 올바른 MTU가 시그널링되는 방법은 네트워크 장치(예: 라우터)가 RSVP에서 MTU 시그널링을 명시적으로 지원하는지 여부에 따라 다릅니다.

네트워크 디바이스가 RSVP에서 MTU 시그널링을 지원하는 경우 MTU 시그널링을 활성화하면 다음 상황이 발생합니다.

• MTU는 Adspec 개체를 통해 수신 라우터에서 송신 라우터로 시그널링됩니다. 이 개체를 포워딩하기 전에 수신 라우터는 경로 메시지가 전송되는 인터페이스에 연결된 MTU 값을 입력합니다. 경로의 각 홉에서 Adspec 개체의 MTU 값은 수신된 최소값과 발신 인터페이스의 값으로 업데이트됩니다.

• 수신 라우터는 트래픽 사양(Tspec) 개체를 사용하여 전송할 트래픽에 대한 매개 변수를 지정합니다. 수신 라우터에서 Tspec 개체에 시그널링된 MTU 값은 최대 MTU 값(M 시리즈 및 T 시리즈 라우터의 경우 9192바이트, PTX 시리즈 패킷 전송 라우터의 경우 9500바이트)입니다. 이 값은 송신 라우터로 향하는 중에 변경되지 않습니다.

• Adspec 개체가 송신 라우터에 도달하면 MTU 값이 경로에 대해 정확합니다(즉, 발견된 가장 작은 MTU 값). 송신 라우터는 Adspec 개체의 MTU 값을 Tspec 개체의 MTU 값과 비교합니다. Resv 메시지의 Flowspec 개체를 사용하여 더 작은 MTU를 시그널링합니다.

• Resv 개체가 수신 라우터에 도달하면, 이 개체의 MTU 값이 LSP를 사용하는 다음 홉에 대해 MTU로 사용됩니다.

RSVP에서 MTU 시그널링을 지원하지 않는 디바이스가 있는 네트워크에서 다음과 같은 동작이 발생할 수 있습니다.

• 송신 라우터가 RSVP에서 MTU 시그널링을 지원하지 않는 경우, MTU는 기본적으로 1,500바이트로 설정됩니다.

• RSVP에서 MTU 시그널링을 지원하지 않는 주니퍼 네트웍스 전송 라우터는 기본적으로 Adspec 개체에서 MTU 값을 1,500바이트로 설정합니다.

나가는 최대 전송 단위(MTU) 값은 나가는 인터페이스의 MTU 값과 비교해 Adspec 객체에 수신된 값 중 작은 값입니다. 나가는 인터페이스의 최대 전송 단위(MTU) 값은 다음과 같이 결정됩니다:

• [family mpls]계층 레벨에서 최대 전송 단위(MTU) 값을 구성하는 경우, 이 값은 신호됩니다.

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

다음은 RSVP에서 MTU 시그널링에 대한 제한입니다.

• 최대 전송 단위(MTU) 값의 변화는 다음 상황에서 일시적인 트래픽 손실을 유발할 수 있습니다.

  • 링크 보호 및 노드 보호를 위해 우회 최대 전송 단위(MTU) 는 우회가 활성화되는 시점에서만 시그널링됩니다. 새로운 경로 MTU가 전파하는 데 걸리는 시간 동안 MTU 불일치 때문에 패킷 손실이 발생할 수 있습니다.

  • Fast Reroute의 경우 경로 최대 전송 단위(MTU)는 우회가 활성화된 후에만 업데이트되므로 수신 라우터에서의 MTU 업데이트가 지연됩니다. 최대 전송 단위(MTU)가 업데이트될 때까지 MTU 불일치가 있는 경우 패킷 손실이 발생할 수 있습니다.

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

• 최대 전송 단위(MTU)가 업데이트되면 다음 홉의 변화를 트리거합니다. 다음 홉의 변경은 경로 통계를 손실되게 합니다.

• RSVP에서 최대 전송 단위(MTU) 시그널링 지원 최소 MTU는 1,488바이트입니다. 이 값은 허위 또는 잘못 구성된 전송 값을 사용하지 않도록 합니다.

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