Jouni Korhonen | 1 Apr 17:02 2015
Picon

Call for adoption: draft-perkins-dmm-4283mnids-01

Folks,

This emails starts a two week call for the I-D
   draft-perkins-dmm-4283mnids-01
to confirm the aadoption s a DMM WG document. The call ends April 15th 
EOB PST.

Express your support or opposition to the mailing list. During the 
IETF92 meeting we got 7 voices for the adoption so at least the same 
amount supporting emails should be expected.

- Jouni & Dapeng
Jouni Korhonen | 1 Apr 07:04 2015
Picon

IETF#92 meeting minutes available

The minutes are here:
http://tools.ietf.org/wg/dmm/minutes?item=minutes-92-dmm.html

Thanks to John for taking extensive minutes.

- Jouni & dapeng
Dapeng Liu | 31 Mar 11:51 2015
Picon

http://tools.ietf.org/html/draft-yegin-dmm-ondemand-mobility-03

Folks,

I would like to reaffirm that the technical comments that I made is individual opinion (without co-chair’s hat). 

To facilitate the discussion, I have the following suggestions:

1. If you are OK with the DMM API approach in general, but you have comments to this specific proposal:
1.1 If you think the proposal can be improved:
      Then please suggest the changes that you think can improve the proposal (providing text changes)
1.2 If you think we need a new proposal:
You can provide the reason why this proposal does not work. and probably new idea that works.
2. Provide other comments if it not belongs to the above case.


Thanks,
-- 
Dapeng Liu
_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm
Seil Jeon | 26 Mar 21:08 2015
Picon

Answer on raised questions for the proposed API

Hi,

 

I could attend DMM Thursday meeting via MeetEcho.

I could also hear some raised comments by Danny and Someone. Here goes answers to the raised questions.

 

 

First, regarding the need of the proposed API (IPV6_PREFER_SRC_NEW),

 

The use of the proposed API is suggested in the SUSTAINED IP address case in the draft. On receiving this API with the SUSTAINED IP address type at the IP stack, it will try to get a new SUSTAINED IP address if there is no available in the currently attached access network. So, actual obtaining of the IP address will be tried one time while attached at a specific access network. Even some applications put this API after, the already obtained SUSTAINED IP will be used. So, no worries about abuse.

 

Second question sounded to me like that this API is not needed because the host can get a new SUSTAINED IP address, right?

If the question is right, I don’t understand what the question is meant, that is how the host can get a new SUSTAINED IP address?

Based on the definition of three types of IP address, an application should show its requirement with an API among them. If it is the SUSTAINED IP address, how do we expect the IP stack will try to get a new SUSTAINED IP address?

 

Besides, the propsoed API is not used alone but with the three type APIs.

 

 

 

Regards,

 

Seil Jeon

 

 

_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm
Brian Haberman | 26 Mar 19:53 2015
Picon

DMM work teams

DMM WG,
     I want to, once again, clarify the guiding principles for the DMM
work teams. Hopefully, this will make it clear to all participants how
the work teams will influence the WG.  The guiding principles are:

1. All work teams are open to input from anyone

2. Any work team holding a meeting will announce that meeting to the WG

3. Any document produced by a work team is treated as any individual draft

4. Anyone can publish alternative proposals and ask the WG to consider them

5. WG consensus will drive the adoption of any solutions drafts (work
team generated or otherwise).

If you have any questions about the above, please contact me.

Regards,
Brian

_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm
h chan | 26 Mar 18:54 2015

Enhanced mobility anchoring

I was asked to provide more explanation about anchoring.

 

Distributed mobility management may have anchoring functionality in different networks so that routes do not need to traverse a centralized anchor.

 

Yet, the definition of "anchoring function" (AF) in RFC 7333 is in terms of route advertisement for the IP address only, and such function is available in multiple network.

 

So what are the rest of the functions?

 

Such functions may tend to cause the packets to traverse certain nodes.

 

Consider a typical handover scenario: MN moves from Net1 moves to Net2, and CN is in Net3

 

The old AR (AR1) of MN in Net1 performs RA for IP1; the new AR (AR2) of MN in Net2 performs RA for IP2; the AR (AR3) of CN in Net3 performs RA for IP3.

 

The additional functions at AR1 and AR2 both try to cause the packets of the flow to traverse them. If we call these additional functions part of distributed anchoring function, the question is what they are anchoring.

 

So according to the definition of AF, AR1 performs AF for IP1; AR2 performs AF for IP2 (not IP1); and AR3 performs AF for IP3.

 

One approach is to borrow the well known concept of separation of session ID (SID) from routing address. There are tons of papers addressing such separation, and the lack of such separation is considered the fundamental problem of breaking session as an IP address changes during handover.

 

In line with this separation, the function of anchoring of a session/flow can be separated from that of anchoring an IP address.

 

The separation of session ID and routing address can be considered a generalization, because the session ID can be anything. An example is HIT in the IETF protocol HIP.

 

The use of HoA and CoA can be considered a particular case of SID and routing address separation. In using indirection, one IP address (CoA) is used for routing, whereas another IP address (HoA) is used in the socket as part of the SID identification.

 

Another IETF protocol of such separation is LISP.

 

In one example of handover scenario the desired path can be:

 

packet from CN first goes to AR3, to which IP3 is anchored.

 

it then goes to AR1, to which IP1 is anchored.

 

it then goes to AR2, to which IP2 is anchored.

 

What causes the packets of the flow to go this way may be:

 

AR2 has the location information: the binding of SID of the flow (IP1) to IP address of AR2. It sends this information to AR1.

 

Such additional function basically tries to cause the packets of the flow (IP1) to traverse AR1 and AR2.

 

In another example of this same scenario, the desired path is:

 

packet from CN first goes to AR3, to which IP3 is anchored.

 

it then goes directly to AR2, to which IP2 is anchored.

 

What causes the packets of the flow to go this way may be:

 

AR3 has the location information: the binding of SID of the flow (IP1) to IP address of AR2.

 

Please let me know if any of these is not clear enough. Thank you.

 

H Anthony Chan

 

 

 

 

 

 

_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm
Weixinpeng (Jackie | 26 Mar 18:39 2015

Re: DMM API

Hi Alper

My understanding about the reason why there needs to define serval types of IP prefixes is that,  if the application itself could deal with the change of IP address, i.e. the application itself could deal with session continuty in case of IP address change, so the host would choose a normadic address otherwise the host should choose a sustained address.

But my question is that, if the application could deal with session continuty itself, does that mean the application is willing to change its IP address? Because even though a new address might bring some kinds of benefit, but it will also

bring additional cost for application to deal with IP address change.

Thanks.

 

Xinpeng

 

 

发件人: dmm [dmm-bounces <at> ietf.org] 代表 Dapeng Liu [maxpassion-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
发送时间: 2015年3月26日 5:01
收件人: Alper Yegin
抄送: dmm-EgrivxUAwEY@public.gmane.org
主题: [DMM] 回复: DMM API

Hello Alper,

I still have the following comments:

1. Regarding the definition of “fixed IP address” in the draft:

  “- Fixed IP Address
This is what standard Mobile IP provides with a Home Address (HoA). The mobile host is configures a HoA from a centrally-located Home Network. Both IP session continuity and IP address reachability are provided to the mobile host with the help of a router in the Home Network (Home Agent, HA). This router acts as an anchor for the IP 
address of the mobile host.” 

If this is equal to HoA, then RFC5014 already cover that. We do not need to repeat it here with another name.

2. Regarding the definition of “sustained IP address” in the draft:

"- Sustained IP Address This type of IP address provides IP session continuity but not IP address reachability. It is achieved by ensuring that the IP address used at the beginning of the session remains usable despite the movement of the mobile host. The IP address may change after the termination of the IP session(s), therefore it does not exhibit persistence. "
There is no clear dividing line between fixed IP address and sustained IP address. Whether the IP address is used for reachability is not determined by the IP address itself. For example, even when the MN get a HoA, after it moves to another location of the network, it may decide to release current HoA and get another HoA, in this case the "fixed IP address" becomes a "sustained IP address".

Further more, the reachability normally is implemented by domain name instead of IP address. For example, we reach “Google” by its domain name, never by it’s server’s IP address. 

Using temporary private IP address we can also achieve the goal of “reachability”. For example, using dynamic DNS, as shown in  http://hsk.oray.com/ , it can  provide reachability even the host get a private IP address.

3. Regarding the definition of “nomadic IP address”:

- Nomadic IP Address
This type of IP address provides neither IP session continuity nor IP address reachability. The IP address is obtained from the serving IP gateway and it is not maintained across gateway changes. In other words, the IP address may be released and replaced by a new IP address when the IP gateway changes due to the movement of the mobile 
host.

Seems this IP address is the IP address that we normally used in most cases. If this is the case, why we need a new name for it?


-- 
Dapeng Liu

在 2015年3月25日 星期三,下午2:02,Alper Yegin 写道:

Hello Dapeng and Alex,

I hope you had a chance to digest our responses to your comments and questions about the API work.
If you have any remaining issues, please let us know over the email at your earliest convenience.
It'd be good if you can articulate them in detail.


Thanks.

Alper

_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm
Alexandru Petrescu | 26 Mar 00:41 2015
Picon

clarifications on draft-chan-dmm-distributed-mobility-anchoring-01 - and 2 questions

Hello,

During yesterday's DMM meeting there were several clarification
questions on draft-chan-dmm-distributed-mobility-anchoring-01.

I talked this morning to Anthony, and I think there is a case.

The IP Anchor - we all know what is.  It typically anchors the HoA of
Mobile IPv6 protocol.  It is a Border Router or a Home Agent, or so.

The "Session IP" Anchor is new and deserves clarification.

The "Session IP Anchor" is actually a "Session Anchor".  If a session is
identified by an IP address (i.e. a brief web browsing session to the IP
address of a web server) then that's the Care-of Address; that is a
"Session IP Anchor" and it is typically an Access Router where that IP
address (CoA) is topologically correct.

On another hand, Sessions can be identified by something else than an IP
address.  For example, a TCP session is identified by a quad
IPsrc/IPdst/srcport/srcdst.  The anchor of this session may be something
else than the Access Router.  It could be for example an Application
Layer Gateway (ALG) like for example a HTTP proxy.

So we end up with two anchors: the "Address Anchor" and the "HTTP Proxy
Anchor".

A session can be identified by a SIP identifier as well (SIP - Session
Initiation Protocol).  In that case the "Session Anchor" would be a SIP
Server.

Following this presumably locator-identifier split, we can think about
this session to be for HIP, for SHIM6 and even DNS.  Each time there is
a different Session Anchor.

And this draft proposes to offer a double-level mobility which allows
changing the IP anchor or the session anchor without interrupting the
sessions.

That said, I wonder whether the IP Anchor of this draft supports
SUSTAINED, NOMADIC, FIXED kinds of addresses.

I also wonder whether the Alper's API draft supports SUSTAINED, NOMADIC,
FIXED attributes of IP addresses in the DNS.

Alex
Alexandru Petrescu | 26 Mar 00:27 2015
Picon

SUSTAINED, NOMADIC, FIXED: existing kinds, lifetimes

Alper, authors of draft-yegin-dmm-ondemand-mobility-03,

I would like to ask how do you see the relationships between
other kinds of addresses (HoW, CoA, LL, GUA, ULA, NATTed, privacy,
multicast) and the SUSTAINED, NOMADIC, FIXED addresses.

In addition, I think there may be a relationship with the lifetimes of
the addresses generated by existing address configuration mechanisms.

Alex
Alper Yegin | 25 Mar 20:02 2015

DMM API

Hello Dapeng and Alex,

I hope you had a chance to digest our responses to your comments and questions about the API work.
If you have any remaining issues, please let us know over the email at your earliest convenience.
It'd be good if you can articulate them in detail.

Thanks.

Alper
Lyle Bertz | 25 Mar 13:39 2015
Picon

Developer Usage of Socket Types as described in draft-yegin-dmm-ondemand-mobility

A question was raised during the dmm session regarding whether a developer would use the Socket options specified in the draft or even be aware of them.  Mobile developers (Android and other OSes) are quite aware of not only the network type but also the 'features' that can be requested.   

Using Android as an example - 
The basic networking tutorial exposes the developer to ways to check connections and their types (http://developer.android.com/training/basics/network-ops/managing.html).  The developer is also made aware of permissions requests and features of the connection type during this and many other 'Getting Started' tutorials one may find on the Internet.

The Android API permits a developer to request a feature using the requestNetwork( request, operation) method.  The method is described as "Request a network to satisfy a set of NetworkCapabilities " which can be found here - http://developer.android.com/reference/android/net/NetworkCapabilities.html

Although many of these capabilities are merely network types you'll note a few are sub-features or 'qualities' such as NOT_RESTRICTED (general use) or NOT_METERED.  

It is reasonable to assume that for Android the options specified in the draft would be enumerated here if the developer wishes to manipulate it at the application level or pass as socket options in the Android Socket API which likely, in turn, calls the ConnectivityManager first and, upon success, attempts to open the Socket.   Other operating systems in the mobile space have similar features.   

If security is an issue the OS provider can use their respective application permissions frameworks to restrict the application's request.

I think the OSes have very good methods to accommodate the options as described in the draft and developers have a good idea of how to or discover how to use them.

Lyle

_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm

Gmane