One document matched: draft-jeong-nsis-mobility-ntlp-00.txt
IETF Next Steps in Signaling S. Jeong
Working Group HUFS
Internet-Draft S. Lee
Expires: April 19, 2004 J. Bang
B. Lee
SAMSUNG AIT
J. Hong
HUFS
October 20, 2003
Mobility Functions in the NTLP
draft-jeong-nsis-mobility-ntlp-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 19, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
The lower general layer in the NSIS protocol suite, called the NSIS
Transport Layer Protocol (NTLP), is intended to provide a general
transport service for signaling messages. One of the items on the
list of desired features for the NTLP is mobility support. This
document identifies possible mobility functions in the NTLP according
to the mobility requirements for future signaling protocols.
Jeong, et al. Expires April 19, 2004 [Page 1]
Internet-Draft Mobility Functions in the NTLP October 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Interaction with NSLPs . . . . . . . . . . . . . . . . . . . . 5
3. Detection of Route Change Caused by Mobility . . . . . . . . . 6
4. Crossover Node Discovery . . . . . . . . . . . . . . . . . . . 7
5. Dead Peer Discovery (DPD) . . . . . . . . . . . . . . . . . . 9
6. Interworking with Mobility Protocols . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13
References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 17
Jeong, et al. Expires April 19, 2004 [Page 2]
Internet-Draft Mobility Functions in the NTLP October 2003
1. Introduction
The Next Steps in Signaling (NSIS) working group is standardizing a
protocol suite for signaling in the network. The lower general layer
in the protocol suite, called the NSIS Transport Layer Protocol
(NTLP), is intended to provide a general transport service for such
signaling messages. The actual signaling messages are originated
within upper layer signaling applications, each having its own NSIS
Signaling Layer Protocol (NSLP). The main role of the NTLP is to
detect appropriate NSIS nodes and to deliver the signaling messages
to them.
Mobility support is one of the items on the list of desired features
for the NTLP. This document identifies what kind of mobility
functions should be supported in the NTLP according to the mobility
requirements for future signaling protocols. Possible mobility
functions for the NTLP include interaction with NSLPs, detection of
route change caused by mobility, crossover node discovery, dead peer
discovery, interworking with mobility protocols, and so on. The
following sections describe each of the mobility functions.
1.1 Terminology
AR: Access Router
CN: Correspondent Node
CoA: Care of Address
DPD: Dead Peer Discovery
NE: NSIS Entity
MN: Mobile Node
NSLP: NSIS Signaling Layer Protocol
NTLP: NSIS Transport Layer Protocol
PD: Peer Discovery
PD Requestor: PD requestor is an NE which sends a PD request message
PD Responder: PD Responder is an NE which receives the PD request
message and sends the PD response message
Jeong, et al. Expires April 19, 2004 [Page 3]
Internet-Draft Mobility Functions in the NTLP October 2003
QoS-NSLP: An NSLP for QoS Signaling
Jeong, et al. Expires April 19, 2004 [Page 4]
Internet-Draft Mobility Functions in the NTLP October 2003
2. Interaction with NSLPs
In general, incoming NSIS messages will first be captured and
processed by the NTLP. Any NSIS messages related to the associated
NSLP will be passed to the NSLP by the NTLP. Upon reception of any
notification or trigger from the NTLP, the NSLP needs to decide its
next behavior on its own. For example, the QoS-NSLP may need to
update QoS-NSLP state information or initiate necessary actions in
response to the trigger. The creation, update, or removal of NTLP
states may also trigger the associated NSLP to create, update, or
release related NSLP states.
To trigger an NSLP, the NTLP first needs to detect any triggering
events. For example, the NTLP may generate a trigger after detecting
that a route change (e.g., due to mobility) has occurred. The NSLP is
responsible for initiating necessary actions in response to such
triggers.
NTLP/NSLP states established on the old paths should be removed
immediately after re-establishing the states on the new path because
the old states should not be maintained any longer (e.g., due to a
route change caused by mobility). To do this, the NSLP of a proper NE
can request the NTLP to send a teardown message to the NEs on the old
path. In this case, NTLP should know where to send the teardown
message on the obsolete path.
Jeong, et al. Expires April 19, 2004 [Page 5]
Internet-Draft Mobility Functions in the NTLP October 2003
3. Detection of Route Change Caused by Mobility
Route changes (or rerouting) should be detected by the NTLP for
necessary state creation, update, or removal. Route changes can be
detected when the NTLP finds out that the route taken by a flow has
changed. To provide fast adaptation to route changes for particular
destinations, the NTLP may be in interaction with routing protocols.
The route change detected by the NTLP will then be delivered as a
trigger to the NSLP of NEs involved with the sessions which are
impacted by the route change. When the NSLP receives a trigger from
the NTLP, it sends necessary NSLP messages on the new route via the
NTLP.
A route change may occur due to a mobility event that can be
characterized by the change of the IP address (e.g., care-of-address
(CoA)) of one of the end nodes (e.g., an MN) due to a handover.
Although the route change caused by the mobility event may be
considered similar to the normal route change, the main difference
from the normal route change is the fact that the flow identifier
should be updated at the NEs involved with the session along the
end-to-end signaling path. To do this, the crossover node, the
merging point of the old and new signaling paths, needs to decide to
forward a state update message further towards the destination (e.g.,
CN).
The crossover node should also remove the states on the old path. The
detailed description of the crossover node discovery can be found in
Section 4.
Jeong, et al. Expires April 19, 2004 [Page 6]
Internet-Draft Mobility Functions in the NTLP October 2003
4. Crossover Node Discovery
When a route change caused by handover occurs, to improve scalability
and reduce signaling overhead, the NTLP signaling for the peer
discovery and service re-establishment should be localized. To
achieve this, when a handover occurs, the crossover node should be
discovered by the NTLP and accordingly the NSLP (e.g., QoS-NSLP)
should be triggered for necessary actions (e.g., QoS state
re-establishement and teardown of old reservation states). For this
purpose, the MOBILITY object, session identifier, flow identifier,
and incoming interface number can be used for this purpose.
The MOBILITY object which is set by the NSLP (e.g., QoS-NSLP) of an
MN or AR acts as an explicit indicator of any mobility event. The
session identifier is common for the NTLP and NSLP, and it is
independent from the IP address of a node (e.g., MN) and globally
unique. Therefore, it can be used to identify the session easily,
even after a change of the CoA due to an MN's handover to another AR.
For the duration of a data flow, the session identifier has to remain
the same while the flow identifier information associated with the
same data flow may change.
The flow identifier is used to specify the relation of the addressing
(e.g., IP address and port) to the state establishment (e.g., state
establishment of the QoS-NSLP). In general, flow identifier contains
information that identifies a particular data flow for which the
specific service is requested from the network. For example, a flow
identifier may consist of a combination of source IP address,
destination IP address and flow label in IPv6-based networks.
The incoming interface number may be useful for the crossover node
determination together with the unique session identifier if the
crossover node is the NSIS-aware merging point of the old and new
paths. If the merging point is not NSIS-aware and can't act as a
crossover node, the nearest (from the merging point) NSIS-aware node
along the joined path can act as a crossover node for the session. In
this case, the incoming interface number may not be useful for
crossover node determination when the NSIS node is no longer a
merging point of the old and new paths. Therefore, other identifiers
(e.g., flow identifier, MOBILITY Object, and so on) are needed to
detect the crossover node on the joint path.
When a route change caused by mobility occurs, the crossover node can
be recognized by comparing the existing session identifier with the
session identifier of the flow received from an incoming interface.
If the session identifier is still the same and the flow identifier
or interface number has been changed, the current NSIS-aware node is
recognized as a crossover node. The MOBILITY object (e.g., if it
Jeong, et al. Expires April 19, 2004 [Page 7]
Internet-Draft Mobility Functions in the NTLP October 2003
contains handover information) can also be used to ensure that the MN
has moved to a new AR and a route change has occurred due to
mobility.
The crossover node discovery can also be initiated during handover
(i.e., before the handover is completed), for instance, for fast
QoS-NSLP re-establishment or pre-establishment. However, in this
case, an efficient mechanism is needed to find a candidate crossover
node. For example, after a mobility event is detected by the NTLP,
the current AR may use a candidate access router discovery (e.g.,
CARD [10]) protocol to transfer the context for QoS-NSLP
re-establishment immediately. After candidate ARs are found, a
context transfer mechanism (e.g., CT [9]) can be used to transfer the
context including the QoS-NSLP session information to quickly
re-establish QoS-NSLP states. If an appropriate AR is found and the
context transfer is completed, 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.
Jeong, et al. Expires April 19, 2004 [Page 8]
Internet-Draft Mobility Functions in the NTLP October 2003
5. Dead Peer Discovery (DPD)
Before the delivery of any NTLP messages, the NE (e.g., NI, NF, or
NR) first needs to launch the peer discovery (PD) mechanism which
sends a PD request message (e.g., Scout message in CASP [4]) to its
neighboring nodes along the signaling path to detect its NSIS peer.
The transmission of PD messages by the NTLP may be separated from the
transmission of regular signaling messages since PD messages may be
difficult to protect. It is also possible to combine both types of
messages for efficiency in message delivery. For example, the
detection of an NSIS peer and establishment of a QoS-NSLP state can
be performed by sending an NSIS message.
The NE which sends a PD request message is called PD requestor, and
the NE which receives the PD request message and sends an
acknowledgement (ACK) message is called PD responder. Upon receiving
a PD request message, the PD responder sends an ACK. The ACK message
includes a cookie for security purposes. The PD requestor needs to
check the cookie to make sure security protection. In this way, NSIS
peers can be found securely and easily.
Note that NEs may not always transmit signaling messages successfully
to its NSIS peer along the signaling path. For example, signaling
messages may not be delivered to its peer when an NF (or NR) is
temporarily or permanently disconnected from the network due to the
failure of communication links (or processors), system rebooting,
node congestion, or mobile node handovers, causing the change of
signaling path in the network.
Therefore, dead peers which are no longer reachable should be
detected. To do this, the PD requestor periodically transmits a
ferret message (i.e., a PD request message) to its neighboring peers.
The PD requestor must receive an ACK message from its peer (i.e., the
PD responder) within a certain amount of time to determine if its
peer is still alive.
If the PD requestor does not receive any ACK message from the PD
responder within a certain amount of time, the PD requestor
retransmits the same PD message to the PD responder one more time. If
the PD requestor does not still receive any ACK message from the PD
responder, the PD requestor will consider the PD responder as a dead
peer. In this case, the PD requestor will send a new PD message to
find its new peer. This rediscovery process is actually the same as
the PD mechanism described above. If the peer node failure (due to a
link or node processor failure) causes any route change, the NTLP may
need to interact with a routing protocol to determine where to send
the new PD message.
Jeong, et al. Expires April 19, 2004 [Page 9]
Internet-Draft Mobility Functions in the NTLP October 2003
If a mobile node acts as an NI or NR, a route change in the network
may occur (e.g., due to handover). In this case, the old AR will find
that its peer is not alive since it will not receive any ACK from the
MN in response to periodical transmission of PD request messages.
However, in this case, the old AR should not generate any error
message to avoid teardown of existing states before the crossover
node initiates teardown message.
It is important to verify the correctness of PD messages for security
purposes. For example, an efficient mechanism should be used to
determine if the PD message has been received from the authorized
peer. If the PD request message is found to be valid, the PD
responder sends an ACK message immediately. Upon receiving the ACK
message from the PD responder, the PD requestor needs to inspect the
cookie of the received ACK message from the PD responder for security
protection.
Jeong, et al. Expires April 19, 2004 [Page 10]
Internet-Draft Mobility Functions in the NTLP October 2003
6. Interworking with Mobility Protocols
The NSIS protocol needs to efficiently handle the path change due to
mobility in order to support existing fast and seamless mobility
mechanisms although the NSIS protocol is not to be coupled tightly
with mobility protocols (e.g., FMIPv6, HMIPv6, or MIPv6). To do this,
the movement of an MN should be detected first by the NTLP of an MN
or AR. For example, the NTLP of an MN can detect movement by
monitoring layer 2 connections, and the NTLP of an AR can also detect
movement by receiving the 'handover initiation' message (e.g.,
'RtSolPr' message in Fast Handover for MIPv6). The NSLP is then
triggered by the NTLP to act appropriately. For example, the QoS-NSLP
may set the MOBILITY object of an outgoing QoS-NSLP message for fast
QoS state re-establishment [21].
After receiving the information on the mobility event, the NTLP of
the AR may trigger the candidate access router discovery (CARD) to
find an appropriate access router (an NSIS-aware node) before the
handover is completed. The NSLP may need to be interaction with the
context transfer (CT) protocol to transfer the NSLP state information
to the newly discovered access router.
After handover, the NTLP of a new AR may detect handover completion,
which can be used to minimize the service re-establishment delay and
the data packet loss. For instance, when an MN begins to transmit
Binding Update (BU) message to its CN (or MAP in case of HMIPv6), the
NTLP initiates peer discovery and sends NSLP messages at the same
time to create a new state on the new signaling path for the same
signaling application.
Jeong, et al. Expires April 19, 2004 [Page 11]
Internet-Draft Mobility Functions in the NTLP October 2003
7. Security Considerations
The NTLP relies on the security mechanisms described in [4]. Securing
the NTLP 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 NTLP 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.
Jeong, et al. Expires April 19, 2004 [Page 12]
Internet-Draft Mobility Functions in the NTLP October 2003
8. Conclusions
This document identified what kind of mobility functions should be
supported in the NTLP according to the mobility requirements for
future signaling protocols. Possible mobility functions for the NTLP
include interaction with NSLPs, detection of route change caused by
mobility, crossover node discovery, dead peer discovery, interworking
with mobility protocols, and so on. There are still some issues to be
addressed, including last NSIS node detection, crossover node
discovery in receiver- and sender-initiated modes, IP-in-IP
encapsulation, etc.
Jeong, et al. Expires April 19, 2004 [Page 13]
Internet-Draft Mobility Functions in the NTLP 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.
Jeong, et al. Expires April 19, 2004 [Page 14]
Internet-Draft Mobility Functions in the NTLP 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] Lee, S., "Mobility Functions in the QoS-NTLP",
draft-jeong-nsis-mobility-ntlp-00 (work in progress), October
2003.
Authors' Addresses
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
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
Jeong, et al. Expires April 19, 2004 [Page 15]
Internet-Draft Mobility Functions in the NTLP October 2003
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 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
Jin Pyo Hong
Hankuk University of FS
89 Wangsan Mohyun
Yongin-si, Gyeonggi-do 449-791
KOREA
Phone: +82 31 330 4116
EMail: jphong@hufs.ac.kr
Jeong, et al. Expires April 19, 2004 [Page 16]
Internet-Draft Mobility Functions in the NTLP 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
Jeong, et al. Expires April 19, 2004 [Page 17]
Internet-Draft Mobility Functions in the NTLP 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.
Jeong, et al. Expires April 19, 2004 [Page 18]| PAFTECH AB 2003-2026 | 2026-04-23 06:11:16 |