Ahmad,

I was referring to the IP address used as a session identifier which can be the 
same as or different from the IP address used as a routing address of the MN 
interface. To identify the network session, a TCP session for example uses 
source-destination IP addresses and port numbers in the socket to uniquely 
identify the network session between the MN and CN. 

Referring to the IP address used as session identifier then: An MN can be 
running multiple IP application sessions. Each of these IP application sessions 
uses an IP address. The different IP application sessions run on the same MN 
can have the same or different IP addresses.  

The use case of using different IP addresses for different IP application 
sessions by the same MN is as follows:

The mobile node has acquired an IP (routing) address as it attaches to a 
network. With this IP address, it can run multiple network application 
sessions, say a telnet session and a VOIP call session. When it then moves to a 
different network, it will acquire a new IP (routing) address from the new 
network. If it now starts a new application session(s) after it has already 
moved to the new network, it is easier to just use this new IP address as the 
session identifier for these application sessions(s). (so that the IP address 
used in session identifier is the same as the routing address.) This is the 
reason for REQ2. 

The use case here is that for the mobile host, the VOIP call session can 
continue after moving to the new network. This session will need to use the 
previous IP address as the session identifier. Then the mobile node is now 
using 2 different IP addresses (used as session identifiers): the VOIP 
session(s) which had started in the previous network and which has not yet 
terminated will use the previous IP address; the new application sessions that 
started after the MN has moved to the new network can use the new IP address. 

H Anthony Chan

-----Original Message-----
From: Ahmad Muhanna [mailto:[email protected]] 
Sent: Friday, December 21, 2012 10:13 AM
To: h chan; Jouni Korhonen; [email protected]
Cc: Julien Laganier
Subject: RE: [DMM] [DMM Requirements] [WAS Call for WG Adoption of a "current 
practices and gap analysis" document

Anthony,

Thanks for offering me to propose text, however, before getting into that, I 
would like to make sure that we understand the details and we are on the same 
page.

Good explanation! Please see some follow up questions below:
1. Do you mean an IP session is an IP address that is associated with a 
specific application that is hosted on a specific device (Mobile node) while 
being anchored at a specific Node in the network?

2. In addition, are you saying that every application is using a different IP 
session? Or multiple applications can use the same IP session?

3. I assume from your explanation, a specific device (mobile node) can have 
multiple IP sessions that are hosted on that device, right? 

4. Moreover, you seem to suggest that the same device can have multiple IP 
sessions with different mobility requirements. Correct?

Hopefully you do not mind the clarification.
Many thanks in advance!

Regards,
Ahmad

-----Original Message-----
From: h chan [mailto:[email protected]] 
Sent: Thursday, December 20, 2012 12:43 PM
To: Ahmad Muhanna; Jouni Korhonen; [email protected]
Cc: Julien Laganier
Subject: RE: [DMM] [DMM Requirements] [WAS Call for WG Adoption of a "current 
practices and gap analysis" document

Ahmad,

The mobile nodes are running network applications (IP sessions).
Mobility can be thought of as being provided to the mobile nodes. Alternatively 
it can be thought of as being provided to the applications. I think the 
difference is shown in the following:

IP mobility support is not always needed by all network applications or at all 
times. Web-browser does not need it. A laptop often does not move during the 
life of an IP session. 
So the flexibility to provide and not to provide mobility support is needed. 

What REQ2 is trying to avoid is to provide mobility support to the mobile nodes 
such that it is provided by default to all the applications when the mobility 
support is provided to the mobile node. 

So I would think of providing mobility support to the applications.

Please feel free to suggest text changes if the REQ are not clear. 

H Anthony Chan

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Ahmad 
Muhanna
Sent: Thursday, December 20, 2012 11:35 AM
To: Jouni Korhonen; [email protected]
Cc: Julien Laganier
Subject: Re: [DMM] [DMM Requirements] [WAS Call for WG Adoption of a "current 
practices and gap analysis" document

Hello Jouni and All,

I am trying to catch up with the DMM working group. 
I must admit that I was NOT able to follow all the discussions but I felt 
before being able to address the current practice and gap analysis, I needed to 
understand the proposed requirements.

So, I went ahead and read the Requirements draft one more time and I found a 
couple of things that are essential to be clarified in order to have a solid 
ground for hopefully a solid proposals and solutions.

   REQ1:  Distributed deployment

          IP mobility, network access and routing solutions provided by
          DMM MUST enable distributed deployment for mobility management
          of IP sessions so that traffic does not need to traverse
          centrally deployed mobility anchors and thus can be routed in
          an optimal manner.

[Ahmad]
In order to understand this requirement or may be in order for this requirement 
to be clear and makes sense, I would like to understand what is meant by IP 
session(s) in this context? And may be its relationship to the mobile node.


   REQ2:  Transparency to Upper Layers when needed

          DMM solutions MUST provide transparent mobility support above
          the IP layer when needed.  Such transparency is needed, for
          example, when, upon change of point of attachment to the
          Internet, an application flow cannot cope with a change in the
          IP address.  Otherwise, support for maintaining a stable home
          IP address or prefix during handovers may be declined.

[Ahmad]
This a simple requirement that is phrased in a way that makes it a little more 
complex than needed. However, my question here is: how this requirement is 
related to the "IP session(s)" mentioned in the REQ1? I believe it is 
fundamentally important to understand the relationship in order to be able to 
move forward.


In addition, I believe the remaining requirements sort of straight forward and 
clarification of the above two points is essential (at least to me)

Thanks for all the help!

Regards,
Ahmad

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Jouni 
Korhonen
Sent: Wednesday, December 19, 2012 2:25 PM
To: [email protected]
Cc: Julien Laganier
Subject: [DMM] Call for WG Adoption of a "current practices and gap analysis" 
document

Folks,

We are unfortunately slipping our milestone, our (chairs) apologies for that. 
The next step is to select a "current practices and gap analysis" document to 
serve as the basis for the future WG document. We consider two documents on 
this topic to choose from:

[1] draft-zuniga-dmm-gap-analysis-02
[2] draft-liu-dmm-best-practices-gap-analysis-01

and we as a WG need to decide which one is going to form the _basis_ for the WG 
document.

Please voice your preference either for [1] or for [2] on the mailing list. We 
would appreciate if you can also provide a one-liner justification for your 
selection. The chairs will determine if there is (rough) consensus from active 
WG participants to proceed with selecting one document against the other. 

The call starts today 19th Dec 2012 and ends by 10th Jan 2013. We have a longer 
three week call now due the holiday season in between.

- Jouni & Julien
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm

Reply via email to