Internet DRAFT - draft-tommasi-nsis-semipro
draft-tommasi-nsis-semipro
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
<draft-tommasi-nsis-semipro-01.txt>
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
