Subject: [seamoby] Issue two: more questions then answers

From: "Gary Kenward" <[email-masked]>
Date: Tue, 11 Sep 2001 12:05:26 -0400

There is a consensus in favour of adopting issue 2 for the requirements
document.
However, there are some difficulties with the proposed changes. The
resolution
was to adopt issue 2,**with wordsmithing**.

As far as I can tell, these are the issues:

 1. The proposed changes do not state what is to be done with the existing
    4.1 and 4.2. 

 2. Existing 4.1 clearly requires the **characteristics** of the triggers be
defined,
    while the proposed 4.2 requires that the triggers themselves be defined.
    Since the IETF does not define layer two events, it is unclear how
Seamoby
    can define these triggers.

    Proposal: keep existing 4.1, with wordmsithing

 3. The existing 4.2 addresses the need for abstracting out layer two
specifics from
    the layer 3 event. This clearly is the best approach when dealing with
many different
    link layers, and has value as a requirement. Neither of the two proposed
new requirements
    address this issue.

    Proposal: keep existing 4.2, with wordsmithing.

 4. The utility of signalling protocols for soliciting and controlling
context transfer
    has been a debatable subject from the beginning of the context transfer
discussion.
    However, there is a case to be made for initiating ct from layer 3
directly (as opposed
    to a layer 3 event generated in response to a layer 2 event).

    Propose the following wordsmithed set of requirements:

      4.1 The context transfer framework MUST define the characteristics of
the IP
          level trigger mechanisms that initiate the transfer of context.

      4.2 The IP level context transfer triggers MAY be initiated by a link
level (layer two)
          event.

      4.3 The IP level trigger mechanisms for context transfer MUST hide the
specifics of
          any layer 2 trigger mechanisms.

      4.4 The IP level context transfer triggers MAY be initiated by IP
level (layer three)        
          signalling.

	 4.5 Any IP level signalling for Context Transfer MUST be separated
from the actual 
          transfer of context. 

Bash away,
Gary Kenward

(reference material follows:)

****************************************************************************
**********
From the seamoby issues www page,
(http://www.diameter.org/seamoby-ct-issues.html
Issue 2: Make IP messages uniform 
	Submitter name: Kulwinder Atwal 
	Submitter email address: [email-masked] 
	Date first submitted: Jun 19, 2001 
	Reference: 
	Comment type: Technical 
	Priority: S 
	Section: 4.2, 4.3 
	Rationale/Explanation of issue: 
	
	The current text does not provide a uniform set of IP messages for
various 
	entities to request context to be transferred in an access
technology 
	independant manner. 
	
	While an L2 Trigger can be used to initiate the transfer of context
at the 
	current Forwarding Node, other entities in the network need a method
to 
	request, and recieve the completion status of a context transfer
operation. 
	While other entities may not need to be involved in every aspect of
the 
	transfer of context, they do need to be able to request particular
context 
	and recieve the results of the context transfer request. 
	Requested change: 
	
	4.2 The context transfer MUST define the common IP level (layer 3)
triggers 
	to initiate context transfer. 
	
	4.3 The context transfer MUST separate the signaling to initiate
Context 
	Transfer from the transfer of context. 
	
	The request for the transfer of context may come from the MN, 
	current AR, recieving AR, or other entity on the Access Network.
There could 
	be instances where the access network or the MN may need to initiate
context 
	transfer e.g. to actively balance the load between several ARs or to
switch 
	to a different type of access technology. Therefore, a common set of
IP 
	level signalling messages (Layer 3 Triggers) must be defined, and
the 
	current AR must capable of recieveing such messsages on any of its 
	interfaces. These signalling messages do not preclude the use of
Layer 2 
	Triggers at the current AR to initiate the common layer 3 signaling
for 
	context transfer initiation. 
	Update: 
	Consensus appears to be leaning towards rejecting this one. We 
	will discuss this one in London. 

****************************************************************************
**********
WG Chairs comments on Issue 2 as recorded on the www page, 
http://www.diameter.org/seamoby-ct-issues.html:

	 4.2 Not much favor on list - CT must define common IP 
	     level (layer 3) triggers to initiate CT, support mobile
	     to initiate CT. Already there.
	 4.3 New requirement. CT must separate signaling to initiate 
	     CT from actual transfer.

	 Should the requirement be dropped? 4.3 is proposed text. 
	 Not currently in requirements. 

	 Comment: We must have this feature and the mobile must initiate.

	 Comment: This requirement isn't needed. It doesn't disallow any
		  feature.

	 Comment: 4.3 is not for mobile initiated. 4.2 is what triggers
		  cause a context transfer, but we won't define what they
		  are.

	 Comment: If there are L2 triggers, do I have to defined L3 
		  triggers? Triggers without signaling may be OK, but
		  4.3 is not necessary. 4.2 is a must.

	 Comment: We need both. CT is useful if no L2 triggers exist.

	 Hum: How many folks want to keep this text with some wordsmithing?
	      Consensus is yes.

****************************************************************************
**********

Current requirements 4.1 and 4.2:

4.1 The context transfer framework MUST define the characteristics of the IP
    level trigger mechanisms that initiate the transfer of context.

4.2 The IP level trigger mechanisms for context transfer MUST hide the
    specifics of the layer 2 trigger mechanisms.

   Handover at the IP level is a consequence of a change in the physical
   path used to communicate between the MN and the access network. The
   mechanisms utilized to change the communications path at layer 2 are
   specific to the physical characteristics of the medium, and often 
   specific to the layer 2 transmission technology being used (e.g. TIA
   IS 2000, ETSI UMTS R4, IEEE 802.11).

   In order for any action to be taken at the IP level to maintain IP 
   sessions during a layer 2 path change, some indication of the path 
   change must be made available to the IP level. One example of an
   indicator would be the trigger event that initiates context transfer. 

   Since it is expected that IP handover, and thus context transfer will 
   work irrespective of the layer 2 technology, the IP level solutions
   must not utilize specific layer 2 information. The conditions and 
   events that caused the generation of an IP level trigger must be
   opaque to the IP level. This implies that there are general
   characteristics of an IP level trigger that need to be defined so 
   that the triggers generated by different layer 2 solutions will have
   identical semantics at the IP level.

==========================================================================

The contents of this email are Nortel Networks Confidential

---

From: [email-masked]
Date: Tue, 18 Sep 2001 15:21:58 +0300

Hi Gary,

Your proposals seem OK to me, but I'm not sure about the last line:

John

---

From: "Gary Kenward" <[email-masked]>
Date: Tue, 18 Sep 2001 09:44:40 -0400

Ouch! Thanks John. 
 
Just goes to show you that Nortel has no real secrets to keep.
 
Gary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: September 18, 2001 08:22
To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked]
Subject: RE: [seamoby] Issue two: more questions then answers

Hi Gary,

 
 
John