IETF Next Steps in Signaling S. Marwaha Internet Draft H. Cheng Expires: May 2007 T. Sanda T. Ue Panasonic October 16, 2006 Problems Analysis of NSIS Aggregation Teardown Signaling in Mobility Scenarios draft-marwaha-nsis-aggregation-teardown-signaling-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 16, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Marwaha, et al. Expires May 16, 2007 [Page 1] Internet-Draft Problem Analysis of NSIS Aggregation November 2006 Abstract If a Mobile Node communicates with different Corresponding Nodes and there exists a common path for these sessions, NSIS allows these reservations to be aggregated. However, change of aggregation path caused by mobility event creates problems related to the prompt removal of the old aggregation state in case Correspondent Nodes are NSIS Initiators, i.e. multiple Correspondent Nodes will send multiple teardown messages for tearing down the same unused aggregated section and may cause problems of extra signaling overhead, delay in tearing down, reliability, redundancy and extra processing overhead. This draft presents the analysis of these problems. Table of Contents 1. Introduction...................................................2 2. Requirements Notation and Terminology..........................3 3. Aggregation Scenarios in Mobile Environments...................4 3.1. HMIP Aggregation under Mobility Scenario..................5 4. Problem Statement..............................................6 5. Possible Approaches for the NSIS WG............................9 6. Security Considerations.......................................10 7. Conclusions...................................................10 8. References....................................................11 8.1. Normative References.....................................11 8.2. Informative References...................................11 Author's Addresses...............................................12 Intellectual Property Statement..................................12 Disclaimer of Validity...........................................13 Copyright Statement..............................................13 Acknowledgment...................................................13 1. Introduction In a mobile communication network, tunneling is widely used, e.g. from a mobile terminal to its foreign agent or home agent. These tunnels usually result in aggregation of the data traffic for different sessions. For path coupled signaling schemes, such as RSVP [1] or NSIS [2], the aggregation of data traffic also means the aggregation of signaling. The aggregator would modify certain path discovery message, so that the end to end signaling messages will skip the aggregation interior nodes and head directly towards the de- aggregator similar to NSIS tunneling operation[3]. As for the aggregated section, a separate session would be allocated for the signaling management. This type of solution yields reductions in the amount of states to be stored and amount of signaling message Marwaha, et al Expires April 16, 2007 [Page 2] Internet-Draft Problem Analysis of NSIS Aggregation November 2006 exchanged in the aggregation region. However, it also causes problems for mobility support. When there is a mobility event at the aggregator resulting in a change of the de-aggregator, then the old aggregated path is no longer used and needs to be torn down. Under current NSIS Signaling scheme, tearing down aggregated sessions requires multiple RESERVE- with-TEAR to be sent on the old path from each of the CNs in case the CNs are NSIS Initiators (NIs). Every Reserve-with-Tear message will result in an update message [3] to be sent within the aggregated path thus resulting in high overhead; which would keep increasing as the number of sessions increase. All this makes the tearing down operation very slow and requires high processing overhead at the de- aggregator as well as the path QNEs. Moreover, if any of the RESERVE- with-TEAR messages is not successfully delivered to the De- aggregator, the aggregated path would not be torn down immediately.. In such a case, the aggregated path will only be torn down after the soft-state timer has expired. Relying on the soft-state timer will delay the tearing down of aggregated reservation which is a huge chunk of resources. Obviously, this prohibits new reservations to utilize the aggregated resources. Therefore, there exists a need to develop a scheme for efficiently removing the aggregated resources. This draft explores the problems associated with tearing down aggregated reservations in NSIS. It also explores possible approaches for providing expedited and efficient teardown of aggregated reservations. First, the Aggregation scenarios are presented in section 2, followed by the possible problems that may arise while tearing down the aggregated paths in section 3. Section 4 explores the possible solution approaches, which are classified into two categories: (a) Policy based and (b) Explicit signaling based. In policy based approach the De-aggregator detects MN's movement and tears down the path, whereas in the signaling based approach, the MN signals to either the CN or the De-aggregator directly informing them of the change in aggregation path. 2. Requirements Notation and Terminology 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 [4]. The terminology in this draft is based on [5] and [10]. In addition, the following terms are used. (1) Reserve-with-Tear-Flag (R+T) Marwaha, et al Expires April 16, 2007 [Page 3] Internet-Draft Problem Analysis of NSIS Aggregation November 2006 A message sent to teardown the resource reservation state on an unused data path. (2) De-aggregation point (DA) A network entity that distributes the various data flows onto the various individual paths. 3. Aggregation Scenarios in Mobile Environments:- In general, aggregation occurs, when there are multiple sessions sharing a common path. When one of the end-nodes is a Mobile Node, and there is a mobility event, the old aggregated section (MN' to DA- 1 in figure 1) may become obsolete. The unused reservations on the old aggregated path (MN' to DA-1) need to be quickly removed in order for newer sessions to make use of the reserved network resources. In such a scenario it may also happen that the de-aggregation point also changes (DA-2). This may result in the old aggregate reservation being left un-attended since both the end points are no longer present on the new path. Old +-----+<---------------------------+ +----+ Agg Path | | | | MN'|<=========>|DA-1 |<---------------+ | +----+ | | | | +-----+<---+ | | . | | | . +-->+----+ | | . CRN +-->|CN-1| | | Handover | +----+ | | . | | | . | +-->+----+ | . | CRN +-->|CN-2| | . | | +----+ | . | | | . | | +-->+----+ V | | CRN +-->|CN-3| New +-----+<---+ | | +----+ +----+ Agg Path | | | | | MN |<=========>|DA-2 |<---------------+ | +----+ | | | +-----+<---------------------------+ Figure 1: Aggregation Scenario Problems Marwaha, et al Expires April 16, 2007 [Page 4] Internet-Draft Problem Analysis of NSIS Aggregation November 2006 The above situation may arise in various network scenarios such as:- (i) HMIP [6] case, wherein a MN may move from one MAP to another. This may require the old tunnel from the MN to the previous MAP to be removed. (ii) Another scenario can be 3G inter-working, where the MN establishes a new tunnel with another PDG after moving to a new location. In this case also, the network needs to release the reserved resources on the old aggregated path from the previous location of the MN to the old PDG. (iii) Still a more complicated scenario may exist, wherein in the above mentioned scenarios, the MN might be replaced by a mobile network (MR). In this case, the MR may establish a new tunnel with another AR and the previous aggregation path to old AR (or another Gateway) needs to be quickly torn down. Here the end-to-end signaling point is different from the aggregation point. To illustrate the problem, HMIP case is described below in more detail as an example scenario. 3.1. HMIP Aggregation under Mobility Scenario When a Mobile Node communicates with different Corresponding Nodes (CNs), for example CN-1, CN-2 and CN-3 in figure 2, there may exist a common path for these sessions, for example between MN to MAP. NSIS must allow such reservations to be aggregated [5]. Aggregations generally begin at the MN and end at the de-aggregation point (MAP- 1), as shown in figure 2. Individual path reservation will only be visible after the MAP-1. When the MN moves to another location (MN' to MN as shown in figure 2), the aggregated path would change as well and a new de-aggregation point (MAP-2) will thus be created. This is as shown in figure 2 where the aggregation portion shifts from the path between MN' and MAP-1 to the path between MN and MAP-2. Marwaha, et al Expires April 16, 2007 [Page 5] Internet-Draft Problem Analysis of NSIS Aggregation November 2006 Old +-----+<---------------------------+ +----+ Agg Path | | | | MN'|<=========>|MAP-1|<---------------+ | +----+ | | | | +-----+<---+ | | . | | | . +-->+----+ | | . CRN +-->|CN-1| | | Handover | +----+ | | . | | | . | +-->+----+ | . | CRN +-->|CN-2| | . | | +----+ | . | | | . | | +-->+----+ V | | CRN +-->|CN-3| New +-----+<---+ | | +----+ +----+ Agg Path | | | | | MN |<=========>|MAP-2|<---------------+ | +----+ | | | +-----+<---------------------------+ Figure 2: Aggregation Scenario Problems 4. Problem Statement When new aggregation section is created, old one needs to be torn- down. There are two ways of tearing down, i.e. Soft-state Timer or Explicit Teardown signaling. For tearing down such aggregated reservation, sending explicit teardown message (RESERVE-with TEAR) is generally preferred. This is because, if the soft-state timer is used, the tearing down of aggregated reservation which is a huge chunk of resources will be delayed prohibiting new reservation to utilize the aggregated resources. However, with the explicit teardown signaling the CN will send a RESERVE-with TEAR message to the aggregation section, removing the reserved resources. Under aggregation scenarios explicit teardown signaling may not work that well, as it may lead to extra signaling overhead, redundancy and higher processing overhead. These problems are further explained below in more detail. Marwaha, et al Expires April 16, 2007 [Page 6] Internet-Draft Problem Analysis of NSIS Aggregation November 2006 Old +-----+<---------------------------+ +----+ Agg Path | | | | MN'|<=========>|MAP-1|<---------------+ | +----+ | | | | +-----+<---+ R+T-1 | | . | <== | | . +-->+----+ | | . +-->|CN-1| | | Handover | +----+ | R+T-2 | . | | <== | . | +-->+----+ | . | +-->|CN-2| | . | | +----+ | R+T-3 . | | | <== . | | +-->+----+ V | | +-->|CN-3| New +-----+<---+ | | +----+ +----+ Agg Path | | | | | MN |<=========>|MAP-2|<---------------+ | +----+ | | | +-----+<---------------------------+ Figure 3: Aggregation Scenario Problems MN MAP-2 MN' MAP-1 CN-1 CN-2 CN-3 | Query | | | | | | |------->| | | | | | | |Query-1 | | | | | | |--------|--------|------->| | | | |Query-2 | | | | | | |--------|--------|--------|------->| | | |Query-3 | | | | | | |--------|--------|--------|--------|------->| | | | | R+T-1 | | | | | |Update-1|<-------|--------|--------| | | |<-------| | | | | | | | R+T-2 | | | | | |Update-2|<-------|--------| | | | |<-------| | | | | | | | R+T-3 | | | | | |Update-3|<-------| | | | | |<-------| | | | | | | | | | | Figure 4: Signaling to Teardown and aggregated Reservation in HMIP Marwaha, et al Expires April 16, 2007 [Page 7] Internet-Draft Problem Analysis of NSIS Aggregation November 2006 Using current NSIS signaling scheme, when a MN moves to a second Access Network, the CN can receive trigger to teardown the old path and establish the new path. This is as shown in figure 4; CN-1 may receive a Query-1 message from the MN (from new location). The trigger may also be in the form of a Binding process carrying the new CoA of the MN towards the CN [8]. When the CN receives the QUERY or the BU message, it will issue a Reserve-with-Tear-Flag (R+T) message onto the old path [8] as shown in the network scenario in figure 3: e.g. R+T-1, R+T-2 and; R+T-3 will be generated by CN-1, CN-2 and CN-3, if there are three separate sessions each to the three separate CNs. The different Reserve-with- Tear-Flag-n messages generated by the various CNs will arrive at the old de-aggregation point (MAP-1) separately. Once the De-aggregator receives the R+T message, it generates an Update message to be sent on the aggregated path, for example Update-1, Update-2 and Update-3 generated by MAP-1 in figure 4. The above operation may lead to the following problems:- a. Higher Overhead-> Each of the Reserve-with-Tear-Flag messages generated by the CNs will trigger an UPDATE over the aggregated path, in total three UPDATE messages will be generated in the scenario shown in figure 3 along with 3 Reserve-with-Tear-Flag message. b. Slow Operation-> The previous de-aggregator (MAP-1) in figure 3 will have to wait for all the three Reserve-with-Tear-Flag messages to be received before tearing down completely the aggregated path. For example, if path from CN-3 to MAP-1 is very long, it will delay the removal of the aggregated path, even though MAP-1 may have received the other two Reserve-with-Tear- flag message long time ago from CN-1 and CN-2. c. Higher Processing Overhead-> Multiple messages are generated in the current process as described before i.e. three Reserve-with- Tear-Flag and three update (Update-1, Update-2. Update-3) messages, which need to be processed at the de-aggregator leading to high processing overhead at the de-aggregator. d. Reliability (Message Loss) issues-> If any of the Reserve-with- Tear-Flag messages is not successfully delivered from the CN to MAP-1, then the aggregated path will be torn down very late Marwaha, et al Expires April 16, 2007 [Page 8] Internet-Draft Problem Analysis of NSIS Aggregation November 2006 using soft state. This will result in wastage of network resources. If a MN is performing many handovers (e.g. due to fast speed in micro-architecture type of networks) and establishes aggregate reservations for multiple sessions along the movement path, it will hog up a lot of network resources and the above mentioned problem will get further aggravated and hamper the normal operation of the network. Therefore, the teardown procedure for aggregated sessions must be efficiently carried out in an expedited fashion. 5. Possible Approaches for the NSIS WG The problems presented above need to be addressed by NSIS and some solution defined. Possible approaches could perhaps involve:- o Based on relevant policy [9], the De-aggregator may decide at some point that an aggregate reservation is no longer needed and should be torn down. An example could be when one of the QNI sends a Reserve-with-Tear-Flag to the DA and the DA tears down the whole aggregated path without waiting for the remaining individual teardown messages for that aggregated path. However, the drawback of this approach may be that a large number of QNI in the network need to be updated to support the policy based algorithms. o Another approach would be for MN to provide some mobility information to the network in order to explicitly and efficiently teardown the old aggregated path. This category can be sub-divided based on who takes the action as follows:- - Teardown initiated by QNI: - In this approach, the MN can send some information to the CN on its movement and the CN can detect the change and accordingly send a teardown on the old path. This involves embedding extra information in the end-to-end Teardown message regarding the aggregation portion. The De-aggregator may be able to teardown the entire aggregated path as soon as it receives the first such modified teardown message. - Teardown initiated by Tunnel Controller: - In this approach, the MN can directly instruct the tunnel controller of the aggregated path previously under use to teardown as it is no longer in operation. Marwaha, et al Expires April 16, 2007 [Page 9] Internet-Draft Problem Analysis of NSIS Aggregation November 2006 6. Security Considerations Current NSIS [5] protocol provides the basic security mechanism for signaling, however when aggregation is involved because of different bindings and ownerships of the sessions. This should be considered in the future versions of this draft. 7. Conclusions Mobility events in an aggregation scenario require multiple teardown messages to be sent on the old path, resulting in excessive signalling and processing overhead. This may also not be very reliable since if one of the teardown messages is lost, the aggregated section may not be torn down immediately. Without these teardown messages the old-path QNEs will have to wait until the soft-state timer expires. This may not be desirable as aggregated reservation may be a huge chunk of resources and not releasing these resources quickly may prohibit new connections to acquire these trapped resources. Thus after re-establishing NSIS state along a new path the aggregated reservation on the old path needs to be quickly removed using some reliable teardown signalling in order to avoid wastage of resources. Different solution approaches to overcome these problems are presented in this draft, which can be further discussed or analysed by the working group. Marwaha, et al Expires April 16, 2007 [Page 10] Internet-Draft Problem Analysis of NSIS Aggregation November 2006 8. References 8.1. Normative References [1] R. Braden, et al "Resource ReSerVation Protocol (RSVP)", RFC2205 (Standards Track) Sept. 1997. [2] J. Manner, NSLP for Quality-of-Service Signaling, Internet Draft draft-ietf-nsis-qos-nslp-11.txt (Work in Progress), June 2006. [3] C. Shen, H. Schulzrinne, S. Lee, J. Bang, IETF NSIS I-D, "NSIS Operation Over IP Tunnels", Internet Draft draft-ietf`nsis- tunnel-00.txt (Work in Progress) June 19 [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] H. Schulzrinne, R. Hancock, "GIST: General Internet Messaging Protocol for Signaling", Internet Draft draft-ietf-nsis-ntlp (Work in Progress) June 2006 [6] H. Soliman et al, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005. [7] 3GPP TS 23.234, 3GPP system to Wireless Local Area Network (WLAN) inter-working; System description (Release 7) Sept. 2006 [8] S. Lee (Ed.), IETF NSIS I-D, Applicability Statement of NSIS Protocols in Mobile Environments", Internet Draft draft-ietf- nsis-applicability-mobility-signaling-05.txt (Work in Progress) June 26, 2006 [9] Bruce Davie, Pratik Bose, Chris Christou, Michael Davenport, "Generic Aggregate RSVP Reservations", Internet Draft draft- ietf-tsvwg-rsvp-dste-05.txt (Work in Progress) Sept 2006. 8.2. Informative References [10] J. Manner, M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [11] M. Brunner, "Requirements for Signaling Protocols", RFC 3726, Apr. 2004 Marwaha, et al Expires April 16, 2007 [Page 11] Internet-Draft Problem Analysis of NSIS Aggregation November 2006 Author's Addresses Shivanajay Marwaha Panasonic Singapore Laboratories Block 1022, Tai Seng Avenue, #06-3530 Tai Seng Industrial Estate, Singapore 534415 Phone: +65 6550 5414 Email: shivanajay.marwaha@sg.panasonic.com Cheng Hong Panasonic Singapore Laboratories Block 1022, Tai Seng Avenue, #06-3530 Tai Seng Industrial Estate, Singapore 534415 Phone: +65 6550 5477 Email: hong.cheng@sg.panasonic.com Takako Sanda Next-Generation Mobile Communications Development Center, Matsushita Electric Industrial Co., Ltd. (Panasonic) 5-3 Hikarino-oka, Yokosuka, Kanagawa 239-0847, Japan Phone: +81 46 840 5764 Email: sanda.takako@jp.panasonic.com Toyoki Ue Next-Generation Mobile Communications Development Center, Matsushita Electric Industrial Co., Ltd. (Panasonic) 5-3 Hikarino-oka, Yokosuka, Kanagawa 239-0847, Japan Phone: + 81 46 840 5816 Email: ue.toyoki@jp.panasonic.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has Marwaha, et al Expires April 16, 2007 [Page 12] Internet-Draft Problem Analysis of NSIS Aggregation November 2006 made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Marwaha, et al Expires April 16, 2007 [Page 13]