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] IETF Next Steps in Signaling S. Jeong Working Group HUFS Internet-Draft S. Lee Expires: April 26, 2004 J. Bang BJ Lee SAMSUNG AIT October 27, 2003 Mobility Functions in the NTLP draft-jeong-nsis-mobility-ntlp-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 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 26, 2004 [Page 1] Internet-Draft Mobility Functions in the NTLP October 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Interactions with the NSLP . . . . . . . . . . . . . . . . . . 5 3. Detection of Route Change Caused by Mobility . . . . . . . . . 6 4. Crossover Node (CRN) Discovery . . . . . . . . . . . . . . . . 7 5. Dead Peer Discovery (DPD) . . . . . . . . . . . . . . . . . . 9 6. Interworking with Mobility Protocols . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 17 Jeong, et al. Expires April 26, 2004 [Page 2] Internet-Draft Mobility Functions in the NTLP October 2003 1. Introduction The lower general layer in the NSIS signaling protocol suite, called the NSIS Transport Layer Protocol (NTLP), is intended to provide a general transport service for signaling messages. The actual signaling messages are generated within upper layer signaling applications, each having its own NSIS Signaling Layer Protocol (NSLP) [2]. The main functionality of the NTLP is to discover appropriate NSIS nodes and to deliver the signaling messages to them. Mobility support is considered as one of the desired features of the NTLP [3, 13, 15, 21, 22]. This document attempts to identify mobility functions that may need to be supported in the NTLP. In this document, the mobility functions in the NTLP refer to the functions which are used to support mobility in NSIS signaling. The possible mobility (-related) functions in the NTLP include interactions with the NSLP, detection of route change caused by mobility, crossover node discovery, dead peer discovery (e.g., dead crossover node discovery), interworking with mobility protocols, and so on. This document mainly discusses possible issues related to each of the mobility functions in the NTLP. 1.1 Terminology AR: Access Router CARD: Candidate Access Router Discovery CN: Correspondent Node CoA: Care of Address CRN: Crossover Node CT: Context Transfer DPD: Dead Peer Discovery MN: Mobile Node NE: NSIS Entity NF: NSIS Forwarder NI: NSIS Initiator Jeong, et al. Expires April 26, 2004 [Page 3] Internet-Draft Mobility Functions in the NTLP October 2003 NSLP: NSIS Signaling Layer Protocol NTLP: NSIS Transport Layer Protocol PD: Peer Discovery PD Requestor: an NE which sends a PD request message PD Responder: an NE which receives the PD request message and sends the PD response message QoS-NSLP: NSLP for QoS Signaling Jeong, et al. Expires April 26, 2004 [Page 4] Internet-Draft Mobility Functions in the NTLP October 2003 2. Interactions with the NSLP In this section, we identify possbile interactions between the NTLP and the NSLP, which can also be applied in mobile scenarios. An incoming NSIS signaling message will first be captured and processed by the NTLP. Any NSIS message related to the associated NSLP (e.g., QoS-NSLP) will be passed to the NSLP via an API from 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 such as removal of old QoS reservation states. The change of NTLP states may also trigger the associated NSLP to create, update, or release related NSLP states. To trigger the NSLP, the NTLP first needs to detect any triggering events. For example, the NTLP may be able to generate a trigger after detecting that a route change due to mobility has occurred. In this case, the triggering message may need to include information about sessions that are impacted by the route change. The NSLP is then responsible for deciding necessary actions for the impacted sessions. The NSLP will also trigger the NTLP via an API to deliver necessary signaling messages to the next NSIS peer node. When a mobility event such as a handover (e.g., fast handover in Mobile IPv6) is initiated, the NTLP/NSLP should operate to re-establish the states along the new path as quickly as possible. For this purpose, the interactions with seamoby protocols may be necessary (see Section 5 for further details). It may not be possible to re-establish states (e.g., since the necessary resources are not available on the new path). In this case, it may be desired that the NTLP/NSLP needs to get service availability (e.g., QoS resource availability) in advance or before the handover is completed. The NTLP/NSLP states established on the old path should be removed immediately after re-establishing the states along the new path because the old states should not be maintained any longer. To do this, the NSLP of an appropriate NSIS entity (NE) (e.g., crossover node) may ask the associated NTLP to deliver a teardown message to the NEs on the old path. In this case, the NTLP should know where to send the teardown message on the obsolete path. Jeong, et al. Expires April 26, 2004 [Page 5] Internet-Draft Mobility Functions in the NTLP October 2003 3. Detection of Route Change Caused by Mobility In mobile scenarios, a route change (rerouting) 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 points (e.g., an MN) due to a handover. Link or node failure (or management-related operations) may also cause a route change. However, this document considers only route changes due to mobility-related events such as an MN's handover. A route change caused by mobility should be detected by the NTLP for necessary state creation, update, or removal. A route change can be detected when the NTLP of an NE finds out that the route taken by a flow has changed (e.g., by checking the incoming interface). To provide fast adaptation to route changes for particular destinations, the NTLP may be in interaction with routing protocols. The route change event detected by the NTLP will then be used to trigger the NSLP associated with the sessions which are impacted by the route change. When the NSLP receives a trigger from the NTLP, it sends necessary NSLP messages along the new route with the help of the NTLP. Although the route change caused by a 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 (CRN), the merging point of the old and new signaling paths, should be discovered first, and the NTLP of the CRN needs to forward a state update message further towards the other end point (e.g., CN). The NTLP of the CRN should also send a state installation message on the new path and a state teardown message on the obsolete path. The detailed discussion about the crossover node discovery can be found in the following section. Jeong, et al. Expires April 26, 2004 [Page 6] Internet-Draft Mobility Functions in the NTLP October 2003 4. Crossover Node (CRN) Discovery In this section, we discuss how to find the CRN in general and the role of the CRN (especially in QoS re-establishment). We also discuss possible use of seamoby protocols such as CT or CARD for the CRN discovery during handover. When a route change due to a handover occurs, the NTLP signaling for the NSIS peer discovery and service (e.g., QoS) re-establishment should be localized to improve scalability and reduce signaling overhead. To achieve this, the CRN should be discovered quickly by the NTLP, and the NSLP (e.g., QoS-NSLP) should be triggered by the NTLP for necessary actions (such as QoS re-establishment on the new path and teardown of old reservation states on the obsolete path). For the CRN discovery, some information including the MOBILITY object, the session identifier, the flow identifier, and the incoming interface can be used. The MOBILITY object may be defined in the NTLP message (e.g., GIMPS payload) to notify any mobility event explicitly. The MOBILITY object may contain various mobility-related fields such as the handover_init field and the mobility_event_counter field. The handover_init field can be used to explicitly notify that a handover is initiated for fast state re-establishment. The mobility_event_counter field can be used to detect the latest hanover event to avoid confusion about where to send a confirmation message which indicates that the CRN has been found. This type of confirmation may be needed when the MN moves toward the second new AR immediately after it experiences a handover to the first new AR from the old AR, because the CRN discovery message from the second new AR may arrive earlier that that of the first new AR. The MOBILITY object may also be defined in the NSLP in a similar way. In this case, there should be some relationship between the MOBILITY objects of the NTLP and the NSLP. The session identifier can be very useful for the crossover node discovery. It should be globally unique and independent from the IP address of an end node (e.g., MN) to identify the involved session easily even after a change of the CoA due to a handover to a new AR. It is important that for the duration of a data flow, the session identifier has to remain the same while the flow identifier (see below) information associated with the same data flow may change. The flow identifier is normally used to identify a particular data flow for which the specific service (e.g., QoS) 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. This flow identifier may also be used to specify the relationship between the address information and the state Jeong, et al. Expires April 26, 2004 [Page 7] Internet-Draft Mobility Functions in the NTLP October 2003 re-establishment (e.g., QoS-NSLP state re-establishment). Additionally, the incoming interface may also be used for the CRN discovery together with the unique session identifier if the CRN 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 CRN, the nearest (from the merging point) NSIS-aware node along the joined/common/unchanged path can act as a CRN for the involved session. In this case, the incoming interface may not be useful for the CRN discovery because the NSIS-aware node is no longer a merging point of the old and new paths. Therefore, in this case, other identifiers (e.g., flow identifier, MOBILITY Object, and so on) may also be needed to discover the crossover node on the joined/common/unchanged path. When a route change caused by mobility occurs, the CRN 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 CRN. As mentioned above, the MOBILITY object can also be used to indicate that the MN has experienced a handover and a route has occurred. The CRN discovery may 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 CRN. 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 re-establish QoS-NSLP states quickly. If an appropriate AR is found and the context transfer is completed, a candidate CRN can be discovered easily since the candidate CRN discovery is basically the same as above. 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 CRN discovery only after it changes the point of attachment. 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. Jeong, et al. Expires April 26, 2004 [Page 8] Internet-Draft Mobility Functions in the NTLP October 2003 5. Dead Peer Discovery (DPD) It may be possible that the CRN may be found dead before re-establishing states on the new path or removing the old states on the obsolete path. It is also possible that the old AR cannot communicate with the MN (the peer node of the OAR) any longer after a handover is initiated. Therefore, an efficient mechanism (which should be used by the NTLP) is needed to find dead peers immediately to minimize service interruption. This section first discusses a possible way of finding live NSIS peers and then how to discover dead NSIS peers. 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. An NE which sends a PD request message is called a PD requestor, and an NE which receives the PD request message and sends an acknowledgement (ACK) message is called a PD responder. Upon receiving a PD request message, the PD responder sends an ACK. The ACK message includes a cookie for security protection. 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 a mobile node's handover, 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 (i.e., the PD timer expires), the PD requestor retransmits the same PD message to the PD responder one more time. If the PD requestor does not still receive Jeong, et al. Expires April 26, 2004 [Page 9] Internet-Draft Mobility Functions in the NTLP October 2003 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. If an MN 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 (i.e., MN) is not alive any longer since it will not receive any ACK from the MN in response to the periodic transmission of PD request messages. However, in this case, the NTLP of the old AR should not generate any error message to avoid teardown of existing states before the CRN initiates a teardown message on the obsolete path. The old AR can be considered as the actual last node on the old path after the MN changes the point of attachment. It is important to verify the correctness of PD messages for security purposes. For example, an efficient mechanism may need to be used in order 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 may need to inspect the cookie of the received ACK message from the PD responder for security protection. Jeong, et al. Expires April 26, 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 with the help of monitoring layer 2 connections, and the NTLP of an AR can also detect movement by receiving a 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 appropriately set the MOBILITY object of an outgoing QoS-NSLP message for fast QoS state re-establishment [24]. After receiving the information on the mobility event, the NTLP of the AR may interact with a candidate access router discovery protocol (e.g., CARD) to find an appropriate AR (an NSIS-aware node) before the handover is completed. After the appropriate AR is discovered, the NTLP may trigger the NSLP, and the NSLP may need to interact with the context transfer (CT) protocol to transfer the NSLP state information to the newly discovered AR. 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 first Binding Update (BU) message to its CN (or MAP in case of HMIPv6), the NTLP may initiate peer discovery and send 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 26, 2004 [Page 11] Internet-Draft Mobility Functions in the NTLP October 2003 7. Security Considerations The NTLP may rely on the security mechanisms described in [4]. Securing the NTLP can be 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 may be 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 26, 2004 [Page 12] Internet-Draft Mobility Functions in the NTLP October 2003 8. Summary 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 interactions with the NSLP, 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 in further detail, including the last NSIS node detection, crossover node discovery in receiver- and sender-initiated modes, IP-in-IP encapsulation, interworking with seamoby protocols, security and AAA, and etc. Jeong, et al. Expires April 26, 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 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. Jeong, et al. Expires April 26, 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] 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] 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 Jeong, et al. Expires April 26, 2004 [Page 15] Internet-Draft Mobility Functions in the NTLP October 2003 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 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 Jeong, et al. Expires April 26, 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 26, 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 26, 2004 [Page 18]