자원 예약 프로토콜
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
자원 예약 프로토콜(RSVP)은 단방향 통신 흐름에 대한 자원 예약을 요청하는 프로토콜이다. 수신자 지향적이며, 소프트 상태 유지를 통해 네트워크 변화에 동적으로 적응한다. RSVP는 라우팅 프로토콜이 결정한 경로를 따라 자원 예약을 수행하며, 다양한 예약 스타일을 제공한다. 핵심 개념으로는 플로우스펙과 필터스펙이 있으며, 이를 통해 QoS를 보장한다. RSVP는 IETF를 통해 여러 RFC 문서로 기술되었으며, 복잡성, 확장성 등의 한계로 인해 대안 프로토콜이 제시되었으나 널리 사용되지는 못했다.
더 읽어볼만한 페이지
- 네트워크 계층 프로토콜 - IPv6
IPv6는 IPv4 주소 고갈 문제를 해결하고자 개발된 차세대 인터넷 프로토콜로, 128비트 주소 체계를 통해 사실상 무한대에 가까운 IP 주소를 제공하며, 주소 자동 설정, 패킷 처리 효율성 향상, 보안 기능 강화 등의 특징을 갖는다. - 네트워크 계층 프로토콜 - X.25
X.25는 CCITT가 1970년대 중반에 개발한 패킷 교환 데이터 통신 표준으로, 가상 회선 서비스 기반의 3계층 구조를 가지며 공중 데이터망의 기반이 되었으나 1990년대 초부터 프레임 릴레이와 TCP/IP로 대체되기 시작하여 현재는 일부 시스템 및 아마추어 무선 분야에서 사용된다. - 인터넷 프로토콜 - IPTV
IPTV는 인터넷 프로토콜을 사용하여 실시간 방송, VOD 등 다양한 콘텐츠를 제공하는 텔레비전 서비스이며, 고속통신망과의 통합, 양방향 서비스 등의 장점을 가지지만 망 사업자 제한 등의 제한 사항도 존재한다. - 인터넷 프로토콜 - DNSSEC
DNSSEC는 DNS의 보안 취약점을 개선하기 위해 도메인 정보에 디지털 서명을 추가하여 응답 레코드의 무결성을 보장하고 DNS 위장 공격을 막는 기술로, RRSIG, DNSKEY 등 다양한 리소스 레코드 유형을 사용하여 인증 체인을 구성하며 공개 키 암호 방식을 활용한다.
| 자원 예약 프로토콜 | |
|---|---|
| 자원 예약 프로토콜 (RSVP) | |
| 유형 | 네트워크 프로토콜 |
| 설명 | QoS (Quality of Service)를 위한 프로토콜 |
| 약어 | RSVP |
| 개발 | IETF |
| RFC | RFC 2205 |
| 상태 | 표준 (Proposed Standard) |
| 관련 프로토콜 | IPv4 IPv6 Integrated Services 프레임 릴레이 ATM |
2. 주요 특성
RSVP는 IP 또는 UDP 상위 프로토콜로 기능하며, 두 컴퓨터 간 통신 경로상의 CPU, 버퍼, 대역폭 등의 자원을 확보하여 QoS을 보장한다. 주로 IntServ QoS 보장 방식을 위해 사용된다. 화상 회의나 실시간 동영상 스트리밍과 같이 즉시성·연속성이 요구되는 시스템에서 일정량의 데이터 전송 속도를 연속적으로 보장하기 위해 개발되었다.
RSVP의 약자는 유럽 및 미국에서 편지 끝에 쓰는 "RSVP"(Répondez s'il vous plaît, 프랑스어로 "회신 부탁드립니다")에 맞춘 것이다.
2. 1. 단방향 데이터 흐름
RSVP는 단방향 통신 흐름, 즉 송신자에서 하나 이상의 수신자로 한 방향으로만 흐르는 트래픽 스트림에 대한 자원을 요청한다. 이는 RSVP가 유니캐스트 및 멀티캐스트 통신 모두에 사용될 수 있음을 의미한다.2. 2. 라우팅 프로토콜과의 협력
RSVP는 자체적인 라우팅 기능을 수행하지 않으며, OSPF, BGP와 같은 기존의 라우팅 프로토콜과 함께 작동한다. RSVP는 라우팅 프로토콜이 결정한 경로를 따라 자원 예약을 수행한다.2. 3. 수신자 기반 동작
RSVP는 데이터 흐름의 수신자가 해당 흐름에 대한 자원 예약을 시작하고 유지 관리한다는 점에서 수신자 지향적이다.[1] 이는 데이터를 받는 측에서 프로토콜을 동작시키고 데이터 흐름에 대한 자원 예약 상태를 관리함을 의미한다. RSVP는 호스트와 라우터의 자원 예약에 대한 소프트 상태(각 노드의 예약은 주기적인 갱신이 필요함)를 유지하므로 네트워크 변경에 대한 동적 자동 적응을 지원한다.[1]2. 4. 소프트 상태 유지
RSVP는 호스트와 라우터의 자원 예약에 대한 소프트 상태를 유지한다. 각 노드의 예약은 주기적인 갱신 메시지(Path 및 Resv)를 통해 유지되며, 네트워크 토폴로지 변화나 장애 발생 시 동적으로 적응할 수 있다.[1]2. 5. 다양한 예약 스타일 지원
RSVP는 다양한 애플리케이션의 요구 사항을 충족하기 위해 여러 예약 스타일(예약 옵션)을 제공한다. 예약 스타일에는 고정 필터(Fixed-Filter), 공유 명시적(Shared-Explicit), 와일드카드 필터(Wildcard-Filter) 등이 있다.[1]2. 6. 트래픽 및 정책 제어
RSVP는 트래픽 및 정책 제어 매개변수를 전송하고 유지 관리한다.[1] 이를 통해 네트워크 관리자는 트래픽 흐름을 제어하고, 네트워크 정책을 적용할 수 있다.3. 핵심 개념
RSVP 예약 모델의 두 가지 핵심 개념은 ''플로우스펙''(flowspec)과 ''필터스펙''(filterspec)이다. RSVP는 인터넷 프로토콜(IP) 또는 UDP 상위 프로토콜로 기능하며, 두 대의 컴퓨터가 통신 경로 상의 CPU, 버퍼, 대역폭 등의 자원을 확보하여 QoS(통신 품질)을 보장한다. 주로 IntServ(인트서브) QoS 보장 방식을 위해 사용된다.
RSVP에서는 송수신 컴퓨터 간에 데이터 통신 시작 시 제어 메시지를 주고받음으로써, 경로 상의 라우터나 스위치가 전송 대역폭을 확보한다. 화상 회의나 실시간 동영상 스트리밍 등에서는 즉시성·연속성이 요구되며, RSVP는 이러한 일정량의 데이터 전송 속도가 연속적으로 필요한 시스템을 위해 개발되었다.
''R''esource re''S''er''V''ation ''P''rotocol이라는 기묘한 약자는 유럽 및 미국에서 편지 끝에 쓰는 "RSVP"(Répondez s'il vous plaît, 프랑스어로 "회신 부탁드립니다")에 맞춘 것이다.
3. 1. 플로우스펙 (Flowspec)
RSVP 예약 모델의 핵심 개념 중 하나인 ''플로우스펙''(flowspec)은 특정 플로우에 필요한 서비스 품질(QoS)을 정의한다.''플로우스펙''은 다음으로 구성된다.
- 서비스 클래스
- 예약 사양 - QoS를 정의한다.
- 트래픽 사양 - 데이터 흐름을 설명한다.
RSVP는 인터넷 프로토콜(IP) 또는 UDP의 상위 프로토콜로 기능하며, 두 대의 컴퓨터가 통신 경로 상의 CPU, 버퍼, 대역폭 등의 자원을 확보하여 QoS(통신 품질)을 보장한다. 주로 IntServ(인트서브) QoS 보장 방식을 위해 사용된다.
3. 2. 필터스펙 (Filterspec)
필터스펙(filterspec)은 플로우스펙(flowspec)에 의해 정의된 QoS를 수신할 데이터 패킷을 정의한다.[1] 필터스펙은 일반적으로 노드에서 처리되는 모든 패킷의 하위 집합을 선택하며,[1] 패킷의 모든 속성(예: 송신자 IP 주소 및 포트)에 따라 선택이 달라질 수 있다.[1]RSVP 예약 요청은 플로우스펙과 필터스펙으로 구성되며, 이 쌍을 플로우 디스크립터(flowdescriptor)라고 한다.[1] 플로우스펙은 노드에서 패킷 스케줄러의 매개변수를, 필터스펙은 패킷 분류기의 매개변수를 각각 설정한다.[1]
3. 3. 예약 스타일
RSVP는 다음과 같은 예약 스타일을 제공한다.- 고정 필터(Fixed Filter, FF): 특정 플로우에 대한 리소스를 예약한다.
- 공유 명시적(Shared Explicit, SE): 여러 플로우에 대한 리소스를 예약하고, 모든 플로우가 리소스를 공유한다.
- 와일드카드 필터(Wildcard Filter, WF): 플로우를 지정하지 않고 일반적인 유형의 플로우에 대한 리소스를 예약한다. 모든 플로우가 리소스를 공유한다.
RSVP 예약 요청은 ''플로우스펙(flowspec)''과 ''필터스펙(filterspec)''으로 구성되며, 이 쌍을 ''플로우 디스크립터(flowdescriptor)''라고 한다. ''플로우스펙''은 노드에서 패킷 스케줄러의 매개변수를 설정하고, ''필터스펙''은 패킷 분류기의 매개변수를 설정한다.
''필터스펙''은 ''플로우스펙''의 영향을 받는 패킷 집합, 즉 플로우스펙에 의해 정의된 QoS를 수신할 데이터 패킷을 정의한다. ''필터스펙''은 일반적으로 노드에서 처리되는 모든 패킷의 하위 집합을 선택하며, 패킷의 모든 속성(예: 송신자 IP 주소 및 포트)에 따라 선택이 달라질 수 있다.
4. 동작 방식
RSVP는 인터넷 프로토콜 (IP) 또는 UDP 상위에서 동작하며, 두 컴퓨터 간 통신 경로 상의 CPU, 버퍼, 대역폭 등의 자원을 예약하여 QoS(통신 품질)을 보장한다. 주로 IntServ (인트서브) QoS 보장 방식을 위해 사용된다.
RSVP는 송수신 컴퓨터 간 데이터 통신 시작 시 제어 메시지를 주고받아 경로 상의 라우터나 스위치가 전송 대역폭을 확보한다. 화상 회의나 실시간 동영상 스트리밍 등 즉시성과 연속성이 요구되는 시스템을 위해 개발되었다.
''R''esource re''S''er''V''ation ''P''rotocol이라는 약자는 유럽 및 미국에서 편지 끝에 쓰는 "RSVP"(Répondez s'il vous plaît, 프랑스어로 "회신 부탁드립니다")에 맞춘 것이다.
4. 1. 경로 설정 및 상태 유지
송신 호스트는 라우팅 프로토콜에 의해 미리 설정된 유니캐스트 또는 멀티캐스트 경로를 따라 30초마다 RSVP ''path''(경로) 메시지를 주기적으로 전송한다. RSVP를 이해하지 못하는 라우터는 ''path'' 메시지를 해석하지 않고 전달하며, 해당 흐름에 대한 자원을 예약하지 않는다.[1]데이터 흐름을 수신하려는 측에서는 ''resv''(''reserve''의 약자, 예약) 메시지를 보내는데, 이 메시지는 다시 발신자에게 경로를 추적한다. ''resv'' 메시지에는 ''flowspec''(흐름 사양)과 ''filterspec''(필터 사양) 객체가 포함되어 있다. ''filterspec''은 flowspec에 정의된 서비스 품질(QoS)을 수신할 패킷을 정의하며, 간단한 필터 사양은 발신자의 IP 주소와 선택적으로 UDP 또는 TCP 포트가 될 수 있다. 라우터가 RSVP ''resv'' 메시지를 수신하면 다음과 같은 작업을 수행한다.[1]
# 요청 매개변수를 기반으로 예약을 수행한다. 접수 제어는 요청 매개변수를 처리하고, 선택된 데이터 패킷을 올바르게 처리하도록 패킷 분류기에 지시하거나, 상위 계층과 패킷 처리를 협상한다. 지원할 수 없는 경우 수신자에게 거부 메시지를 보낸다.
# 요청을 상류(발신자 방향)로 전달한다. 각 노드에서 ''resv'' 메시지의 ''flowspec''은 전달 노드에 의해 수정될 수 있다. (예: 멀티캐스트 흐름 예약의 경우 예약 요청을 병합할 수 있다.)
# 라우터는 흐름의 특성을 저장하고 선택적으로 흐름 사양에 따라 트래픽 관리를 설정한다.
특정 시간 동안 응답이 없으면 예약 시간이 초과되어 취소된다. 이는 발신자 또는 수신자가 충돌하거나 예약을 취소하지 않고 종료되는 경우 문제를 해결한다.[1]
4. 2. 자원 예약 요청
수신 호스트는 Resv (Reservation, 예약) 메시지를 송신 호스트 방향으로 역방향 경로를 따라 전송한다. Resv 메시지에는 플로우스펙(필요한 리소스)과 필터스펙(QoS를 수신할 패킷)이 포함된다.이 흐름을 수신하려는 측에서는 이에 상응하는 ''resv''(''reserve''의 약자, 예약) 메시지를 전송하며, 이 메시지는 다시 발신자에게 경로를 추적한다. ''resv'' 메시지에는 ''flowspec''(흐름 사양)이 포함되어 있다. 또한 ''filterspec''(필터 사양) 객체가 있으며, 이는 flowspec에 정의된 요청된 QoS를 수신할 패킷을 정의한다. 간단한 필터 사양은 발신자의 IP 주소와 선택적으로 UDP 또는 TCP 포트가 될 수 있다. 라우터가 RSVP ''resv'' 메시지를 수신하면 다음과 같은 작업을 수행한다.
# 요청 매개변수를 기반으로 예약을 수행한다. 접수 제어는 요청 매개변수를 처리하고, 선택된 데이터 패킷의 하위 집합을 올바르게 처리하도록 패킷 분류기에 지시하거나, 상위 계층과 패킷 처리를 수행하는 방법에 대해 협상할 수 있다. 지원할 수 없는 경우 수신자에게 거부 메시지를 보내 알린다.
# 요청을 상류(발신자 방향)로 전달한다. 각 노드에서 ''resv'' 메시지의 ''flowspec''은 전달 노드에 의해 수정될 수 있다(예: 멀티캐스트 흐름 예약의 경우 예약 요청을 병합할 수 있다).
# 그런 다음 라우터는 흐름의 특성을 저장하고 선택적으로 흐름 사양에 따라 트래픽 관리를 설정한다.
특정 시간 동안 아무런 응답이 없으면 예약 시간이 초과되어 취소된다. 이는 발신자 또는 수신자가 충돌하거나 예약을 먼저 취소하지 않고 종료되는 경우 문제를 해결한다.
4. 3. 라우터의 동작
라우터가 RSVP ''resv'' (''reserve''의 약자, 예약) 메시지를 수신하면 다음과 같은 작업을 수행한다.# 요청 매개변수를 기반으로 예약을 수행한다. 접수 제어는 요청 매개변수를 처리하고, 선택된 데이터 패킷의 하위 집합을 올바르게 처리하도록 패킷 분류기에 지시하거나, 상위 계층과 패킷 처리를 수행하는 방법에 대해 협상할 수 있다. 지원할 수 없는 경우 수신자에게 거부 메시지를 보내 알린다.[1]
# 요청을 상류(발신자 방향)로 전달한다. 각 노드에서 ''resv'' 메시지의 ''flowspec''(흐름 사양)은 전달 노드에 의해 수정될 수 있다(예: 멀티캐스트 흐름 예약의 경우 예약 요청을 병합할 수 있다).[1]
# 그런 다음 라우터는 흐름의 특성을 저장하고 선택적으로 흐름 사양에 따라 트래픽 관리를 설정한다.[1]
4. 4. 소프트 상태 유지
RSVP는 소프트 상태(soft state) 메커니즘을 사용하므로, 일정 시간 동안 갱신 메시지(Path 또는 Resv)가 없으면 예약이 자동으로 해제된다.[1] 이는 발신자 또는 수신자가 충돌하거나 예약을 먼저 취소하지 않고 종료되는 경우의 문제를 해결한다.[2]5. 메시지 유형
RSVP는 다음과 같은 주요 메시지 유형을 사용한다.
- '''Path 메시지''': 송신 호스트에서 데이터 경로를 따라 전송되며, 경로 상의 각 노드에 ''경로 상태''를 저장한다.
- '''Resv 메시지''': 수신자에서 송신 호스트로 데이터 경로를 따라 역방향으로 전송된다.
RSVP 메시지와 데이터 개체의 전체 목록은 RFC 2205에서 확인할 수 있다.
RSVP는 IP 또는 UDP 상위 프로토콜로, 두 컴퓨터 간 통신 경로 상의 CPU, 버퍼, 대역폭 등의 자원을 확보하여 QoS(통신 품질)을 보장한다. 주로 IntServ QoS 보장 방식을 위해 사용된다.
RSVP는 송수신 컴퓨터 간 데이터 통신 시작 시 제어 메시지를 주고받아 경로 상의 라우터나 스위치가 전송 대역폭을 확보하도록 한다. 화상 회의나 실시간 동영상 스트리밍 등 즉시성과 연속성이 요구되는 시스템을 위해 개발되었다.
''R''esource re''S''er''V''ation ''P''rotocol이라는 약자는 유럽 및 미국에서 편지 끝에 쓰는 "RSVP"(Répondez s'il vous plaît|레퐁데 실 부 플레프랑스어, 프랑스어로 "회신 부탁드립니다")에서 유래했다.
RSVP의 문제점은 IntServ 항목에서 확인할 수 있다.
5. 1. Path 메시지
Path 메시지는 데이터 경로를 따라 송신 호스트에서 전송되며 경로를 따라 각 노드에 ''경로 상태''를 저장한다.[3] 경로 상태에는 이전 노드의 IP 주소와 일부 데이터 개체가 포함된다. 데이터 개체는 다음과 같다.- Filterspec영어 형태로 송신자 데이터 형식을 설명하는 ''송신자 템플릿''
- 데이터 흐름의 트래픽 특성을 설명하는 ''송신자 tspec''
- 광고 데이터를 전달하는 ''adspec'' (자세한 내용은 RFC 2210 참조)
5. 2. Resv 메시지
Resv 메시지는 수신자에서 송신 호스트로 역방향 데이터 경로를 따라 전송된다. 각 노드에서 Resv 메시지의 IP 목적지 주소는 역방향 경로의 다음 노드 주소로 변경되고, IP 소스 주소는 역방향 경로의 이전 노드 주소로 변경된다.[3] Resv 메시지에는 흐름에 필요한 자원을 식별하는 'flowspec' 데이터 개체가 포함된다.[3]5. 3. 기타 메시지
RSVP는 경로(Path) 메시지와 예약(Resv) 메시지 외에도 다음과 같은 메시지를 사용한다.- PathErr: 경로 메시지 처리 과정에서 오류가 발생했음을 알리는 메시지이다.
- ResvErr: 예약 메시지 처리 과정에서 오류가 발생했음을 알리는 메시지이다.
- PathTear: 경로 상태를 제거하는 메시지이다.
- ResvTear: 예약 상태를 제거하는 메시지이다.
6. 기타 기능
RSVP는 다음과 같은 기능을 제공한다.
- '''무결성''': RSVP 메시지는 메시지 내용과 공유 키를 MD5를 사용하여 결합하여 생성된 메시지 다이제스트를 추가한다. 키는 "무결성 챌린지 요청"과 "무결성 챌린지 응답"이라는 두 가지 메시지 유형을 사용하여 배포 및 확인할 수 있다.
- '''오류 보고''': 노드가 오류를 감지하면 오류 코드와 함께 오류 메시지가 생성되어 보낸 사람에게 역방향 경로로 상위 노드로 전파된다.
- '''RSVP 흐름에 대한 정보''': 네트워크 운영자는 두 가지 유형의 진단 메시지를 통해 특정 흐름에 대한 RSVP 상태 정보를 요청할 수 있다.
- '''진단 기능''': 경로를 따라 RSVP 상태에 대한 정보를 수집할 수 있도록 하는 표준의 확장이다.
6. 1. 무결성(Integrity)
RSVP 메시지는 메시지 내용과 공유 키를 메시지 다이제스트 알고리즘(MD5)을 사용하여 결합하여 생성된 메시지 다이제스트를 추가한다. 키는 "무결성 챌린지 요청"과 "무결성 챌린지 응답"이라는 두 가지 메시지 유형을 사용하여 배포 및 확인할 수 있다.[4]6. 2. 오류 보고(Error Reporting)
노드가 오류를 감지하면 오류 코드와 함께 오류 메시지를 생성하여 보낸 사람에게 역방향 경로로 상위 노드로 전파한다.[4]6. 3. 진단 기능(Diagnostic)
네트워크 운영자는 두 가지 유형의 진단 메시지를 통해 특정 흐름에 대한 RSVP 상태 정보를 요청할 수 있다.[4] 이는 경로를 따라 RSVP 상태 정보를 수집할 수 있도록 하는 표준의 확장이다.[4]7. 발전 과정 및 관련 표준
RSVP는 IETF의 RFC 문서들에 의해 기술된다.
| RFC 번호 | 발행일 | 내용 |
|---|---|---|
| RFC 2205 | 1997년 9월 | 버전 1 기능 명세. 자원 가용성만을 기반으로 한 승인 제어를 기술. |
| RFC 2210 | RSVP 사용 및 데이터 객체 정의. 제어 부하 RFC 2211 및 보장된 RFC 2212 QoS 제어 서비스와 함께 RSVP의 사용을 정의. | |
| RFC 2211 | 제어 부하 서비스 네트워크 요소 동작을 지정. | |
| RFC 2212 | 보장된 QoS 서비스 네트워크 요소 동작을 지정. | |
| RFC 2750 | 2000년 1월 | 정책 기반 승인 제어 확장. 정책 객체의 사양과 정책 이벤트 처리에 대한 설명을 포함. |
| RFC 3209 | 2001년 12월 | RSVP-TE(RSVP Traffic Engineering). MPLS LSP 터널을 위한 RSVP 확장. |
| RFC 3473 | 2003년 1월 | GMPLS 시그널링 RSVP-TE 확장. |
| RFC 3936 | 2004년 10월 | RSVP 수정 절차 및 현재 모범 사례를 설명. |
| RFC 4495 | 2006년 5월 | 예약 대역폭 감소 확장. 기존 예약의 대역폭을 예약을 해제하지 않고 줄일 수 있도록 RSVP를 확장. |
| RFC 4558 | 2006년 6월 | 노드 ID 기반 RSVP Hello에 대한 설명. |
RSVP의 기본적인 개념은 1993년에 처음 제안되었다.[2]
7. 1. RFC 2205
IETF는 1997년에 RFC 2205에서 RSVP 버전 1의 기능 명세를 기술하였다.[2] 버전 1은 자원 가용성만을 기반으로 한 승인 제어를 기술하였고, 이후 RFC 2750에서 정책 기반 승인 제어 지원을 확장하였다.7. 2. RFC 2210
는 제어 부하 RFC 2211영어 및 보장된 RFC 2212영어 QoS 제어 서비스와 함께 RSVP의 사용을 정의한다. 더 자세한 내용은 통합 서비스를 참조하라. 또한 RFC 2205영어에서 RSVP에 의해 정의된 데이터 객체(자원 예약 정보를 전달)의 사용법 및 데이터 형식을 정의한다.[2]7. 3. RFC 2211, RFC 2212
IETF RFC 2211은 제어 부하 서비스를 제공하는 데 필요한 네트워크 요소 동작을 지정한다.[2] RFC 2212는 보장된 QoS 서비스를 제공하는 데 필요한 네트워크 요소 동작을 지정한다.[2]7. 4. RFC 2750
IETF는 2000년 1월에 RFC 2750에서 정책 기반 승인 제어를 지원하기 위한 RSVP 확장 제안을 설명한다. 이 확장에는 정책 객체의 사양과 정책 이벤트 처리에 대한 설명이 포함되었다.[2]7. 5. RFC 3209, RFC 3473
RFC 3209는 MPLS LSP 터널을 위한 RSVP 확장인 "RSVP-TE"(RSVP Traffic Engineering)를 2001년 12월에 정의하였다.[2]RFC 3473은 "일반화된 다중 프로토콜 라벨 스위칭(GMPLS) 시그널링 자원 예약 프로토콜-트래픽 엔지니어링(RSVP-TE) 확장"을 2003년 1월에 정의하였다.[2]
7. 6. RFC 3936
RFC 3936[2]은 RSVP 수정 절차를 설명하고, 현재 모범 사례를 제시한다.7. 7. RFC 4495, RFC 4558
RFC 4495는 2006년 5월에 공개되었으며, RSVP를 확장하여 기존 예약의 대역폭을 예약을 해제하지 않고 줄일 수 있도록 한다.[2] RFC 4558은 노드 ID 기반 RSVP Hello에 대한 설명을 담고 있다.8. RSVP의 한계 및 대안
RSVP의 문제점을 해결하기 위해 다양한 프로토콜이 제안되었지만, IETF에서 표준화된 것은 없으며, RSVP 이상으로 널리 사용되는 것도 없다.
- ST-II (The Internet Stream Protocol, version 2)[5] - RSVP에 앞서 개발된 프로토콜이지만, RSVP와는 달리 송신자가 최초 메시지를 전송했다.
- YESSIR (YEt another Sender Session Internet Reservations)[6] - ST-II와 마찬가지로 송신자가 최초 메시지를 보내는 프로토콜이며, RTCP (Real-time Transport Control Protocol)의 확장이다.
- 부메랑(Boomerang)[7] - ICMP (Internet Control Message Protocol)와 함께 사용한다.
IETF의 NSIS (Next-Step In Signaling) 워킹 그룹에서는 이 분석 결과를 토대로 새로운 프로토콜을 표준화하고 있다.
참조
[1]
서적
Juniper Networks Field Guide and Reference
https://books.google[...]
Addison-Wesley Professional
[2]
논문
"RSVP: A New Resource ReSerVation Protocol"
IEEE Network
1993-09
[3]
간행물
Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification
https://tools.ietf.o[...]
1997-09
[4]
간행물
RSVP Diagnostic Messages
[5]
간행물
“Experimental Internet Stream Protocol, Version 2 (ST-II)”
IETF
1990-10
[6]
논문
“YESSIR: A Simple Reservation Mechanism for the Internet”
ACM SIGCOMM Computer Communication Review
1999-04
[7]
논문
“Boomerang – A Simple Protocol for Resource Reservation in IP Networks”
IEEE Workshop on QoS Support for Real-Time Internet Applications
1999-06
[8]
논문
“QoS Signaling Across Heterogeneous Wired/Wireless Networks: Resource Management in Diffserv Using the NSIS Protocol Suite”
2nd Int’l Conference on Quality of Service in Heterogeneous Wired/Wireless Networks (QShine’05)
2005-08
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com