Next Steps in Signaling F. Tommasi Internet-Draft S. Molendini Expires: February 2007 A. Tricco E. Scialpi University of Lecce August 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 February, 2007. Copyright Notice Copyright (C) The Internet Society (2006). F.Tommasi, et al. Expires February 2007 [Page 1] Internet-Draft Semi-Proactive QoS Re-establishment August 2006 Abstract Re-establishment of the QoS after a Mobile Node handover must be done as quickly as possible in order to reduce degradation or interruption of the QoS and it is especially useful when realtime applications are used. We propose a Semi-Proactive procedure for a fast QoS re-establishment in environments where there are Mobile Nodes. The basic idea of this procedure is to perform as many operation as possible before the handover (in a proactive way). Resources are reserved only after the handover on the effective new data path, in order to avoid their waste. Moreover, we propose to buffer at the Candidate CRossover Node - CCRN (an intermediate node on end-to-end data path) the packets directed to the Mobile Node during the handover. In this way the total QoS re-establishment time is reduced. This buffering also guarantees, for the buffered packets, the same QoS treatment of the other packets (the no-buffered ones). 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 . . . . . . . . . . . . . . . . 4 3.2 Triggering section. . . . . . . . . . . . . . . . . . . . . . 8 3.3 Proactive section . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1 Classification of the end-points . . . . . . . . . . . . 8 3.3.2 Receiver-initiated reservation . . . . . . . . . . . . . 9 3.3.3 Sender-initiated reservation . . . . . . . . . . . . . . 9 3.3.4 Proactive selection of the CAR . . . . . . . . . . . . . 9 3.4 Reactive section. . . . . . . . . . . . . . . . . . . . . . . 9 4 Semi-Proactive Procedure by the GIST point of view. . . . . . . . 10 4.1 CCRN e CRN. . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2 CCRN Discovery. . . . . . . . . . . . . . . . . . . . . . . . 11 5 The new buffering . . . . . . . . . . . . . . . . . . . . . . . . 12 6 Security Considerations . . . . . . . . . . . . . . . . . . . . . 12 7 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 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, the Mobile IP provides the node to maintain a higher-layer connection while moving. 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. F.Tommasi, et al. Expires February 2007 [Page 2] Internet-Draft Semi-Proactive QoS Re-establishment August 2006 In order to allow the signal packets to have a secure path, GIST provides the modality "connection" creating the GIST state so that there is an association between the adjacent GIST nodes. This 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, the so called 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. Resource reservation on the New path must be done as quickly as possible in order to reduce the degradation of QoS for the MN which is especially important when real-time applications are used. A basic idea for reducing such delay could be to re-establish QoS before the handover on all 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 they are assigned on all Candidate paths and we have no guarantee that the handover will occur. We therefore, propose to take the pros of both mechanism by creating the Messaging Associations in a proactive way and by assigning resources in the reactive way. We may say that we are acting in a Semi-Proactive way. Adopting this solution we anticipate the creation of the GIST state before the handover. The resource reservation is as usual performed after the handover but the total time will be minimal. Moreover, resources are assigned only to the effective path to avoid their waste. In our solution the re-establishment is faster also because we introduce the possibility of buffering the packets directed to MN, in an intermediate node of the end-to-end path. This node is known as the Candidate CRossover Node (CCRN). This type of solution is a case of: - Predictive routing (section 3.3 of [4]) defined as a predictive installation of the state on the path that will be used after a MN handover; - Path-decoupled signaling as defined in [3]. Consequently, implementing this solution does not need to introduce new messages in the QoS-NSLP and NTLP protocols but only a new Message Routing Method (MRM) will be added. This describes the algorithm for discovering both the CCRN and the route which signaling messages should take (see section 4). The procedures described in the following paragraphs are applicable in networks served by Mobile IPv4 with Route Optimization [6] or by Mobile IPv6 (in which the Route Optimization is already integrated). F.Tommasi, et al. Expires February 2007 [Page 3] Internet-Draft Semi-Proactive QoS Re-establishment August 2006 2 Terminology NSIS-aware: a node is NSIS-aware when it supports NTLP and QoS-NSLP; Mobile Node (MN): a host that can change its point of connection to the network; Correspondent Node (CN): the network node with which the MN is communicating at that time; Access Router (AR): the access node to the network for an MN; Previous AR (PAR): the AR for the MN before the handover; Candidate AR (CAR): possible AR for a handover of the MN; New AR (NAR): the AR for the MN after the handover; New path: the path between CN and NAR; Old path: the path between CN and PAR; Candidate path: the path between CN and CAR; Crossover node (CRN): one of the NSIS-aware nodes of the intersection between the Old and New path; Candidate CRN (CCRN): one of the NSIS-aware nodes of the intersection between the Old and Candidate path; 3 Semi-Proactive Procedure from the NSLP point of view In following paragraphs we will present a detailed description of the main phases of the Semi-Proactive procedure. 3.1 Introduction to the procedure Let us first recall 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 is called 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, the QNI is the NSIS-aware node that is closer to the sender of that flow. Moreover, going through the nodes, the same RESERVE message allows the GIST to create its state. In the case of a receiver-initiated reservation (figure 2), the RESERVE message travels in the opposite direction to the data flow. F.Tommasi, et al. Expires February 2007 [Page 4] Internet-Draft Semi-Proactive QoS Re-establishment August 2006 Therefore, the QNI is the NSIS-aware node that is closer 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 its state. QNI QNE QNE QNR sender receiver | | | | | RESERVE | | | +--------->| | | | | RESERVE | | | +--------->| | | | | RESERVE | | | +--------->| | | | | | | | RESPONSE | | | |<---------+ | | RESPONSE | | | |<---------+ | | RESPONSE | | | |<---------+ | | | | | | | | | | Figure 1 : Basic Sender-initiated Reservation QNR QNE QNE QNI sender receiver | | | | | QUERY | | | +--------->| | | | | QUERY | | | +--------->| | | | | QUERY | | | +--------->| | | | | | | | RESERVE | | | |<---------+ | | RESERVE | | | |<---------+ | | RESERVE | | | |<---------+ | | | | | | | RESPONSE | | | +--------->| | | | | RESPONSE | | | +--------->| | | | | RESPONSE | | | +--------->| | | | | Figure 2 : Basic Receiver-initiated Reservation F.Tommasi, et al. Expires February 2007 [Page 5] Internet-Draft Semi-Proactive QoS Re-establishment August 2006 The Semi-Proactive procedure, presented in this draft, proposes to re-establish the QoS as fast as possible. The best way is to initiate, in a proactive way, as many operations as possible but without the waste of the available resources. In order to do this we propose to create the GIST state 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 is 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 before the handover and the QNI responds with the RESERVE message after the movement of the MN. The problem is the separation of the two phases when the reservation is sender-initiated. Therefore, also in this case, we could send a QUERY message in order to obtain the separation between the GIST state 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 February 2007 [Page 6] Internet-Draft Semi-Proactive QoS Re-establishment August 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 already available a list of CARs. Each one of these could act like or as a QNI or as a QNR depending on the type of reservation; so it would send or receive the QUERY message for the GIST state creation. The procedure consists of three main sections: 1. Triggering, in which the PAR communicates to the correct end- point so that it sends 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 the resources are reserved. F.Tommasi, et al. Expires February 2007 [Page 7] Internet-Draft Semi-Proactive QoS Re-establishment August 2006 3.2 Triggering section Triggering section is the first phase of the procedure proposed in this draft and it is composed by two main steps. In the first step the MN asks the PAR for the list of the CARs and notifies the PAR to send the trigger message. In the second step if the MN is the sender of the data flow, the PAR triggers each CAR for creating a GIST state towards the CN. Instead, if the MN is the receiver of the data flow, the PAR triggers the CN for creating a GIST state on each Candidate path towards the CARs. 3.3 Proactive section The aim of this section is to describe the creation of the GIST state 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 for the receiver-initiated reservation the receiver would be the starter. From the MN point of view two other cases exist: the MN can be the sender or the receiver of the data stream. This means that we have the following possible combinations as 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 According to the current definition of NSIS a QoS-NSLP RESERVE message travels from QNI to QNR and the QoS-NSLP QUERY follows the data flow direction. F.Tommasi, et al. Expires February 2007 [Page 8] Internet-Draft Semi-Proactive QoS Re-establishment August 2006 3.3.2 Receiver-initiated reservation The QUERY message is sent by QNR node in downstream direction towards the QNI. A Mobility flag (M flag) is added in the Generic flags that are in the QoS-NSLP Common Header. This allows a QNE to distinguish the Semi- Proactive procedure from the regular NSIS procedure. When QNI receives this message it waits 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, but in this case the message travels from the QNI to the QNR. After the handover, the QNR that has received a QUERY message will wait for the RESERVE message with the Mobility flag, without taking any other 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 In this paragraph we will define the procedures carried out after the MN handover. The GIST state has been installed, as previously mentioned, in the paths between the CN and each CAR. The resource reservation is performed only on the path from the QNI to the QNR in a reactive way. The possible scenarios are described in the following figure. F.Tommasi, et al. Expires February 2007 [Page 9] Internet-Draft Semi-Proactive QoS Re-establishment August 2006 +---------------------+----------------------------------+ | \ 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 the 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 must be one of the CARs otherwise there wouldn't be a GIST state with the CN and the procedure from Semi-Proactive would become totally Reactive. In this phase we perform the Local Path Repair procedure instead of the Path Repair, using the CRN discovered during the creation of the GIST state. The 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. To understand the Local Path Repair, 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; What happens is that, in the Local New path, the resources must be reserved (RESERVE massage) and torn down in the Local Old path (RESERVE massage with TEAR flag set) while updated in the Local Update path (RESERVE massage with REPLACE flag set). 4 Semi-Proactive Procedure by the GIST point of view The fundamental aim of the GIST protocol is to discover the path in which signaled data will follow and to create a GIST state between the end-points of the data flow. On the basis of what has already been said previously, in networks where there are MNs it is better to create a proactive GIST state on all of the Candidate paths. The GIST protocol during the creation of the GIST state discovers the CCRN. The algorithm for 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 GIST state as the nodes contained in the CAR list. F.Tommasi, et al. Expires February 2007 [Page 10] Internet-Draft Semi-Proactive QoS Re-establishment August 2006 In order to implement the Semi-Proactive mechanism a new Message routing method (MRM) is used. This MRM is called Semi-Proactive MRM. The document in [4] describes the path-coupled MRM which is applied when signaling messages follow the route defined by an existing flow in the network. Semi-Proactive MRM describes the algorithm for realizing Predictive routing and path-decoupled signaling. It also contains information for discovering the CCRN and the route that signaling messages should take. It transports information of the newly discovered CCRN to the other QNE on the path. Details of the Semi-Proactive MRM will be provided in future version of this document. 4.1 CCRN and CRN Both CCRN and CRN have an important role in the procedures described in this draft. 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 buffers the packets sent to the MN during the handover (as described in paragraph 5). In the reactive phase the CRN will be the principle node of the Local path Repair (see paragraph 3.4). 4.2 CCRN Discovery If the MN is the data flow sender the CCRN could be the first NSIS-aware node in which the Old and the Candidate path converge. If the MN and the receiver of the data flow the CCRN could be the last NSIS-aware entity 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 realized by the GIST protocol during the creation of the GIST state. 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 are communicating with the same CN or with neighbouring CN, the CCNRs of different handovers could coincide in the same node. Therefore the node in managing different buffering would have more work load to handle with. It is possible to introduce more complex algorithm for choosing other CCRNs. This algorithm must take in account the node position and the presence of bufferization already in act. Future versions will consider detailed description of the two algorithms. F.Tommasi, et al. Expires February 2007 [Page 11] Internet-Draft Semi-Proactive QoS Re-establishment August 2006 5 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 has already been defined. For example, Perkins[7] propose to buffer at the PAR (in the document this node is called Foreign Agent) but it guarantees only a minimal loss of packets and 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 the other packets from the same flow. A CCRN starts to buffer packets as soon as it has been discovered. The CRN ends the 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 a timeout. If the MN is the data flow sender it is not necessary to effect any bufferization. 6 Security Considerations For the moment we haven?t taken into account the security problem. 7 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. [3] Hancock, R., Karagiannis, G., Loughney, J. and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005. F.Tommasi, et al. Expires February 2007 [Page 12] Internet-Draft Semi-Proactive QoS Re-establishment August 2006 [4] Schulzrinne, H., and R. Hancock, "GIST: General Internet Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-10 (work in progress), July 2006. [5] Bosch, S., "NSLP for Quality-of-Service signalling", draft-ietf- nsis-qos-nslp-11 (work in progress), June 2006. [6] Johnson, D., and C. Perkins, "Route Optimization in Mobile IP" Internet Draft draft-ietf-mobileip-optim-11, 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 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 F.Tommasi, et al. Expires February 2007 [Page 13] Internet-Draft Semi-Proactive QoS Re-establishment August 2006 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 February 2007 [Page 14] Internet-Draft Semi-Proactive QoS Re-establishment August 2006