idnits 2.17.00 (12 Aug 2021) /tmp/idnits23013/draft-jeong-nsis-mobility-ntlp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 15) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 372 has weird spacing: '...ovement with ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 27, 2003) is 6781 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 424, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 436, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 440, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 443, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 446, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 457, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 460, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 467, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 474, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 478, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 482, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 500, but no explicit reference was found in the text == Outdated reference: draft-ietf-nsis-req has been published as RFC 3726 ** Downref: Normative reference to an Informational draft: draft-ietf-nsis-req (ref. '1') == Outdated reference: draft-ietf-nsis-fw has been published as RFC 4080 ** Downref: Normative reference to an Informational draft: draft-ietf-nsis-fw (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 3583 (ref. '3') -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: draft-ietf-nsis-qos-nslp has been published as RFC 5974 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-qos-nslp (ref. '7') -- Possible downref: Normative reference to a draft: ref. '8' == Outdated reference: draft-ietf-seamoby-ctp has been published as RFC 4067 ** Downref: Normative reference to an Experimental draft: draft-ietf-seamoby-ctp (ref. '9') == Outdated reference: draft-ietf-seamoby-card-protocol has been published as RFC 4066 ** Downref: Normative reference to an Experimental draft: draft-ietf-seamoby-card-protocol (ref. '10') == Outdated reference: draft-ietf-nsis-threats has been published as RFC 4081 ** Downref: Normative reference to an Informational draft: draft-ietf-nsis-threats (ref. '11') -- Possible downref: Normative reference to a draft: ref. '12' -- Possible downref: Normative reference to a draft: ref. '13' -- No information found for draft-ietf-mobileip-fast-mipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '14' -- Possible downref: Normative reference to a draft: ref. '15' -- Possible downref: Normative reference to a draft: ref. '18' ** Downref: Normative reference to an Informational RFC: RFC 3521 (ref. '19') -- Possible downref: Normative reference to a draft: ref. '21' -- Possible downref: Normative reference to a draft: ref. '22' == Outdated reference: draft-ietf-nsis-ntlp has been published as RFC 5971 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. '23') == Outdated reference: A later version (-01) exists of draft-jeong-nsis-mobility-ntlp-00 -- Possible downref: Normative reference to a draft: ref. '24' Summary: 12 errors (**), 0 flaws (~~), 24 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Next Steps in Signaling S. Jeong 3 Working Group HUFS 4 Internet-Draft S. Lee 5 Expires: April 26, 2004 J. Bang 6 BJ Lee 7 SAMSUNG AIT 8 October 27, 2003 10 Mobility Functions in the NTLP 11 draft-jeong-nsis-mobility-ntlp-01.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 26, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 The lower general layer in the NSIS protocol suite, called the NSIS 42 Transport Layer Protocol (NTLP), is intended to provide a general 43 transport service for signaling messages. One of the items on the 44 list of desired features for the NTLP is mobility support. This 45 document identifies possible mobility functions in the NTLP according 46 to the mobility requirements for future signaling protocols. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Interactions with the NSLP . . . . . . . . . . . . . . . . . . 5 53 3. Detection of Route Change Caused by Mobility . . . . . . . . . 6 54 4. Crossover Node (CRN) Discovery . . . . . . . . . . . . . . . . 7 55 5. Dead Peer Discovery (DPD) . . . . . . . . . . . . . . . . . . 9 56 6. Interworking with Mobility Protocols . . . . . . . . . . . . . 11 57 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 58 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 59 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 61 Intellectual Property and Copyright Statements . . . . . . . . 17 63 1. Introduction 65 The lower general layer in the NSIS signaling protocol suite, called 66 the NSIS Transport Layer Protocol (NTLP), is intended to provide a 67 general transport service for signaling messages. The actual 68 signaling messages are generated within upper layer signaling 69 applications, each having its own NSIS Signaling Layer Protocol 70 (NSLP) [2]. The main functionality of the NTLP is to discover 71 appropriate NSIS nodes and to deliver the signaling messages to them. 73 Mobility support is considered as one of the desired features of the 74 NTLP [3, 13, 15, 21, 22]. This document attempts to identify 75 mobility functions that may need to be supported in the NTLP. In this 76 document, the mobility functions in the NTLP refer to the functions 77 which are used to support mobility in NSIS signaling. The possible 78 mobility (-related) functions in the NTLP include interactions with 79 the NSLP, detection of route change caused by mobility, crossover 80 node discovery, dead peer discovery (e.g., dead crossover node 81 discovery), interworking with mobility protocols, and so on. This 82 document mainly discusses possible issues related to each of the 83 mobility functions in the NTLP. 85 1.1 Terminology 87 AR: Access Router 89 CARD: Candidate Access Router Discovery 91 CN: Correspondent Node 93 CoA: Care of Address 95 CRN: Crossover Node 97 CT: Context Transfer 99 DPD: Dead Peer Discovery 101 MN: Mobile Node 103 NE: NSIS Entity 105 NF: NSIS Forwarder 107 NI: NSIS Initiator 108 NSLP: NSIS Signaling Layer Protocol 110 NTLP: NSIS Transport Layer Protocol 112 PD: Peer Discovery 114 PD Requestor: an NE which sends a PD request message 116 PD Responder: an NE which receives the PD request message and sends 117 the PD response message 119 QoS-NSLP: NSLP for QoS Signaling 121 2. Interactions with the NSLP 123 In this section, we identify possbile interactions between the NTLP 124 and the NSLP, which can also be applied in mobile scenarios. An 125 incoming NSIS signaling message will first be captured and processed 126 by the NTLP. Any NSIS message related to the associated NSLP (e.g., 127 QoS-NSLP) will be passed to the NSLP via an API from the NTLP. 128 Upon reception of any notification or trigger from the NTLP, the NSLP 129 needs to decide its next behavior on its own. For example, the 130 QoS-NSLP may need to update QoS-NSLP state information or initiate 131 necessary actions such as removal of old QoS reservation states. The 132 change of NTLP states may also trigger the associated NSLP to create, 133 update, or release related NSLP states. 135 To trigger the NSLP, the NTLP first needs to detect any triggering 136 events. For example, the NTLP may be able to generate a trigger after 137 detecting that a route change due to mobility has occurred. In this 138 case, the triggering message may need to include information about 139 sessions that are impacted by the route change. The NSLP is then 140 responsible for deciding necessary actions for the impacted sessions. 141 The NSLP will also trigger the NTLP via an API to deliver necessary 142 signaling messages to the next NSIS peer node. 144 When a mobility event such as a handover (e.g., fast handover in 145 Mobile IPv6) is initiated, the NTLP/NSLP should operate to 146 re-establish the states along the new path as quickly as possible. 147 For this purpose, the interactions with seamoby protocols may be 148 necessary (see Section 5 for further details). It may not be possible 149 to re-establish states (e.g., since the necessary resources are not 150 available on the new path). In this case, it may be desired that the 151 NTLP/NSLP needs to get service availability (e.g., QoS resource 152 availability) in advance or before the handover is completed. 154 The NTLP/NSLP states established on the old path should be removed 155 immediately after re-establishing the states along the new path 156 because the old states should not be maintained any longer. To do 157 this, the NSLP of an appropriate NSIS entity (NE) (e.g., crossover 158 node) may ask the associated NTLP to deliver a teardown message to 159 the NEs on the old path. In this case, the NTLP should know where to 160 send the teardown message on the obsolete path. 162 3. Detection of Route Change Caused by Mobility 164 In mobile scenarios, a route change (rerouting) may occur due to a 165 mobility event that can be characterized by the change of the IP 166 address (e.g., care-of-address (CoA)) of one of the end points (e.g., 167 an MN) due to a handover. Link or node failure (or management-related 168 operations) may also cause a route change. However, this document 169 considers only route changes due to mobility-related events such as 170 an MN's handover. 172 A route change caused by mobility should be detected by the NTLP for 173 necessary state creation, update, or removal. A route change can be 174 detected when the NTLP of an NE finds out that the route taken by a 175 flow has changed (e.g., by checking the incoming interface). To 176 provide fast adaptation to route changes for particular destinations, 177 the NTLP may be in interaction with routing protocols. 179 The route change event detected by the NTLP will then be used to 180 trigger the NSLP associated with the sessions which are impacted by 181 the route change. When the NSLP receives a trigger from the NTLP, it 182 sends necessary NSLP messages along the new route with the help of 183 the NTLP. 185 Although the route change caused by a mobility event may be 186 considered similar to the normal route change, the main difference 187 from the normal route change is the fact that the flow identifier 188 should be updated at the NEs involved with the session along the 189 end-to-end signaling path. To do this, the crossover node (CRN), the 190 merging point of the old and new signaling paths, should be 191 discovered first, and the NTLP of the CRN needs to forward a state 192 update message further towards the other end point (e.g., CN). The 193 NTLP of the CRN should also send a state installation message on the 194 new path and a state teardown message on the obsolete path. The 195 detailed discussion about the crossover node discovery can be found 196 in the following section. 198 4. Crossover Node (CRN) Discovery 200 In this section, we discuss how to find the CRN in general and the 201 role of the CRN (especially in QoS re-establishment). We also discuss 202 possible use of seamoby protocols such as CT or CARD for the CRN 203 discovery during handover. 205 When a route change due to a handover occurs, the NTLP signaling for 206 the NSIS peer discovery and service (e.g., QoS) re-establishment 207 should be localized to improve scalability and reduce signaling 208 overhead. To achieve this, the CRN should be discovered quickly by 209 the NTLP, and the NSLP (e.g., QoS-NSLP) should be triggered by the 210 NTLP for necessary actions (such as QoS re-establishment on the new 211 path and teardown of old reservation states on the obsolete path). 212 For the CRN discovery, some information including the MOBILITY 213 object, the session identifier, the flow identifier, and the incoming 214 interface can be used. 216 The MOBILITY object may be defined in the NTLP message (e.g., GIMPS 217 payload) to notify any mobility event explicitly. The MOBILITY object 218 may contain various mobility-related fields such as the handover_init 219 field and the mobility_event_counter field. The handover_init field 220 can be used to explicitly notify that a handover is initiated for 221 fast state re-establishment. The mobility_event_counter field can be 222 used to detect the latest hanover event to avoid confusion about 223 where to send a confirmation message which indicates that the CRN has 224 been found. This type of confirmation may be needed when the MN moves 225 toward the second new AR immediately after it experiences a handover 226 to the first new AR from the old AR, because the CRN discovery 227 message from the second new AR may arrive earlier that that of the 228 first new AR. The MOBILITY object may also be defined in the NSLP in 229 a similar way. In this case, there should be some relationship 230 between the MOBILITY objects of the NTLP and the NSLP. 232 The session identifier can be very useful for the crossover node 233 discovery. It should be globally unique and independent from the IP 234 address of an end node (e.g., MN) to identify the involved session 235 easily even after a change of the CoA due to a handover to a new AR. 236 It is important that for the duration of a data flow, the session 237 identifier has to remain the same while the flow identifier (see 238 below) information associated with the same data flow may change. 240 The flow identifier is normally used to identify a particular data 241 flow for which the specific service (e.g., QoS) is requested from the 242 network. For example, a flow identifier may consist of a combination 243 of source IP address, destination IP address, and flow label in 244 IPv6-based networks. This flow identifier may also be used to specify 245 the relationship between the address information and the state 246 re-establishment (e.g., QoS-NSLP state re-establishment). 248 Additionally, the incoming interface may also be used for the CRN 249 discovery together with the unique session identifier if the CRN is 250 the NSIS-aware merging point of the old and new paths. If the merging 251 point is not NSIS-aware and can't act as a CRN, the nearest (from the 252 merging point) NSIS-aware node along the joined/common/unchanged path 253 can act as a CRN for the involved session. In this case, the incoming 254 interface may not be useful for the CRN discovery because the 255 NSIS-aware node is no longer a merging point of the old and new 256 paths. Therefore, in this case, other identifiers (e.g., flow 257 identifier, MOBILITY Object, and so on) may also be needed to 258 discover the crossover node on the joined/common/unchanged path. 260 When a route change caused by mobility occurs, the CRN can be 261 recognized by comparing the existing session identifier with the 262 session identifier of the flow received from an incoming interface. 263 If the session identifier is still the same and the flow identifier 264 or interface number has been changed, the current NSIS-aware node is 265 recognized as a CRN. As mentioned above, the MOBILITY object can also 266 be used to indicate that the MN has experienced a handover and a 267 route has occurred. 269 The CRN discovery may also be initiated during handover (i.e., before 270 the handover is completed), for instance, for fast QoS-NSLP 271 re-establishment or pre-establishment. However, in this case, an 272 efficient mechanism is needed to find a candidate CRN. For example, 273 after a mobility event is detected by the NTLP, the current AR may 274 use a candidate access router discovery (e.g., CARD [10]) protocol to 275 transfer the context for QoS-NSLP re-establishment immediately. After 276 candidate ARs are found, a context transfer mechanism (e.g., CT [9]) 277 can be used to transfer the context including the QoS-NSLP session 278 information to re-establish QoS-NSLP states quickly. If an 279 appropriate AR is found and the context transfer is completed, a 280 candidate CRN can be discovered easily since the candidate CRN 281 discovery is basically the same as above. 283 In some cases, however, it may not be possible to use 284 mobility-related protocols such as CT and CARD. In this case, the MN 285 can initiate the CRN discovery only after it changes the point of 286 attachment. To expedite the discovery process, it may be useful to 287 transmit the peer discovery message (by the NTLP) and the first 288 binding update message at the same time. 290 5. Dead Peer Discovery (DPD) 292 It may be possible that the CRN may be found dead before 293 re-establishing states on the new path or removing the old states on 294 the obsolete path. It is also possible that the old AR cannot 295 communicate with the MN (the peer node of the OAR) any longer after a 296 handover is initiated. Therefore, an efficient mechanism (which 297 should be used by the NTLP) is needed to find dead peers immediately 298 to minimize service interruption. This section first discusses a 299 possible way of finding live NSIS peers and then how to discover dead 300 NSIS peers. 302 Before the delivery of any NTLP messages, the NE (e.g., NI, NF, or 303 NR) first needs to launch the peer discovery (PD) mechanism which 304 sends a PD request message (e.g., Scout message in CASP [4]) to its 305 neighboring nodes along the signaling path to detect its NSIS peer. 306 The transmission of PD messages by the NTLP may be separated from the 307 transmission of regular signaling messages since PD messages may be 308 difficult to protect. It is also possible to combine both types of 309 messages for efficiency in message delivery. For example, the 310 detection of an NSIS peer and establishment of a QoS-NSLP state can 311 be performed by sending an NSIS message. 313 An NE which sends a PD request message is called a PD requestor, and 314 an NE which receives the PD request message and sends an 315 acknowledgement (ACK) message is called a PD responder. Upon 316 receiving a PD request message, the PD responder sends an ACK. The 317 ACK message includes a cookie for security protection. The PD 318 requestor needs to check the cookie to make sure security protection. 319 In this way, NSIS peers can be found securely and easily. 321 Note that NEs may not always transmit signaling messages successfully 322 to its NSIS peer along the signaling path. For example, signaling 323 messages may not be delivered to its peer when an NF (or NR) is 324 temporarily or permanently disconnected from the network due to the 325 failure of communication links (or processors), system rebooting, 326 node congestion, or a mobile node's handover, causing the change of 327 signaling path in the network. Therefore, dead peers which are no 328 longer reachable should be detected. To do this, the PD requestor 329 periodically transmits a ferret message (i.e., a PD request message) 330 to its neighboring peers. The PD requestor must receive an ACK 331 message from its peer (i.e., the PD responder) within a certain 332 amount of time to determine if its peer is still alive. 334 If the PD requestor does not receive any ACK message from the PD 335 responder within a certain amount of time (i.e., the PD timer 336 expires), the PD requestor retransmits the same PD message to the PD 337 responder one more time. If the PD requestor does not still receive 338 any ACK message from the PD responder, the PD requestor will consider 339 the PD responder as a dead peer. In this case, the PD requestor will 340 send a new PD message to find its new peer. This rediscovery process 341 is actually the same as the PD mechanism described above. If the peer 342 node failure (due to a link or node processor failure) causes any 343 route change, the NTLP may need to interact with a routing protocol 344 to determine where to send the new PD message. 346 If an MN acts as an NI or NR, a route change in the network may occur 347 (e.g., due to handover). In this case, the old AR will find that its 348 peer (i.e., MN) is not alive any longer since it will not receive any 349 ACK from the MN in response to the periodic transmission of PD 350 request messages. However, in this case, the NTLP of the old AR 351 should not generate any error message to avoid teardown of existing 352 states before the CRN initiates a teardown message on the obsolete 353 path. The old AR can be considered as the actual last node on the old 354 path after the MN changes the point of attachment. 356 It is important to verify the correctness of PD messages for security 357 purposes. For example, an efficient mechanism may need to be used in 358 order to determine if the PD message has been received from the 359 authorized peer. If the PD request message is found to be valid, the 360 PD responder sends an ACK message immediately. Upon receiving the ACK 361 message from the PD responder, the PD requestor may need to inspect 362 the cookie of the received ACK message from the PD responder for 363 security protection. 365 6. Interworking with Mobility Protocols 367 The NSIS protocol needs to efficiently handle the path change due to 368 mobility in order to support existing fast and seamless mobility 369 mechanisms although the NSIS protocol is not to be coupled tightly 370 with mobility protocols (e.g., FMIPv6, HMIPv6, or MIPv6). To do this, 371 the movement of an MN should be detected first by the NTLP of an MN 372 or AR. For example, the NTLP of an MN can detect movement with the 373 help of monitoring layer 2 connections, and the NTLP of an AR can 374 also detect movement by receiving a handover initiation message 375 (e.g., 'RtSolPr' message in Fast Handover for MIPv6). The NSLP is 376 then triggered by the NTLP to act appropriately. For example, the 377 QoS-NSLP may appropriately set the MOBILITY object of an outgoing 378 QoS-NSLP message for fast QoS state re-establishment [24]. 380 After receiving the information on the mobility event, the NTLP of 381 the AR may interact with a candidate access router discovery protocol 382 (e.g., CARD) to find an appropriate AR (an NSIS-aware node) before 383 the handover is completed. After the appropriate AR is discovered, 384 the NTLP may trigger the NSLP, and the NSLP may need to interact with 385 the context transfer (CT) protocol to transfer the NSLP state 386 information to the newly discovered AR. 388 After handover, the NTLP of a new AR may detect handover completion, 389 which can be used to minimize the service re-establishment delay and 390 the data packet loss. For instance, when an MN begins to transmit 391 first Binding Update (BU) message to its CN (or MAP in case of 392 HMIPv6), the NTLP may initiate peer discovery and send NSLP messages 393 at the same time to create a new state on the new signaling path for 394 the same signaling application. 396 7. Security Considerations 398 The NTLP may rely on the security mechanisms described in [4]. 399 Securing the NTLP can be provided by CMS which allows resource 400 objects and related objects defined in this document to be 401 encapsulated and protected by CMS. Therefore, no separate 402 specification within the NTLP may be necessary to describe the format 403 of these objects. This allows some flexibility in including protected 404 objects to link the authorization step of different protocols and to 405 transport local information within domains. The functionality 406 described in [19] and [20] can be provided without substantial 407 protocol modification/extensions. 409 8. Summary 411 This document identified what kind of mobility functions should be 412 supported in the NTLP according to the mobility requirements for 413 future signaling protocols. Possible mobility functions for the NTLP 414 include interactions with the NSLP, detection of route change caused 415 by mobility, crossover node discovery, dead peer discovery, 416 interworking with mobility protocols, and so on. There are still some 417 issues to be addressed in further detail, including the last NSIS 418 node detection, crossover node discovery in receiver- and 419 sender-initiated modes, IP-in-IP encapsulation, interworking with 420 seamoby protocols, security and AAA, and etc. 422 References 424 [1] Brunner, M., "Requirements for Signaling Protocols", 425 draft-ietf-nsis-req-09 (work in progress), August 2003. 427 [2] Hancock, R., "Next Steps in Signaling: Framework", 428 draft-ietf-nsis-fw-04 (work in progress), September 2003. 430 [3] Chaskar, H., "Requirements of a Quality of Service (QoS) 431 Solution for Mobile IP", RFC 3583, September 2003. 433 [4] Schulzrinne, H., "CASP - Cross-Application Signaling Protocol", 434 draft-schulzrinne-nsis-casp-01 (work in progress), March 2003. 436 [5] Schulzrinne, H., "A Quality-of-Service Resource Allocation 437 Client for CASP", draft-schulzrinne-nsis-casp-qos-01 (work in 438 progress), March 2003. 440 [6] McDonald, A., "A Quality of Service NSLP for NSIS", 441 draft-mcdonald-nsis-qos-nslp-00 (work in progress), June 2003. 443 [7] Bosch, S., "NSLP for Quality-of-Service signaling", 444 draft-ietf-nsis-qos-nslp-00 (work in progress), September 2003. 446 [8] Schulzrinne, H., "GIMPS: General Internet Messaging Protocol 447 for Signaling", draft-schulzrinne-nsis-ntlp-00 (work in 448 progress), June 2003. 450 [9] Loughney, J., "Context Transfer Protocol", 451 draft-ietf-seamoby-ctp-04 (work in progress), October 2003. 453 [10] Liebsch, M., "Candidate Access Router Discovery", 454 draft-ietf-seamoby-card-protocol-04 (work in progress), 455 September 2003. 457 [11] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", 458 draft-ietf-nsis-threats-02 (work in progress), July 2003. 460 [12] Buchli, M., "A Network Service Layer Protocol for QoS 461 signaling", draft-buchli-nsis-nslp-00 (work in progress), June 462 2003. 464 [13] Fu, X., "Mobility Issues in Next Steps in Signaling (NSIS)", 465 draft-fu-nsis-mobility-01 (work in progress), October 2003. 467 [14] Koodli, R., "Fast Handovers for Mobile IPv6", 468 draft-ietf-mobileip-fast-mipv6-08 (work in progress), October 469 2003. 471 [15] Lee, S., "QoS Signaling for IP-based Radio Access Networks", 472 draft-lee-nsis-signaling-ran-00 (work in progress), June 2003. 474 [16] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin, 475 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 476 Specification", RFC 2205, September 1997. 478 [17] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S. 479 Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 480 2961, April 2001. 482 [18] Westberg, L., "A Proposal for RSVPv2", 483 draft-westberg-proposal-for-rsvpv2-01 (work in progress), 484 November 2002. 486 [19] Hamer, L-N., Gage, B. and H. Shieh, "Framework for Session 487 Set-up with Media Authorization", RFC 3521, April 2003. 489 [20] Hamer, L-N., Gage, B., Kosinski, B. and H. Shieh, "Session 490 Authorization Policy Element", RFC 3520, April 2003. 492 [21] Shen, C., "Several Framework Issues Regarding NSIS and 493 Mobility", draft-shen-nsis-mobility-fw-00 (work in progress), 494 July 2002. 496 [22] Chaskar, H. and C. Westphal, "QoS Signaling Framework for 497 Mobile IP", draft-westphal-nsis-qos-mobileip-00 (work in 498 progress), June 2002. 500 [23] Schulzrinne, H., "GIMPS: General Internet Messaging Protocol 501 for Signaling", draft-ietf-nsis-ntlp-00 (work in progress), 502 October 2003. 504 [24] Lee, S., "Mobility Functions in the QoS-NTLP", 505 draft-jeong-nsis-mobility-ntlp-00 (work in progress), October 506 2003. 508 Authors' Addresses 510 Seong-Ho Jeong 511 Hankuk University of FS 512 89 Wangsan Mohyun 513 Yongin-si, Gyeonggi-do 449-791 514 KOREA 516 Phone: +82 31 330 4642 517 EMail: shjeong@hufs.ac.kr 518 Sung-Hyuck Lee 519 SAMSUNG Advanced Institute of Technology 520 i-Networking Lab. 521 San 14-1, Nongseo-ri, Giheung-eup 522 Yongin-si, Gyeonggi-do 449-712 523 KOREA 525 Phone: +82 31 280 9585 526 EMail: starsu.lee@samsung.com 528 Jongho Bang 529 SAMSUNG Advanced Institute of Technology 530 i-Networking Lab. 531 San 14-1, Nongseo-ri, Giheung-eup 532 Yongin-si, Gyeonggi-do 449-712 533 KOREA 535 Phone: +82 31 280 9585 536 EMail: jh0278.bang@samsung.com 538 Byoung-Joon (BJ) Lee 539 SAMSUNG Advanced Institute of Technology 540 i-Networking Lab. 541 San 14-1, Nongseo-ri, Giheung-eup 542 Yongin-si, Gyeonggi-do 449-712 543 KOREA 545 Phone: +82 31 280 9626 546 EMail: bj33.lee@samsung.com 548 Intellectual Property Statement 550 The IETF takes no position regarding the validity or scope of any 551 intellectual property or other rights that might be claimed to 552 pertain to the implementation or use of the technology described in 553 this document or the extent to which any license under such rights 554 might or might not be available; neither does it represent that it 555 has made any effort to identify any such rights. Information on the 556 IETF's procedures with respect to rights in standards-track and 557 standards-related documentation can be found in BCP-11. Copies of 558 claims of rights made available for publication and any assurances of 559 licenses to be made available, or the result of an attempt made to 560 obtain a general license or permission for the use of such 561 proprietary rights by implementors or users of this specification can 562 be obtained from the IETF Secretariat. 564 The IETF invites any interested party to bring to its attention any 565 copyrights, patents or patent applications, or other proprietary 566 rights which may cover technology that may be required to practice 567 this standard. Please address the information to the IETF Executive 568 Director. 570 Full Copyright Statement 572 Copyright (C) The Internet Society (2003). All Rights Reserved. 574 This document and translations of it may be copied and furnished to 575 others, and derivative works that comment on or otherwise explain it 576 or assist in its implementation may be prepared, copied, published 577 and distributed, in whole or in part, without restriction of any 578 kind, provided that the above copyright notice and this paragraph are 579 included on all such copies and derivative works. However, this 580 document itself may not be modified in any way, such as by removing 581 the copyright notice or references to the Internet Society or other 582 Internet organizations, except as needed for the purpose of 583 developing Internet standards in which case the procedures for 584 copyrights defined in the Internet Standards process must be 585 followed, or as required to translate it into languages other than 586 English. 588 The limited permissions granted above are perpetual and will not be 589 revoked by the Internet Society or its successors or assignees. 591 This document and the information contained herein is provided on an 592 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 593 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 594 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 595 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 596 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 598 Acknowledgement 600 Funding for the RFC Editor function is currently provided by the 601 Internet Society.