Internet DRAFT - draft-abondo-hmprsvp
draft-abondo-hmprsvp
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:
<SESSION> <SESSION>
Service_Class: Flow_Specification_Class:
<SENDER_TSPEC> <TIME_VALUES>
[FLOWSPEC]
[<POLICY_DATA>]
Flow_Specification_Class: Security_Class:
<SESSION> [<INTEGRITY>]
<SENDER_TEMPLATE>
<TIME_VALUES>
{<FILTER_SPEC>}
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
