Internet-Draft Charles Abondo Expires: April, 2005 Polytechnique Montreal Samuel Pierre Polytechnique Montreal October, 2004 Hierarchical Proxy Mobile Ressource Reservation Protocol draft-abondo-hmprsvp-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document defines a resource reservation protocol Hierarchical Proxy Mobile Resource Reservation Protocol (HPMRSVP). This protocol is based on the hierarchical architecture HMIPv6 and used a modified version of FHMIPv6 to handle the handover. During a session, the resource reservation between two mobile nodes is limited to the access network. Furthermore, when a handover occurs, resources are uniquely reserved to the target access point before the handover is completed. The proposed protocol allows to reduce delays and packet loss. In addition, management of refresh messages is moved to the access router, which holds the refresh reservation state for the duration of the session on behalf of the mobile unit. The access network thereby becomes responsible for upholding the session, which optimizes the utilization of the radio link. Abondo, Pierre [Page 1] INTERNET DRAFT hpmrsvp October 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Resource Reservation Procedures. . . . . . . . . . . . . . . 3 2.1 Initial Reservation . . . . . . . . . . . . . . . . . . . 3 2.2 Reservation Modification . . . . . . . . . . . . . . . . . 5 3. Handover Procedure . . . . . . . . . . . . . . . . . . . . . 7 4. Refresh Procedure . . . . . . . . . . . . . . . . . . . . . 10 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 5.2 Informative References . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property . . . . . . . . . . . . . . . . . . . 13 1. Introduction This document describes a Quality of Service (QoS) signalling protocol to guarantee the resource reservation in an IP-based mobile environment. HPMRSVP maintains the same messaging semantics as defined in RSVP [RFC2205], however, it no longer supports multicast applications but only unicast applications. This is a more realistic approach given the complexity of the reservation process with multicasting, and given the security issues around it. The protocol uses a simplex reservation process. On the contrary of RSVP, it is sender-oriented rather than receiver-oriented. It also keeps soft state resource reservation. It carries and supports all parameters for traffic and security control. It is based on the HMIPv6 [3] architecture and on the FHMIPv6 [5] protocol, however, it exclusively supports the optimal routing as defined in MIPv6 [2]. The main benefit is the avoidance of delays often caused by triangular routing. The MAP is used as a resource reservation proxy. Thus, it determines the routing of the QoS signalling messages within the access network. It allows to reserve resources on the behalf of a remote mobile node based on the session information gathered by a session initialization protocol (i.e. SIP). The routing of reservation messages in the MAP area is achieved by using two care-of-addresses (LCoA and RCoA). The mobile node uses a unique LCoA by linking the sub network identity (64 bits) to the presumably unique MAC address (64 bits). Consequently, this alleviates confusion between the Inter and Intra MAP [8] session reservations and it eliminates the need for the duplication address detection (DAD). Abondo, Pierre [Page 2] INTERNET DRAFT hpmrsvp October 2004 The session reservation refresh is accomplished by coordinating a refresh state jointly with the reservation state at the access router. The access router will then refresh the reservation for the duration of the session on behalf of the mobile node. The access network thereby becomes responsible for upholding the session, which optimizes the utilization of the radio link. During the handover, resource reservation between two mobiles nodes is limited to the access network based on layer 2 triggers. These mechanisms optimize the utilization of the radio link and allow to reduce delays and packet loss. HPMRSVP specifications tend to respect the signalling protocol requirements as defined in [4]. This document is structured as follows. The first section outlines the initial and modification resource reservation procedures. The second section describes handover procedures while the last section is dedicated to the management of refresh messaging. 2. Resource Reservation Procedures Each mobile has three addresses, a permanent address (HoA), a local care-of-address (LCoA) and a regional care-of-address (RCoA). The mobile node or the corresponding node is either a sender (MN_S), a receiver (MN_R), or both at once (MN_RS). 2.1 Initial Procedure The initial reservation between two corresponding nodes is restricted to the access network. This procedure assumes that the two mobile nodes do not belong to the same access network. The MN_RS sends a PATH message to the CN_RS. This message sets up and reserves the resources along the communication path to the MAP. Upon receipt of the message, the MAP sends a RESV confirmation message for the reservation on the uplink. The MAP then sends a PATH reservation message on behalf of the CN_RS for the reservation on the downlink. This assumes that the MAP is aware of the QoS requirements of the CN_RS. These requirements can be included at the beginning of the SIP session between two corresponding nodes. On the contrary of the protocol proposed in [8], this approach bypasses the need for the MN_RS to make the resource reservation on behalf of CN_RS. The later reservation has security issues in that the resources reserved on the uplink are only guaranteed by the MN_SR entity, which is not always trustable. It is therefore more secure that the reservation be made by the network rather than by the corresponding node. By this way, we eliminate the security issues due to none authenticate mobiles. Furthermore, the delays caused by end-to-end QoS signalling are reduced. The initial reservation procedure is shown below: Abondo, Pierre [Page 3] INTERNET DRAFT hpmrsvp October 2004 AR IR1 IR2 MAP | | | | | | (1)PATH | | --+----------+----------+--------->| | | | | | | (2)RESV | | <-+----------+----------+----------| | | | | MN_RS | | | | CN_RS | | (3)PATH | | <-+----------+----------+----------| | | | | | | (4)RESV | | --+----------+----------+--------->| | | | | Figure 1: Initial Inter-domain reservation 1. The MN_RS mobile node sends a PATH message to the MAP in order to reserve the resources on the uplink. 2. The MAP receives the PATH message and sends a RESV message to confirm the resource reservation. 3. The MAP sends a PATH message to MN_RS in order to reserve the resources on the downlink on behalf of the CN_RS using the CN_RS application and address information (HoA, RCoA, LCoA), which are taken from the session opening by SIP. 4. The MN_RS receives the PATH message and sends a RESV message to confirm the resource reservation. The advantage of this procedure is that the resource reservation is made locally within the access network rather than end-to-end. In the case where two communicating nodes belong to the same MAP domain, it is preferable that the initial reservation between the MN_RS and the CN_RS is made in an end-to-end fashion along the communication path. A local resource reservation using the MAP would be too expensive. Figure 3 shows the initial intra-domain reservation. The mobile node inserts the two destination addresses LCoA then RCoA in the MIPv6 destination header message. The presence of LCoA within the intermediary routersË routing tables allows for the messages to be sent directly to the CN_RS instead of to the MAP. AR1 IR1 MAP IR2 AR2 | | | | | | | | | |(1)PATH(MN->CN) | | | | |---------+--------------+--------------+-------------+----->| | | | | | | | Abondo, Pierre [Page 4] INTERNET DRAFT hpmrsvp October 2004 | | |(2)RESV(MN->CN) | | | | |<--------+--------------+--------------+--------------------| | | | | | | | | | | | | | | MN_RS | | | | | CN_RS | | | | | | | | | |(3)PATH(CN->MN) | | | | |<--------+--------------+--------------+--------------------| | | | | | | | | | |(4)RESV(Cn->MN) | | | | |---------+--------------+--------------+------------------->| Figure 2: Initial intra-domain reservation 2.2 Reservation Modification HMPRSVP defines a restricted local signalling in the access network. Nonetheless, two mobile nodes can decide to change QoS parameters while the session is in progress. This prompts HMPRSVP to launch a modification message which allows the resource reservation to be changed during the session. This message, identical to the PATH while containing a new element, is transmitted by the MAP to the CN_RS. Upon receipt of the message, the CN_RS sends back a RESV confirmation to the MN_RS. Different from what is suggested in [8], the IP-IP encapsulation problem in PATH messages is resolved with the point-to-point HMPRSVP message transmission. There is therefore no confusion in the interpretation of reservation messages within the access network. AR1 MAP1 B_IR MAP2 AR2 | | | | | | | |(1)PATHMOD(MN->CN) |(2)PATHMOD(MN->CN) |(3)PATHMOD(MN->CN) | | |------------>+-----------+---------->+-------------+----->| | | | | | | | | | | | |(R1)PATH(CN->MAP2) | | | | | |<------------+------| | | | | | | | | | | | |(R2)RESV(CN->MAP2) | | | | | |-------------+----->| MN_RS | | | | | | | | | | |(S1)PATHMOD(MAP->CN)| | | | | |<------------+------| | | | | | | | | | | | |(S2)PATH(MAP2->CN) | | | | | |-------------+----->| | | | | | | | | | | | | (4)RESVMOD(CN->MN) | | | | | |<------------+------| Abondo, Pierre [Page 5] INTERNET DRAFT hpmrsvp October 2004 | | | | | | | | | | | | | | | | | | | | | | | |(5)RESVMOD(CN->MN) | | | | | <-----------+-----------| | | | | | | | | | | | | | | | | |(R3)PATH(MAP1->MN) | | | | | |<----+-------------+ | | | | | | | | | | | |(R4)RESV(MAP1->MN) | | | | CN_RS |-----+------------>| | | | | | | | | | | | (6)RESVMOD(CN->MN) | | | | | |<----+-------------+ | | | | | | | | | | | |(S3)PATH(MN->MAP1) | | | | | |-----+------------>| | | | | | | | | | | | |(S4)RESV(MN->MAP1) | | | | | |<----+-------------+ | | | | | | | | | | | Figure 3: Reservation Modification The benefit of this approach is that it accounts for the MAP capability to interpret QoS signalling messages. As well, it resolves the tunnelling problem by avoiding to generate two signalling messages. In addition, the solution proposed in [8] splits the messages sent to the end of the tunnel and to the receiving entity, even though they are linked from a resource availability standpoint. It is therefore crucial to quickly confirm whether or not resources are available. The messaging structure during the reservation modification procedure is outlined in Figure 3: 1. The MN_RS sends a PATHMOD message to the MAP1. 2. The MAP1 transmits the PATHMOD message to the MAP2. 3. The MAP2 routs the message to the CN_RS. 1st Scenario: The MN_RS wants to modify the QoS parameters for the data packets it will receive from the CN_RS: R1. The CN_RS sends a PATH message to the MAP2 in order to reserve resources on the CN_RS uplink. Abondo, Pierre [Page 6] INTERNET DRAFT hpmrsvp October 2004 R2. Upon receipt of the PATH message, the MAP2 replies with a RESV message confirming that the reservation resource was successful. 2nd Scenario: The MN_RS wants to modify the QoS parameters for the data packets it will send from the CN_RS: S1. The CN_RS sends a PATHMOD message to the MAP2 requesting that the MAP2 reserve resources on the CN_RS downlink. S2. Upon receipt of the PATHMOD message, the MAP2 sends a PATH message PATH to make the resource reservation. 4. The CN_RS sends a RESVMOD message to P2 to confirm the reservation in the CN_RS local network. 5. When the MAP2 receives the RESVMOD message, it transmits it to MAP1. 1st Scenario: The MN_RS wants to modify the QoS parameters for the data packets it will receive from the CN_RS: R3. The MAP1 sends a PATH message to the MN_RS in order to reserve resources on the MN_RS downlink. R4. Upon receipt of the PATH message, the MN_RS replies with a RESV message confirming that the reservation resource was successful. 2nd Scenario: The MN_RS wants to modify the QoS parameters for the data packets it will send to the CN_RS: 6. The MAP1 sends a RESVMOD message to the MN_RS to reserve resources on the uplink. S3. The MN sends a PATH message to the MAP1 in order to reserve resources on the uplink. S4. Upon receipt of the PATH message, the MAP1 sends a RESV message to the MN confirming that the reservation resource was successful. 3. Handover Procedures In this section, we assume that the initial reservation between the MN_RS and the CN_RS was already established. In addition, the generic operations outlined are those related exclusively to a handover initiated by the mobile unit. A handover prompted by the network will follow the same principles. We assume that layer 2 mechanisms are responsible for anticipating the handover. The MAP holds the necessary information to support the access router handover located within the same HMIPv6 domain. PAR MAP NAR | | | | | | (1)SBU | | | |-----+------------->|--------------------->| | Abondo, Pierre [Page 7] INTERNET DRAFT hpmrsvp October 2004 | | | | | | | | (D1)PATH(MAP->NAR) | | | | |--------------------->| | | | | | | | | | | | | | | (D2)RESV(MAP->NAR) | | | | |<---------------------| | | | | | | | | | | | MN @ PAR| | (U1)PATH(NAR->MAP) | MN @ NAR | | |<---------------------| | | | | | | | | | | | | | | (U2)RESV(NAR->MAP) | | | | |--------------------->| | | | | | | | | | forwarding packets | | | | |=====================>| | | | | | | | | | | | | | | | (2)RS/RA messages | | | | |<----------------->| | | | | | | | | | | | | | |(3)MN packets delivered | | | |------------------>| | | | | | | | | (4)LBU | | | | |<---------------------+-------------------| | | | | | | | | (5)LBACK | | | | |----------------------+------------------>| | | | | | | | | (6)Data HMIPv6 | | | | |<---------------------+------------------>| Figure 4: Inter-domain handover without bicasting 1st Scenario: Handover without bicasting 1. Based on the anticipation of a layer 2 handover, the MN creates an NLCoA address and sends a SBU message to the MAP. The MAP forwards this message to the NAR. The SBU includes the NARËs NLCoA address information. Then, upon receipt of the SBU message, the MAP triggers the HPMRSVP reservation procedure. D1. The MAP sends a PATH message to the NAR in order to reserve resources on the downlink. D2. Upon receipt of the PATH message, the NAR sends a RESV message to the MAP confirming that the reservation resource was successful. Abondo, Pierre [Page 8] INTERNET DRAFT hpmrsvp October 2004 U1. The NAR sends a PATH message to the MAP to reserve resources on the uplink. U2. Upon receipt of the PATH message, the MAP sends a RESV message to the NAR confirming that the reservation resource was successful. 2. The MN exchanges RS and RA messages with the NAR. 3. When it detects that it has moved to the new link layer and receives the appropriate RA, the NAR delivers the buffered data packets to the MN via the NLCoA. 4. The MN then follows the regular HMIPv6 operation by sending an LBU to the MAP. When the MAP receives the new LBU with the NLCoA from the MN, it will stop its transmission to the PAR and will close the tunnel setup to accommodate the handover. 5. In response to the LBU, the MAP sends a LBACK to the MN and the procedure follows the HMIPv6 procedure. 2nd Scenario: Handover with bicasting 1. Based on the anticipation of a layer 2 handover, the MN sends an SBBU message to the MAP, which then forwards it to the NAR. The SBBU must include the specific NAR NLCoA address information as well as the bicasting information. Then, upon receipt of the SBBU message, the MAP triggers the HPMRSVP procedure. 2. The MAP initiates the bicasting of the data packets to the MN at both the PLCoA and NLCoA addresses. 3. The MN then follows the regular HMIPv6 operations by sending an LBU to the MAP. When the MAP receives the new LBU with the NLCoA from the MN, it will stop its transmission to the NAR and will close the tunnel setup to accommodate the handover. 4. In response to the LBU, the MAP sends an LBACK to the MN and the remainder of the procedure follows the HMIPv6 procedure. PAR MAP NAR | | | | | | (1)SBU | | | |-----+------------->|------------------->| | | | | | | | | | (D1)PATH(MAP->NAR) | | | | |------------------->| | | | | | | | | | (D2)RESV(MAP->NAR) | | | | |<-------------------| | | | | | | MN @ PAR | (U1)PATH(NAR->MAP) | MN @ NAR | | |<-------------------| | | | | | | | | | (U2)RESV(NAR->MAP) | | | | |------------------->| | | | | | | Abondo, Pierre [Page 9] INTERNET DRAFT hpmrsvp October 2004 | | | (2) START BICASTING| | |<===========================================================>| | | | | | | | | (3)LBU | | | | |<-------------------+-------------------| | | | | | | | | (4)LBACK | | | | |--------------------+------------------>| | | | | | | | | (5)Data HMIPv6 | | | | |<======================================>| | | | | | | | | | | Figure 5: Intra-domain handover with bicasting 4. Refresh Procedure The soft reservation state created in an intermediary router of the access network is a temporary state and thus must be refreshed all along the session. In RSVP [RFC2205], the corresponding nodes are responsible for the refresh management. This involves sending several signalling messages on the radio link which can cause the deterioration of the radio link. In order to resolve this issue, HPMRSVP creates a refresh state jointly with the reservation state at the access router level. The access router will support the reservation for the duration of the session on behalf of the mobile node. The network thereby becomes responsible for upholding the session, which optimizes the utilization of the radio link. The different objects that define the refresh state and the reservation state of a session are shown in Figure 6. Reservation State Refresh State Session_ID_Class: Session_ID_Class: Service_Class: Flow_Specification_Class: [FLOWSPEC] [] Flow_Specification_Class: Security_Class: [] {} Abondo, Pierre [Page 10] INTERNET DRAFT hpmrsvp October 2004 Figure 6: HPMRSVP Reservation Session The end of a reservation session will closed both sessionsË state. As a result, there are no resources wasted, neither at the network layer nor at the link layer. 5. References 5.1 Normative References [1] Braden, R., Zhang, L., Berson,S., Herzog, S., Jamin, S., ŸResource Reservation Protocol í Version 1 Functional Specification÷, RFC 2205, September 1997. [2] Johnson, D., Perkins, C., Arkko, J., ŸMobility Support in IPv6÷, Internet Draft, draft-ietf-mobileip-ipv6-24.txt, 30 June 2003. [3] Soliman H. and al., ŸHierarchical MIPv6 mobility management HMIPv6÷, Internet Draft, draft-ietf-mobileip-HMIPv6-07.txt, October 2002. [4] Chaskar, H., ŸRequirements of a QoS Solution for Mobile IP÷, Internet Draft, draft-ietf-mobileip-qos-requirements-04.txt, 30 July 2002. [5] Jung, H., Koh, S., Lee, J., Soliman, H., El-Malki, K., ŸFast Handover for Hierarchical MIPv6 (F-HMIPv6)÷, Internet Draft, draft-jung-mobileip-fastho-hmipv6-01.txt, June 2003. 5.2 Informative References [6] Manner, J., Fu, X., ŸAnalysis of Existing Quality Service Signaling Protocols÷, Internet Draft, draft-ietf-nsis-signalling -analysis-01.txt, February 2003. [7] Shen, C. Q. and al., ŸMobility Extension RSVP in an RSVP-Mobile IPv6 Framework÷, Internet Draft, draft-shen-nsis-rsvp-mobileipv6 -00.txt, July 2002. [8] Manner, J., Suihko, T., Kojo, M., Liljeberg, M., Raatikainen, K., ŸLocalized RSVP÷, Internet Draft, draft-manner-lrsvp-01.txt, January 2003. [9] A. Terzis, J. Krawezyk, J. Wroclawski, L. Zhang, ŸRSVP Operation over IP Tunnels÷, RFC 2746, January 2000. [10] Westberg, L., Bader, A., Partain, D., Rexhepi, V., ŸA Proposal for RSVPv2-NSLP÷, Internet Draft, draft-westberg-proposal-for- rsvpv2-nslp-00.txt, April 2003. Abondo, Pierre [Page 11] INTERNET DRAFT hpmrsvp October 2004 Authors' Addresses Charles Abondo Polytechnique Montreal P.O Box 6079, Station Centre-ville, Montreal, Quebec Canada EMail: charles.abondo@polymtl.ca Samuel Pierre Polytechnique Montreal P.O Box 6079, Station Centre-ville, Montreal, Quebec Canada EMail: samuel.pierre@polymtl.ca Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Abondo, Pierre [Page 12] INTERNET DRAFT hpmrsvp October 2004 Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Abondo, Pierre [Page 13] INTERNET DRAFT hpmrsvp October 2004