โปรโตคอลการจองทรัพยากร ( RSVP ) เป็นโปรโตคอลเลเยอร์การขนส่ง^{[ 1 ]} ที่ออกแบบมาเพื่อจองทรัพยากรทั่วทั้งเครือข่ายโดยใช้ โมเดล บริการแบบบูรณาการ RSVP ทำงานบนIPv4หรือIPv6และให้การตั้งค่าการจองทรัพยากรที่เริ่มต้นโดยผู้รับสำหรับ การไหลของข้อมูล แบบมัลติแคสต์หรือยูนิแคสต์มันไม่ได้ขนส่งข้อมูลแอปพลิเคชัน แต่คล้ายกับโปรโตคอลควบคุม เช่นโปรโตคอลข้อความควบคุมอินเทอร์เน็ต (ICMP) หรือโปรโตคอลการจัดการกลุ่มอินเทอร์เน็ต (IGMP) RSVP ได้รับการอธิบายไว้ในRFC 2205และได้รับหมายเลขโปรโตคอล IP 46 

RSVP สามารถใช้โดยโฮสต์และเราเตอร์เพื่อร้องขอหรือส่งมอบระดับคุณภาพการบริการ (QoS) ที่เฉพาะเจาะจงสำหรับสตรีมข้อมูล แอปพลิเคชัน RSVP กำหนดวิธีการที่แอปพลิเคชันทำการจองและวิธีการที่พวกเขาสามารถคืนทรัพยากรที่จองไว้เมื่อไม่ต้องการใช้งานอีกต่อไป การดำเนินการ RSVP โดยทั่วไปจะส่งผลให้มีการจองทรัพยากรในแต่ละโหนดตามเส้นทาง RSVP ไม่ใช่โปรโตคอลการกำหนดเส้นทางแต่ได้รับการออกแบบมาเพื่อทำงานร่วมกับโปรโตคอลการกำหนดเส้นทางในปัจจุบันและอนาคต

ในปี 2546 ความพยายามในการพัฒนาระบบวิศวกรรมโทรคมนาคมได้ถูกเปลี่ยนจาก RSVP ไปเป็นRSVP - TEและ มีการเสนอให้สร้าง Next Steps in Signaling (NSIS) ขึ้นมาทดแทน RSVP

1. RSVP ร้องขอทรัพยากรสำหรับ การไหล แบบซิมเพล็กซ์: กระแสการรับส่งข้อมูลในทิศทางเดียวจากผู้ส่งไปยังผู้รับหนึ่งรายหรือมากกว่า^{[ 2 ]}
2. RSVP ไม่ใช่โปรโตคอลการกำหนดเส้นทาง แต่สามารถทำงานร่วมกับโปรโตคอลการกำหนดเส้นทางในปัจจุบันและอนาคตได้
3. RSVP เป็นระบบที่เน้นผู้รับเป็นหลัก กล่าวคือ ผู้รับข้อมูลจะเป็นผู้เริ่มต้นและดูแลรักษาการจองทรัพยากรสำหรับข้อมูลนั้น
4. RSVP รักษาสถานะแบบอ่อน (การจองที่แต่ละโหนดจำเป็นต้องมีการรีเฟรชเป็นระยะ) ของการจองทรัพยากรของโฮสต์และเราเตอร์ จึงสนับสนุนการปรับตัวอัตโนมัติแบบไดนามิกต่อการเปลี่ยนแปลงของเครือข่าย
5. RSVP มีรูปแบบการจองหลายแบบ (ชุดตัวเลือกการจอง) และอนุญาตให้เพิ่มรูปแบบใหม่ในอนาคตผ่านการแก้ไขโปรโตคอลเพื่อให้เหมาะสมกับการใช้งานที่หลากหลาย
6. RSVP ทำหน้าที่ขนส่งและดูแลรักษาพารามิเตอร์การควบคุมการจราจรและนโยบาย ซึ่งเป็นสิ่งที่ไม่สามารถมองเห็นได้ชัดเจนสำหรับ RSVP เอง

แนวคิดพื้นฐานของ RSVP ได้รับการเสนอครั้งแรกในปี พ.ศ. 2536 ^{[ 3 ]}

RSVP ได้รับการอธิบายไว้ในเอกสาร RFC หลายฉบับจาก IETF:

• RFC 2205 : ข้อกำหนดการทำงานเวอร์ชัน 1 ได้รับการอธิบายไว้ใน RFC 2205 (กันยายน 1997) โดยIETFเวอร์ชัน 1 อธิบายถึงอินเทอร์เฟซสำหรับการควบคุมการรับเข้า (การจราจร) ที่อิงตามความพร้อมใช้งานของทรัพยากร "เท่านั้น" ต่อมาRFC 2750ได้ขยายการสนับสนุนการควบคุมการรับเข้าให้กว้างขึ้น 
• RFC 2210กำหนดการใช้งาน RSVP ร่วมกับ RFC 2211 สำหรับการควบคุมโหลด และบริการควบคุมคุณภาพบริการ (QoS) ที่รับประกันได้ตามมาตรฐาน RFC 2212 รายละเอียดเพิ่มเติมอยู่ใน หัวข้อ บริการแบบบูรณาการนอกจากนี้ยังกำหนดการใช้งานและรูปแบบข้อมูลของอ็อบเจ็กต์ข้อมูล (ที่บรรจุข้อมูลการจองทรัพยากร) ที่กำหนดโดย RSVP ใน RFC 2205 ด้วย 
• RFC 2211ระบุพฤติกรรมขององค์ประกอบเครือข่ายที่จำเป็นสำหรับการให้บริการควบคุมโหลด (Controlled-Load services) 
• RFC 2212ระบุพฤติกรรมขององค์ประกอบเครือข่ายที่จำเป็นต่อการส่งมอบบริการ QoS ที่รับประกันได้ 
• RFC 2750อธิบายถึงส่วนขยายที่เสนอเพื่อรองรับ การควบคุมการเข้าถึง ตามนโยบาย ทั่วไป ใน RSVP ส่วนขยายนี้รวมถึงข้อกำหนดของออบเจ็กต์นโยบายและคำอธิบายเกี่ยวกับการจัดการเหตุการณ์นโยบาย (มกราคม 2000) 
• RFC 3209 , "RSVP-TE: ส่วนขยายของ RSVP สำหรับอุโมงค์ LSP" (ธันวาคม 2001) 
• RFC 3473 "ส่วนขยายโปรโตคอลการจองทรัพยากรการส่งสัญญาณแบบ GMPLS-Traffic Engineering (RSVP-TE)" (มกราคม 2546) 
• RFC 3936 "ขั้นตอนสำหรับการแก้ไขโปรโตคอลการสงวนทรัพยากร (RSVP)" ( ตุลาคม 2547) อธิบาย ถึง แนวปฏิบัติที่ดีที่สุดใน ปัจจุบันและระบุขั้นตอนสำหรับการแก้ไข RSVP 
• RFC 4495 "ส่วนขยายของโปรโตคอลการจองทรัพยากร (RSVP) สำหรับการลดแบนด์วิดท์ของกระแสการจอง" (พฤษภาคม 2549) ขยาย RSVP เพื่อให้สามารถลดแบนด์วิดท์ของการจองที่มีอยู่แทนที่จะยกเลิกการจอง 
• RFC 4558 "โปรโตคอลการจองทรัพยากรแบบอิงตามรหัสโหนด (RSVP) Hello: คำชี้แจงเพิ่มเติม" (มิถุนายน 2549) 

แนวคิดหลักสองประการของโมเดลการจอง RSVP คือflowspecและfilterspec

ข้อความมีสองประเภทหลัก:

• ข้อความเส้นทาง ( เส้นทาง )

ข้อความเส้นทางจะถูกส่งจากโฮสต์ผู้ส่งไปตามเส้นทางข้อมูล และจะจัดเก็บสถานะเส้นทาง ไว้ ในแต่ละโหนดตามเส้นทางนั้น

สถานะเส้นทางประกอบด้วยที่อยู่ IP ของโหนดก่อนหน้า และอ็อบเจ็กต์ข้อมูลบางส่วน:

1. เทมเพลตผู้ส่งเพื่ออธิบายรูปแบบข้อมูลผู้ส่งในรูปแบบ Filterspec ^{[ 4 ]}
2. sender tspec ใช้เพื่ออธิบายลักษณะการรับส่งข้อมูลของกระแสข้อมูล
3. adspecที่บรรจุข้อมูลโฆษณา (ดู RFC 2210 สำหรับรายละเอียดเพิ่มเติม)

• ข้อความการจอง ( resv )

ข้อความresvจะถูกส่งจากตัวรับไปยังโฮสต์ผู้ส่งตามเส้นทางข้อมูลย้อนกลับ ในแต่ละโหนด ที่อยู่ IP ปลายทางของ ข้อความ resvจะเปลี่ยนเป็นที่อยู่ของโหนดถัดไปในเส้นทางย้อนกลับ และที่อยู่ IP ต้นทางจะเปลี่ยนเป็นที่อยู่ของโหนดก่อนหน้าในเส้นทางย้อนกลับ

ข้อความresvประกอบด้วย อ็อบเจ็กต์ข้อมูล flowspecซึ่งระบุทรัพยากรที่โฟลว์ต้องการ

ข้อมูลในข้อความตอบรับคำเชิญ (RSVP) สามารถส่งได้ในลำดับใดก็ได้ สำหรับรายการข้อความตอบรับคำเชิญและข้อมูลทั้งหมด โปรดดู RFC 2205

โฮสต์ RSVP ที่ต้องการส่งข้อมูลที่มีคุณภาพการบริการ (QoS) เฉพาะ จะส่ง ข้อความ เส้นทาง RSVP ทุกๆ 30 วินาที โดยข้อความจะเดินทางไปตามเส้นทางแบบยูนิคาสต์หรือมัลติคาสต์ที่กำหนดไว้ล่วงหน้าโดยโปรโตคอลการกำหนดเส้นทางที่ใช้งานอยู่ หาก ข้อความ เส้นทางมาถึงเราเตอร์ที่ไม่เข้าใจ RSVP เราเตอร์นั้นจะส่งต่อข้อความโดยไม่ตีความเนื้อหาของข้อความ และจะไม่สำรองทรัพยากรสำหรับข้อมูลนั้น

ผู้ที่ต้องการรับฟังจะส่ง ข้อความ resv (ย่อมาจากreserve ) ที่เกี่ยวข้อง ซึ่งจะติดตามเส้นทางกลับไปยัง ผู้ส่ง ข้อความ resvประกอบด้วยflowspec และอ็อบเจ็กต์filterspec ซึ่งกำหนดแพ็กเก็ตที่จะได้รับ QoS ที่ร้องขอตามที่กำหนดไว้ใน flowspec filterspec อย่างง่ายอาจเป็นเพียงที่อยู่ IP ของผู้ส่งและพอร์ต UDP หรือ TCP ก็ได้ เมื่อเราเตอร์ ได้รับข้อความ RSVP resvมันจะดำเนินการดังนี้:

1. ทำการจองโดยอิงตามพารามิเตอร์ของคำขอการควบคุมการรับเข้าจะประมวลผลพารามิเตอร์ของคำขอ และสามารถสั่งให้ตัวจำแนกแพ็กเก็ตจัดการชุดย่อยของแพ็กเก็ตข้อมูลที่เลือกได้อย่างถูกต้อง หรือเจรจากับเลเยอร์บนสุดเกี่ยวกับวิธีการจัดการแพ็กเก็ต หากไม่สามารถรองรับได้ จะส่งข้อความปฏิเสธเพื่อให้ผู้รับฟังทราบ
2. ส่งต่อคำขอไปยังต้นทาง (ในทิศทางของผู้ส่ง) ที่แต่ละโหนด โหนดส่งต่อสามารถแก้ไข flowspecใน ข้อความ resvได้ (เช่น ในกรณีของการจองโฟลว์แบบมัลติแคสต์ คำขอจองสามารถรวมเข้าด้วยกันได้)
3. จากนั้นเราเตอร์จะจัดเก็บลักษณะของกระแสข้อมูล และอาจตั้งค่าการควบคุมตามข้อกำหนดของกระแสข้อมูลนั้นๆ

หากไม่มีการติดต่อใดๆ เป็นเวลานานพอสมควร การจองจะหมดเวลาและถูกยกเลิก วิธีนี้จะช่วยแก้ปัญหาได้หากผู้ส่งหรือผู้รับเกิดขัดข้องหรือปิดระบบโดยไม่ได้ยกเลิกการจองก่อน

ความซื่อสัตย์

ข้อความตอบรับคำเชิญ (RSVP) จะถูกเพิ่มด้วยข้อมูลสรุปข้อความ (message digest) ที่สร้างขึ้นโดยการรวมเนื้อหาของข้อความและรหัสลับที่ใช้ร่วมกันโดยใช้อัลกอริทึมการสร้างข้อมูลสรุปข้อความ (โดยทั่วไปคือMD5 ) รหัสลับนี้สามารถแจกจ่ายและยืนยันได้โดยใช้ข้อความสองประเภท ได้แก่คำขอตรวจสอบความถูกต้อง (integrity challenge request ) และการตอบสนองการตรวจสอบความถูกต้อง (integrity challenge response )

การรายงานข้อผิดพลาด

เมื่อโหนดตรวจพบข้อผิดพลาด ระบบจะสร้างข้อความแสดงข้อผิดพลาดพร้อมรหัสข้อผิดพลาด และส่งต่อไปยังผู้ส่งในเส้นทางย้อนกลับ

ข้อมูลเกี่ยวกับขั้นตอนการตอบรับคำเชิญ

ข้อความวินิจฉัยสองประเภทช่วยให้ผู้ให้บริการเครือข่ายสามารถขอข้อมูลสถานะ RSVP สำหรับการรับส่งข้อมูลเฉพาะได้

สถานตรวจวินิจฉัยโรค

ส่วนขยายของมาตรฐานที่อนุญาตให้ผู้ใช้รวบรวมข้อมูลเกี่ยวกับสถานะ RSVP ตามเส้นทาง^{[ 5 ]}

• "โปรโตคอลการจองทรัพยากร"ซิสโก้. เก็บถาวรจากต้นฉบับเมื่อ 2017-07-05 . เรียกดูเมื่อ2011-02-16 .
• นาเวน จอย (17 มิถุนายน 2002). "RSVP ให้บริการที่มีคุณภาพ" . เน็ตเวิร์ก เวิลด์ . เก็บถาวรจากต้นฉบับเมื่อ 29 มิถุนายน 2013 . สืบค้นเมื่อ14 กุมภาพันธ์ 2012 .
• "โครงการ RSVP"สถาบันวิทยาศาสตร์สารสนเทศ มหาวิทยาลัยเซาท์แคลิฟอร์เนีย (USC) เก็บถาวรจากต้นฉบับเมื่อวันที่ 27 เมษายน 2560