{"title":"RSVP通过IPsec隧道方式使用rfc3175","authors":"T. Griem, A. Ayyagari, J. H. Kim","doi":"10.1109/MILCOM.2005.1606156","DOIUrl":null,"url":null,"abstract":"Today, there is no effective solution for end-to-end (E2E) resource reservation protocol (RSVP) over Internet protocol security (IPsec) tunnel mode or virtual private network (VPN) environment. Currently, the interior routers supporting tunnels cannot respond to the encapsulated E2E RSVP messages and data. In this paper, we address the problem by providing a capability to support E2E RSVP over IPsec using the IETF RFC 3175 specifications. The RFC 3175-\"aggregation of RSVP for IPv4 and IPv6 reservations\", is an IETF proposal for improving the scalability of RSVP. however, it does not address its implementation over IPsec (or VPN) environments. We propose aggregate RSVP (A-RSVP) sessions between the routers to reserve the interior resources on behalf of the E2E RSVP sessions. The A-RSVP sessions are transmitted plain-text (PT) between enclaves and use the global DiffServ code point (DSCP) and tunnel exit point address as the RSVP session identifier. The encapsulated data is classified and scheduled by the interior network based on DiffServ's global DSCP marking and the corresponding per hop behaviors. The primary contribution of this design over RFC 3175 is to waive the requirement for protocol identifier modification (RSVP-E2E-IGNORE) and to identify a framework for implementing the capability over a tunnel-specific environment with multiple security enclaves. An alternative for multicast support is also proposed. The original proposal in RFC 3175 has the interior network depending on exterior multicast addresses to identify destination de-aggregators. We propose that portions of the multicast E2E path be aggregated together with unicast E2E RSVP sessions into the (unicast) A-RSVP sessions. The A-RSVP session will aggregate unicast and multicast RSVP sessions with similar service requirements.","PeriodicalId":223742,"journal":{"name":"MILCOM 2005 - 2005 IEEE Military Communications Conference","volume":"12 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"2005-10-17","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"1","resultStr":"{\"title\":\"RSVP over IPsec tunnel mode using RFC 3175\",\"authors\":\"T. Griem, A. Ayyagari, J. H. Kim\",\"doi\":\"10.1109/MILCOM.2005.1606156\",\"DOIUrl\":null,\"url\":null,\"abstract\":\"Today, there is no effective solution for end-to-end (E2E) resource reservation protocol (RSVP) over Internet protocol security (IPsec) tunnel mode or virtual private network (VPN) environment. Currently, the interior routers supporting tunnels cannot respond to the encapsulated E2E RSVP messages and data. In this paper, we address the problem by providing a capability to support E2E RSVP over IPsec using the IETF RFC 3175 specifications. The RFC 3175-\\\"aggregation of RSVP for IPv4 and IPv6 reservations\\\", is an IETF proposal for improving the scalability of RSVP. however, it does not address its implementation over IPsec (or VPN) environments. We propose aggregate RSVP (A-RSVP) sessions between the routers to reserve the interior resources on behalf of the E2E RSVP sessions. The A-RSVP sessions are transmitted plain-text (PT) between enclaves and use the global DiffServ code point (DSCP) and tunnel exit point address as the RSVP session identifier. The encapsulated data is classified and scheduled by the interior network based on DiffServ's global DSCP marking and the corresponding per hop behaviors. The primary contribution of this design over RFC 3175 is to waive the requirement for protocol identifier modification (RSVP-E2E-IGNORE) and to identify a framework for implementing the capability over a tunnel-specific environment with multiple security enclaves. An alternative for multicast support is also proposed. The original proposal in RFC 3175 has the interior network depending on exterior multicast addresses to identify destination de-aggregators. We propose that portions of the multicast E2E path be aggregated together with unicast E2E RSVP sessions into the (unicast) A-RSVP sessions. The A-RSVP session will aggregate unicast and multicast RSVP sessions with similar service requirements.\",\"PeriodicalId\":223742,\"journal\":{\"name\":\"MILCOM 2005 - 2005 IEEE Military Communications Conference\",\"volume\":\"12 1\",\"pages\":\"0\"},\"PeriodicalIF\":0.0000,\"publicationDate\":\"2005-10-17\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"1\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"MILCOM 2005 - 2005 IEEE Military Communications Conference\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/10.1109/MILCOM.2005.1606156\",\"RegionNum\":0,\"RegionCategory\":null,\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"\",\"JCRName\":\"\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"MILCOM 2005 - 2005 IEEE Military Communications Conference","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1109/MILCOM.2005.1606156","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
Today, there is no effective solution for end-to-end (E2E) resource reservation protocol (RSVP) over Internet protocol security (IPsec) tunnel mode or virtual private network (VPN) environment. Currently, the interior routers supporting tunnels cannot respond to the encapsulated E2E RSVP messages and data. In this paper, we address the problem by providing a capability to support E2E RSVP over IPsec using the IETF RFC 3175 specifications. The RFC 3175-"aggregation of RSVP for IPv4 and IPv6 reservations", is an IETF proposal for improving the scalability of RSVP. however, it does not address its implementation over IPsec (or VPN) environments. We propose aggregate RSVP (A-RSVP) sessions between the routers to reserve the interior resources on behalf of the E2E RSVP sessions. The A-RSVP sessions are transmitted plain-text (PT) between enclaves and use the global DiffServ code point (DSCP) and tunnel exit point address as the RSVP session identifier. The encapsulated data is classified and scheduled by the interior network based on DiffServ's global DSCP marking and the corresponding per hop behaviors. The primary contribution of this design over RFC 3175 is to waive the requirement for protocol identifier modification (RSVP-E2E-IGNORE) and to identify a framework for implementing the capability over a tunnel-specific environment with multiple security enclaves. An alternative for multicast support is also proposed. The original proposal in RFC 3175 has the interior network depending on exterior multicast addresses to identify destination de-aggregators. We propose that portions of the multicast E2E path be aggregated together with unicast E2E RSVP sessions into the (unicast) A-RSVP sessions. The A-RSVP session will aggregate unicast and multicast RSVP sessions with similar service requirements.