Network Working Group T-W. You Internet Draft ETRI Expires: January 2006 I-D. Jang ETRI S-Y. Lee ETRI July 2005 L3Shim state management using Vertical layered Communication draft-you-shim6-l3shim-state-management-00 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 January 10, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This draft proposed vertical layered communication method; especially it is mechanism to notify locator changing from L3Shim to TCP layer. In this draft, it is called indirect TCP congestion control. This mechanism make TCP congestion situation using behavior of L3Shim You et al. Expires - January 2006 [Page 1] L3Shim state management July 2005 layer without correcting conventional TCP. And then we describe L3Shim state through the event. These kinds of events and progress state are presented in a single system view. And it will be help to implement L3Shim functionality through understanding L3Shim process. Table of Contents 1. Introduction...................................................2 2. Vertical layered Communications................................3 2.1 Interaction between L3Shim and TCP or Upper layer..........4 2.2 Interaction between L3Shim and IP or Lower layer...........5 3. L3Shim Events process..........................................6 3.1 The Events happened by timeline............................6 3.2 The L3Shim Events..........................................6 3.2.1 Bootstrap.............................................6 3.2.2 Connect Communication Session ........................7 3.2.3 Shim Context Establishment ...........................7 3.2.4 Doubt Primary Address Pair Failure ..................7 3.2.5 Explicit Test .......................................8 3.2.6 Address change trigger ..............................8 4. L3Shim states process..........................................8 4.1 L3Shim states.............................................10 4.2 Node Behavior.............................................11 5. Future works..................................................12 6. Security Considerations.......................................12 7. IANA Considerations...........................................12 8. References....................................................12 8.1 Normative References......................................12 8.2 Informative References....................................13 Author's Addresses...............................................13 Intellectual Property Statement..................................14 Disclaimer of Validity...........................................14 Copyright Statement..............................................14 Acknowledgment...................................................14 1. Introduction In approach the L3Shim protocol, changes in the addresses that are used below the shim will be invisible to the upper layers [ID.L3Shim]. However, upon changing to a new address pair, transport layer protocol should be notified so that it can perform a slow start, or some other form of adaptation to the possibly changed conditions. This is necessary, for instance, when switching from a high-bandwidth LAN interface to a low bandwidth cellular interface [ID.ARCH]. Also L3Shim should decide whether have to notify changed locator based on requirement for application such as guaranteed bandwidth and delay or not You et. al Expires January 2006 [Page 2] L3Shim state management July 2005 In this draft, we propose the methods to inform locator change from L3Shim layer to TCP using indirect TCP congestion control. This mechanism make TCP congestion situation using behavior of L3Shim layer without correcting conventional TCP. Next, we describe L3Shim state process by happened the events referencing [RFC 2960], [ID.HIP]. These kinds of events and progress state are presented in a single system view. And it will be help to implement L3Shim functionalities through understanding L3Shim process. 2. Vertical layered Communications The goal of vertical layered communications achieves optimal network performance to inform cross layers information. In approach L3Shim, Vertical layered Communications need to notify possible triggers include failure of upper level keepalive signal to the SHIM layer, explicit trigger from upper level, ICMP error, and explicit SHIM level reachability failure [ID.FAIL]. Vertical layered Communications can be divided by two categorization based on L3Shim as depict Figure 1. You et. al Expires January 2006 [Page 3] L3Shim state management July 2005 +-------------------------+ | | | TCP or Upper layer | | | +-------------------------+ ^ | Notification | | Notification Locator change | | TCP congestion or App. Requirement | V +-------------------------+ | | | L3Shim layer | | | +-------------------------+ ^ | Notification | | Sending Local connectivity | | Active probe message | V +-------------------------+ | | | IP or Lower layer | | | +-------------------------+ Figure 1. Classification of Vertical layered Communications 2.1 Interaction between L3Shim and TCP or Upper layer - Signaling from L3Shim to TCP or application In this categorization, there is consideration that any locator change in the L3Shim should trigger a notification to the transport layer protocol. This notification would be used to trigger a resetting of the TCP congestion state to slow start, corresponding to the selection of a new network path. However, note that this notification can not be done in protocol designs where the end points are not the final hosts, such as where a gateway is used. Therefore we proposed method to notify to TCP changing locator using indirect TCP congestion control. The indirect TCP congestion control triggers TCP congestion control mechanism through L3Shim's action basically. At first, the goal of notification to TCP changed any locator is used to trigger a resetting of the TCP congestion state to slow start. Therefore we proposed indirect TCP congestion control that is method to achieve such purpose without notify locator change to TCP directly. You et. al Expires January 2006 [Page 4] L3Shim state management July 2005 When any locator change was occurred, L3Shim should discard the entire packets from correspondent node during TCP-Congestion- Triggering-Time. Consequently the TCP congestion control mechanism triggers naturally by this one. The main key point is that how to set up the time of TCP-Congestion-Triggering-Time enhancing performance. It can be heuristic setting up the value. Also, the VALID state, which is one of L3Shim state and is explained in next chapter, keep up the situation expecting error for operational primary address pair during Probably-Active-Duration-Time with indirect TCP Congestion control separately, TCP Congestion control mechanism should be achieved automatically. At last, If we can also envision that application would be able to tell the L3Shim layer that the current connection in unsatisfactory. This would require an API to be developed. Therefore indirect TCP congestion control should be running only in case of occurring unsatisfactory situation. - Signaling from TCP or Application and Shim This communication is used to monitor available address pairs? rechability. As following protocols exist [ID.FAIL]. O Positive Feedback from upper layer protocols. TCP can indicate to the L3Shim layer that it is making progress. O Negative Feedback from upper layer protocols. It is conceivable that upper layer protocols five an indication of a problem to the either congestion or lack of connectivity using ECN (Explicit Congestion Notification) protocol [RFC 3168]. And as mentioned before, there is a signaling from Application to Shim to confirm whether current connection is satisfaction or not. 2.2 Interaction between L3Shim and IP or Lower layer - Signaling from L3Shim to IP This interaction signaling is used to send explicit test message by L3Shim directly. O Explicit reachability tests. IKEv2 keepalive mechanism can be categorized one - Signaling from IP to L3Shim This signaling is used to inform local information from lower layer such as Neighbor Discovery and available addresses such as Route Advertisement. You et. al Expires January 2006 [Page 5] L3Shim state management July 2005 3. L3Shim state process L3Shim Protocol can be divided by some states through several events to support IPv6 site Multihoming. During the lifetime of an L3Shim enabled end node, the endpoint's L3Shim state changed from one stat to another in response to various events. In this draft, first we have arranged the events happened lifetime interval based on timeline. Each of the events are represented by situations that can happened at endpoint node supported Shim. These kinds of events and progress state are presented in a single system view. And it will be help to implement L3Shim functionality through understanding L3Shim process. 3.1 The Events happened by timeline We firstly put in order several events from start point of time that the node communicate with other peer since the node did boot up to close communication including other situation between this such as shim context establishment complete and address change trigger cause to happened operational primary address pair outage. Active-Working-Time | V Doubt Primary Address Address Pair Failure Change Trigger +-+ +-+ +-+ +-+ +-+ +-+ Time | |--------| |---------| |---------| |--------| |--------| |------> +-+ +-+ +-+ +-+ +-+ +-+ Bootstrap Connect Shim Explicit Test Communication Context ^ Session Establishment | Probably-Active-Duration-Time Figure 2. The Events happened by timeline 3.2 The L3Shim Events 3.2.1Bootstrap The L3Shim enabled node manages locally operational addressees basically for failure detection. The addresses are discovered and monitored through IPv6 Neighbor Discovery and link layer specific mechanisms. Therefore when the L3Shim enabled node does boot up, You et. al Expires January 2006 [Page 6] L3Shim state management July 2005 firstly set memory to operate L3Shim functionalities, and then it collect and manage available addresses' information. As mentioned the [ID.FAIL], two different granularity levels are needed for failure detection in address managements. In other words, a phase of bootstrap only cares for locally operational addresses. Other functionalities can be operated after establishment L3Shim association 3.2.2Connect Communication Session The event is speaking for beginning communication through connection request between Shim enabled node and correspondent peer. In this Shim6 approach the endpoint identities and the locators are both IP addresses. The intention of this approach is to minimize the amount of change and backward compatibility with L3Shim ?disabled node. That is to say when communication session is established for the first time, there is no L3Shim association. In accordance with beginning communication, the node enables functionalities for L3Shim, which are loaded memory in the bootstrap. These functionalities are kept in clearly state. But we do not know whether the remote peer can support L3Shim or not, other functionalities can not be operating exception locally operational addresses administration. 3.2.3Shim Context Establishment The L3Shim enabled node determines the ability of the remote peer to support the Shim6 protocol via explicit negotiation after complete communication session. O If the capability negotiation fails for Shim6 supported. The Shim6 protocol will continue to operate in a conventional. Therefore L3Shim functionality ready to operate is lain in the idle state continuously. O If the remote host can support L3Shim [ID.FUNC] notes that once the initial capability exchange has completed "both ends know a set of locators for the peer that are acceptable as the source in received packets." The end node makes an operational address pair, and managed this information. The initial state of the Shim6 mapping between ULID and locator is a null mapping. 3.2.4Doubt Primary Address Pair Failure L3Shim should check an operational primary address pair's state through receiving various kinds of feedback or message. You et. al Expires January 2006 [Page 7] L3Shim state management July 2005 Firstly, the L3Shim is receiving Upper level positive indication in determinate period representing Active-Working-Time. Whenever receive this feedback, Active-Working-Time do to reset. But when occurred timeout since the last positive feedback was received, the Doubt primary address pair failure event happened. Secondly, when receive TCP negative feedback using such as ECN (The Addition of Explicit Congestion Notification to IP), this event happened. Finally, enter upon the state if receive ICMP error message. Available address pairs are probed connectivity for address change trigger after this event occurred. But there is no action about currently operational primary address pair until decided time (Probably-Active-Duration-Time) passed. One of the reasons that put off a term of validity as like Probably- Active-Duration-Time is that give upper layer protocols additional time to provide reachability confirmation in those cases where Active-Working-Time have passed since the last positive indication due to lack of recent traffic. And the other is mentioned before at Section 2.1; the case of Signaling from L3Shim to TCP. 3.2.5Explicit Test More than Probably-Active-Duration-Time has elapsed since the last positive indication was received, Explicit Test event occurs. L3Shim should attempt Rechability test about operational primary address pair immediately. 3.2.6Address change trigger If rechabilility test fails, select one of managing available address pairs and trigger address change. In case of that changed address pair's bandwidth is bad than previous one, Indirect TCP Congestion Control mechanism is operated as like mentioned before 4. State transition diagram The L3Shim state diagram illustrates state change progress. There is not a complete overlap of processing logic here. Especially this diagram did not present detailed state about Shim context establishment and address change mechanism. This state diagram focuses on the situation between complete Shim context establishment and occurred address change trigger. The state diagram in the figures below shows the major state transitions, together with the causing events and resulting actions. You et. al Expires January 2006 [Page 8] L3Shim state management July 2005 +-------------+ ------>| START | Boot UP +-------------+ | ^ Request Connection: | | Request Connection: Success | | Fail v | +-------------+ | IDLE | +-------------+ Establish L3Sim | ^ Establish L3Shim Success -> | | Fail Establishment | | Association L3Shim V | +-------------+ +------------------->| ACTIVE |<-+ ULP Positive Feedback +--->| | | Active-working-Time: | +-------------+ | Reset | | | | ^ | | | | | | | +------+ | | Receive ULP Positive indication | Active-working- | | before elapse Probably-Active- | Time: Timeout or | | Duration-Time | Receive ICMP error | | Active-working-Time: Reset | message or ECN message V | | | +-------------+ | | | VALID | | | +-------------+ | | Elapse Probably- | | Probe Test: OK | Active-Duration- | | Active-working- | Time V | Timer: Reset | +-------------+ | | | PROBE | | | +-------------+ | | Explicit Test - Send | | | | Keepalive Message | +------+ | :Fail V | +-------------+ +--------------------| CHANGE |<-+ Until Succeed Address +-------------+ | pair changes using Complete Change address pair | | available address pairs Active-working-Time: Reset +------+ Figure 3. L3Shim state transition diagram You et. al Expires January 2006 [Page 9] L3Shim state management July 2005 4.1 L3Shim states O STRAT When L3Shim enabled node does boot up, initialized L3Shim. Specifically, Initialized work such as loading L3Shim in memory, is achieved O IDLE The IDLE state is entered upon that the application send packet to a new peer or indication from a peer wishing to connect to us. But L3Shim association did not complete yet. Therefore, L3Shim is operated in idle state that does own all functions so that do clear until L3Shim association exchanged. O ACTIVE This state is completed L3Shim association through L3Shim context exchange. All of L3Shims?functions operate in this state. In this Shim6 approach the endpoint identities and the locators are both IP addresses basically. The initial state of the Shim6 mapping between ULID and locator is a null mapping. The end node makes an operational address pair, and managed this information. We make timer called Active-Working-Time to manage ACTIVE state continuously. If positive indication from an upper layer protocol was received within the last Active-working-time, we can confirm that L3shim operate well. O VALID More than Active-working-time has elapsed since the last positive confirmation was received. Or if node received ICMP error message or ECN from TCP, L3Shim was entered the VALID state. However receipt of such a message does not confirm that address pairĘs rechability is cut off. The means entering the VALID state insures address pairĘs rechability is verified quickly if the primary address pair is actually being used. But there is no action about currently operational primary address pair until decided time (Probably-Active- Duration-Time) passed. Within this state, L3Shim only manages available address pairs through probe message to ready to occur address change trigger. Available address pairs are check and managed through RTT so on. O PROBE The Probably-Active-Duration-Time has no sooner elapsed than L3Shim attempt explicit rechability test about an operational primary address pair. A rechability confirmation is actively sought by such as IKEv2 Keepalive mechanism [ID.MOBIKE]. Note that due to You et. al Expires January 2006 [Page 10] L3Shim state management July 2005 potentially asymmetric connectivity, both sides have to perform their own tests. O CHANGE The CHANGE state is entered upon to unsuccessful recahbility confirmation about operational primary address pair. Then L3Shim should select preferred address pair for operational primary one because to verify other available address pairs validity in VALID state. If Address change is completely, Active-working-Time does reset, enter ACTIVE state. 4.2 Node Behavior When L3shim enabled node does boot up, entered upon START state. The node does load L3Shim in memory preparing L3Shim use. If Connect Communication Session event is happened, L3Shim is operated in IDLE state that the entire functionalities are clearing until L3Shim association will be exchanged. If connection request becomes fail, return by START state again. The node in IDLE state monitors ICMP error message or Link layer specific mechanism to gather locally information for failure detection. After Connection establishment is completed, L3Shim tries Shim context exchange to know that remote note have capability L3Shim. If the remote host can support L3Shim, L3Shim context is exchanged, and then own full functionalities of L3Shim are actively operating for the first time. The other side, if the capability negotiation fails for Shim6 supported, L3Shim functionalities are ready to operate in IDLE state continuously. When L3Shim receive Upper level positive indication within Active- Working-Time, it keeps this ACTIVE state resetting Active-Working- Time. While Active-Working-Time have elapsed, positive indication was not received, enter upon the VALID state. Also the VALID state is entered upon receiving either ICMP error message or Upper level negative indication using such as ECN. However, receipt of such messages does not confirm address pair's rechability. But there is no action about current operational primary address pair until decided time (Probably-Active-Duration-Time) passed. If positive confirmation was received before timeout happened, return to ACTIVE state. During VALID state, L3Shim should verify other available address pairs?rechability through probe message to prepare address change triggering situation. In the case of SCTP protocol, other available address pairs are managed through sending heart-beat chunk You et. al Expires January 2006 [Page 11] L3Shim state management July 2005 periodically [RFC 2960]. But L3Shim can verify other available address pairs?rechability in VALID state only. Consequently performance degradation by sending frequently test message is reduced. More than Probably-Active-Duration-Time has elapsed since the last positive indication was received performed explicit rechability test immediately. If the explicit rechability test is succeeded, return to ACTIVE state. On the contrary, if this test is failed, it should be occurring address change trigger entering CHANGE state. In the CHANGE state, L3Shim should change an operational primary address pair to select preferred one of set of available address pairs. If we will exhaust available address pairs, keep CHANGE sate until succeed an operational primary pair change. I would think that this point is related with Pair selection state mechanism in [ID.FAIL]. The correlations between proposed L3Shim state and Pair selection state mechanism will be remain to future works. 5. Future works As mentioned before, our proposed L3Shim state process should have a few collision points with Pair selection state mechanism referred to [ID.FAIL]. The states from IDLE to CHANGE sate may be seem to be related with the Pair selection mechanism. Therefore we are going to look for a way to cooperate with two mechanisms or to clear off mutual relationship about two mechanisms for future works. 6. Security Considerations This document has no direct impact on Internet infrastructure security. 7. IANA Considerations This document has no IANA considerations. 8. References 8.1 Normative References [ID.L3SHIM] E. Nordmark, M. Bagnulo, "Multihoming L3 Shim Approach", draft-ietf-multi6-l3shom-00.txt, February 2005 You et. al Expires January 2006 [Page 12] L3Shim state management July 2005 [ID.ARCH] G. Huston, "Architectural Commnetary on Site Multi-homing using Level 3 Shim", draft-huston-l3shim-arch-00.txt, February 2005 [ID.FAIL] J. Arkko, "Failure Detection and Locator Selection in Multi6", draft-ietf-multi6-failure-detection-00.txt, January 2005 [ID.FUNC] M. Bagnulo, J. Arkko, "Functional decomposition of the M6 protocol", draft-ietf-multi6-functional-dec-00, Febrary 2005. 8.2 Informative References [RFC 2960] R. Stewart, etc, "Stream Control Transmission Protocol", RFC 2960, October 2000 [ID.HIP] R. Moskowitz, etc, "Host Identity Protocol", draft-ietf hip-base-03, June 2005 [RFC 3168] K. Ramakrishnan, etc, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001 [ID.MOBIKE] T. Kivinen, etc, "Design of the MOBIKE Protocol", draft- ietf-mobike-design-02.txt, February 2005 Author's Addresses Taewan You ETRI/PEC 161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea Tel : +82 42 860 4996 Fax : +82 42 861 5404 E-mail : twyou@pec.etri.re.kr Indong Jang ETRI/PEC 161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea Tel : +82 42 860 4978 Fax : +82 42 861 5404 E-mail : indoi@pec.etri.re.kr Seungyun Lee ETRI/PEC 161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea Tel : +82 42 860 5508 Fax : +82 42 861 5404 E-mail : syl@etri.re.kr You et. al Expires January 2006 [Page 13] L3Shim state management July 2005 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 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 (2005). 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. You et. al Expires January 2006 [Page 14]