Internet Engineering Task Force Charles Qi Shen draft-shen-nsis-rsvp-mobileipv6-00.txt Winston Seah July 12, 2002 Anthony Lo Expires: January 2003 ICR Haihong Zheng Marc Greis Nokia Mobility Extensions to RSVP in an RSVP-Mobile IPv6 Framework <draft-shen-nsis-rsvp-mobileipv6-00.txt> STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. 1 Abstract This memo first gives a brief review of a RSVP and Mobile IPv6 interoperation framework proposed in [1] and compared its features with the Performance Requirements set forth by Requirements of a QoS Solution for Mobile IP [2]. The subsequent part of the memo presents specification details including message formats, processing rules and algorithms that form the framework. The vast majority of these specifications has been verified by a prototype implementation. It is expected that this work could serve as a useful input in dealing with NSIS protocol and mobility issue. 2 Terminology MS - Mobile Sender A Mobile Node that is acting as a Flow Sender. MR - Mobile Receiver A Mobile Node that is acting as a Flow Receiver. Shen, Seah, Lo, Zheng and Greis [Page 1]
Internet Draft RSVP Mobile IPv6 Interop July 17, 2002 SNCR - Sender Nearest Common Router the first common router on the old path and new path after a handoff caused by MN functioning as a MS. RNCR - Receiver Nearest Common Router the first common router on the old path and new path after a handoff caused by MN functioning as a MR. NCR - Nearest Common Router could be either a SNCR or a RNCR. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 3 Introduction The increasing interest in supporting QoS sensitive applications in a mobile environment has led to extensive work on interoperation of QoS signaling and mobility mechanisms. Typically the issue is addressed in the context of RSVP and Mobile IP . This memo is a follow-up of our previous proposal on an Interoperation Framework for using RSVP in an Mobile IPv6 network[1]. In this memo, we first give a brief review of the framework and evaluate it against the Requirement of a QoS Solution for Mobile IP [2] that was formed after our framework proposal. Then we present the specification details concerning New Message/Object Formats, processing rules as well as (Nearest Common Router) NCR Decision Algorithms which have been developed extensively since the previous framework memo. It is known that the IETF Next Step In Signaling (NSIS) WG has been charted to look at a future resource signaling protocol and the NSIS framework is well likely to cover the interaction with general mobility mechanism as well. In view of the fact that, RSVP is recommended to be used as a starting point for NSIS, and Mobile IP is likely the pre-dominant mobility mechanism for IP macro-mobility, we expect this work to be a useful input to the area of NSIS and mobility interaction. In addition, we provide a separate discussion on several issues related to general NSIS and mobility interaction in [3]. The similar topic is also covered as part of a framework proposal by Handcock et. al. [4]. It is worth noting that, the vast majority of signaling logic and processing rules disclosed herein have been verified by a prototype implementation modified from the latest ISI RSVP release. 4 Framework and Requirements Review Shen, Seah, Lo, Zheng and Greis [Page 2]
Internet Draft RSVP Mobile IPv6 Interop July 17, 2002 The essential point of our framework[1] is to maintain a unique flow identifier regardless of node mobility. To achieve this specifically within the Mobile IP and RSVP context, we have chosen to use MN HAs in RSVP SESSION object and RSVP SENDER_TEMPLATE object. While the correct routing of signaling packets is ensured by using MN CoAs. A brief review of our RSVP-Mobile IPv6 framework is given below. We assume a generic scenario where both communication parties could be mobile. So we will use the terms Mobile Sender (MS) and Mobile Receiver (MR) instead of MN to reflect the situation more accurately, wherever necessary. The illustration of framework operation in each of the MR and MS case is divided into three signaling phases according to different functionalities, although they indeed overlap in terms of actual signaling timing. 4.1 Framework Review: Mobile Sender (MS) Case 4.1.1 Resource Establishment in the New Path When the MS obtains a new care-of address upon handoff, it immediately sends a PATH message containing its mobility information (which is its new CoA) towards the CN. This PATH message triggers the establishment of PATH state in the RSVP routers on the path until it reaches the Sender Nearest Common Router (SNCR). The SNCR finds the PATH message arriving with a previous hop address different from the one stored in the path state, upon which it immediately replies with a RESV message towards the MN using the new path. The reserved resources between the SNCR and the CN can be reused. 4.1.2 Resource Release in the Obsoleted Path In addition to the above, the SNCR sends a RESVTEAR message towards the previous hop stored in the old path state. The RESVTEAR message triggers the removal of the reserved resources on the old path which are no longer needed. 4.1.3 Refresh Handling in the Common Path The SNCR also forwards the received handoff PATH message to the next hop in any case so as to update the mobility information in all RSVP routers on the rest of the path. This is to ensure correct routing of subsequent refresh messages. 4.2 Framework Review: Mobile Receiver (MR) Case 4.2.1 Resource Establishment in the New Path When the MR obtained a new care-of address upon handoff, it is Shen, Seah, Lo, Zheng and Greis [Page 3]
Internet Draft RSVP Mobile IPv6 Interop July 17, 2002 required to inform the Receiver Nearest Common Router (RNCR) of its mobility information in order to trigger a quick handoff PATH message from the RNCR. This avoids waiting for a handoff PATH message from the CN, which requires at least a round trip time between MR and CN. This is achieved by the use of a new RSVP PATHREQ message. It may optionally be piggybacked in a PATH message sent by the MN when it acts as both MS and MR. In the following discussion, we assume the former method, or a separate PATHREQ message is used. The PATHREQ message which carries MR's mobility information (the new CoA) will be sent toward the CN and will be examined by each intermediate RSVP node until it reaches RNCR. The RNCR then triggers a Local Repair for the receiver route change that is, the router sends a handoff PATH message associated with the unique flow identifier, to the MN's new care-of address. This serves to establish resource state in the new path as soon as possible. 4.2.2 Resource Release in the Obsoleted Path In addition to the above, RNCR also sends a PATHTEAR message towards the MN's old care-of address. The PATHTEAR message triggers the removal of the resources on the old path which are no longer needed. 4.2.3 Refresh Handling in the Common Path RNCR also forwards the PATHREQ message to the next hop until it reaches the CN so as to update the mobility information in all the RSVP routers on the common path. This is to insure correct routing of subsequent refresh messages. 4.3 Requirements Review: Evaluate the Framework Against Requirements A quick examination of the Requirement of a QoS Solution for Mobile IP [2] shows that the above framework addressed all three performance requirements set forth, namely o Minimize the interruption in QoS at the time of handover. o Localize the QoS (re)establishment to the affected parts of the packet path in the network. o Releasing after handover the QoS state (if any) along the old packet path. The first and second requirements are addressed by the use of NCR in establishing resource state within new path incurred by handoff. The third requirement is met by explicitly issuing of corresponding state teardown messages at the NCRs. In the following sections we present specification details concerning New Message/Object Formats, NCR Shen, Seah, Lo, Zheng and Greis [Page 4]
Internet Draft RSVP Mobile IPv6 Interop July 17, 2002 Algorithms and Processing rules that form the above RSVP-Mobile IPv6 framework. 5 Formats of New RSVP Objects and Messages 5.1 Formats of SENDER_MOBILITY Object and RECEIVER_MOBILITY Object New MOBILITY objects are defined in order to convey MN's mobility information to RSVP. In the simplest case for Mobile IP, it contains the MN's current care-of address. By including these new objects, the RSVP process does not need to get the mobility information of the MN from the IP header of the RSVP messages, the clear interface between the IP layer and the RSVP process is maintained. 0 1 2 3 +-------------+-------------+-------------+-------------+ | Length (bytes) | Class-Num | C-Type | +-------------+-------------+-------------+-------------+ | | + + | | + Care-of Address + | | + + | | +-------------+-------------+-------------+-------------+ | Flags | (Reserved) | Sequence Number | +-------------+-------------+-------------+-------------+ Flags: 8 bits 0x01: NCR Identified When set, indicates that the NCR has been identified. Figure 1: MOBILITY Object In accordance with the simplex nature of RSVP, two types of MOBILITY objects are defined, namely, SENDER_MOBILITY objects and RECEIVER_MOBILITY objects. Figure 1 shows the format for the MOBILITY object. The length field indicates the total object length in bytes. Shen, Seah, Lo, Zheng and Greis [Page 5]
Internet Draft RSVP Mobile IPv6 Interop July 17, 2002 The Class Num and the C-Type for the MOBILITY object would have to be assigned by IANA. SENDER_MOBILITY objects and RECEIVER_MOBILITY objects shall have different Class Nums. The contents of the MOBILITY object contain: o Mobility information which is MS or MR's current care-of address. o An NCR Flag bit which indicates whether the appropriate NCR has been located. The bit carries an initial value of 0 and is set to 1 by the NCR. o A two-byte Sequence Number field which increases by one after each handoff and thus indicates how up-to-date the mobility information is. 5.2 Format of PATHREQ Message The new PATHREQ message is defined to allow the MR to request a PATH message from RNCR immediately after it performs a handoff. Figure 2 shows the format of a PATHREQ message, it contains: o An RSVP common header, in which the message type for PATHREQ message has to be assigned by IANA. o A SESSION object containing the MR's home address. o A SENDER_TEMPLATE object containing the MS's home address. o A RECEIVER_MOBILITY object containing the MR's current care-of address. o A SENDER_MOBILITY object containing the MS's current care-of address. Inclusion of the above four objects makes RSVP aware of the care-of address and home address of both MS and MR thus covers the most complicated case where both communication parties are MNs and acts as Sender and Receiver simultaneously. In case either party is stationary, the corresponding MOBILITY object will not be applicable and the home address above is replaced by the corresponding fixed address. 6 Nearest Common Router (NCR) Decision Algorithm The decision for NCRs is divided into two parts: SNCR and RNCR. Generally, decision for SNCR is triggered by receiving of PATH Shen, Seah, Lo, Zheng and Greis [Page 6]
Internet Draft RSVP Mobile IPv6 Interop July 17, 2002 +-------------+-------------+-------------+-------------+ | RSVP Common Header | +-------------+-------------+-------------+-------------+ | | + + | | + SESSION object + | | + + | | +-------------+-------------+-------------+-------------+ | | + + | | + SENDER_TEMPLATE object + | | + + | | +-------------+-------------+-------------+-------------+ | | + + | | + RECEIVER_MOBILITY object + | | + + | | +-------------+-------------+-------------+-------------+ | | + + | | + SENDER_MOBILITY object + | | + + | | +-------------+-------------+-------------+-------------+ Figure 2: PATHREQ Message messages; decision for RNCR is triggered by receiving of PATHREQ messages; RNCR and SNCR may be physically collocated in the same router, or could be in two different network entities. Shen, Seah, Lo, Zheng and Greis [Page 7]
Internet Draft RSVP Mobile IPv6 Interop July 17, 2002 6.1 Decision Algorithm for Sender NCR (SNCR) RSVP decides that it is the SNCR if all of the following conditions are met. o A PATH message which contains a SENDER_MOBILITY object is received. o The NCR Flag bit in the received SENDER_MOBILITY object is Zero. o There is a matching PSB found for the PATH message. o The matching PSB does not include a SENDER_MOBILITY object or the matching PSB contains a SENDER_MOBILITY object which has a sequence number lower than that of the received SENDER_MOBILITY object. 6.2 Decision Algorithm for Receiver NCR (RNCR) RSVP decides that it is the RNCR if all of the following conditions are met. o A PATHREQ message which contains a RECEIVER_MOBILITY object is received. o The NCR Flag bit in the received RECEIVER_MOBILITY object is Zero. o There is a matching PSB found for the SESSION object in the received PATHREQ message. o The matching PSB does not include a RECEIVER_MOBILITY object or the matching PSB contains a RECEIVER_MOBILITY object which has a sequence number lower than that of the received RECEIVER_MOBILITY object. 7 Processing Rules for PATHREQ Message and PATH Message with MOBILITY Object 7.1 Processing Rule for New PATHREQ Message The PATHREQ message is sent by a MR when it changes its care-of address. The general processing rules when RSVP receives a PATHREQ message are as follows: o RSVP searches for PSBs in the opposite direction whose SESSION object matches the corresponding object in the PATHREQ Shen, Seah, Lo, Zheng and Greis [Page 8]
Internet Draft RSVP Mobile IPv6 Interop July 17, 2002 message. o If there are no matching PSBs, the PATHREQ message is simply forwarded to the next RSVP node. The source address and destination address of the forwarded PATHREQ message are determined as follows: - The source address is retrieved from RECEIVER_MOBILITY object which contains the receiver's care-of address. - The destination address is retrieved from SENDER_MOBILITY object which contains the sender's care-of address, if it exists. Otherwise, the destination address is retrieved from SENDER_TEMPLATE object which contains the sender's fixed or home address. o Otherwise there are matching PSBs found. For each matching PSB, - If RECEIVER_MOBILITY information is found in the PSB and the sequence number of that RECEIVER_MOBILITY is higher than that of the received RECEIVER_MOBILITY object, discard the received PATHREQ message. - Otherwise, if RECEIVER_MOBILITY is not found in the PSB or RECEIVER_MOBILITY is found in the PSB but with a lower sequence number: - The PSB is updated with the new RECEIVER_MOBILITY object. - If SENDER_MOBILITY exists either or both in PSB or PATHREQ, compare their sequence number, update PSB with the newer SENDER_MOBILITY object if applicable. - Check the NCR Flag bit in the received RECEIVER_MOBILITY object: - If the NCR Flag bit is 1, and the RSVP node is not the sender, forward the PATHREQ message to the next RSVP node using the same source and destination address decision rules as stated above when there is no matching PSB. - If the Flag bit is 0, the RSVP node is identified as RNCR. It does the following: Sets the NCR Flag bit into 1; Constructs a handoff PATH message that includes the RECEIVER_MOBILITY object, and Shen, Seah, Lo, Zheng and Greis [Page 9]
Internet Draft RSVP Mobile IPv6 Interop July 17, 2002 sends it to the receiver's current care-of address obtained from the same RECEIVER_MOBILITY object; Constructs a PATHTEAR message containing the old RECEIVER_MOBILITY object, if exists, to the receiver's old care-of address; If the RSVP node is not sender of the flow, it further forwards the PATHREQ message to the next RSVP node using the same source and destination address construction rule as stated above when there is no matching PSB. 7.2 New Processing Rules for PATH Message To deal with node mobility, PATH messages shall carry MOBILITY objects. If the MS performs a handoff, a SENDER_MOBILITY object will be included in the PATH messages. If the MR performs a handoff and reports it to the sender through PATHREQ message, the subsequent PATH message will carry the RECEIVER_MOBILITY object. The following states new/modified processing rules for PATH messages in addition to existing rules specified in RFC 2209 due to the introduction of new MOBILITY objects. o When RSVP creates a new PSB for a new PATH message with MOBILITY objects, the following rules apply in addition to/in place of existing rules where applicable: - If SENDER_MOBILITY object is included in the PATH message, it is also copied to the newly created PSB. - If RECEIVER_MOBILITY object is included in the PATH message, it is also copied to the newly created PSB. - When the PATH message is forwarded to the next RSVP node. The source address and destination address of the forwarded PATH message are determined as follows: - The source address is retrieved from SENDER_MOBILITY object which contains the sender's care-of address, if it exists. Otherwise, the source address is retrieved from SENDER_TEMPLATE object which contains the sender's fixed or home address. - The destination address is retrieved from RECEIVER_MOBILITY object which contains the receiver's care-of address, if it exists. Otherwise, the destination address is retrieved from SESSION object which contains the receiver's fixed or home address. Shen, Seah, Lo, Zheng and Greis [Page 10]
Internet Draft RSVP Mobile IPv6 Interop July 17, 2002 o Otherwise, if matching PSB is found, the following rules apply in addition to/ in place of existing rules where applicable: - First, if a RECEIVER_MOBILITY object is included in the PATH message, the RSVP node determines whether it carries the most updated information based on the sequence number of the object. If the existing PSB contains no RECEIVER_MOBILITY information or the received RECEIVER_MOBILITY information is newer than the existing one, the PSB updates its RECEIVER_MOBILITY information. - Second, if a SENDER_MOBILITY object is included in the PATH message, the RSVP node determines whether it carries the most updated information based on the sequence number of the object. If the received SENDER_MOBILITY is older than the existing one in PSB, stops processing the PATH message and discards it. Otherwise, if the existing PSB contains no SENDER_MOBILITY information or the received SENDER_MOBILITY information is newer than the existing one, - The PSB updates its SENDER_MOBILITY information. - The NCR Flag bit in the received SENDER_MOBILITY object is checked. If it is not set, the RSVP node is identified as SNCR. It does the following: Sets the NCR Flag bit to 1; Sends a RESV message to the previous hop which leads to the MS's current care-of address; Sends a RESVTEAR message to the previous hop which leads to the MS's old care-of address; If the RSVP node is not receiver of the flow, it further forwards the PATH message to the next RSVP node using the same source and destination address decision rules as stated above when there is no matching PSB. - Otherwise the RSVP node is not SNCR. If the RSVP node is not receiver of the flow, it forwards the PATH message to the next RSVP node using the same source and destination address decision rules as stated above when there is no matching PSB. 8 Future Work In traditional operation of RSVP, a flow identifier is virtually also used as a reservation identifier. This seems to be fine in fixed networks. In mobile environments however, it might sometimes be desirable to separate these two, while the flow identifier could be changing from time to time, the reservation identifier remains Shen, Seah, Lo, Zheng and Greis [Page 11]
Internet Draft RSVP Mobile IPv6 Interop July 17, 2002 constant all the time [3,4]. It should be noted that our proposed framework does not in any sense exclude this possibility. More specifically, in cases where the reservation identifier is defined differently than the flow identifier, our use of HAs as reservation identifier does not exclude the use of addresses other than HAs, such as the CoAs as flow identifier. In this case, it is expected that the signaling logic explained in this memo will still largely be applicable, although certain modifications are likely to be needed. The applicability of this approach in our framework is currently under study. 9 Acknowledgments We would like to thank Mr. Donglin Shi for helpful discussion during the prototype implementation of this work. 10 Bibliography [1] C. Q. Shen, W. Seah, A. Lo, H. Zheng, and M. Greis, "An Interoperation Framework for Using RSVP in Mobile IPv6 Networks," draft-shen-rsvp-mobileipv6-interop-00.txt , July 2001. Work in Progress. [2] H. Chaskar (Editor), "Requirements of a QoS Solution for Mobile IP," draft-ietf-mobileip-qos-requirements-02.txt , June 2001. Work in Progress. [3] C. Q. Shen, "Several Framework Issues Regarding NSIS and Mobility," draft-shen-nsis-mobility-fw-00.txt , July 2002. Work in Progress. [4] R. Hancock et.al., "Next Steps in Signaling: A Framework Proposal," draft-hancock-nsis-fw-00.txt , June 2002. Work in Progress. 11 Authors' addresses Charles Qi Shen Institute for Communications Research (ICR) 20 Science Park Road #02-34/37, TeleTech Park Singapore Science Park II Singapore 117674 Phone: +65 6870-9358 Email: shenqi@icr.a-star.edu.sg Winston Seah Institute for Communications Research (ICR) Shen, Seah, Lo, Zheng and Greis [Page 12]
Internet Draft RSVP Mobile IPv6 Interop July 17, 2002 20 Science Park Road #02-34/37, TeleTech Park Singapore Science Park II Singapore 117674 Phone: +65 6870-9163 Email: winston@icr.a-star.edu.sg Anthony Lo Institute for Communications Research (ICR) 20 Science Park Road #02-34/37, TeleTech Park Singapore Science Park II Singapore 117674 Haihong Zheng Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972 894 4232 Email: haihong.zheng@nokia.com Marc Greis Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972 374 0629 Email: marc.greis@nokia.com 12 Full Copyright Statement "Copyright (C) The Internet Society (date). 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 Shen, Seah, Lo, Zheng and Greis [Page 13]
Internet Draft RSVP Mobile IPv6 Interop July 17, 2002 revoked by the Internet Society or its successors or assigns. 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Table of Contents 1 Abstract ............................................ 1 2 Terminology ......................................... 1 3 Introduction ........................................ 2 4 Framework and Requirements Review ................... 2 4.1 Framework Review: Mobile Sender (MS) Case ........... 3 4.1.1 Resource Establishment in the New Path .............. 3 4.1.2 Resource Release in the Obsoleted Path .............. 3 4.1.3 Refresh Handling in the Common Path ................. 3 4.2 Framework Review: Mobile Receiver (MR) Case ......... 3 4.2.1 Resource Establishment in the New Path .............. 3 4.2.2 Resource Release in the Obsoleted Path .............. 4 4.2.3 Refresh Handling in the Common Path ................. 4 4.3 Requirements Review: Evaluate the Framework Against Requirements ........................................... 4 5 Formats of New RSVP Objects and Messages ............ 5 5.1 Formats of SENDER_MOBILITY Object and RECEIVER_MOBILITY Object ....................................... 5 5.2 Format of PATHREQ Message ........................... 6 6 Nearest Common Router (NCR) Decision Algorithm ...... 6 6.1 Decision Algorithm for Sender NCR (SNCR) ............ 8 6.2 Decision Algorithm for Receiver NCR (RNCR) .......... 8 7 Processing Rules for PATHREQ Message and PATH Message with MOBILITY Object ................................... 8 7.1 Processing Rule for New PATHREQ Message ............. 8 7.2 New Processing Rules for PATH Message ............... 10 8 Future Work ......................................... 11 9 Acknowledgments ..................................... 12 10 Bibliography ........................................ 12 11 Authors' addresses .................................. 12 12 Full Copyright Statement ............................ 13 Shen, Seah, Lo, Zheng and Greis [Page 14]