Subject: [DMM] Comments on REQ5 (Compatibility) of draft-ietf-dmm-requirements-02

From: [email-masked]
Date: Tue, 20 Nov 2012 10:33:00 +0800

Hi All,

I have a comment on REQ5:  Compatibility of 
draft-ietf-dmm-requirements-02. What is not clear to me is that the 
meaning of the terms "compatibility\compatible\interoperate\co-exist" is 
not specific. Here is my clearification as following based on the comment 
I provided in the last DMM session in Atlanta.

Consider the scenario which is illustrated in figure A & B: 
Assuming operator A has already deployed PMIP protocol in city A (blue 
area in both figures), and wants to deploy dmm enabled euqipment in a 
certain area of city A in incremental manner (green area in both figures). 
Operator A needs the dmm protocol enabled area to be 
compatible\interopertable to exsiting PMIP protocol enabled area.  Here, 
operator A may have different requirements in terms of 
compatible\interopertable which are illustrated in figure A and B 
respectively.

Figure A, consider as roaming scenario. Any mobile node, as long as it is 
a subscriber of operator A, can be attached to operator A's network in 
both blue and green areas. The mobile node can not see any difference. 
E.g. assuming mobile node is now in green area, powered on, and initial 
attachment is performed (be asigned with an IP@). Then the mobile node can 
access the service provided by operator A (internet access and etc.).  In 
"roaming" scenario, when mobile node leaves green area and enters into 
blue area, the mobile node may need to perform initial attachment 
percedure again (be asigned with another IP@) for the purpose of accessing 
operator A's service. In this case, session continuity may not guaranteed 
when mobile node moves between the green and blue areas (i.e. IP@ may 
change when mobile node moves accross the border of the green and blue 
area).

Figure B, consider as handover scenario which requires more than the 
roaming scenario. E.g. assuming mobile node is initialized in blue area 
(be asigned with an IP@) and enjoys session continuity support when it 
moves within the blue area. When the mobile node enters the green area, in 
this handover scenario, the session continuity for sessions which have 
already setup shall be maintained (i.e. keep IP@ unchanged). The same 
requirement may also be applied to the scenario that when the mobile node 
is initialized in green area and moves to blue area. 

What I suggest is that we should make the terms 
"compatibility\compatible\interoperate\co-exist" more specific. I suppose 
adding some usage cases or usage scenarios may help to understand REQ5 
better.

Any comments are welcome.

BR
LUOWEN

---

From: h chan <[email-masked]>
Date: Tue, 20 Nov 2012 16:52:09 +0000

Thanks for drawing the figure to explain your comments.

Let me try to understand by rephrasing in terms of a well-known cellular network analogy:

The blue area is GPRS. The green area is WCDMA
WCDMA can be deployed incrementally.

In your figure, the Green area is inside the blue area. So, the green area in your figure is WCDMA+GPRS

Figure B:
When a phone was in the GPRS only area, and move to an WCDMA+GPRS area. There was an option for "new session" to use WCDMA.  Yet the session with existing GPRS simply continues to use GPRS without breaking session continuity.

Figure A:
When a phone was in the WCDMA+GPRS area, and move to an GPRS only area:
If there was existing GPRS session prior to the move, the GPRS session continues.
If there was WCMDA session prior to the move, the WCDMA session was not supported outside the WCDMA session.

In the later case, you could in principle perform a handover from WCDMA to GPRS. Yet the data-rate could drop. You can only perform such a handover only if the data-rate performance allowed by GPRS can support that particular application session.

I would not go too far with compatibility that the user should see no difference. In this analogy, the user may see a difference in performance whether it is in WCDMA or GPRS network in terms of data rate etc, else there was no need for WCDMA.

H Anthony Chan

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 19, 2012 8:33 PM
To: [email-masked]; h chan
Subject: Comments on REQ5 (Compatibility) of draft-ietf-dmm-requirements-02

Hi All,

I have a comment on REQ5:  Compatibility of draft-ietf-dmm-requirements-02. What is not clear to me is that the meaning of the terms "compatibility\compatible\interoperate\co-exist" is not specific. Here is my clearification as following based on the comment I provided in the last DMM session in Atlanta.

Consider the scenario which is illustrated in figure A & B:
Assuming operator A has already deployed PMIP protocol in city A (blue area in both figures), and wants to deploy dmm enabled euqipment in a certain area of city A in incremental manner (green area in both figures). Operator A needs the dmm protocol enabled area to be compatible\interopertable to exsiting PMIP protocol enabled area.  Here, operator A may have different requirements in terms of compatible\interopertable which are illustrated in figure A and B respectively.

Figure A, consider as roaming scenario. Any mobile node, as long as it is a subscriber of operator A, can be attached to operator A's network in both blue and green areas. The mobile node can not see any difference. E.g. assuming mobile node is now in green area, powered on, and initial attachment is performed (be asigned with an IP@). Then the mobile node can access the service provided by operator A (internet access and etc.).  In "roaming" scenario, when mobile node leaves green area and enters into blue area, the mobile node may need to perform initial attachment percedure again (be asigned with another IP@) for the purpose of accessing operator A's service. In this case, session continuity may not guaranteed when mobile node moves between the green and blue areas (i.e. IP@ may change when mobile node moves accross the border of the green and blue area).

Figure B, consider as handover scenario which requires more than the roaming scenario. E.g. assuming mobile node is initialized in blue area (be asigned with an IP@) and enjoys session continuity support when it moves within the blue area. When the mobile node enters the green area, in this handover scenario, the session continuity for sessions which have already setup shall be maintained (i.e. keep IP@ unchanged). The same requirement may also be applied to the scenario that when the mobile node is initialized in green area and moves to blue area.

What I suggest is that we should make the terms "compatibility\compatible\interoperate\co-exist" more specific. I suppose adding some usage cases or usage scenarios may help to understand REQ5 better.

BR
LUOWEN