One document matched: draft-lee-nsis-mobility-nslp-00.txt
IETF Next Steps in Signaling S. Lee
Working Group J. Bang
Internet-Draft B. Lee
Expires: April 19, 2004 SAMSUNG AIT
S. Jeong
HUFS
October 20, 2003
Mobility Functions in the QoS-NSLP
draft-lee-nsis-mobility-nslp-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 on April 20, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
The NSIS working group is standardizing a signaling protocol suite
with QoS signaling as the first use case. The overall signaling
protocol suite is decomposed into a generic lower layer with separate
upper layers for signaling applications. The upper layer protocol,
called NSIS Signaling Layer Protocol (NSLP), has an end-to-end scope
and contains application specific functionality. One of the important
features of an NSLP is mobility support. This document identifies
desired mobility functions in an NSLP for QoS signaling (QoS-NSLP) in
the network.
Lee, et al. Expires April 19, 2004 [Page 1]
Internet-Draft mQoS-NSLP October 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Route Change and Mobility . . . . . . . . . . . . . . . . . . 5
3. Make-before-Break vs. Break-before-Make . . . . . . . . . . . 6
4. Mobility Event Detection . . . . . . . . . . . . . . . . . . . 7
5. Localized Path Repair . . . . . . . . . . . . . . . . . . . . 8
6. Route Change and Mobility . . . . . . . . . . . . . . . . . . 9
7. Support for Reservation Modes . . . . . . . . . . . . . . . . 10
8. Interaction with Mobility Protocols . . . . . . . . . . . . . 11
9. QoS Re-establishment Mechanisms in Mobile Scenarios . . . . . 13
9.1 Fast QoS Re-establishment . . . . . . . . . . . . . . . . . . 13
9.2 Fast Release of Resources . . . . . . . . . . . . . . . . . . 14
9.3 Confirmation/Error Handling . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix. A QoS Pre-establishment Procedures . . . . . . . . . . . 18
References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . 22
Lee, et al. Expires April 19, 2004 [Page 2]
Internet-Draft mQoS-NSLP October 2003
1. Introduction
The lower layer in the NSIS protocol suite, the NSIS Transport Layer
Protocol (NTLP) is intended to provide a generally useful transport
service for such signaling messages. The actual signaling messages
are in general originated within upper layer signaling applications,
each having its own NSIS Signaling Layer Protocol (NSLP), and the
role of the NTLP is primarily just to move these messages around the
network to the appropriate nodes. The general description of the NSIS
protocol suite, including its two-layer architecture, can be found in
[2].
One of the important features of an NSLP (in particular, an NSLP with
QoS support) is mobility support. This document describes desired
mobility functions in an NSLP for QoS signaling (hereafter
'QoS-NSLP') considering the mobility requirements for future
signaling protocols. The main objective of the QoS-NSLP is to provide
resource reservation. In this draft, only mobility-related protocol
mechanisms of the QoS-NSLP are described, and the mobility
functionality of the QoS-NSLP is called mQoS-NSLP.
In high mobility environments, frequent handovers may result in a
significant degradation of QoS performance if the wireless access
network is unable to provide enhanced solutions for prompt QoS
re-establishments. Therefore, one of the key features that should be
supported in mQoS-NSLP is fast QoS re-establishment. The mQoS-NSLP
should also support resource reservation in both sender- and
receiver-oriented modes where a mobile node (MN) could be the sender
or receiver. Based on these considerations, this document describes
desired mobility functions for the mQoS-NSLP, including
make-before-break, mobility event detection, localized path repair,
state management, interaction with mobility protocols and so on.
1.1 Terminology
AR: Access Router
CAR: Candidate Access Router
CARD: Candidate Access Router Discovery
CCND: Candidate Crossover Node Discovery
CN: Correspondent Node
CT: Context Transfer
Lee, et al. Expires April 19, 2004 [Page 3]
Internet-Draft mQoS-NSLP October 2003
MN: Mobile Node
mQoS-NSLP: Mobility Functionality of QoS-NSLP
NE: NSIS Entity
NSLP: NSIS Signaling Layer Protocol
NTLP: NSIS Transport Layer Protocol
OAR: Old Access Router
Lee, et al. Expires April 19, 2004 [Page 4]
Internet-Draft mQoS-NSLP October 2003
2. Route Change and Mobility
Although the route change caused by the mobility event may be
considered similar to standard route changes, the main difference is
that the flow identifier does not change after the standard route
change while the mobility may cause the change of the flow
identifier. Therefore, the flow identifier should be updated along
the entire chain of NSIS entities that are involved with the session
that has been impacted by the mobility event. To update the flow
identifier in an end-to-end manner, the crossover node which is the
merging point of the old and new paths may decide to forward a state
update message further towards the destination.
The NTLP should detect any route change caused by the mobility event
at transport level and triggers the mQoS-NSLP, and then the mQoS-NSLP
should initiate necessary state creation (i.e., QoS re-establishment)
along the new path and the update or removal of associated states, at
signaling application level. Note that QoS re-establishment due to
the standard route change may not need any state update along the
entire signaling path since the flow identifier does not change
(e.g., the IP address of endpoint does not change). The details about
the route change detection procedure can be found in [21].
Lee, et al. Expires April 19, 2004 [Page 5]
Internet-Draft mQoS-NSLP October 2003
3. Make-before-Break vs. Break-before-Make
The act of transferring support of an MN from one AR to another is
called handover. In other words, handover occurs when a flow has to
be handed off from one AR to another as the MN moves. There are two
possibilities for handling handover in terms of resource reservation:
Make-before-Break and Break-before-Make.
With Make-before-Break approach, resource reservation is set up along
the new path including a new AR before releasing the resource along
the old path. With Break-before-Make approach, current resource
reservation is torn down before resource reservation is set up on the
new path.
Compared to the Break-before-Make approach, the Make-before-Break
provides less QoS service disruption. In this case, however, it is
necessary to provide QoS re-establishment in a very fast manner.
Pre-reservation of resources or multi-homing support could be helpful
for immediate QoS re-establishment after handover. In this draft,
Make-before-Break approach is assumed to be used.
Lee, et al. Expires April 19, 2004 [Page 6]
Internet-Draft mQoS-NSLP October 2003
4. Mobility Event Detection
Most of the existing approaches for signaling protocols consider only
the actions which have to be taken after a handover occurs. Some
newly proposed protocols use various ideas to speed up the QoS
re-establishment and handle the specific mobility related events,
e.g., the change of the IP address of an MN. However, most of the
protocols do not introduce mechanisms for the preparation of a
handover.
To prepare immediate handover (i.e., for fast QoS re-establishment),
the ?«MOBILITY?? object can be used by the mQoS-NSLP [15]. The
?«MOBILITY?? object contains the detailed information about the
mobility event which should be used for a particular treatment by
associated NSIS entities. The signaling messages can contain the
MOBILITY object as an explicit indicator of any mobility event. The
MOBILITY object may consist of one or more 32-bit words with a one
word header.
When an MN detects a handover, the mQoS-NSLP of the MN may set the
MOBILITY object in the refresh message and sends it to the current
AR. The mQoS-NSLP of the AR may also set the MOBILITY object after
receiving the movement information generated by a mobility protocol
(e.g., 'RtSolPr' message in FMIPv6 [14]) within the MN.
The MOBILITY object will be delivered to involved NSIS entities along
the current signaling path to inform of the mobility event. The
mobility event will eventually cause a route change as the MN moves
to the new AR.
Lee, et al. Expires April 19, 2004 [Page 7]
Internet-Draft mQoS-NSLP October 2003
5. Localized Path Repair
Usually, QoS-related information is generated by an MN or CN, and
sent to a peer representing the opposite terminating point of the
path. The paths in a mobility supporting access network usually
change only partially. Therefore, the mQoS-NSLP should support
localized path repair to avoid end-to-end signaling message exchanges
which may incur a long delay. In other words, the mQoS-NSLP needs to
limit the scope of signaling information to a section of the
signaling path. This is referred to as localized signaling.
The localized QoS signaling can be initiated by the NSIS-aware
merging point of the old and new paths, which is sometimes called
crossover node. After the crossover node is determined by the NTLP
[21], the mQoS-NSLP should be notified of the crossover determination
to re-install reservation states along the new path and to remove old
reservation states along the old path.
If the Old AR is the last node due to handover, the mQoS-NSLP of the
NE in the old AR may trigger an error message to indicate that no
more mQoS-NSLP messages will be forwarded to the last node (e.g., the
MN). However, the states along the old path must not be deleted
before re-establishing the state along the new path although the
error message is initiated.
Lee, et al. Expires April 19, 2004 [Page 8]
Internet-Draft mQoS-NSLP October 2003
6. Route Change and Mobility
The soft state similar to RSVP may need to be maintained to manage
the reservation state at the NEs in the crossover node, routers, and
MNs. On receiving a resource reservation message, an NE (specifically
the mQoS-NSLP) sets up state for fast reservation. This state is
deleted unless it is refreshed by a new resource reservation message
before the refresh timer expires.
It may be necessary to set the refresh timer value in a wireless
network to a smaller value than that in the core (wired) network [6].
The main objective of adjustment of the refresh timer value is to
minimize the unnecessary waste of resources. To do this, NEs can
appropriately set the refresh interval suitable for their own
environments in a peer-to-peer manner. Setting the timer value of the
access network differently from that of the backbone network can be
done by manual configuration or some adaptive technique.
An example of adaptive technique may be to use the 'Refresh' object
by defining the 'M' bit for mobility and the 'PRE' bit for fast
re-establishment. In mobile and wireless networks, it may be
desirable that the mQoS-NSLP can set its refresh timer value (by
setting the M bit to 1) appropriately depending on the part of the
network (e.g., an access network or backbone network). On receiving
the MOBILITY object during handover, the mQoS-NSLP of candidate NEs
which are supposedly involved in the QoS signaling application sets
the 'RFE' bit of outgoing mQoS-NSLP messages (Refresh object) for
fast QoS re-establishment. For instance, pre-reservation state may be
maintained for a short period of time. To do this, the mQoS-NSLP of
the involved NEs may set the 'PRE' bit to 1, and a pre-reservation
state may be temporarily maintained to avoid the excessive waste of
resources until the handover is completed. After handover, the PRE
bit is reset to 'null' to reduce the overhead due to frequent
transmission of refresh messages, and 'M' bit is kept to be '1' (see
Section 9.1 and Appendix A for more details)[15].
Lee, et al. Expires April 19, 2004 [Page 9]
Internet-Draft mQoS-NSLP October 2003
7. Support for Reservation Modes
The mQoS-NSLP should be able to support resource reservation in both
sender- and receiver-oriented modes where the MN could be the sender
or receiver. With the sender-initiated approach, the MN (as a sender)
can initiate a reservation setup for its outgoing flows as soon as it
has moved toward another AR. With the receiver-initiated approach,
the MN (as a sender) somehow has to inform the receiver of its
handover, thus allowing the receiver to initiate a reservation for
the flows. This delayed signaling problem in the receiver-initiated
approach can be solved in a way similar to the fast re-establishment
using the CT as described in Section 9.1.
In addition to the unidirectional reservation above, the mQoS-NSLP
should also support bidirectional reservation setup. With this
bidirectional reservation setup, the state for bidirectional data
flows is setup. In the basic case, bidirectional QoS signaling can
simply use a separate instance of the same signaling mechanism in
each direction. The bidirectional data flows have the same end
points, but the path in the two directions does not need to be the
same. In this case, there are a few merging points that downstream
state of reservation and upstream state of reservation meet.
Therefore, a crossover node for downstream reservation may be
different from that for upstream reservation when the MN reaches a
new attachment point of the network, i.e., a new AR. As a matter of
course, the Session ID in the downstream reservation must be
different from that of the upstream reservation. If the routes (i.e.,
upstream and downstream paths) are symmetric, a single signaling
message can be used to set up reservation in both directions. If the
routes are asymmetric, a signaling message from the originator (e.g.,
MN or CN) should trigger an independent signaling message from the
responder. The correlation of the signaling for the two flow
directions is carried out in the mQoS-NSLP. The NTLP would simply be
enabled to bundle the messages together.
Lee, et al. Expires April 19, 2004 [Page 10]
Internet-Draft mQoS-NSLP October 2003
8. Interaction with Mobility Protocols
As mentioned in Section 4, the mQoS-NSLP of an NE may be able to
interwork with mobility protocols using the movement detection. The
movement of an MN should be detected first by the NTLP of an MN or
AR. The mQoS-NSLP is then triggered by the NTLP to act appropriately.
The mQoS-NSLP may set the MOBILITY object of an outgoing QoS-NSLP
message for fast QoS state re-establishment. This MOBILITY object can
be used to find a crossover node or set the 'Refresh' object for
changing the timer value.
Seamless Mobility protocols Such as CARD and CT can be used to fast
re-establish the mQoS-NSLP state after handover (or during handover).
For fast re-establishment, the possible interaction scenarios with
the seamless mobility protocols are as follows. When a handover is
initiated, the current AR receiving the movement detection
information from an MN may be able to use the CARD mechanism to find
an appropriate access router (an NSIS aware node) before the handover
is completed, and as a result a few candidate access routers (CARs)
may be found. In this process, the AR should be able to recognize
whether the CARs are NSIS-aware node after sending the 'capability
reply' message (of CARD). The mQoS-NSLP of the AR may need to be
interaction with the CT protocol to transfer the mQoS-NSLP state
information for mQoS-NSLP state establishment to the newly discovered
NSIS-aware candidate ARs. After receiving the context, NTLPs of the
candidate ARs may be able to begin to trigger a candidate crossover
node discovery mechanism using the mQoS-NSLP state information [21].
The crossover node discovery can be initiated during handover (i.e.,
before the handover is completed), for instance, for fast QoS
re-establishment or pre-reservation. However, in this case, an
efficient mechanism is needed to find a candidate crossover node.
CARD and CR mechanisms can be used for this purpose. A candidate
crossover node can be found easily since the candidate crossover node
discovery is basically the same as the normal crossover node
discovery. In response to the peer discovery request message, the
candidate crossover node sends an acknowledgement message to its peer
node.
In some cases, however, it may not be possible to use mobility
related protocols such as CT and CARD. In this case, the MN can
initiate the crossover node discovery only after it arrives at a new
AR. To expedite the discovery process, it may be useful to transmit
the peer discovery message (by the NTLP) and the binding update
message at the same time.
To immediately re-establish the mQoS-NSLP state after handover, the
mQoS-NSLP should interwork with handover information (e.g., Binding
Lee, et al. Expires April 19, 2004 [Page 11]
Internet-Draft mQoS-NSLP October 2003
Update message in MIPv6). For instance, on receiving the handover
information, mQoS-NSLP can set the 'M' bit of 'Refresh' bits to
appropriately adjust the refresh timer for an access network and
quickly trigger the peer discovery of NTLP.
Lee, et al. Expires April 19, 2004 [Page 12]
Internet-Draft mQoS-NSLP October 2003
9. QoS Re-establishment Mechanisms in Mobile Scenarios
A route change due to mobility may cause the obsolete paths of
mQoS-NSLP and may also cause the service disruption due to
re-establishment of the mQoS-NSLP state. Therefore, it is required to
immediately re-establish the same state of the mQoS-NSLP and
afterwards to delete the obsolete paths quickly after handover [1].
The subsequent sections describe QoS re-establishment mechanisms in
mobile scenarios in further detail.
9.1 Fast QoS Re-establishment
This section considers two possible mechanisms to quickly
re-establish reservation of resources along the new path after
handover: Pre-establishment and Fast re-establishment [15].
The pre-establishment approach is used to reserve resources in areas
which the MN may visit to support seamless QoS services. Although the
NSIS requirement draft describes only QoS re-establishment after
handover [1], the pre-establishment is a desirable feature to
guarantee the seamless QoS services. On the other hand, the fast
re-establishment approach is used to quickly set up reservation of
resources along the new path to minimize the disruption of QoS
services after handover.
To carry out the pre-establishment mechanism, NEs may interwork with
seamless mobility protocols (e.g., CARD and CT) as mentioned in
Section 8 and use the CCND to localize the pre-establishment. The
refresh timer value may also be optimized to avoid unnecessary
pre-reservation (see Appendix A for further details).
If pre-establishment is not used (or if pre-establishment of the
mQoS-NSLP fails due to the lack of available resources or the failure
of NEs along the new path), the NEs are responsible for fast
re-establishing the mQoS-NSLP state after handover. The key ideas of
the fast re-establishment are to transfer the mQoS-NSLP state to
candidate NEs between a CCN and CARs by the CT before handover and to
localize the re-establishment after handover.
With the context transfer approach described above, the candidate NEs
try to distribute the information of mQoS-NSLP state or continuously
maintain the state until the pre-establishment succeeds before the
completion of handover. The candidates can learn the mQoS-NSLP state
from the By-the-CT approach in this way.
For example, if the MN acts as a sender in the sender-initiated
approach, the CAR may be used to establish the mQoS-NSLP state by
sending a reservation message where the 'PRE' bit is set or to
Lee, et al. Expires April 19, 2004 [Page 13]
Internet-Draft mQoS-NSLP October 2003
transfer the context related to the mQoS-NSLP state toward the CCN
during the handover. In this way, the candidate NEs between CAR and
CCN can recognize the state information.
It is also possible that the MN may initiate a reservation message
after handover. In this case, the associated NEs can establish the
mQoS-NSLP states more quickly since the mQoS-NSLP only needs to
update the changed information (e.g., refresh timer value, flow ID,
and so on)[17].
If the MN acts as a receiver, the CCN also uses the same process
toward the CARs as the MN as a sender. If the CCN fails to transfer
the states, the crossover node triggers a reservation message where
the 'M' bit is set to establish the mQoS-NSLP state after receiving
the handover information (e.g., a BU message).
In order to fast re-establish the mQoS-NSLP states in the
receiver-initiated approach, a path state should be established
first. If the MN acts as a receiver, the mQoS-NSLP of the CCN needs
to first establish the path state toward the CAR using in a
peer-to-peer manner, and afterwards the MN can quickly reserve the
resources by only sending a reservation message to the crossover node
as soon as a path setup message is received after handover.
If the MN acts as a sender, the CAR pre-establishes the path state up
to the CCN. After handover, the mQoS-NSLP of the MN sends a path
setup message where the 'M' bit is set toward the crossover node but
the NEs on the new path only update changed information (e.g.,
refresh timer value, flow ID, mQoS-NSLP SPEC, and so on). As a
result, the mQoS-NSLP state can be re-established quickly.
If the CARD and the CT are not able to interwork with NTLP/mQoS-NSLP
nor operate correctly, the re-establishment of the mQoS-NSLP state
should be localized to minimize the disruption of QOS services. In
this case, the mQoS-NSLP states are only re-established by the same
method that the existing sender-initiated and receiver-initiated
approaches operate without pre-establishment after handover. In this
case, mQoS-NSLP messages should be transmitted simultaneously with
Handover information (e.g., Biding Update message in MIPv6) even if
NTLP and mQoS-NSLP do not have any interaction with mobility
protocols as described in Section 8.
9.2 Fast Release of Resources
As in RSVP, reservation states may be explicitly torn down when a
flow terminates or when the admission control rejects a reservation.
In addition, it is needed to release the previously reserved
resources along the old path immediately after establishing the state
Lee, et al. Expires April 19, 2004 [Page 14]
Internet-Draft mQoS-NSLP October 2003
of QoS NSLP along new paths due to handover. To release the
previously reserved resources along the old path after handover, a
crossover node first needs to receive a teardown message (or a
reservation message) from the MN which arrived at a new AR. On
receiving the teardown message, NSLP on the crossover node
immediately updates reservation states of the old session and
simultaneously transmits a reservation a Reserve message toward the
old AR to delete the state of the mQoS-NSLP along the old paths.
9.3 Confirmation/Error Handling
As in RSVP, the MN can send a request for confirmation for its
reservation request. In this case, the request for confirmation is
included in the resource reservation messages.
If any reservation fails, a reservation error message will be
delivered to the MN. The reservation error message may contain enough
information so that the MN can decide its future direction.
If the Old AR is the last node after handover, the mQoS-NSLP of NE in
the old AR may trigger an error message that indicates that no more
NSLP messages are forwarded the last node. However, the states along
the old paths must not be deleted before establishing the state along
the new paths due to this error message.
Lee, et al. Expires April 19, 2004 [Page 15]
Internet-Draft mQoS-NSLP October 2003
10. Security Considerations
The mQoS-NSLP relies on the security mechanisms described in [4].
Securing the mQoS-NSLP is provided by CMS which allows resource
objects and related objects defined in this document to be
encapsulated and protected by CMS. Therefore, no separate
specification within the mQoS-NSLP is necessary to describe the
format of these objects. This allows some flexibility in including
protected objects to link the authorization step of different
protocols and to transport local information within domains. The
functionality described in [19] and [20] can be provided without
substantial protocol modification/extensions.
Lee, et al. Expires April 19, 2004 [Page 16]
Internet-Draft mQoS-NSLP October 2003
11. Conclusion
This document described the mobility functionality of the QoS-NSLP,
including make-before-break, localized path repair, state management,
unidirectional and bidirectional reservation support, interaction
with mobility protocols, and so on.
Lee, et al. Expires April 19, 2004 [Page 17]
Internet-Draft mQoS-NSLP October 2003
Appendix. QoS Pre-establishment Procedures
The pre-establishment mechanism may consist of three general
operations for seamless handover [9] [10] and two main operations for
QoS re-establishment: Movement Detection, Candidate Access Router
Discovery (CARD), Context Transfer (CT), Candidate Crossover Node
Discovery (CCND), and reservation setup.
As mentioned in Section 4, a handover initiator (e.g., an MN or an
AR) notifies the NE within the AR of the mobility event. In this
case, the mQoS-NSLP of the NE constitutes the MOBILITY object, and
should not delete the existing state along the old path even if the
error message indicating the 'Can-Not-Be-Forwarded-to-the-LAST-NODE'
is issued (see Section 5). After receiving the handover initiation
information, the mQoS-NSLP/NTLP in the AR transfers its state
information (such as the session identifier, flow identifiers,
MOBILITY object, security-related information, and so on) to
NSIS-aware CARs through interworking with CARD and CT as mentioned
Section 8. After receiving the context, the NTLP in the candidate AR
begins to trigger the CCND mechanism [21] based on the NTLP/mQoS-NSLP
state information to localize pre-establishment.
Before pre-establishment, the mQoS-NSLP of candidate ARs and a CCN
need to reset the soft state refresh timer to the optimized value by
the 'PRE' bit to utilize the resource efficiently. For example, if
the refresh timer value in the pre-establishment phase is set to a
little higher value than the estimated handover latency, the MN can
received seamless QoS Services by the pre-reserved resources, and
resources which are pre-reserved but unused will be automatically
released after timeout. After handover is completed, the mQoS-NSLP
should restore the original refresh timer value in order to avoid
frequent transmission of refresh messages (as mentioned in Section
6).
If the sender-initiated approach is used for pre-reservation and an
MN acts as a sender (or a receiver), the CARs (or the CCN(s)) reserve
resources in advance by sending a reservation message toward the
CCN(s) (or the CARs). On the other hand, if the receiver-initiated
approach is used and an MN is a sender (or receiver), the opposite
operation is performed. To distinguish pre-establishment signaling
messages from re-establishment signaling messages, the 'PRE' bit of
the 'Refresh' object may be also used. Finally, mQoS-NSLP states
between CCN and CAR will be pre-established, and the MN arriving at a
new AR can receive QoS service immediately.
Lee, et al. Expires April 19, 2004 [Page 18]
Internet-Draft mQoS-NSLP October 2003
References
[1] Brunner, M., "Requirements for Signaling Protocols",
draft-ietf-nsis-req-09 (work in progress), August 2003.
[2] Hancock, R., "Next Steps in Signaling: Framework",
draft-ietf-nsis-fw-04 (work in progress), September 2003.
[3] Chaskar, H., "Requirements of a Quality of Service (QoS)
Solution for Mobile IP", RFC 3583, September 2003.
[4] Schulzrinne, H., "CASP - Cross-Application Signaling Protocol",
draft-schulzrinne-nsis-casp-01 (work in progress), March 2003.
[5] Schulzrinne, H., "A Quality-of-Service Resource Allocation
Client for CASP", draft-schulzrinne-nsis-casp-qos-01 (work in
progress), March 2003.
[6] McDonald, A., "A Quality of Service NSLP for NSIS",
draft-mcdonald-nsis-qos-nslp-00 (work in progress), June 2003.
[7] Bosch, S., "NSLP for Quality-of-Service signaling",
draft-ietf-nsis-qos-nslp-00 (work in progress), September 2003.
[8] Schulzrinne, H., "GIMPS: General Internet Messaging Protocol
for Signaling", draft-schulzrinne-nsis-ntlp-00 (work in
progress), June 2003.
[9] Loughney, J., "Context Transfer Protocol",
draft-ietf-seamoby-ctp-04 (work in progress), October 2003.
[10] Liebsch, M., "Candidate Access Router Discovery",
draft-ietf-seamoby-card-protocol-04 (work in progress),
September 2003.
[11] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS",
draft-ietf-nsis-threats-02 (work in progress), July 2003.
[12] Buchli, M., "A Network Service Layer Protocol for QoS
signaling", draft-buchli-nsis-nslp-00 (work in progress), June
2003.
[13] Fu, X., "Mobility Support in NSIS", draft-fu-nsis-mobility-00
(work in progress), June 2003.
[14] Koodli, R., "Fast Handovers for Mobile IPv6",
draft-ietf-mobileip-fast-mipv6-08 (work in progress), October
2003.
Lee, et al. Expires April 19, 2004 [Page 19]
Internet-Draft mQoS-NSLP October 2003
[15] Lee, S., "QoS Signaling for IP-based Radio Access Networks",
draft-lee-nsis-signaling-ran-00 (work in progress), June 2003.
[16] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[17] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S.
Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC
2961, April 2001.
[18] Westberg, L., "A Proposal for RSVPv2",
draft-westberg-proposal-for-rsvpv2-01 (work in progress),
November 2002.
[19] Hamer, L-N., Gage, B. and H. Shieh, "Framework for Session
Set-up with Media Authorization", RFC 3521, April 2003.
[20] Hamer, L-N., Gage, B., Kosinski, B. and H. Shieh, "Session
Authorization Policy Element", RFC 3520, April 2003.
[21] Jeong, S., "Mobility Functions in the NTLP",
draft-jeong-nsis-mobility-ntlp-00 (work in progress), October
2003.
Authors' Addresses
Sung-Hyuck Lee
SAMSUNG Advanced Institute of Technology
i-Networking Lab.
San 14-1, Nongseo-ri, Giheung-eup
Yongin-si, Gyeonggi-do 449-712
KOREA
Phone: +82 31 280 9585
EMail: starsu.lee@samsung.com
Jongho Bang
SAMSUNG Advanced Institute of Technology
i-Networking Lab.
San 14-1, Nongseo-ri, Giheung-eup
Yongin-si, Gyeonggi-do 449-712
KOREA
Phone: +82 31 280 9585
EMail: jh0278.bang@samsung.com
Lee, et al. Expires April 19, 2004 [Page 20]
Internet-Draft mQoS-NSLP October 2003
Byoung-Joon Lee
SAMSUNG Advanced Institute of Technology
i-Networking Lab.
San 14-1, Nongseo-ri, Giheung-eup
Yongin-si, Gyeonggi-do 449-712
KOREA
Phone: +82 31 280 9626
EMail: bj33.lee@samsung.com
Seong-Ho Jeong
Hankuk University of FS
89 Wangsan Mohyun
Yongin-si, Gyeonggi-do 449-791
KOREA
Phone: +82 31 330 4642
EMail: shjeong@hufs.ac.kr
Lee, et al. Expires April 19, 2004 [Page 21]
Internet-Draft mQoS-NSLP October 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Lee, et al. Expires April 19, 2004 [Page 22]
Internet-Draft mQoS-NSLP October 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lee, et al. Expires April 19, 2004 [Page 23]
IETF Next Steps in Signaling S. Lee
Working Group SAMSUNG AIT
Internet-Draft S. Jeong
Expires: April 26, 2004 HUFS
J. Bang
BJ Lee
SAMSUNG AIT
October 27, 2003
Mobility Functions in the QoS-NSLP
draft-lee-nsis-mobility-nslp-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 on April 26, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
The NSIS working group is standardizing a signaling protocol suite
with QoS signaling as the first use case. The overall signaling
protocol suite is decomposed into a generic lower layer with separate
upper layers for signaling applications. The upper layer protocol,
called NSIS Signaling Layer Protocol (NSLP), has an end-to-end scope
and contains application specific functionality. One of the important
features of an NSLP is mobility support. This document identifies
desired mobility functions in an NSLP for QoS signaling (QoS-NSLP) in
Lee, et al. Expires April 26, 2004 [Page 1]
Internet-Draft mQoS-NSLP October 2003
the network.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Route Change and Mobility . . . . . . . . . . . . . . . . . . 5
3. Make-before-Break vs. Break-before-Make . . . . . . . . . . . 6
4. Actions Triggered by a Mobility Event . . . . . . . . . . . . 7
5. Localized Path Repair . . . . . . . . . . . . . . . . . . . . 8
6. State management . . . . . . . . . . . . . . . . . . . . . . . 9
7. Support for Reservation Modes . . . . . . . . . . . . . . . . 10
8. Interactions with Mobility Protocols . . . . . . . . . . . . . 11
9. QoS Re-establishment Mechanisms in Mobile Scenarios . . . . . 13
9.1 Fast QoS Re-establishment . . . . . . . . . . . . . . . . . . 13
9.2 Fast Release of Resources . . . . . . . . . . . . . . . . . . 14
9.3 Confirmation/Error Handling . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. QoS Pre-establishment Procedures . . . . . . . . . . . 18
References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . 22
Lee, et al. Expires April 26, 2004 [Page 2]
Internet-Draft mQoS-NSLP October 2003
1. Introduction
The general description of the NSIS protocol suite, including its
two-layer architecture, can be found in [2]. The lower layer in the
NSIS protocol suite, the NSIS Transport Layer Protocol (NTLP) is
intended to provide a generally useful transport service for such
signaling messages. The actual signaling messages are in general
originated within upper layer signaling applications, each having its
own NSIS Signaling Layer Protocol (NSLP).
One of the important features of an NSLP (in particular, NSLP for QoS
support) is mobility support. This document identifies desired
mobility functions in the QoS-NSLP [7] whose main objective is
provide resource reservation according to the mobility requirements
for future signaling protocols. The mobility functions in this
document refer to the functions which are used to support mobility in
NSIS signaling. In this document, only mobility-related protocol
mechanisms of the QoS-NSLP are discussed, and the mobility
functionality of the QoS-NSLP is called mQoS-NSLP.
In high mobility environments, frequent handovers may result in a
significant degradation of QoS performance if the wireless access
network is unable to provide enhanced solutions for prompt QoS
re-establishment. Therefore, one of the key features that should be
supported in mQoS-NSLP is fast QoS re-establishment. The mQoS-NSLP
should also support resource reservation in both sender- and
receiver-oriented modes where a mobile node (MN) may act as a sender
or receiver. Based on these considerations, this document discusses
desired mobility functions for the mQoS-NSLP, including
make-before-break, mobility event detection, localized path repair,
state management, interaction with mobility protocols, and so on.
1.1 Terminology
AR: Access Router
CAR: Candidate Access Router
CARD: Candidate Access Router Discovery
CCND: Candidate Crossover Node Discovery
CN: Correspondent Node
CRN: Crossover Node
Lee, et al. Expires April 26, 2004 [Page 3]
Internet-Draft mQoS-NSLP October 2003
CT: Context Transfer
MN: Mobile Node
mQoS-NSLP: Mobility Functionality of QoS-NSLP
NE: NSIS Entity
NSLP: NSIS Signaling Layer Protocol
NTLP: NSIS Transport Layer Protocol
NAR: New Access Router
OAR: Old Access Router
Lee, et al. Expires April 26, 2004 [Page 4]
Internet-Draft mQoS-NSLP October 2003
2. Route Change and Mobility
Although the route change caused by a mobility event may be
considered similar to standard route changes, the main difference is
that the flow identifier may not change after the normal route change
(e.g., due to link or node failure) while the mobility may cause the
change of the flow identifier. Therefore, the flow identifier should
be updated along the entire chain of NSIS entities that are involved
with the session that has been impacted by the mobility event. To
update the flow identifier in an end-to-end manner, the crossover
node (CRN) which is the merging point of the old and new paths may
decide to forward a state update message further towards the
destination.
The NTLP should detect any route change caused by the mobility event
at transport level and triggers the mQoS-NSLP, and then the mQoS-NSLP
should initiate necessary state creation (i.e., QoS re-establishment)
along the new path and the update or removal of associated states, at
signaling application level. Note that QoS re-establishment due to
the standard route change may not need any state update along the
entire signaling path since the flow identifier does not change
(e.g., the IP address of endpoint does not change). The details about
the route change detection procedure can be found in [24].
Lee, et al. Expires April 26, 2004 [Page 5]
Internet-Draft mQoS-NSLP October 2003
3. Make-before-Break vs. Break-before-Make
The act of transferring support of an MN from one AR to another is
called handover. In other words, handover occurs when a flow has to
be handed off from one AR to another as the MN moves. There are two
possibilities for handling handover in terms of resource reservation:
Make-before-Break and Break-before-Make.
With the Make-before-Break approach, resource reservation is set up
along the new path including a new AR before releasing the resource
along the old path. On the other hand, with the Break-before-Make
approach, current resource reservation is torn down before resource
reservation is re-setup on the new path.
Compared to the Break-before-Make approach, the Make-before-Break
provides less QoS service disruption. In this case, however, it is
necessary to support QoS re-establishment in a very fast manner.
Pre-reservation of resources or multi-homing support could be helpful
for immediate QoS re-establishment after handover is initiated. In
the Make-before-Break approach which is assumed to be used in this
document, the mQoS-NSLP of the CRN will play a significant role in
QoS re-establishment because the CRN will be the appropriate node to
initiate a new reservation state installation.
Lee, et al. Expires April 26, 2004 [Page 6]
Internet-Draft mQoS-NSLP October 2003
4. Actions Triggered by a Mobility Event
In this section, we identify possible actions triggered by a mobility
event. After a mobility event such as a handover is detected by the
NTLP (e.g., using the Fast MIPv6 protocol), the mQoS-NSLP may need to
initiate necessary actions such as immediate QoS re-establishment on
the new path and release of resources on the old path.
To support seamless handover (i.e., immediate QoS re-establishment),
the MOBILITY object may be defined in the mQoS-NSLP message [15]. The
MOBILITY object may contain various mobility-related fields such as
the handover_init field and 'REFRESH' field. This handover_init field
may be used to notify of handover initiation or any other mobility
events, and therefore determine the appropriate time at which QoS
re-establishment can be initiated by an NSIS node (e.g., the CRN).
The REFRESH field can be used to explicitly notify of the change of
state for fast state re-establishment (see Section 6). In other
words, the MOBILITY object may act as an explicit indicator of a
mobility event for fast QoS re-establishment. In addition, the CRN
can regonize that the QoS re-establishment should be made on the
local segment (e.g., MN-to-NAR) of the signaling path when receiving
the MOBILITY object. The MOBILITY object may consist of one or more
32-bit words with a one word header as in RSVP [16]. The MOBILITY
object may also be defined in the NTLP in a similar way. In this
case, there should be some relationship between the MOBILITY objects
of the NTLP and the NSLP.
When an MN detects a handover, the mQoS-NSLP of the MN may set the
MOBILITY object in the mQoS-NSLP signaling message and send it to the
current AR, or the mQoS-NSLP of the AR may set the MOBILITY object
after receiving the movement information generated by a mobility
protocol (e.g., 'RtSolPr' message in FMIPv6 [14]).
The MOBILITY object will be delivered to involved NSIS entities along
the current signaling path to inform of the mobility event. The
MOBILITY object will eventually cause the interaction with the
seamless mobility protocols (e.g., CARD and CT), furthermore it can
be used to appropriately adjust the value of refresh timer to
minimize the waste of resources (see Sections 6 and 9).
Lee, et al. Expires April 26, 2004 [Page 7]
Internet-Draft mQoS-NSLP October 2003
5. Localized Path Repair
In general, the mQoS-NSLP related information is generated by an MN
or CN, and sent to the opposite terminating point of the path.
However, the paths in a mobility supporting access network usually
change only partially. Therefore, the mQoS-NSLP should support
localized path repair to avoid end-to-end signaling message exchanges
which may incur a long delay. In other words, the mQoS-NSLP needs to
limit the scope of signaling information to a local section of the
signaling path. This is referred to as localized signaling in this
document.
The localized QoS signaling can be initiated by the NSIS-aware
merging point of the old and new paths, which is sometimes called
crossover node (CRN). After the CRN is determined by the NTLP (see
Section 4 in [24]), the mQoS-NSLP should be notified of the CRN
determination to quickly re-install reservation states along the new
path and to remove old reservation states on the obsolete path to
avoid double reservation and to increase resource utilization.
In the localized path repair scenarios, the CRN may play the role of
an NI, NF, or NR. For example, if an MN is receiver, the CRN may need
to act as an NI to initiate QoS re-establishment on the new path and
remove the old states on the obsolete path. if an MN is sender, the
CRN may need to act as an NR to respond to the signaling initiation
message from the MN and act as an NI to remove the old states on the
obsolete path. Therefore, there may need to be some transitions
between the operation modes of the CRN depending on the situation.
If the old AR is the last node due to handover, the mQoS-NSLP of the
old AR may trigger an error message to indicate that mQoS-NSLP
messages can not be forwarded any further. The error message may
cause the removal of the old states. However, in the case, the states
along the old path must not be deleted before re-establishing the
states along the new path although the error message is initiated.
Lee, et al. Expires April 26, 2004 [Page 8]
Internet-Draft mQoS-NSLP October 2003
6. State management
The soft state similar to RSVP may need to be maintained to manage
the reservation state at the NEs in the CRN, routers, and MNs. On
receiving a resource reservation message, an NE (specifically the
mQoS-NSLP) sets up state for fast reservation. This state is deleted
unless it is refreshed by a new resource reservation message before
the refresh timer expires.
It may be necessary to set the refresh timer value in a wireless
network to a smaller value than that in the core (wired) network [6].
The main objective of adjustment of the refresh timer value is to
minimize the unnecessary waste of resources. To do this, the
mQoS-NSLP of NEs may appropriately set the refresh interval
considering network environments in a peer-to-peer manner. Setting
the timer value of the access network differently from that of the
backbone network can be done by manual configuration or some adaptive
techniques.
An example of such adaptive techniques may be to use the 'REFESH'
field of the MOBILITY object where the 'M' bit is defined to indicate
the type of network (e.g., the mobility-supporting access network)
and the 'PRE' bit is defined for fast QoS re-establishment. In mobile
and wireless networks, it may be desirable that the mQoS-NSLP can set
its refresh timer value (by setting the M bit to '1') appropriately
depending on the part of the network (e.g., an access network or
backbone network). Upon receiving the MOBILITY object during
handover, the mQoS-NSLP of candidate NEs which are supposedly
involved in the QoS signaling application sets the 'PRE' bit of
outgoing mQoS-NSLP messages for fast QoS re-establishment. For
instance, pre-reservation state may need to be maintained for a short
period of time. To do this, the mQoS-NSLP of the involved NEs may set
the 'PRE' bit to 1, and a pre-reservation state may be temporarily
maintained to avoid the waste of resources until the handover is
completed. After handover, the PRE bit is reset to 'null' to reduce
the overhead due to frequent transmission of refresh messages, and
'M' bit is kept to be '1' (see Section 9.1 and Appendix A for more
details)[15].
Lee, et al. Expires April 26, 2004 [Page 9]
Internet-Draft mQoS-NSLP October 2003
7. Support for Reservation Modes
The mQoS-NSLP should be able to support resource reservation in both
sender- and receiver-oriented modes where the MN could be the sender
or receiver. With the sender-initiated approach, the MN (as a sender)
can initiate a reservation setup for its outgoing flows as soon as it
has moved to a new AR. With the receiver-initiated approach, the MN
(as a sender) somehow has to inform the receiver of its handover,
thus allowing the receiver to initiate a reservation for the flows.
This delayed signaling problem in the receiver-initiated approach can
be solved in a way similar to the fast re-establishment using the
Candidate Access Router Discovery [10] and Context Transfer [9] as
described in Section 9.1.
In addition to the unidirectional reservation above, the mQoS-NSLP
should also support bidirectional reservation setup. With this
bidirectional reservation setup, the state for bidirectional data
flows is setup. In the basic case, bidirectional QoS signaling can
simply use a separate instance of the same signaling mechanism in
each direction. Although the bidirectional data flows have the same
end points, the path in the two directions does not need to be the
same. In this case, there are a few merging points that the
downstream state of reservation and the upstream state of reservation
meet. Therefore, the CRN for the downstream reservation may be
different from that for the upstream reservation when the MN reaches
a new attachment point of the network. As a matter of course, the
Session ID in the downstream reservation must be different from that
of the upstream reservation. If the routes (i.e., upstream and
downstream paths) are symmetric, a single signaling message can be
used to set up reservation in both directions. If the routes are
asymmetric, a signaling message from the originator (e.g., MN or CN)
should trigger an independent signaling message from the responder.
The correlation of the signaling for the two flow directions is
carried out in the mQoS-NSLP.
Lee, et al. Expires April 26, 2004 [Page 10]
Internet-Draft mQoS-NSLP October 2003
8. Interactions with Mobility Protocols
As mentioned in Section 4, the mQoS-NSLP of an NE may be able to
interwork with mobility protocols using the movement detection. The
movement of an MN should be detected first by the NTLP of an MN or
AR. The mQoS-NSLP is then triggered by the NTLP to act appropriately.
The mQoS-NSLP may set the MOBILITY object of an outgoing QoS-NSLP
message for fast QoS state re-establishment. This MOBILITY object can
be used to find a CRN or set the 'REFRESH' field for changing the
value of refresh timer.
Although NSIS is focused on Path-coupled signaling, interactions with
path-decoupled signaling protocols such as seamless mobility
protocols (e.g., CARD and CT) may be needed to fast re-establish the
mQoS-NSLP state or check resource avability on the new path after
handover (or during handover). For fast re-establishment, the
possible interaction scenarios with the seamless mobility protocols
are as follows. When a handover is initiated, the current AR
receiving the movement detection information (e.g., 'RtSolPr' message
in FMIPv6 [14]) from an MN may interact with the CARD mechanism to
find an appropriate access router (an NSIS aware node) before the
handover is completed (or, a few candidate access routers (CARs) may
be found). In this process, the NTLP of the current AR should be able
to recognize whether the CAR is an NSIS-aware node after sending the
'capability reply' message (of CARD). The mQoS-NSLP of the AR may
need to be interaction with the CT protocol to transfer the mQoS-NSLP
state information to the newly discovered NSIS-aware candidate AR.
After receiving the context, the NTLP of the candidate AR may be able
to begin to trigger a candidate crossover node discovery (CCND)
mechanism using the mQoS-NSLP state information [24].
The CRN discovery can be initiated during handover (i.e., before the
handover is completed), for instance, for fast QoS re-establishment
or pre-reservation. However, in this case, an efficient mechanism is
needed to find a candidate crossover node. CARD and CT mechanisms can
be used for this purpose. A candidate crossover node can be found
easily since the candidate crossover node discovery is basically the
same as the normal crossover node discovery [24]. In response to a
peer discovery request message, the candidate crossover node sends an
acknowledgement message to its peer node.
In some cases, however, it may not be possible to use mobility
related protocols such as CT and CARD. In this case, the MN can
initiate the crossover node discovery only after it arrives at a new
AR. To expedite the discovery process, it may be useful to transmit
the peer discovery message (by the NTLP) and the first binding update
message at the same time.
Lee, et al. Expires April 26, 2004 [Page 11]
Internet-Draft mQoS-NSLP October 2003
To immediately re-establish the mQoS-NSLP state after handover, the
mQoS-NSLP may need to monitor handover information (e.g., Binding
Update messages in MIPv6). For instance, on receiving the handover
information, mQoS-NSLP can set the 'M' bit of 'REFRESH' field to
appropriately adjust the value of refresh timer suitable for an
access network and quickly trigger the peer discovery of NTLP.
Lee, et al. Expires April 26, 2004 [Page 12]
Internet-Draft mQoS-NSLP October 2003
9. QoS Re-establishment Mechanisms in Mobile Scenarios
A route change due to mobility may cause the obsolete paths of
mQoS-NSLP and may also cause the service disruption due to
re-establishment of the mQoS-NSLP state. Therefore, it is required to
immediately re-establish the same state of the mQoS-NSLP on the new
path and afterwards to delete the obsolete paths quickly after
handover [1]. The following subsequent sections discuss QoS
re-establishment mechanisms in mobile scenarios in further detail.
9.1 Fast QoS Re-establishment
This section considers two possible mechanisms to quickly
re-establish reservation of resources along the new path after
handover: Pre-establishment and Fast re-establishment [15].
The pre-establishment approach can be used to reserve resources in
areas which the MN may visit to support seamless QoS services.
Although the NSIS requirement draft describes only QoS
re-establishment after handover [1], the pre-establishment is a
desirable feature to guarantee the seamless QoS services. On the
other hand, the fast re-establishment approach can be used to quickly
set up reservation of resources along the new path to minimize the
disruption of QoS services after handover.
To carry out the pre-establishment mechanism, NEs may interwork with
seamless mobility protocols (e.g., CARD and CT) as mentioned in
Section 8 and use the CCND to localize the pre-establishment. The
refresh timer value may also be optimized to avoid unnecessary
pre-reservation (see Appendix A for further details).
If pre-establishment is not used (or if pre-establishment of the
mQoS-NSLP fails due to the lack of available resources or the failure
of NEs along the new path), the NEs are responsible for fast
re-establishing the mQoS-NSLP state after handover. The key idea of
the fast re-establishment is to transfer the mQoS-NSLP state to
candidate NEs between the CCN and the CAR by the CT before handover
and to localize the re-establishment after handover.
With the context transfer approach described above, the candidate NEs
try to distribute the information of mQoS-NSLP state among themselves
or continuously maintain the state until the pre-establishment
succeeds before the completion of handover. In this way, the
candidate NEs can learn the mQoS-NSLP state through interactions with
the seamboby protocols.
For example, if the MN acts as a sender in the sender-initiated
approach, the CAR may be used to establish the mQoS-NSLP state by
Lee, et al. Expires April 26, 2004 [Page 13]
Internet-Draft mQoS-NSLP October 2003
sending a reservation message where the 'PRE' bit is set or to
transfer the context related to the mQoS-NSLP state toward the CCN
during the handover. In this way, the candidate NEs between CAR and
CCN can recognize the state information and check the avability of
resources on the new path.
It is also possible that the MN may initiate a reservation message
after handover. In this case, the associated NEs can establish the
mQoS-NSLP states more quickly since the mQoS-NSLP only needs to
update the changed information (e.g., refresh timer value, flow ID,
and so on)[17].
If the MN acts as a receiver, the CCN may also use the same process
toward the CARs as the MN as a sender. If the CCN fails to transfer
the states, the CRN generates a reservation message where the 'M' bit
is set to establish the mQoS-NSLP state after receiving the handover
information (e.g., the first BU message).
In order to fast re-establish the mQoS-NSLP states in the
receiver-initiated approach, a Path state may need to be established
first. If the MN acts as a receiver, the mQoS-NSLP of the CCN may
need to first establish the path state toward the CAR using in a
peer-to-peer manner, and afterwards the MN can quickly reserve the
resources by only sending a reservation message to the CRN as soon as
a path setup message is received by the MN after handover.
If the MN acts as a sender in the receiver-initiated approach, the
CAR pre-establishes the path state up to the CCN. After handover, the
mQoS-NSLP of the MN sends a path setup message where the 'M' bit is
set toward the CRN but the NEs on the new path only update changed
information (e.g., refresh timer value, flow ID, mQoS-NSLP states,
and so on). As a result, the mQoS-NSLP state can be re-established
quickly.
If the CARD and the CT are not able to interwork with NTLP/mQoS-NSLP
nor operate correctly, the re-establishment of the mQoS-NSLP state
should be still localized to minimize the disruption of QOS services.
In this case, the mQoS-NSLP states are only re-established by the
same method that the existing sender-initiated and receiver-initiated
approaches operate without pre-establishment after handover. In this
case, mQoS-NSLP messages should be transmitted simultaneously with
Handover information (e.g., the first Biding Update message in MIPv6)
even if the NTLP and the mQoS-NSLP do not have any interactions with
mobility protocols as described in Section 8.
9.2 Fast Release of Resources
As in RSVP, reservation states may be explicitly torn down by the
Lee, et al. Expires April 26, 2004 [Page 14]
Internet-Draft mQoS-NSLP October 2003
mQoS-NSLP when a flow terminates or when the admission control
rejects a reservation. In addition, it may be needed to release the
previously reserved resources along the old path immediately after
establishing the state of mQoS-NSLP along new paths due to handover.
To release the previously reserved resources along the old path after
handover, a CRN first needs to receive a teardown message (or a
reservation message) from the MN which has arrived at a new AR. On
receiving the teardown message, mQoS-NSLP of the CRN immediately
updates reservation states of the old session and simultaneously
transmits a reservation message toward the old AR to delete the state
of the mQoS-NSLP along the old path.
9.3 Confirmation/Error Handling
As in RSVP, the MN can send a request for confirmation for its
reservation request. In this case, the request for confirmation is
included in the resource reservation message.
If any reservation fails, a reservation error message will be
delivered to the MN. The reservation error message may contain enough
information so that the MN can decide its future direction.
If the Old AR is the last node after handover, the mQoS-NSLP of the
old AR may trigger an error message that indicates that NSLP messages
can not be forwarded any further. However, the states along the old
path must not be deleted before establishing the state along the new
path due to this error message.
Lee, et al. Expires April 26, 2004 [Page 15]
Internet-Draft mQoS-NSLP October 2003
10. Security Considerations
The mQoS-NSLP relies on the security mechanisms described in [4].
Securing the mQoS-NSLP is provided by CMS which allows resource
objects and related objects defined in this document to be
encapsulated and protected by CMS. Therefore, no separate
specification within the mQoS-NSLP is necessary to describe the
format of these objects. This allows some flexibility in including
protected objects to link the authorization step of different
protocols and to transport local information within domains. The
functionality described in [19] and [20] can be provided without
substantial protocol modification/extensions.
Lee, et al. Expires April 26, 2004 [Page 16]
Internet-Draft mQoS-NSLP October 2003
11. Summary
This document identified the mobility functionality of the QoS-NSLP,
including make-before-break, localized path repair, state management,
unidirectional and bidirectional reservation support, interactions
with mobility protocols, and so on.
Lee, et al. Expires April 26, 2004 [Page 17]
Internet-Draft mQoS-NSLP October 2003
Appendix A. QoS Pre-establishment Procedures
The pre-establishment mechanism may consist of three general
operations for seamless handover [9] [10] and two main operations for
QoS re-establishment: Movement Detection, Candidate Access Router
Discovery (CARD), Context Transfer (CT), Candidate Crossover Node
Discovery (CCND), and reservation setup.
As mentioned in Section 4, a handover initiator (e.g., an MN or an
AR) notifies the NE within the AR of the mobility event. In this
case, the mQoS-NSLP of the NE constitutes the MOBILITY object, and
should not delete the existing state along the old path even if the
error message indicating the 'Can-Not-Be-Forwarded-to-the-LAST-NODE'
is issued (see Section 5). After receiving the handover initiation
information, the mQoS-NSLP/NTLP in the AR transfers its state
information (such as the session identifier, flow identifiers,
MOBILITY object, security-related information, and so on) to
NSIS-aware CARs through interworking with CARD and CT as mentioned
Section 8. After receiving the context, the NTLP in the candidate AR
begins to trigger the CCND mechanism [21] based on the NTLP/mQoS-NSLP
state information to localize pre-establishment.
Before pre-establishment, the mQoS-NSLP of candidate ARs and a CCN
need to reset the soft state refresh timer to the optimized value by
the 'PRE' bit to utilize the resource efficiently. For example, if
the refresh timer value in the pre-establishment phase is set to a
little higher value than the estimated handover latency, the MN can
received seamless QoS Services by the pre-reserved resources, and
resources which are pre-reserved but unused will be automatically
released after timeout. After handover is completed, the mQoS-NSLP
should restore the original refresh timer value in order to avoid
frequent transmission of refresh messages (as mentioned in Section
6).
If the sender-initiated approach is used for pre-reservation and an
MN acts as a sender (or a receiver), the CARs (or the CCN(s)) reserve
resources in advance by sending a reservation message toward the
CCN(s) (or the CARs). On the other hand, if the receiver-initiated
approach is used and an MN is a sender (or receiver), the opposite
operation is performed. To distinguish pre-establishment signaling
messages from re-establishment signaling messages, the 'PRE' bit of
the 'Refresh' object may be also used. Finally, mQoS-NSLP states
between CCN and CAR will be pre-established, and the MN arriving at a
new AR can receive QoS service immediately.
Lee, et al. Expires April 26, 2004 [Page 18]
Internet-Draft mQoS-NSLP October 2003
References
[1] Brunner, M., "Requirements for Signaling Protocols",
draft-ietf-nsis-req-09 (work in progress), August 2003.
[2] Hancock, R., "Next Steps in Signaling: Framework",
draft-ietf-nsis-fw-04 (work in progress), September 2003.
[3] Chaskar, H., "Requirements of a Quality of Service (QoS)
Solution for Mobile IP", RFC 3583, September 2003.
[4] Schulzrinne, H., "CASP - Cross-Application Signaling Protocol",
draft-schulzrinne-nsis-casp-01 (work in progress), March 2003.
[5] Schulzrinne, H., "A Quality-of-Service Resource Allocation
Client for CASP", draft-schulzrinne-nsis-casp-qos-01 (work in
progress), March 2003.
[6] McDonald, A., "A Quality of Service NSLP for NSIS",
draft-mcdonald-nsis-qos-nslp-00 (work in progress), June 2003.
[7] Bosch, S., "NSLP for Quality-of-Service signaling",
draft-ietf-nsis-qos-nslp-00 (work in progress), September 2003.
[8] Schulzrinne, H., "GIMPS: General Internet Messaging Protocol
for Signaling", draft-schulzrinne-nsis-ntlp-00 (work in
progress), June 2003.
[9] Loughney, J., "Context Transfer Protocol",
draft-ietf-seamoby-ctp-04 (work in progress), October 2003.
[10] Liebsch, M., "Candidate Access Router Discovery",
draft-ietf-seamoby-card-protocol-04 (work in progress),
September 2003.
[11] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS",
draft-ietf-nsis-threats-02 (work in progress), July 2003.
[12] Buchli, M., "A Network Service Layer Protocol for QoS
signaling", draft-buchli-nsis-nslp-00 (work in progress), June
2003.
[13] Fu, X., "Mobility Issues in Next Steps in Signaling (NSIS)",
draft-fu-nsis-mobility-01 (work in progress), October 2003.
[14] Koodli, R., "Fast Handovers for Mobile IPv6",
draft-ietf-mobileip-fast-mipv6-08 (work in progress), October
2003.
Lee, et al. Expires April 26, 2004 [Page 19]
Internet-Draft mQoS-NSLP October 2003
[15] Lee, S., "QoS Signaling for IP-based Radio Access Networks",
draft-lee-nsis-signaling-ran-00 (work in progress), June 2003.
[16] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[17] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S.
Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC
2961, April 2001.
[18] Westberg, L., "A Proposal for RSVPv2",
draft-westberg-proposal-for-rsvpv2-01 (work in progress),
November 2002.
[19] Hamer, L-N., Gage, B. and H. Shieh, "Framework for Session
Set-up with Media Authorization", RFC 3521, April 2003.
[20] Hamer, L-N., Gage, B., Kosinski, B. and H. Shieh, "Session
Authorization Policy Element", RFC 3520, April 2003.
[21] Shen, C., "Several Framework Issues Regarding NSIS and
Mobility", draft-shen-nsis-mobility-fw-00 (work in progress),
July 2002.
[22] Chaskar, H. and C. Westphal, "QoS Signaling Framework for
Mobile IP", draft-westphal-nsis-qos-mobileip-00 (work in
progress), June 2002.
[23] Schulzrinne, H., "GIMPS: General Internet Messaging Protocol
for Signaling", draft-ietf-nsis-ntlp-00 (work in progress),
October 2003.
[24] Jeong, S., "Mobility Functions in the NTLP",
draft-jeong-nsis-mobility-ntlp-01 (work in progress), October
2003.
Authors' Addresses
Sung-Hyuck Lee
SAMSUNG Advanced Institute of Technology
i-Networking Lab.
San 14-1, Nongseo-ri, Giheung-eup
Yongin-si, Gyeonggi-do 449-712
KOREA
Phone: +82 31 280 9585
EMail: starsu.lee@samsung.com
Lee, et al. Expires April 26, 2004 [Page 20]
Internet-Draft mQoS-NSLP October 2003
Seong-Ho Jeong
Hankuk University of FS
89 Wangsan Mohyun
Yongin-si, Gyeonggi-do 449-791
KOREA
Phone: +82 31 330 4642
EMail: shjeong@hufs.ac.kr
Jongho Bang
SAMSUNG Advanced Institute of Technology
i-Networking Lab.
San 14-1, Nongseo-ri, Giheung-eup
Yongin-si, Gyeonggi-do 449-712
KOREA
Phone: +82 31 280 9585
EMail: jh0278.bang@samsung.com
Byoung-Joon (BJ) Lee
SAMSUNG Advanced Institute of Technology
i-Networking Lab.
San 14-1, Nongseo-ri, Giheung-eup
Yongin-si, Gyeonggi-do 449-712
KOREA
Phone: +82 31 280 9626
EMail: bj33.lee@samsung.com
Lee, et al. Expires April 26, 2004 [Page 21]
Internet-Draft mQoS-NSLP October 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Lee, et al. Expires April 26, 2004 [Page 22]
Internet-Draft mQoS-NSLP October 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lee, et al. Expires April 26, 2004 [Page 23]| PAFTECH AB 2003-2026 | 2026-04-24 01:56:13 |