Let me explain why I picked the use of SHALL and SHOULD in this draft: REQ-1 and REQ-2 are requirements of distributed mobility management. They address relevant problems in centralized deployment, which are the reasons for the dmm work. If the solutions does not meet these requirements, they probably may not qualify as a dmm solution.
The rest of the requirements: REQ-3, REQ-4, REQ-5, REQ-6 are requirements not limited to dmm but are needed in any mobility management. Yet I do not know whether the dmm proposals submitted by various people so far can meet all these requirements. I do not know even if every existing centralized mobility management protocols meet all these requirements. If we insist on using SHALL, we will not be able to name any of them as a mobility management solution if that solution fails any one of them. So I guess the use of these later requirements is not to disqualify these solutions, but to enable the user to tell whether which solution meets or does not meet each requirement. Therefore I think that the use of SHOULD is sufficient. H Anthony Chan -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of h chan Sent: Friday, June 08, 2012 1:00 AM To: Charles E. Perkins; Peter McCann Cc: [email protected]; Behcet Sarikaya Subject: Re: [DMM] draft requirement discussions A draft of the requirement capturing all the requirements so far together with the problem statements has been uploaded: http://www.ietf.org/id/draft-chan-dmm-requirements-01.txt The following is an explanation of how it is structured. Out of the large number of problem statements, Session 4 on problem statement listed 5 of them as relevant problems. In Session 5 on requirements, the first 2 requirements address all the relevant problems. They distinguish dmm from the existing centralized deployments. So I think they are the key requirements. They both use "SHALL" The remaining requirements are not owing to problem statements with existing centralized deployments. So I suggest to use the "SHALL" very sparingly. Else we may not be able to call even some existing mobility protocols a mobility management solution lest they meet all the "SHALL" requirements. H Anthony Chan -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Charles E. Perkins Sent: Thursday, June 07, 2012 4:52 PM To: Peter McCann Cc: [email protected]; Behcet Sarikaya Subject: Re: [DMM] draft requirement discussions Hello Pete, Yes, I am fine with that revision and the new proposed text. I was more worried about the seeming suggestion that the DMM requirement was to interwork with any arbitrary security mechanism. But, as I mentioned, I think we are pretty close. Regards, Charlie P. On 6/7/2012 1:53 PM, Peter McCann wrote: > I thought the new text from Anthony was an attempt to answer your > comment, Charles. For instance, he removed the text that said, > "should not be considered the default." Are you ok with his new > proposed text? If not, can you propose text that you would like? > > -Pete > > Charles E. Perkins wrote: >> Hello folks, >> >> It seems to me that we may be perhaps arriving at a good point for a >> new draft. >> However, there are still some points of discussion that are perhaps >> worthy to be resolved (for example, in my email earlier this week). >> >> Maybe we should fire up the issue tracker...? >> >> Regards, >> Charlie P. >> >> >> On 6/7/2012 12:04 PM, Behcet Sarikaya wrote: >> >> Hi Jouni, >> >> What are the plans on DMM requirements? I see lots of mails and never >> ending discussions. >> >> Isn't it the time to get the draft out, thank Anthony for his hard >> work and move on? >> >> Regards, >> >> Behcet >> >> >> On Wed, Jun 6, 2012 at 11:32 AM, h chan <[email protected]> >> wrote: >> >> >> Yes, the second and third sentences are not additional >> requirements, >> but rather explanations of the requirement in the first sentence. Does >> the rewrite sound better now: >> >> >> >> REQ-2: Transparency to Upper Layers >> >> The DMM solutions SHALL provide transparency above the IP layer >> when >> needed. Such transparency is needed, when the mobile hosts or entire >> mobile networks change their point of attachment to the Internet, for >> the application flows that cannot cope with a change of IP address. >> Otherwise the support to maintain a stable home IP address or prefix >> during handover may be declined. >> >> >> >> H Anthony Chan >> >> >> >> From: [email protected] [mailto:[email protected]] >> Sent: Wednesday, June 06, 2012 12:56 AM >> To: h chan >> Cc: [email protected]; [email protected]; jouni korhonen; Peter >> McCann >> Subject: 答复: Re: [DMM] draft requirement REQ-2: >> Transparency to Upper Layers >> >> >> >> >> Hi Anthony: >> >> The last part of the sentence (i.e. but the need to maintain a >> stable home IP address or prefix SHOULD NOT be taken as >> default.) seems a littel strange to me. REQ-2 just describes under >> what circumstances the transparency is needed (i.e. when the mobile >> hosts or entire mobile networks change their point of attachment to >> the Internet, for the application flows that cannot cope with a change >> of IP address), that means automatically, otherwise the transparency >> is not needed. So why bother to write the last part of the sentence？ >> >> Besides, when mobile node attaches to its home network, it will >> obviously get a home IP address/prefix from its home network. The IP >> address/prefix can be considered as stable IP, as long as the mobile >> does not change its point of attachment. The last part of the sentence >> will just exclude this scenario. >> >> If I make any mistake, please correct me. >> >> Thanks >> Luowen >> >> >> >> >> >> h chan <[email protected]> >> 发 件人: [email protected] >> >> 2012/06/06 01:12 >> >> 收件人 >> >> "[email protected]" <[email protected]>, Peter McCann <[email protected]>, >> jouni korhonen <[email protected]> >> >> 抄送 >> >> >> >> 主题 >> >> Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers >> >> >> >> >> >> >> >> >> >> >> Revise as follows: >> >> REQ-2: Transparency to Upper Layers >> The DMM solutions SHALL provide transparency above the IP layer >> when >> needed. Such transparency is needed, when the mobile hosts or entire >> mobile networks change their point of attachment to the Internet, for >> the application flows that cannot cope with a change of IP address, >> but the need to maintain a stable home IP address or prefix SHOULD NOT >> be taken as default. >> REQ-2M (Motivation for REQ-2) >> The goal of this requirement is to enable more efficient use of >> network resources and more efficient routing by not maintaining a >> stable IP home IP address when there is no such need. >> >> H Anthony Chan >> >> >> -----Original Message----- From: >> [email protected] >> [mailto:[email protected]] On Behalf Of h chan Sent: >> Wednesday, May >> 23, 2012 7:51 PM To: Peter McCann; jouni korhonen >> Cc: [email protected] >> Subject: Re: [DMM] draft requirement REQ-2: Transparency to >> Upper >> Layers >> >> An attempt to clean up the text so far: >> >> REQ-2: Transparency to Upper Layers >> The DMM solutions SHALL provide transparency above the IP layer >> when >> needed. Such transparency is needed, when the mobile hosts or entire >> mobile networks change their point of attachment to the Internet, for >> the application flows that cannot cope with a change of IP address, >> but SHOULD NOT be taken as the default behavior. >> >> REQ-2M (Motivation for REQ-2) >> The goal of this requirement is to enable more efficient use of >> network resources and more efficient routing when mobility support is >> implemented by not invoking it for the application flows and nodes >> that do not need it. >> >> RELEVANT problem: PS5: Wasting resources to >> support mobile nodes not >> needing mobility support IP mobility support is not always >> required. >> For example, some applications do not need a stable IP address during >> handover, i.e. IP session continuity. Sometimes, the entire >> application session runs while the terminal does not change the point of >> attachment. >> In these situations that do not require IP mobility support, network >> resources are wasted when including additional info to the mobility >> context to support the change the point of attachment. Network >> resources are also wasted when the via routes are set up for many MNs that >> do not >> require IP mobility support. OTHER related problem >> O-PS1: Mobility >> signaling overhead with peer-to-peer communication While mobility >> management enables a mobile host to be reachable, the hosts may then >> communicate directly so that the mobility support is no longer needed. >> Taking the need of mobility support as the default behavior will waste >> network resources. O-PS2: Lack of user-centricity >> Centralized >> deployment compared with distributed mobility management may be less >> capable to support user-centricity. Example in the lack of >> user-centricity is to provide mobility support to all mobile nodes by >> default regardless of whether the user needs it or not. >> >> H Anthony Chan >> >> -----Original Message----- From: Peter McCann >> Sent: Friday, May >> 18, 2012 9:35 AM To: jouni korhonen; h chan Cc: >> [email protected] >> Subject: RE: [DMM] draft requirement REQ-2: Transparency to >> Upper >> Layers >> >> Hi, Jouni, >> >> jouni korhonen wrote: > > Few >> comments/questions here: > > On >> May 7, 2012, at 8:58 PM, h chan wrote: > >> >> REQ-2: Transparency to >> Upper Layers >> The DMM solutions SHALL enable transparency >> above the >> IP layer. Such >> transparency is needed for the application >> flows >> that cannot cope with >> a change of IP address and when >> mobile hosts >> or entire mobile networks >> change their point of attachment to >> the >> Internet, but SHOULD NOT be >> taken as the default behavior. >> > > >> "SHALL enable" but "SHOULD NOT be taken as the default behavior" seem >> > to conflict. So, what is really meant here? Does this mean >> something >> > like "MUST implement, SHOULD use" type of solution? Or can >> one leave >> > transparency completely away if the applications/hosts just >> don't >> care > whether IP changes or not? >> >> I think the latter. If the applications don't care about >> transparency, then we don't need to pay for it with state and >> signaling in the network. >> >> However, we know that some applications do care, so it SHALL be >> possible to provide it. >> >> >> REQ-2M (Motivation for REQ-2) >> The goal of >> this requirement is >> to >> enable more efficient use of network resources and more >> efficient >> routing by not invoking mobility support when there >> is no >> such need. > > Does this still mean the mobility >> support must be >> implement even if it > is not used? >> >> We need some strategy for keeping an IP address through some >> amount of >> mobility. However, we needn't optimize the network for this >> case as >> it might be rather uncommon to keep an address for a very long >> period >> of time. >> >> >> RELEVANT problem: >> PS5: Wasting resources to >> support mobile >> nodes not needing mobility >> support IP mobility support is not >> always required. For example, >> some >> >> applications do not need a >> stable IP address during handover, i.e. IP >> session continuity. >> Sometimes, the entire application session runs >> while the >> terminal >> does not change the point of attachment. In these >> situations >> that >> do not require IP mobility support, network resources >> are >> wasted >> when mobility context is set up. Network resources are also >> >> wasted >> when the via routes are set up for many MNs that do not require >> >> IP >> mobility support. >> >> OTHER related problem >> >> O-PS1: Mobility >> signaling overhead with peer-to-peer communication >> While >> mobility >> management enables a mobile host to be reachable, the >> >> hosts may >> then communicate directly so that the mobility support is no >> >> longer >> needed. Taking the need of mobility support as the default >> >> behavior >> will waste network resources. >> O-PS2: Lack of >> user-centricity >> >> Centralized deployment compared with distributed mobility management >> >> may be less capable to support user-centricity. Example in >> the lack >> of >> user-centricity is to provide mobility support to all mobile >> nodes by >> default regardless of whether the user needs it or >> not. >> > > I have issues to parse O-PS2.. the motivation >> makes sense though >> but > the title "lack of user-centricity" is somewhat confusing.. >> what >> does > forced/always-on mobility support has to do with user >> centricity? >> >> I think Anthony just meant that we should tailor the mobility >> management to the needs of the user. I wouldn't mind seeing this >> explanatory text re-worded. >> >> -Pete >> >> > > - Jouni > > >> >> >> (The above has been drafted with >> contributions, inputs and discussions >> from various people. >> Additional contributions and comments are most >> welcome.) >> >> >> >> H Anthony Chan >> >> >> >> _______________________________________________ >> 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 >> _______________________________________________ >> 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 >> >> >> > > -- Regards, Charlie P. _______________________________________________ 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
