자원 예약 프로토콜

Resource Reservation Protocol

RSVP(Resource Reservation Protocol)는 통합 서비스 모델을 사용하여 네트워크를 통해 리소스를 예약하도록 설계된 전송 계층[1] 프로토콜입니다.RSVP 는 IPv4 또는 IPv6 상에서 동작해, 멀티 캐스트 또는 유니캐스트 데이터 플로우의 자원 예약의 리시버 개시 셋업을 제공합니다.응용 프로그램 데이터를 전송하지 않지만 ICMP(Internet Control Message Protocol) 또는 IGMP(Internet Group Management Protocol)와 같은 제어 프로토콜과 유사합니다.RSVP에 대해서는, 을 참조해 주세요. RFC2205.

RSVP는 호스트 및 라우터에서 응용 프로그램 데이터 스트림의 특정 Quality of Service(QoS; 서비스 품질)를 요구 또는 제공하기 위해 사용할 수 있습니다.RSVP는 응용 프로그램이 예약을 수행하는 방법과 예약된 리소스를 더 이상 필요하지 않게 되면 포기하는 방법을 정의합니다.RSVP 동작은 일반적으로 경로를 따라 각 노드에서 리소스가 예약됩니다.RSVP는 라우팅 프로토콜이 아니지만 현재 및 미래의 라우팅 프로토콜과 상호 운용되도록 설계되었습니다.

RSVP 자체로는 [citation needed]통신 네트워크에 거의 배치되지 않습니다.2003년에는 텔레트래픽 엔지니어링을 위해 RSVP에서 RSVP-TE로 개발 작업이 변경되었습니다.Next Steps in Signaling(NSIS)은 RSVP를 대체하는 제안입니다.

인터넷 프로토콜 스위트
응용 프로그램레이어
트랜스포트 레이어
인터넷 레이어
링크 레이어

주요 속성

  1. RSVP는 심플렉스 흐름에 대한 리소스를 요구합니다.즉, 송신측에서1개 이상의 수신측으로의 트래픽스트림은 한 방향으로만 이루어집니다.
  2. RSVP는 라우팅 프로토콜이 아니지만 현재 및 미래의 라우팅 프로토콜과 함께 작동합니다.
  3. RSVP는 데이터 흐름의 리시버가 해당 흐름의 자원 예약을 시작하고 유지한다는 점에서 리시버 지향입니다.
  4. RSVP는 호스트 및 라우터의 자원 예약 소프트 스테이트(각 노드에서의 예약은 정기적으로 갱신할 필요가 있습니다)를 유지하므로 네트워크 변경에 대한 동적 자동 적응을 지원합니다.
  5. RSVP는 몇 가지 예약 스타일(예약 옵션 세트)을 제공하며, 다양한 애플리케이션에 맞게 프로토콜 개정판에 향후 스타일을 추가할 수 있습니다.
  6. RSVP는 RSVP에 [further explanation needed]불투명한 트래픽 및 정책 제어 파라미터를 전송 및 유지합니다.

이력 및 관련 기준

RSVP의 기본 개념은 [2]1993년에 처음 제안되었습니다.

RSVP에 대해서는 IETF의 일련의 RFC 문서에 기재되어 있습니다.

  • RFC 2205:버전 1의 기능 사양은 IETF의 RFC 2205(1997년 9월)에 기술되어 있습니다.버전 1에서는 자원 가용성에 근거한 어드미션(트래픽) 제어에 대한 인터페이스가 설명되고 있습니다.이후 RFC2750에서는 어드미션컨트롤 지원이 확장되었습니다.
  • RFC 2210에서는 제어부하의 RFC 2211 및 보증된 RFC 2212 QoS 제어 서비스와 함께 RSVP의 사용이 정의되어 있습니다.자세한 내용은 통합 서비스를 참조하십시오.또한 RFC 2205에서 RSVP에 의해 정의된 데이터 오브젝트(리소스 예약 정보를 전송하는 것)의 사용방법 및 데이터 형식을 정의합니다.
  • RFC 2211은 제어부하 서비스를 제공하기 위해 필요한 네트워크 요소의 동작을 규정합니다.
  • RFC 2212에서는 보증된QoS 서비스를 제공하기 위해 필요한 네트워크 요소의 동작이 규정되어 있습니다.
  • RFC 2750에서는 RSVP에서 범용 정책 기반 어드미션 제어를 지원하기 위해 제안된 확장에 대해 설명하고 있습니다.확장 기능에는 정책 개체의 사양과 정책 이벤트 처리에 대한 설명이 포함되어 있습니다.(2000년 1월).
  • RFC 3209, "RSVP-TE: LSP 터널용 RSVP 확장"(2001년 12월)
  • RFC 3473 "Generalized Multi-Protocol Label Switching(GMPLS) Signaling ReserVation Protocol-Traffic Engineering(RSVP-TE) 확장"(2003년 1월)
  • RFC 3936 "Resource reServeration Protocol (RSVP)" (2004년 10월)에서는 현재의 베스트 프랙티스에 대해 설명하고 RSVP를 변경하는 절차를 규정하고 있습니다.
  • RFC 4495 "예약 흐름 대역폭 감소를 위한 Resource Reservation Protocol (RSVP) Extension" (2006년 5월)는 예약을 해체하는 대신 기존 예약 대역폭을 줄일 수 있도록 RSVP를 확장합니다.
  • RFC 4558 "Node-ID Based Resource Reservation Protocol (RSVP) Hello: 설명문" (2006년 6월)

주요 개념

RSVP 예약 모델의 2가지 주요 개념은 flowspec과 filterspec입니다.

플로우 스펙

RSVP는 플로우의 자원을 예약합니다.플로우는, 행선지 주소, 프로토콜 식별자, 및 옵션으로 행선지 포토에 의해서 식별됩니다.Multiprotocol Label Switching(MPLS)에서는 플로우는 Label Switched Path(LSP; 라벨 스위치드 패스)로 정의됩니다.또한 RSVP는 흐름별로 흐름에서 필요한 특정 Quality of Service(QoS; 서비스 품질)도 식별합니다.이 QoS 정보는 flowspec이라고 불리며 RSVP는 flowspec을 응용 프로그램에서 경로를 따라 호스트 및 라우터에 전달합니다.그런 다음 이러한 시스템은 플로우 스펙을 분석하여 리소스를 수용하고 예약합니다.flowspec은 다음과 같이 구성됩니다.

  1. 서비스 클래스
  2. 예약 사양 - QoS를 정의합니다.
  3. 트래픽 사양 - 데이터 흐름을 설명합니다.

필터 사양

filterspec은 flowspec(flowspec에 의해 정의된QoS를 수신하는 데이터 패킷)의 영향을 받는 패킷 세트를 정의합니다.filterspec은 보통 노드에 의해 처리되는 모든 패킷의 서브셋을 선택합니다.패킷의 임의의 속성(송신측의 IP 주소나 포토등)에 의해서 선택할 수 있습니다.

현재 정의되어 있는 RSVP 예약 스타일은 다음과 같습니다.

  1. 고정 필터 - 특정 흐름에 대한 리소스를 예약합니다.
  2. Shared explicit - 여러 흐름에 대한 리소스를 예약하여 모든 리소스를 공유합니다.
  3. 와일드카드 필터 - 플로우를 지정하지 않고 일반적인 흐름 유형을 위해 리소스를 예약합니다.모든 흐름은 리소스를 공유합니다.

RSVP 예약 요구는 flowspec과 filterspec으로 구성되며 이 쌍을 flowdescriptor라고 합니다.flowspec은 노드에 패킷스케줄러의 파라미터를 설정하고 filterspec은 패킷 분류자로 파라미터를 설정합니다.

메시지

메시지에는 주로 다음 두 가지 유형이 있습니다.

  • 경로 메시지(경로)
패스 메시지는 송신원호스트로부터 데이터 패스를 따라서 송신되어 패스의 각 노드에 패스 상태가 보존됩니다.
경로 상태에는 이전 노드의 IP 주소와 일부 데이터 개체가 포함됩니다.
  1. Filterspec[3] 형식으로 보낸 사람 데이터 형식을 설명하는 보낸 사람 템플릿
  2. sender tspec을 사용하여 데이터 흐름의 트래픽 특성을 설명합니다.
  3. 애드버타이즈 데이터를 전송하는 adspec(자세한 내용은 RFC 2210 참조).
  • 예약 메시지(예약)
resv 메시지는 리시버에서 송신원호스트에 리버스 데이터 패스를 따라서 송신됩니다.각 노드에서 resv 메시지의 IP 수신처 주소는 리버스 패스 상의 다음 노드 주소로, IP 소스 주소는 리버스 패스 상의 이전 노드 주소 주소로 변경됩니다.
resv 메시지에는 플로우에 필요한 리소스를 식별하는 flowspec 데이터 개체가 포함됩니다.

RSVP 메시지의 데이터 객체는 임의의 순서로 전송할 수 있습니다.RSVP 메시지 및 데이터 객체의 전체 목록은 RFC 2205를 참조하십시오.

작동

특정 QoS를 사용하여 데이터 플로우를 전송해야 하는 RSVP 호스트는 30초마다 RSVP 경로메시지를 전송합니다.이 메시지는 현용 라우팅 프로토콜에 의해 사전에 확립된 유니캐스트루트 또는 멀티캐스트루트를 따라 전송됩니다경로 메시지가 RSVP를 이해하지 못하는 라우터에 도착하면 해당 라우터는 메시지 내용을 해석하지 않고 메시지를 전송하고 흐름용 리소스를 예약하지 않습니다.

재생을 원하는 사용자는 대응하는 resv(예약 줄임말) 메시지를 전송하고, 이 메시지는 송신자에게 경로를 추적합니다.resv 메시지에 flowspec이 포함되어 있습니다.resv 메시지에는 filterspec 오브젝트도 있습니다.flowspec에서 정의된 요청된QoS를 수신하는 패킷을 정의합니다.단순한 필터 사양은, 송신자의 IP 주소 뿐만이 아니라, 옵션으로 UDP 또는 TCP 포토도 사용할 수 있습니다.라우터는 RSVP resv 메시지를 수신하면 다음과 같이 됩니다.

  1. 요청 매개 변수를 기준으로 예약하십시오.어드미션 제어는 요구 파라미터를 처리하여 패킷 분류자에게 선택한 데이터 패킷의 서브셋을 올바르게 처리하도록 지시하거나 패킷 처리 방법을 상위 레이어와 네고시에이트할 수 있습니다.가 지원되지 않을 경우 거부 메시지가 전송되어 청취자에게 알립니다.
  2. 요구를 업스트림(송신측의 방향)으로 전송합니다.각 노드에서 resv 메시지 내의 플로우 스펙은 전송 노드에 의해 변경할 수 있다(예를 들어 멀티캐스트플로우 예약의 경우 예약 요구를 Marge할 수 있다).
  3. 다음으로 라우터는 흐름의 특성을 저장하고 필요에 따라 흐름 사양에 따라 폴리싱을 설정합니다.

일정 시간 동안 아무 소리도 들리지 않으면 예약이 타임아웃되어 취소됩니다.이것에 의해, 최초로 예약을 취소하지 않고, 송신측 또는 수신측 중 하나가 크래시 하거나 셧다운 되었을 경우에 문제가 해결됩니다.

기타 기능

무결성
RSVP 메시지에는 메시지 다이제스트알고리즘(통상 MD5)을 사용하여 메시지내용과 공유키를 조합하여 작성된 메시지 다이제스트가 부가됩니다.키는 무결성 챌린지 요구와 무결성 챌린지 응답의 두 가지 메시지유형을 사용하여 배포 및 확인할 수 있습니다.
에러 리포트
노드가 오류를 검출하면 오류 메시지가 오류 코드와 함께 생성되어 역경로로 송신자에게 전파됩니다.
RSVP 흐름에 관한 정보
네트워크 오퍼레이터는 2종류의 진단 메시지를 사용하여 특정 흐름에 대한 RSVP 상태 정보를 요구할 수 있습니다.
진단 설비
사용자가 [4]경로를 따라 RSVP 상태에 대한 정보를 수집할 수 있는 표준 확장입니다.

RFC

레퍼런스

  1. ^ Garrett, Aviva; Drenan, Gary; Morris, Cris (2002). Juniper Networks Field Guide and Reference. p. 583. ISBN 9780321122445.
  2. ^ 장, L, 디어링, S., 에스트린, D., 셴커, S., D.Zappala, "RSVP: 새로운 자원 재서비스 프로토콜", IEEE Network, 1993년 9월
  3. ^ Lixia, Zhang; Steve, Berson; Shai, Herzog; Sugih, Jamin (September 1997). Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification. p. 19. doi:10.17487/RFC2205. RFC 2205.
  4. ^ RSVP Diagnostic Messages. doi:10.17487/RFC2745. RFC 2745.
  • John Evans; Clarence Filsfils (2007). Deploying IP and MPLS QoS for Multiservice Networks: Theory and Practice. Morgan Kaufmann. ISBN 978-0-12-370549-5.

외부 링크