Anthony,
Does this requirement also include a way for the application (or
transport protocol) to request/refuse mobility support? The "when
needed" implies some type of knowledge that is either manually
configured or signaled from the upper layer.Regards, Brian On 1/28/14 5:33 PM, h chan wrote: > Let us try to include MR. > > How about the following > > REQ2: Network-layer mobility support when needed > > DMM solutions MUST enable network-layer > mobility when needed. > Such mobility support is needed, for > example, when an application or a host cannot cope with a change in > the > IP address when a node moves. However, it is not always necessary > to maintain a > stable IP address or prefix. > > Here, the node can be a mobile host or a mobile router. > A host can be a mobile host or a host in a LFN. > An application can be running on a mobile host or a on a host in a LFN. > A MR also does not need to maintain stable IP address or prefix when there > are no hosts attached to it or when there are no active applications running > in the hosts of its network. > > Any comments/changes/corrections? > > H Anthony Chan > > > -----Original Message----- > From: Alexandru Petrescu [mailto:[email protected]] > Sent: Tuesday, January 28, 2014 1:27 PM > To: h chan; [email protected] > Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements > > Le 28/01/2014 19:58, h chan a écrit : >> Let me try to understand the concern here. >> >> What is new in this requirement is "when needed" in contrast to >> providing IP mobility by default. > > First, providing mobility by default is not a black/white alternative to not > providing mobility. > > It is very possible on the same machine to have Mobile IP enabled for some > flows and disabled for others (depending what we call a 'flow'). > It is also possible to have Mobile IP and NAT at the same time on the same > Mobile Router. > >> Without this requirement, mobility support may be provided by default, >> which is transparent to higher layers. > > Again, transparency to higher layers means we talk mobility management on a > Mobile Host. > > Transparency to higher layers has little meaning if we talk mobility > management provided on a Mobile Router (which is not a Mobile Host). > >> With this requirement, assume there are separate steps in the DMM >> solution. 1. A decision is made whether network-layer mobility support >> is needed. 2. When the need is established, network-layer mobility >> support is invoked. 3. Then transparent support is provided and is >> transparent to layers above IP. >> >> Transparency is clear in step 3 above. > > This looks like a trigger which enables mobility, or other times disables it. > > But one can have a Mobile IP daemon and a NAT run at the same time on the > same machine. There is no decision in time. > > Some decision happens at packet based on IP destination address. > >> The question however is whether the preceding steps involve the >> application, so that one may question whether the entire DMM solution >> (with all the steps) as a whole is transparent. > > I agree. I am not aware of any application which talks to Mobile IP. > Whenever it is there it is 'transparent'. > >> So the intention of the requirement is that WHEN/AFTER the decision is >> made to invoke mobility support, then the mobility support is >> transparent to the application. Then we may want to check and make >> sure the emphasis of this requirement does mean transparency in this >> respect only. > > I disagree. > > As I said above, the word 'transparency' is dubious. Some times it may mean > 'non-existent', some times it may mean light goes through it but modified. > > If one wants to continue using it, then one should better qualify it with > 'Mobile Host', with 'Upper Layers' and with 'BSD Socket Interface'. > > Because a Mobile Router doing mobility management in a transparent manner on > the Mobile Router for the LFN has nothing to do with applications, neither > with upper layers. > > Also, a Mobile Router doing NAT and Mobile IP at the same time is > 50%-transparent. > >> >> Original wording: >> >> 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, > ^on a Mobile Host. >> upon change of point of attachment to the network, an application flow >> cannot cope with a change in the IP address. > > (it's not the application flow, it is a socket which some times may break > [paste here the error from the screen]; the term 'application flow' in this > context has little meaning) > > (an 'application flow' has no understandable meaning in practice). > >> However, it is not always necessary to maintain a stable home IP >> address or prefix for every application or at all times for a mobile >> node. > ^a Mobile Host. > > I agree. > >> I now tend to think the first sentence in this original wording may >> steer the emphasis on providing transparent support, which is not what >> the motivation and the problems are talking about. > > I agree. > >> The motivation and the problems are talking about when they are not >> needed. The emphasis of this requirement therefore is on the >> capability to turn OFF unnecessary mobility support. > > In a sense I agree with the meaning. > > But when trying to turn off or on mobility support the things are not like if > there were a knob on/off, not even like starting/stopping some daemon. It is > a matter of always having the Mobile IP support on, and tweak the routing > table with some particular entries, and the firewalling rules to NAT some > addresses or not. > >> How about the following >> >> REQ2: Network-layer mobility support ONLY when needed > > If we understood better when it was needed... > >> DMM solutions MUST NOT provide network-layer mobility support when NOT >> needed. > > I would say that Mobile IP MUST always be turned on on a Mobile Host. > >> (or if you don't like double negatives: (DMM solutions MUST provide >> network-layer mobility support ONLY when needed) > > No, I would say to have it always on. If some applications don't want it > then dont use it; realize that by inserting routing table entries. > > One may wonder when some applications dont want it. One answer is when some > applications prefer to not go through the HA in order to take advantage of > the 4G pure speed. When? For example if the HA link is too slow compared to > 4G. (remark this is not the same as saying that the triangular route is > longer than straight, because that is always true). > > This is not a request for Route Optimization. It is an invitation to analyze > in deeper detail the application needs. > > One may have an application start via the HA (offer reachability) and > continue straight, w/o HA. It's the same application. > > Consider a video-call like appli: you want to be reachable always at the same > IP address (through HA) but once the session is ongoing you may not want to > use it through HA if no handover in sight. > > Something like that. > > These things could be further refined if we really went into detail and > understood what are the needs of applications, the distinctions MH-MR, etc. > >> Such transparent mobility support above the IP layer is needed, for >> example, when, upon change of point of attachment to the network, an >> application flow cannot cope with a change in the IP address. >> However, it is not always necessary to maintain a stable home IP >> address or prefix for every application or at all times for a mobile >> node. > > A Mobile Host never maintains a stable prefix, only a stable address. > > A Mobile Router may maintain a stable address (its HoA) and may maintain a > stable prefix (its MNP). It could also just maintain stable just its MNP, > but not its HoA; and vice-versa. Is that mobility? > > For each of these there is an application :-) > > Alex > >> >> Any comments/changes/corrections? >> >> H Anthony Chan >> >> -----Original Message----- From: dmm [mailto:[email protected]] On >> Behalf Of Alexandru Petrescu Sent: Tuesday, January 28, 2014 8:43 AM >> To: [email protected] Subject: Re: [DMM] AD Evaluation: >> draft-ietf-dmm-requirements >> >> Le 28/01/2014 02:45, h chan a écrit : >>> I will drop "related" >>> >>> Regarding the following >>> >>> 5. Section 5: - I am a little confused by REQ2. It says that a DMM >>> solution should be transparent to the applications. >> >> This remark is typically true when we talk Mobile IP on a Mobile Host >> and an application like firefox runs above a BSD Socket interface. >> >> >>> However, the motivation talks about identifying applications that do >>> (or do not) need mobility support from the network layer. That >>> doesn't sound transparent to me. Am I reading this incorrectly? >>> >>> It appears that unless the network can find out whether the >>> application has need of such support, the application indeed may need >>> to invoke mobility support or has to convey its need to the network. >>> >>> The emphasis of requirement is on "when needed." So, I think it is >>> better to drop the word "transparent" as follows: >>> >>> REQ2: Mobility support when needed >>> >>> DMM solutions MUST provide mobility support to above the IP layer >>> when needed. Such support is needed, for example, when, upon change >>> of point of attachment to the network, an application flow cannot >>> cope with a change in the IP address. However, it is not always >>> necessary to maintain a stable home IP address or prefix for every >>> application or at all times for a mobile node. >>> >>> Motivation: The motivation of this requirement is to enable more >>> efficient routing and more efficient use of network resources by >>> selecting an IP address or prefix according to whether mobility >>> support is needed and by not maintaining context at the mobility >>> anchor when there is no such need. >> >> Whenever we discuss this 'transparency' paragraph I have again the >> same comments. >> >> First, I am not sure DMM is only about Mobile Hosts, or about Mobile >> Routers as well. >> >> Because, if we talk Mobile Routers, then rarely an application runs >> directly on it. Most applications would run on LFN. >> >> Transparency? >> >> If the applications run on the LFN, the change of the attachment of >> the MR is 'transparent' to them, regardless whether or not MR does >> something to maintain stability of that address (Mobile IP, other). >> >> Second, this transparency may depend on the direction, or more complex >> 'shape' of the application flows. Some IP flows of some applications >> have very complex 'shapes', with various sets of IP src and dst, and >> triangular or HA-less shapes. >> >> Take for example a video-call. The session establishment through an >> intermediary and behind NAT is followed by the ongoing 4 flows (2 >> audio 2 video)... they all take different paths... each may need or >> not need to go through the HA, and each has distinct behaviours when >> the IP address changes, hence each would have a distinct >> 'transparency' requirement. Is this _one_ application? >> >> Alex >> >>> >>> H Anthony Chan >>> >>> -----Original Message----- From: dmm [mailto:[email protected]] >>> On Behalf Of Brian Haberman Sent: Monday, January 27, 2014 7:20 AM >>> To: h chan; [email protected]; >>> [email protected]; Peter McCann Subject: Re: [DMM] AD Evaluation: >>> draft-ietf-dmm-requirements >>> >>> >>> >>> On 1/24/14 7:38 PM, h chan wrote: >>>> 4. Section 4: - I am not sure that it benefits the document to label >>>> PS6 and PS7 as related. Those issues are problematic on their own. >>>> If you remove the "(related problem)" label from them, make sure >>>> that REQ2 is updated to remove mention of "related problem". >>>> >>>> The intention of the name "related problems" was not to suggest they >>>> are less problematic, but rather to distinguish them from the other >>>> problems directly on mobility management. Although these problems >>>> are not directly on mobility management, the DMM solutions can solve >>>> these additional problems. They are therefore included. So, as long >>>> as this section is not to be interpreted as limited to problems >>>> directly on mobility management, we can drop the word "related." >>>> >>> >>> I will leave it to the authors/WG, but I don't see a benefit to the >>> "related" tag. >>> >>> Regards, Brian >>> >>> _______________________________________________ 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 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
