Network Working Group I. Aydin Internet-Draft C. Shen Expires: April 25, 2004 University of Delaware October 26, 2003 Cellular SCTP: A Transport-Layer Approach to Internet Mobility draft-iaydin-cshen-cellular-sctp-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 25, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes a transport-layer mobility solution for the Internet termed Cellular SCTP, or cSCTP for short, based on the emerging Stream Control Transmission Protocol (SCTP). We suggested to use `two primary addresses simultaneously' by duplicating the packet transmissions (while halving the transmission rate) during handoff to provide `soft' handover. Moreover, we described the inter-working of cSCTP with Session Initiation Protocol (SIP) to facilitate location management function when Correspondent Nodes (CNs) initiate the associations and need to locate Mobile Nodes (MNs). Aydin & Shen Expires April 25, 2004 [Page 1] Internet-Draft Cellular SCTP October 2003 Table of Contents 1. Conventions & Terminology . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Cellular SCTP (cSCTP) . . . . . . . . . . . . . . . . . . . 4 3.1 Cellular SCTP Components . . . . . . . . . . . . . . . . . . 5 3.2 Cellular SCTP Handover Mechanism . . . . . . . . . . . . . . 6 3.2.1 Detecting and Obtaining a New IP Address . . . . . . . . . . 6 3.2.2 Adding the New IP Address into the Association . . . . . . . 6 3.2.3 Data Transfer During Handover . . . . . . . . . . . . . . . 7 3.2.4 Deleting Old IP Address from the Association . . . . . . . . 8 4. Inter-operation of cSCTP and SIP for Location Management . . 9 5. Further Considerations for cSCTP Mechanisms . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . 11 Normative References . . . . . . . . . . . . . . . . . . . . 11 Informative References . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 A. Finite State Machine Diagrams . . . . . . . . . . . . . . . 12 B. Changes in the Finite State Machine Diagrams to Reflect Inter-operation with SIP . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . 16 Aydin & Shen Expires April 25, 2004 [Page 2] Internet-Draft Cellular SCTP October 2003 1. Conventions & Terminology The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC2119 [1]. In this document `cSCTP' is short for `Cellular SCTP'. For formal definitions of Mobile Node (MN), Correspondent Node (CN), Access Router (AR), refer to [5]. Handover (or handoff) are used interchangeably in this document. During a handover, Mobile Node (MN) changes its point of attachment to the Internet. But it should still be possible for the MN to transmit and receive packets with minimum service disruption. 2. Introduction Wide spread use of mobile computing and wireless communication devices has signified the need of `host mobility' support in the Internet. Traditionally, Mobile IP [5] supports host mobility at the network layer by deploying special functioning routers (Home and/or Foreign Agents) into the network to keep track of current location of the mobile host, and hence be able to route the packets destined for the mobile host to its current location (usually by means of tunelling). In contrast, Mobile SCTP [6], or mSCTP for short, has proposed a `transport' layer approach to host mobility based on the Stream Control Transmission Protocol (SCTP), RFC 2960 [2]. SCTP is a new, general-purpose transport layer protocol originally designed to transport telephony signaling messages over IP networks. Like TCP, SCTP provides a connection oriented, reliable service. Moreover, SCTP provides two core features that benefit not only telephony signaling applications but also other Internet and wireless networking applications: `multi-homing' and `multi-streaming'. SCTP multi-homing allows a transport layer connection (an association in SCTP terminology) to be defined between a set of local IP addresses and a set of remote IP addresses. If connectivity is lost on the primary IP address being used for the association, the association seamlessly fails over to an alternate IP address. SCTP multi-streaming allows data to be partitioned into multiple streams, and each stream to be sequentially delivered to the destination end point independently of the other streams. Hence, a packet loss in one Aydin & Shen Expires April 25, 2004 [Page 3] Internet-Draft Cellular SCTP October 2003 stream does not incur head-of-line blocking to other streams. In particular, mSCTP extends the base SCTP to facilitate mobility in the Internet at the transport layer. Basically, mSCTP states that both Mobile Node (MN) and Correspondent Node (CN) need to support the `Dynamic Address Reconfiguration' extension [3] to SCTP for seamless handover. The base SCTP protocol allows a set of IP addresses at both source and destination end points to be decided in the association establishment phase. However, Dynamic Address Reconfiguration extension allows two SCTP end-points to add new IP addresses into and delete IP addresses from an active association as well as to set the primary IP address of the association with the help of newly defined ASCONF (Address Configuration Change) and ASCONF-ACK (Address Configuration Acknowledgment) chunks. In this document, we propose another SCTP-based approach for Internet host mobility support termed Cellular SCTP, or cSCTP for short,for a better handoff performance. We define and describe the components and the handover mechanism of Cellular SCTP. We also describe the inter-working of cSCTP with SIP (Session Initiation Protocol) [4] to let the Correspondent Nodes (CNs) locate the Mobile Nodes (MNs), in case CNs want to initiate associations with MNs. This document is intended to continue discussion to explore the use of SCTP for host mobility support in the Internet. Please send comments to the mailing list . To subscribe to this mailing list, please send an e-mail to . 3. Cellular SCTP (cSCTP) In the following subsections we will describe the components and the handover mechanisms of Cellular SCTP. Figure 1 shows a sample scenario. In the figure, handover happens when MN is moving from Access Router 1 (AR1) to AR2 while communicating with the CN. +=========================+ ########## | Correspondent Node (CN) | # Router #---- +=========================+ ########## | layer5: SIP User Agent | ****************** || |_________________________| *** *** || | layer4: cSCTP | ** *** |_________________________| ** the Internet ** | . | Aydin & Shen Expires April 25, 2004 [Page 4] Internet-Draft Cellular SCTP October 2003 ** ** | . | ** ** | . | *** **** |_________________________| || ****************** || || || ####### ####### # AR1 # # AR2 # ####### ####### | | | +========================+ | Mobile Node (MN) | +========================+ | layer5: SIP User Agent | |________________________| | layer4: cSCTP |=====> moving to AR2 |________________________| | layer3: Host-Agent | |________________________| | . | | . | | . | |________________________| Figure 1 3.1 Cellular SCTP Components As depicted in Figure 1, a Cellular SCTP-equipped MN has three main components: o The Host-Agent component operating in Layer 3, communicates with ARs mainly to help the cSCTP component learn about reaching a new AR and/or leaving the previous AR. The Host-Agent component can also help cSCTP to obtain physical layer information such as the strength of the wireless signal to be used for change of the primary IP address(es) to the MN. o The cSCTP component in Layer 4 is basically an SCTP protocol entity with the dynamic address reconfiguration extension [3] plus the handover procedure described in Section 3.2. o Finally at the application layer, a SIP User Agent is executed to facilitate the location management functionality (later described in Section 4). Aydin & Shen Expires April 25, 2004 [Page 5] Internet-Draft Cellular SCTP October 2003 A Cellular SCTP-equipped CN will also have a corresponding cSCTP component and a SIP User Agent running at the transport layer and the application layer, respectively. In addition, each AR will need to support a neighbor discovery protocol such as in [7]. 3.2 Cellular SCTP Handover Mechanism Following four subsections describe the handover mechanism of Cellular SCTP. 3.2.1 Detecting and Obtaining a New IP Address The Host-Agent component of MN and ARs communicate via a neighbor discovery protocol, such as in [7]. The Host-Agent sends ROUTER SOLICITATION messages and ARs send ROUTER ADVERTISEMENT messages. With the help of DHCP or Stateless Address Auto-configuration, the Host-Agent component eventually obtains a new IP address in the new point of attachment (AR2 according to Figure 1). 3.2.2 Adding the New IP Address into the Association After obtaining a new IP address in the new point of attachment, the Host-Agent component informs the cSCTP component of MN about the new IP address. cSCTP introduces a new boolean variable per SCTP association, termed `handoff_mode'. After cSCTP of the MN learns the existence of the new IP address, handover starts, and the cSCTP component of MN performs the following. o sets its handoff_mode to TRUE. o sends an ADD-IP ASCONF chunk to the CN to inform the CN about the start of the handoff mode, and to let the CN add the new IP address into the association. To do so, we used one of the `Chunk Flags' of the ASCONF (and also of the corresponding ASCONF-ACK) chunk to notify the CN about the start of the handoff mode at the MN. We use one bit (H) of the Chunk Flags to indicate the start of handoff mode as shown in Figure 2. o adds the new IP address into the association. Aydin & Shen Expires April 25, 2004 [Page 6] Internet-Draft Cellular SCTP October 2003 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0xC1 | Chunk Flags |H| Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Serial Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Parameter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASCONF Parameter #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / .... / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASCONF Parameter #N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Upon receiving the ADD-IP chunk with handoff_mode flag set, CN does the following. o sets its handoff_mode to TRUE. o adds the new IP address into the association. o both the old IP address of MN and the newly added IP address are considered as primary addresses to MN. (At this point CN sees the MN as a multi-homed endpoint). Congestion window value (cwnd) for each of these primary addresses is set to be `half' of the cwnd value of the old primary IP address to the MN. Note that SCTP maintains a separate set of congestion control parameters for each path if host is multi-homed. 3.2.3 Data Transfer During Handover (Direction of data transfer is assumed to be from CN to MN to simplify explanation.) CN duplicates and sends packets to `both' of the primary addresses for MN in the rate of newly calculated, reduced cwnd value. Therefore, the same data will be transferred to the MN `via two different paths', to reduce the probability that MN would miss the data packets sent by the CN. Aydin & Shen Expires April 25, 2004 [Page 7] Internet-Draft Cellular SCTP October 2003 There are two motivations/scenarios to advocate the duplicates: 1. In the case where the old and the new attachment points of MN to the Internet are close to each other (i.e., both access routers are within the same ISP, for instance), most likely only the last hop (i.e., the wireless hop) to the MN would change. If (as in Mobile SCTP [6]) either the old or the new IP address is used as the primary address to the MN at a time, before MN sets the new IP address to be the primary IP address of the association, data packets would be sent to the old IP address. However, if MN is not reachable by the old IP address anymore, cwnd of the old IP address would be set to one MTU (due to timeout, and hence back to slow start at the old IP address), and then the retransmissions would be sent to the newly added IP address in the rate of a newly growing cwnd value for the new IP address. This situation would result in delays and decrease the performance of the SCTP association unnecessarily because the reason for retransmissions would not be due to the congestion in the path from CN to MN but due to MN's moving from one access point to another. 2. Furthermore, in the case where MN moves to access point B from access point A, stays in access point B for a little time, moves back to access point A again, and repeats this movement pattern, each handoff would degrade the transmission rate of the CN due to timeouts and re-transmissions. Whereas, by duplicating the data transfer during the handoff mode in cSCTP, we aim to mitigate these negative effects. However, some related issues arise. Discussions on these issues are given in Section 5. 3.2.4 Deleting Old IP Address from the Association When finally MN decides that the old IP address is inactive (by means of not receiving any data from the CN via the old IP address or Host-Agent informing the cSCTP at the MN about not receiving any Router Advertisements from the old Access Router, etc.), MN exits the handoff mode by performing the following actions. o sets its handoff_mode to FALSE. o removes the old IP address from the association. o sends a DELETE-IP ASCONF chunk with handoff_mode flag set to FALSE, to the CN. Aydin & Shen Expires April 25, 2004 [Page 8] Internet-Draft Cellular SCTP October 2003 Upon receiving the DELETE-IP ASCONF chunk, CN performs the following. o also exists the handoff mode by setting handoff_mode to FALSE. o removes the old IP address from the association. o uses the new IP address as the primary address to the MN. Appendix A depicts the finite-state-machine diagrams that summarize the steps during the cSCTP handover process. 4. Inter-operation of cSCTP and SIP for Location Management One key design objective of cSCTP is have a transport layer mobility solution that is completely independent of network layer support such as Mobile IP. To facilitate location management when CNs initiate the associations and need to locate MNs, the location management function of SIP [4] can be used by the CN to retrieve the (current) location(s)/address(es) of the callee (MN in our case). The main components of SIP include `User Agents' (which initiates the requests and produces corresponding responses on behalf of the users),`Proxy Servers',`Redirect Servers', and `Registrar Servers'. The ways Proxy and Redirect servers process the (INVITE) requests by callers differ. For our purpose of locating the callee (i.e., MN), the redirect server would be sufficient. Registrars are the servers that users register their current location(s) with. The inter-working of cSCTP and SIP to locate a MN is as follows. o Each MN runs a SIP User Agent at its application layer. Whenever the MN obtains a new IP address, the SIP User Agent registers the new IP address with the local Registrar server(s) by using SIP REGISTER request (For the details of how the local registrar server(s) are located by User Agent, see Section 4.2.6 of [4].). The two important fields of the REGISTER's request-header for the purpose of location registration are `To' and `Contact'. `Objects' in SIP are addressed as `users at hosts' similar to an email address, identified by SIP URLs, such as user@host. Hence, the `To' and `Contact' fields of the REGISTER's request-header needs to be filled with such a proper SIP syntax. The `To' field will contain the "name" of the MN and the `Contact' field will contain the new IP address of the MN. For instance, the MN in Figure 1, can be given a name in the `To' field. Note that the value Aydin & Shen Expires April 25, 2004 [Page 9] Internet-Draft Cellular SCTP October 2003 of user and the host parts of the name of the MN is not important for our purpose. We just want to "name" the MN in a SIP-suitable way. If MN moves to the network of AR2, and receives a new IP address, let's say 10.1.2.3, then the `Contact' field of the REGISTER request could contain address . Again, the value of the user part of the address is not important for our purpose. o CNs will also run SIP User Agents at the application layer. A CN, who wants to initiate an association with a MN, will send a SIP INVITE request to the local redirect server for MN. For the details of how a caller (CN in our case) locates a SIP server, refer to Section 1.4.2 of [4]. CN will need to give the "name" of MN in the `Request-URI' (and the `To' field) of the SIP INVITE request. Continuing with the same example, CN will write into the `Request-URI' of the INVITE request. Then, eventually the redirect server, contacting with the location service, will return the current location(s) of the MN to the CN (i.e., only in this case). SIP User Agent at the CN receiving the response from redirect server, will send the response to the cSCTP layer, where the response is processed further and finally the current location(s) of the MN is decided. Then, the cSCTP layer of the CN will use the current location(s) of MN to initiate an association with the MN. Appendix B shows the complete finite-state-machine diagrams after changes to the finite-state-machine diagrams of Appendix A are added to describe the mechanisms to support location management as explained in this section. 5. Further Considerations for cSCTP Mechanisms o In cSCTP, the transmission rate during handover is NOT cut less than half of the cwnd for the old IP address of MN. If the new and the old access points are NOT close to each other (for instance, in the same ISP) as in scenario (1) of Section 3.2.3, the policy of NOT reducing the cwnd value less than half of the cwnd for the old IP address, would be a little "aggressive". Therefore, we should figure out a way to see access points are close enough to each other to apply policy. o Because of the policy of duplicating the data transfer during handover, MN can get the data from either old, new, or both IP addresses. Therefore, we need to elaborate the mechanism on how MN would progress its cwnd value(s) and TSN for such cases. Aydin & Shen Expires April 25, 2004 [Page 10] Internet-Draft Cellular SCTP October 2003 o During the handover management, Cellular SCTP uses the multi-homing property of SCTP; however, a combination of multi-homing and multi-streaming during handover with better load balancing techniques would bring benefit and requires further investigation. o Cellular SCTP handles associations initiated from MN to CN and vice versa. But for a complete solution, associations initiated from a MN to another MN needs to be considered. 6. Security Considerations This document discusses Cellular SCTP mechanisms for seamless handover and location management (by inter-operating with SIP). The related security issues will be identified and addresses in the future. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [2] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [3] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., Rytina, I., Belinchon, M. and P. Conrad, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration, draft-ietf-tsvwg-addip-sctp-08.txt", September 2003. [4] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. Informative References [5] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6, draft-ietf-mobileip-ipv6-24.txt", June 2003. [6] Riegel, M. and M. Tuexen, "Mobile SCTP, draft-riegel-tuexen-mobile-sctp-03.txt", August 2003. [7] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. Aydin & Shen Expires April 25, 2004 [Page 11] Internet-Draft Cellular SCTP October 2003 Authors' Addresses Ilknur Aydin University of Delaware Department of Computer & Information Sciences 103 Smith Hall Newark, DE 19716 USA Phone: +1 302 831 1131 EMail: aydin@cis.udel.edu URI: http://www.cis.udel.edu/~aydin Chien-Chung Shen University of Delaware Department of Computer & Information Sciences 103 Smith Hall Newark, DE 19716 USA Phone: +1 302 831 1951 EMail: cshen@cis.udel.edu URI: http://www.cis.udel.edu/~cshen Appendix A. Finite State Machine Diagrams Figure 3 and Figure 4 show the Finite State Machine (FSM) diagrams for MN and CN respectively. Dotted (....>) arrows in the FSM diagrams show some other paths from one state to another. In both Figure 3 and Figure 4, before any handoff occurs (i.e., ESTABLISHED mode entered by following the dotted arrow), the association is defined by {[m1],[c1]} (i.e., both MN and CN are single-homed and primary address for MN is m1 and primary address for CN is c1). . . association:{[m1],[c1]} . . +-----------------+ ..............> | ESTABLISHED | +-----------------+ ^ | | | old IP address m1 | | new IP address m2 Aydin & Shen Expires April 25, 2004 [Page 12] Internet-Draft Cellular SCTP October 2003 became inactive | | is obtained -------------------------- | | --------------------- o handoff_mode = FALSE | | o handoff_mode = TRUE o send DELETE-IP(m1) | | o send ADD-IP(m2) with H flag FALSE, | | with H flag TRUE, to CN | | to CN o association:{[m2],[c1]} | | o association:{[m1,m2],[c1]} | v +-----------------+ | HANDOFF | +-----------------+ Figure 3 . . association:{[m1],[c1]} . . +-----------------+ ...........> | ESTABLISHED | +-----------------+ ^ | | | receive DELETE-IP(m1) | | receive ADD-IP(m2) with H flag FALSE, from MN | | with H flag TRUE, from MN --------------------------- | | ---------------------------- o handoff_mode = FALSE | | o handoff_mode = TRUE o association:{[m2],[c1]} | | o set m1 and m2 as primary IP | | addresses for MN | | o association:{[m1,m2],[c1]} | | o cwnd = cwnd(m1)/2 | | o cwnd(m1) = cwnd(m2) = cwnd | v +-----------------+ | HANDOFF | +-----------------+ Figure 4 Appendix B. Changes in the Finite State Machine Diagrams to Reflect Inter-operation with SIP Figure 5 and Figure 6 shows the completed FSM diagrams after changes to the FSM diagrams of Appendix A is added to reflect inter-operation of cSCTP and SIP as described in Section 4. Aydin & Shen Expires April 25, 2004 [Page 13] Internet-Draft Cellular SCTP October 2003 . . association:{[m1],[c1]} . . +-----------------+ ..............> | ESTABLISHED | +-----------------+ ^ | | | old IP address m1 | | new IP address m2 became inactive | | is obtained -------------------------- | | --------------------- o handoff_mode = FALSE | | o handoff_mode = TRUE o send DELETE-IP(m1) | | o send ADD-IP(m2) with H flag FALSE, | | with H flag TRUE, to CN | | to CN o association:{[m2],[c1]} | | o association:{[m1,m2],[c1]} o de-register with SIP | | o register with a SIP registrar | | | v +-----------------+ | HANDOFF | +-----------------+ Figure 5 +---------------+ SIP INVITE for MN +-----------------+ | CLOSED |------------------------------> | WAIT_LOCATION | +---------------+<----------------------------- +-----------------+ . response from SIP registrar server . association:{[m1],[c1]} . . +-----------------+ ...........> | ESTABLISHED | +-----------------+ ^ | | | receive DELETE-IP(m1) | | receive ADD-IP(m2) with H flag FALSE, from MN | | with H flag TRUE, from MN --------------------------- | | ---------------------------- o handoff_mode = FALSE | | o handoff_mode = TRUE o association:{[m2],[c1]} | | o set m1 and m2 as primary IP | | addresses for MN | | o association:{[m1,m2],[c1]} | | o cwnd = cwnd(m1)/2 Aydin & Shen Expires April 25, 2004 [Page 14] Internet-Draft Cellular SCTP October 2003 | | o cwnd(m1) = cwnd(m2) = cwnd | v +-----------------+ | HANDOFF | +-----------------+ Figure 6 Aydin & Shen Expires April 25, 2004 [Page 15] Internet-Draft Cellular SCTP 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. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 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. Aydin & Shen Expires April 25, 2004 [Page 16] Internet-Draft Cellular SCTP October 2003 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Aydin & Shen Expires April 25, 2004 [Page 17]