Subject: Re: [seamoby] some issues on the ct draft

From: James Kempf <[email-masked]>
Date: Thu, 22 Feb 2001 09:45:14 -0800 (PST)

Sharif,

>2. I would like to bring up the PDP-context as deployed in GPRS networks.
>Since, this network is commercially used today and forms over 80 percent of
>the world's mobile packet network, I don't think we should ignore it. Thus,
>I will send you some text on the activation and transfer of PDP-context as
>an example of what's deployed today.
>

I do not believe IETF should get into specifying standards for technologies
that other SDOs control. Therefore, I do not think there should be
any mention of GPRS in a context transfer protocol for IETF.

That said, I agree that some accommodation needs to be made for
transfering unspecified context. I did some work last year
on transferring radio channel context for an IP replacement to
the IS-41 hard handover messages, and it required such support.
The work never went anywhere but it illustrated to me the need for
such support. 

		jak

---

From: "Shahrier, Sharif M." <[email-masked]>
Date: Thu, 22 Feb 2001 13:35:16 -0500

Henrik,

> an example of what's deployed today.

Did you have comments on this? I had some comments from James. I would like
to add a paragraph in the introduction.

---

From: "Shahrier, Sharif M." <[email-masked]>
Date: Thu, 22 Feb 2001 13:11:50 -0500

James,

I did not impy that IETF should incorporate any part of the GPRS methodology
into the IP context transfer protocol. I simply stated that somewhere (in
the introduction) a mention should be made of the PDP context transfer
scheme. I believe that it should be mentioned and perhaps some articles
referenced because it is predominantly deployed today. As currently defined,
GPRS lies below IP layer.

Sharif Shahrier

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Thursday, February 22, 2001 12:45 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]
Subject: Re: [seamoby] some issues on the ct draft

Sharif,

		jak

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Thu, 22 Feb 2001 19:44:18 -0000

> any mention of GPRS in a context transfer protocol for IETF.

Another good reason is that, what I understand the intent
of seamoby is, the ctxt transfer is a functionality at the IP level,
which is supported by access points that typically don't have 
to open dialogues with an HLR,
like the SGSN where the GPRS ctxt transfer happens. 

alessio

---

From: Kulwinder Atwal <[email-masked]>
Date: Thu, 22 Feb 2001 17:00:57 -0500

What technologies will it work across?

- Kulwinder.

> From: Shahrier, Sharif M. [mailto:[email-masked]]
> Sent: Thursday, February 22, 2001 4:56 PM
> To: 'Kulwinder Atwal'; Shahrier, Sharif M.; 'James Kempf';
> [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; Kiernan, Brian G.
> Subject: RE: [seamoby] some issues on the ct draft
> 
> 
> Kulwinder,
> 
> When I mention PDP-context in terms of GPRS, this is not L2. 
> It is its own
> sub-layer below the IP layer.
> 
> Sharif
> 
> From: Kulwinder Atwal [mailto:[email-masked]]
> Sent: Thursday, February 22, 2001 4:51 PM
> To: 'Shahrier, Sharif M.'; 'James Kempf'; [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; Kiernan, Brian G.
> Subject: RE: [seamoby] some issues on the ct draft
> 
> 
> We already have a 3G bias by mentioning 3G in the intro of 
> the Charter.  
> 
> A L2 context transfer may not work the same way as an L3 
> context transfer.
> What we should provide are the requirements of each 
> technology in terms of
> context transfer, and determine the best L3 approached from there.
> 
> Either you want L2 transfer, in which case you already have it in PDP
> context.
> Or, you want L3 transfer so that it will work across all technologies.
> 
> Maybe, in the requirements phase everyone could provide 
> references to the
> requirements of particular technologies.
> 
> 
> - Kulwinder.
> 
> > From: Shahrier, Sharif M. [mailto:[email-masked]]
> > Sent: Thursday, February 22, 2001 1:12 PM
> > To: 'James Kempf'; [email-masked]; Shahrier, Sharif M.
> > Cc: [email-masked]; [email-masked];
> > [email-masked]; Kiernan, Brian G.
> > Subject: RE: [seamoby] some issues on the ct draft
> > 
> > 
> > James,
> >

---

From: Kulwinder Atwal <[email-masked]>
Date: Thu, 22 Feb 2001 17:00:57 -0500

- Kulwinder.

---

From: Kulwinder Atwal <[email-masked]>
Date: Thu, 22 Feb 2001 21:09:28 -0500

I appologize if you are recieving multiple copies of my emails, we are
experiencing email problems.

- Kulwinder.

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 22 Feb 2001 22:31:02 -0500

Comments included:

> Sent: Thursday, February 22, 2001 11:29 AM
> To: 'Henrik Levkowetz'; Shahrier, Sharif M.
> Cc: Pat Calhoun; Kenward, Gary [WDLN2:AN10:EXCH];
> [email-masked]'; Shahrier, Sharif M.; Kiernan, Brian G.
> Subject: [seamoby] some issues on the ct draft
> 
> 
> Henrik,
> 
> I have read through the draft 
> "draft-ietf-seamoby-ct-problem-alpha06" (I was
> not sure if that was the one submitted for last call, in any 
> case it should
> be close to it). I would like to make some contributions to 
> it as follows.
> 
> 
> 1. In 3.2.1 and 3.2.2 security and header compression was 
> mentioned as 2
> examples of context. I would like to add 2 more, namely, QoS, 
> and IP address
> of (source/target). These are required by our mobility 
> management protocol
> draft which I will be submitting tomorrow.
> Of  course, people can add other parameters as well. I will 
> send you text to
> add as 3.2.3 and 3.2.4.

Address management is part of micromobility, not context
transfer. Ultimately, the micromobility and ct will have to be
rationalized and a coherent solution developed. But addressing
doesn't belong in the ct problem statement.

QoS is discussed enough.

> an example of what's deployed today.

PDP-context is a solution, and a solution for a specific, non-IP,
architecture.
You should submit an informational id on the application of PDP-context
solution to IP CT when we get into a discussion of ct solutions.

> 
> 3. On p. 12, 3.2.5 buffers are discussed. I would like to 
> expand this and
> add buffering methods for some different types of handover. I 
> will you send
> a short segment to add to that section.

Again, solution space. Not for the problem statement.

> 
> 4. Section 4.1.2 discuss mobile updating contexts, while 
> 4.1.3 discusses
> access routers 
> exchanging contexts. I would like to add a subsection that 
> discuss a hybrid
> combination of the two methods. We are studying such a method 
> ourselves for
> future work.

4.1.x are identified as incomplete examples. It was felt that
these were sufficient to map out what the solution space might be,
and that any additional detail would be venturing to far into the
actual solution space.

> 
> 5. 4.1.4: Central repository, I would like to add a con: not 
> fault-tolerant.
> This is a big issue for centralized systems.
> 
> Thank you, and I look forward to receiving some feedback.
> 
> Sharif Shahrier
> 

Thank you,
Gary

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 22 Feb 2001 22:52:44 -0500

The 3G bias was not intentional. I brought up this issue when
the charter was sprung on us before the last IETF meeting.
It was stated (and the email is probably in the seamoby archive
somewhere), that 3G was provided as an example only.

Seamoby is not 3G mobility.

Gary

> Cc: [email-masked]; Kenward, Gary [WDLN2:AN10:EXCH];

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 23 Feb 2001 10:20:26 -0600

Sharif,

I have not been up to date with the latest in GPRS, but as far as I know,
PDP context in GPRS contains data similar to the following:
-IP addresses for mobile
-IP addresses for the GPRS service nodes (GGSNs and SGSNs) to which the
mobile talks to
-The requested QoS

which are network layer info and covered in the context types in the draft.
If there are any other sub-network layer data, that are part of the PDP
context, they would fall into 3.2.6

In conclusion, so if there is any more CONCEPTUAL type of context that is
missin please let us know, otherwise:
I want to say, the goal of the draft was to descibe the problems associated
with context transfer and not to list every single type of context, or list
how to buffer these contexts, or even how to transfer these context types.
Examples of sub-network layer data are already given. 

Being in cellular business for quite a number of years, I have problems with
putting specific transitory technology (GPRS) inside a problem statement
that is laying the ground for systems (seamless mobility type) that would be
in the market after GRPS is dead. GPRS is just an attempt for cellular
providers to bring some short term revenue from data services before the 3G
systems roll out.

Regards,

Madjid 

-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: Thursday, February 22, 2001 12:12 PM
To: 'James Kempf'; [email-masked]; Shahrier, Sharif M.
Cc: [email-masked]; [email-masked];

James,

Sharif Shahrier

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Thursday, February 22, 2001 12:45 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked];

Sharif,

		jak

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 23 Feb 2001 10:28:04 -0600

<MN> Thank you.
Agreed, Going forward with seamoby and context transfer, we neither need nor
are able to deal with/ or change GPRS standards which are handled by  3GPP.

Madjid

---

From: "Shahrier, Sharif M." <[email-masked]>
Date: Mon, 26 Feb 2001 14:52:08 -0500

Madjid.,

I agree that IETF should be a wide open forum for exchange of differing
idea, and incoprporatin some of them into drafts, RFCs etc in line with the
wishes with all its perticipants. It should not be a vehicle for
stanardizing requirements, parameters, and technologies that people have in
their back pockets.

However with respect to GPRS, IIP and other technologies, it is useful to
either include a background section in a draft, or produce a separate
informational draft, so that we can review existing technologies; determine
how our protocols can interface and co-exist with what is out there. Trust
me, I have been to a number of 3GPP meetings where they are trying to come
up with an all-IP core network. Thay said they will use protocols from IETF
as building blocks. However, they have yet to determine how they would fit
in within their exisitng network (GSM/GPRS) infrastructure.

Thnak you.

Sharif Shahrier

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Friday, February 23, 2001 11:28 AM
To: 'James Kempf'; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [seamoby] some issues on the ct draft

<MN> Thank you.

Madjid

---

From: [email-masked]
Date: Tue, 27 Feb 2001 08:57:07 +0200

Hi Shahrier,

> in within their exisitng network (GSM/GPRS) infrastructure.

I believe that information drafts can be written to discuss
the applicability of a solution for a particular network
architecture.  I don't think we want to clutter up other
drafts with too much extraneous text.  However, I think that
when we come to the requirements stage, we should add requirements
from existing networks.  If you have such requirements, now
is the time to state them.

br,
John

---

From: "Shahrier, Sharif M." <[email-masked]>
Date: Tue, 27 Feb 2001 09:32:40 -0500

> 
> When we look at solutions we should review all proposed solutions,
> and if Sharif, or someone else wishes to introduce a PDP context
> based solution, then great. However, I fail to see how PDP context
> is any part of the requirements.

I was not endorsing PDP context transfer based solution for the seamoby
group, either. GPRS is the perdominant network that is deployed today, and
is endorsed by 3GPP, and all its prticipating companies. 3GPP are trying to
come up with an "all IP based mobile core network". In doing so, they were
hoping to take protocols that have already been developed by the IETF and
"reuse" then with the GPRS infrastructure. Thus, in this respect, I had
sggested that we either include a beckground section on GPRS and other
existing technologies, so that the WG had some understanding of the current
state of the art. Another alternative is to do a separate informational
document. 

I believe these steps should provide excellelent information to the WG, and
if neccessary I would be glad to volenteer to do some of this work.

Thanks,

Sharif

---

From: "Shahrier, Sharif M." <[email-masked]>
Date: Tue, 27 Feb 2001 09:22:47 -0500

John,

Why do we have to bring up the requirements issue now. From the past
opinions from this mailing-list, I understood that we should hold off the
requirements until the next phase.

Also, I did not receive your feedback on the other (important) things that I
pointed out in my comments.

Sharif

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, February 27, 2001 1:57 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [seamoby] some issues on the ct draft

Hi Shahrier,

br,
John

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 27 Feb 2001 15:55:47 -0600

Dear Sharif,

I would say, you are extremely welcome to write a separate information draft on 3GPP. It would be informational for all us, specially if you have a solution to co-exist with 3GPP's GPRS tunneling protocol (GTP).

I have been to 3GPP meetings myself. If 3GPP has decided to adopt IETF protocols, then good for them, that is what the rest of internet world is doing.  Personally, I also encourage them to use MobileIP/ seamoby solutions or adopt IETF's AAA, PKI and IKE solutions, but I leave that to the eminent experts in 3GPP forums. 

The goal is have a context transfer mechanism that provides seamless mobility regardless of the underlying access network technology.

Agreeing with Gary's comment, all of us in the design team were encouraged to add comments and text to the draft before its last call in the design team. Let's give the ball to the WG now. 

Besides, I agree with Michael, the more we beat this horse, the slower it gets on its way to the ADs. I suggest that we focus on getting the draft through its mid March deadline, since all the brilliant minds including yourself's have been patiently waiting for the requirement and solution phase. Let's get the poor horse going so we can start the more important work.

Madjid 
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: Monday, February 26, 2001 1:52 PM
To: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; [email-masked];
Shahrier, Sharif M.

Madjid.,

Thnak you.

Sharif Shahrier

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Friday, February 23, 2001 11:28 AM
To: 'James Kempf'; [email-masked];

<MN> Thank you.

Madjid