Internet DRAFT - draft-you-shim6-l3shim-state-management
draft-you-shim6-l3shim-state-management
Network Working Group T-W. You
Internet Draft ETRI
Expires: April 2006 I-D. Jang
ETRI
S-Y. Lee
ETRI
October 2005
L3Shim state management using Vertical layered Communication
draft-you-shim6-L3Shim-state-management-01
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 24, 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 - April 2006 [Page 1]
L3Shim state management October 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 April 2006 [Page 2]
L3Shim state management October 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 April 2006 [Page 3]
L3Shim state management October 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 April 2006 [Page 4]
L3Shim state management October 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 April 2006 [Page 5]
L3Shim state management October 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 April 2006 [Page 6]
L3Shim state management October 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 April 2006 [Page 7]
L3Shim state management October 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 is 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 April 2006 [Page 8]
L3Shim state management October 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 April 2006 [Page 9]
L3Shim state management October 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 April 2006 [Page 10]
L3Shim state management October 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 April 2006 [Page 11]
L3Shim state management October 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 April 2006 [Page 12]
L3Shim state management October 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 April 2006 [Page 13]
L3Shim state management October 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 April 2006 [Page 14]
