Next Steps in Signaling F. Tommasi Internet-Draft S. Molendini Expires: August 2006 A. Tricco E. Scialpi University of Lecce February 2006 Semi-Proactive QoS Re-establishment Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire in August, 2006. Copyright Notice Copyright (C) The Internet Society (2006). F.Tommasi, et al. Expires August 2006 [Page 1] Internet-Draft Semi-Proactive QoS Re-establishment February 2006 Abstract Re-establishment of QoS after a Mobile Node handover must be done as quickly as possible in order to reduce degradation or interruption of QoS. It is specifically useful if real-time applications are used. We propose a Semi-Proactive procedure for QoS re-establisment that also avoids waste of resources. Moreover, we propose a new point of buffering for the packets destined to the Mobile Node during the handover. This is useful when QoS is required for these packets. Table of Contents 1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3 Semi-proactive Procedure from the NSLP point of view. . . . . . . 4 3.1 Introduction to the procedure . . . . . . . . . . . . . . . . 5 3.2 Triggering section. . . . . . . . . . . . . . . . . . . . . . 9 3.3 Proactive section . . . . . . . . . . . . . . . . . . . . . . 9 3.3.1 Classification of the end-points . . . . . . . . . . . . 9 3.3.2 Receiver-initiated reservation . . . . . . . . . . . . . 10 3.3.3 Sender-initiated reservation . . . . . . . . . . . . . . 10 3.3.4 Proactive selection of the CAR . . . . . . . . . . . . . 10 3.4 Reactive section. . . . . . . . . . . . . . . . . . . . . . . 10 4 Semi-proactive Procedure by the GIST point of view. . . . . . . . 12 4.1 CCRN e CRN. . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2 The new buffering . . . . . . . . . . . . . . . . . . . . . . 13 4.3 CCRN Discovery. . . . . . . . . . . . . . . . . . . . . . . . 14 5 Security Considerations . . . . . . . . . . . . . . . . . . . . . 14 6 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1 Introduction Mobile IP [1][2] is a protocol that allows a Mobile Node(MN) to communicate to other Internet nodes after changing its link-layer point of attachment without loosing its IP address. Thus, Mobile IP provides the node for maintaining higher-layer connection while moving. F.Tommasi, et al. Expires August 2006 [Page 2] Internet-Draft Semi-Proactive QoS Re-establishment February 2006 NSIS Working Group[3] uses a two layer architecture for a signaling protocol: - NTLP (GIST) [4] carries signaling messages between neighboring peers; - QoS-NSLP [5] manages resource reservation. In order to allow the signal packets to have a secure GIST path supply the modality "connection" creating an association between the adjacent GIST nodes. This same association is known as Messaging Association. According to the regular specification of the NSIS protocols the re- establishment of the QoS occurs after the handover, that is in a reactive way. This means that both NTLP and QoS-NSLP act after the handover in order to re-establish the proper QoS on the New path. The installation of the state in the New path must be done as quickly as possible in order to reduce the degradation of QoS for the mobile node which is specifically useful if real-time applications are used. A basic idea for reducing such delay would be to re-establish QoS before the handover on the possible future paths, that is to act in a proactive way. Of course this means that there will be a waste of resources since there is no guarantee that the handover will occur and because resources are assigned for all Candidate path. We therefore, propose to exploit pros and cons of both situations by creating the Messaging Associations in a proactive way and by assigning resources in a reactive way, let us say in a semi-proactive way. This solution anticipates the creation of the associations before the handover. Resource reservation is performed usually after the handover but the total time is at a minimum. Moreover, resources are assigned only to the effective path for avoiding a waste of resources. In our solution the re-establishment is faster also because we introduce the possibility of buffering, in an intermediate node of the end-to-end path, the packets destined to MN. This node is known as the Candidate CRossover Node (CCRN). Consequently, in this solution no messages have been introduced in the QoS-NSLP and NTLP protocols; we need just to add a flag (M - Mobility flag) to all messages and some GIST TLV objects to help the F.Tommasi, et al. Expires August 2006 [Page 3] Internet-Draft Semi-Proactive QoS Re-establishment February 2006 discovery of the CCRN as we will explain in section 4. The procedures described in the following paragraphs are applicable in networks served by Mobile IPv4 with Route Optimization [6] or Mobile IPv6 (in which the Route Optimization is integrated). 2 Terminology NSIS aware: a node is NSIS aware when it supports NTLP and QoS-NSLP; Mobile Node (MN): an host that can change its point of connection to the network; Correspondent Node (CN): network node with which MN is communicating at the time; Access Router (AR): access node to the network for an MN; Previous AR (PAR): AR for the MN before the handover; Candidate AR (CAR): possible AR for a handover of the MN; New AR (NAR): AR for the MN after the handover; New path: path between CN and NAR; Old path: path between CN and PAR; Candidate path: path between CN and CAR; Crossover node (CRN): one of the nodes NSIS aware of the intersection between the Old and New path; Candidate CRN (CCRN): one of the nodes NSIS aware of the intersection between the Old and Candidate path; GIST Association (GA): the set of the Messaging Association (MA) on the path. 3 Semi-proactive Procedure from the NSLP point of view In following paragraphs we would like to present a detailed description of the principal phases of the semi-proactive procedure. F.Tommasi, et al. Expires August 2006 [Page 4] Internet-Draft Semi-Proactive QoS Re-establishment February 2006 3.1 Introduction to the procedure Remembering that QoS-NSLP supports both the sender-initiated and the receiver-initiated reservation. The entity that sends the Reserve message takes the name of QoS NSIS Initiator (QNI) and the entity that receives that message takes the name of QoS NSIS Responder (QNR). The intermediary NSIS aware takes the name of QoS NSIS Entity (QNE). In the case of sender-initiated reservation (figure 1), the Reserve message travels in the same direction of the data flow. Therefore, QNI is the NSIS aware node closest to the sender of that flow. Passing between the nodes, the Reserve message allows GIST to create the GA. In the case of a receiver-initiated reservation (figure 2), the Reserve message travels in the opposite direction to the data flow. Therefore, QNI is the NSIS aware node closest to the afore mentioned flow receiver. In this case, due to asymmetric routing, the QNR must send a Query message to allow the GIST to create a GA. QNI QNE QNE QNR sender receiver | | | | | RESERVE | | | +--------->| | | | | RESERVE | | | +--------->| | | | | RESERVE | | | +--------->| | | | | | | | RESPONSE | | | |<---------+ | | RESPONSE | | | |<---------+ | | RESPONSE | | | |<---------+ | | | | | | | | | | Figure 1 : Basic Sender-initiated Reservation F.Tommasi, et al. Expires August 2006 [Page 5] Internet-Draft Semi-Proactive QoS Re-establishment February 2006 QNR QNE QNE QNI sender receiver | | | | | QUERY | | | +--------->| | | | | QUERY | | | +--------->| | | | | QUERY | | | +--------->| | | | | | | | RESERVE | | | |<---------+ | | RESERVE | | | |<---------+ | | RESERVE | | | |<---------+ | | | | | | | RESPONSE | | | +--------->| | | | | RESPONSE | | | +--------->| | | | | RESPONSE | | | +--------->| | | | | Figure 2 : Basic Receiver-initiated Reservation The procedure we are presenting in this draft, the semi-proactive procedure, proposes to re-establish the QoS as fast as possible. The key point of the situation is to initiate, in a proactive way, as many operations as possible without wasting the resources available. In order to do this we propose to create the GA before the handover and to reserve the resources on the New path after the moving of the MN. The Reserve message therefore can only be sent after the handover. In case of receiver-initiated reservation(figure 3) it easy to define a separation between the creation of the state and the reservation of the resources. In fact it is only necessary that the QNR (close to the sender of data flow) sends the Query message F.Tommasi, et al. Expires August 2006 [Page 6] Internet-Draft Semi-Proactive QoS Re-establishment February 2006 before the handover and the QNI responds with Reserve message after the movement of the MN. The problem is the separation of the two phases when the reservation is sender-initiated. Also in this case, the Query message is used in order to obtain the separation between the GA creation and the resource reservation (figure 4). QNR QNE QNE QNI sender receiver | | | | | QUERY | | | Proactive +--------->| | | | | QUERY | | | +--------->| | | | | QUERY | | | +--------->| Proactive | | | | | | | RESERVE | | | |<---------+ Reactive | | RESERVE | | | |<---------+ | | RESERVE | | | Reactive |<---------+ | | | | | | | RESPONSE | | | Reactive +--------->| | | | | RESPONSE | | | +--------->| | | | | RESPONSE | | | +--------->| Reactive | | | | Figure 3 : Receiver-initiated Semi-Proactive QoS Re-establishment F.Tommasi, et al. Expires August 2006 [Page 7] Internet-Draft Semi-Proactive QoS Re-establishment February 2006 QNI QNE QNE QNR sender receiver | | | | | QUERY | | | Proactive +--------->| | | | | QUERY | | | +--------->| | | | | QUERY | | | +--------->| Proactive | | | | | | | | | RESERVE | | | Reactive +--------->| | | | | RESERVE | | | +--------->| | | | | RESERVE | | | +--------->| Reactive | | | | | | | RESPONSE | | | |<---------+ Reactive | | RESPONSE | | | |<---------+ | | RESPONSE | | | Reactive |<---------+ | | | | | | | | | | Figure 4 : Sender-initiated Semi-Proactive QoS Re-establishment In addition, we would like to consider that in the proactive phase the PAR has available a list of CAR. Every one of these should be considered to be like QNI or QNR on the basis of type of the reservation and sends/receives the Query message for the creation of the GA. The procedure consists of three main sections: 1. Triggering, in which the PAR communicate to the correct end- point of sending the Query message. 2. Proactive, in which the Query message allows the creation of the GIST state and the discovery of the CCRN. 3. Reactive, in which resources are reserved. F.Tommasi, et al. Expires August 2006 [Page 8] Internet-Draft Semi-Proactive QoS Re-establishment February 2006 3.2 Triggering section step 1): the MN asks the PAR for the list of CARs and notifies the PAR to send the trigger message. step 2): if the MN is the sender of the data flow, the PAR triggers each CAR for creating a GA towards the CN. Instead, if the MN is the receiver of the data flow, the PAR triggers the CN for creating a GA into each path towards the CARs; 3.3 Proactive section The aim of this section is to describe the creation of the GA in a proactive way. 3.3.1 Classification of the end-points In NSIS a resource reservation can be sender or receiver-initiated. In the first case, the sender of the data flow is the starter of the reservation while in the case of receiver-initiated reservation the receiver is the starter. From the MN point of view two other cases exist: the MN is the sender or the receiver of the data stream. The possible combinations are shown in figure 5. +---------------------+----------------------------------+ | \ MN | Sender | Receiver | |Reservation \ | | | +---------------------+-----------------+----------------+ | Sender-initiated | CAR=QNI,CN=QNR | CAR=QNR,CN=QNI | +---------------------+-----------------+----------------+ | Receiver-initiated | CAR =QNR,CN=QNI | CAR =QNI,CN=QNR| +---------------------+-----------------+----------------+ Figure 5 : Nodes in the Proactive phase F.Tommasi, et al. Expires August 2006 [Page 9] Internet-Draft Semi-Proactive QoS Re-establishment February 2006 According to the current definition of NSIS a QoS-NSLP, the Reserve message travels from QNI to QNR and the QoS-NSLP Query follows the data flow direction. 3.3.2 Receiver-initiated reservation The Query message is sent by QNR node in downstream direction towards the QNI. We add a mobility flag to allow to a QNE to distinguishing the regular NSIS procedure. When QNI receive this message it waits to the end of the handover to respond with a Reserve message that contains mobility flag. No other messages, TLV objects or fields are needed. 3.3.3 Sender-initiated reservation The Query message is sent in a downstream direction in the same way as the receiver-initiated reservation case. An important difference is that this message travels from the QNI to the QNR. After the handover the QNR which has received a Query message will wait for the Reserve message with the mobility flag, without taking any action. 3.3.4 Proactive selection of the CAR In order to optimize this procedure it is possible to define a selective algorithm to choose a given CAR from the set of CARs using information such as the characteristic of the service offered by the CAR. The definition of such algorithm is out of the scope to this version of the document. 3.4 Reactive section The aim of this paragraph is to define the procedures executed after the MN handover. F.Tommasi, et al. Expires August 2006 [Page 10] Internet-Draft Semi-Proactive QoS Re-establishment February 2006 The GA has been installed as previously mentioned in the paths between the CN and a CAR each. The resource reservation is performed only on the path from the QNI to the QNR in reactive way. The possible scenarios are described in the following figure. +---------------------+----------------------------------+ | \ MN | Sender | Receiver | |Reservation \ | | | +---------------------+-----------------+----------------+ | Sender-initiated | NAR=QNI,CN=QNR | NAR=QNR,CN=QNI | +---------------------+-----------------+----------------+ | Receiver-initiated | NAR =QNR,CN=QNI | NAR =QNI,CN=QNR| +---------------------+-----------------+----------------+ Figure 6 : Nodes in the Reactive phase After the handover QNI will send a Reserve message. The QNR will answer with a Response message. Both messages contain the mobility flag. In order to benefit from this procedure the NAR has to be one of the CAR otherwise there wouldn't be a GA with the CN and the procedure becomes totally reactive. In this phase we perform the Local path Repair procedure instead of path Repair using the CRN discovered during the creation of the GA. Path Repair consists of reserving resources for a session in the New path and to tear down the old reservation on the Old path for the same session. The following definitions are given: - Local Old path is the path between PAR and CRN; - Local New path is the path between NAR and CRN; - Local Update path is the path between CN and CRN; F.Tommasi, et al. Expires August 2006 [Page 11] Internet-Draft Semi-Proactive QoS Re-establishment February 2006 Then, resources must be reserved in the Local New path (Reserve massage), torn down in the Local Old path (Reserve massage with TEAR flag set) and updated in the Local Update path (Reserve massage with REPLACE flag set). CRN receives the reserve message from the QNI and in addition sends it towards the QNR and towards the PAR setting TEAR and REPLACE flag as it is explained in the previous paragraph. 4 Semi-proactive Procedure by the GIST point of view The fundamental aim of the GIST protocol is to discover the path that signaled data will follow and to create a GA between the end- points of data flow. On the basis of what has already been said previously, in networks in which there are MNs it is better to create a proactive GA on all of the Candidate paths. The GIST protocol during the creation of the GA takes into consideration also the discovery of the CCRN. The algorithm of the discovery is quite simple thanks to the information contained in the GIST-Query, GIST-Response and GIST-Confirm messages. At the end of the proactive phase there will be therefore, as many GA as there are nodes contained in the CAR list. In order to achieve this all the protocol needs is one flag only (M- Mobility flag) which indicates to the nodes the particular scenario in which they are working. We propose to use one of the reserved bit in GIST Common Header for this flag. Moreover, a new TLV object extends those already present in the protocol, in order to help the discovery of the CCRN and the transport of information in this node after it has been individuated. The next version of the draft counts on having greater details of this object. 4.1 CCRN e CRN Both CCRN and CRN have an important role in the procedures described in this draft. F.Tommasi, et al. Expires August 2006 [Page 12] Internet-Draft Semi-Proactive QoS Re-establishment February 2006 It is potentially possible to discover as many CCNRs as CARs. In the proactive phase, if the MN is the receiver of the data flow, the CCRNs buffer the packets sent to the MN during handover (as described in paragraph 4.2). In the reactive phase the CRN will be the principle node and indispensable to the Local path Repair (see paragraph 3.4). 4.2 The new buffering If the MN is the data flow receiver, it is necessary to have buffering mechanisms in order to avoid the loss of packets sent to MN during its handover. The buffered packets are sent to the MN across the NAR at the end of the handover. This type of solutions have already been defined[7]. They guarantee only a minimal loss of packets but not the right QoS during the sending of the buffered packets to the MN. We have proposed the inclusion of buffering in the CCRN for various reasons. Above all because the CCRN is the closest node to the MN on the New path in which buffering is possible. This means to reduce the total time that the buffered packets use to reach the MN. The second motivation for making this choice regards the QoS. The buffered packets, sent on the Local New path after the reservation of resources are treated by the same QoS as other packets from the same flow. A CCRN start to buffer packets as soon as it has been discovered The CRN ends bufferization of packets when it receives from the QNI the Reserve message. The other CCRNs stop the bufferization of packets and discard the already buffered packets at the end of timeout. F.Tommasi, et al. Expires August 2006 [Page 13] Internet-Draft Semi-Proactive QoS Re-establishment February 2006 If the MN is the data flow sender it is not necessary to effect any bufferization. 4.3 CCRN Discovery If the MN is the data flow sender we are able to discover the CCRN as the first node, NSIS aware, in which the Old and the Candidate path converge. If the MN and the receiver of the data flow the CCRN will be the last entity NSIS aware before the Old and the Candidate path diverge. As a consequence, the CCRN will be a node on the common trunk between the Old path and the Candidate one. The discovery of the CCRN is effected by GIST during the creation of the GA, in fact the protocol, during that phase possesses all the information necessary for the mentioned discovery. If in a subnet there are many mobile terminals that communicate with the same CN or with neighbouring CN, the CCNRs of different handovers can coincide in the same node. The node therefore, could be found managing different buffering as well as forwarding packets. It is possible to introduce more complex algorithms for choosing CCRNs which take into account the node position and the presence of already opened bufferization. Future versions will consider detailed description of the two algorithms and the TLV objects to insert in the GIST messages. 5 Security Considerations There is no security consideration. 6 References [1] Perkins, C., "IP Mobility Support for IPv4", RFC 3220, January 2002. [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. F.Tommasi, et al. Expires August 2006 [Page 14] Internet-Draft Semi-Proactive QoS Re-establishment February 2006 [3] Hancock, R., Karagiannis, G., Loughney, J. and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005. [4] Schulzrinne, H., and R. Hancock, "GIST: General Internet Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-08 (work in progress), September 2005. [5] Bosch, S., "NSLP for Quality-of-Service signalling", draft-ietf- nsis-qos-nslp-08 (work in progress), October 2005. [6] Johnson, D., and C. Perkins, "Route Optimization in Mobile IP" Internet Draft draft-ietf-mobileip-optim-11 (work in progress), September 2001. [7] Perkins, C. and K-Y. Wang, "Optimized smooth handoffs in Mobile IP", Proceedings of IEEE Symposium on Computers and Communications, Egypt, July 1999. Authors' Addresses Franco Tommasi University of Lecce, Fac. Ingegneria Via Monteroni 73100 Lecce, ITALY franco.tommasi@unile.it Simone Molendini University of Lecce, Fac. Ingegneria Via Monteroni 73100 Lecce, ITALY simone.molendini@unile.it Andrea Tricco University of Lecce, Fac. Ingegneria Via Monteroni 73100 Lecce, ITALY andrea.tricco@unile.it Elena Scialpi University of Lecce, Fac. Ingegneria Via Monteroni 73100 Lecce, ITALY elena.scialpi@unile.it F.Tommasi, et al. Expires August 2006 [Page 15] Internet-Draft Semi-Proactive QoS Re-establishment February 2006 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. F.Tommasi, et al. Expires August 2006 [Page 16] Internet-Draft Semi-Proactive QoS Re-establishment February 2006