Subject: RE: [mobile-ip] NAI/need for identifiers

From: "Glenn Morrow" <[email-masked]>
Date: Wed, 16 May 2001 09:07:03 -0500

100% Correct - the proper way of thinking about this is derived from these
requirements. Thanks for making these points.

Glenn

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, May 16, 2001 3:36 AM
To: [email-masked]
Subject: [mobile-ip] NAI/need for identifiers

HI, (My first mail on an IETF list so I know I have done something wrong.)

This is a cry of confusion from an employee of a "large" Norwegian operator.

Could you please explain to me how the NAI, other identifiers and the IP
address are used to  meet the following requirements (which I jotted down
very quickly):

The required separate identifiers for service provisioning are as follows:
·	Subscription
·	User
·	Terminal
·	Session
All four are required, and it is yet unclear to me how this is solved. These
identifiers are needed to accommodate e.g. security and the following three
levels of mobility:
User mobility (i.e. the user can freely move between different terminals as
long as authorised to do so)
Terminal mobility (i.e. the terminal is allowed to change access point/point
of attachment within the given level of authorisation)
Service mobility (i.e. a authorised user may access, possibly personalised,
services from any point of attachment)
The identifiers are also required to allow operators to maintain the
following bindings:
·	Session <-> terminal (e.g. for charging record)
·	Terminal <-> user <-> subscription
·	Terminal <-> subscription (i.e. computer to "computer"
communications)
·	User <-> services

For reasons of number portability and competition it has to be possible to
change the subscription without changing any of the other identifiers. It
also has to be possible for users (and terminals) to be member of more
subscriptions at the same time. (I.e. the above bindings or relations are
many to many.)

Inge
--------------------------------------------
Inge Grønbæk
Telenor FoU
Postboks 83,
2027 Kjeller, Norway
Phone (DDI): (+47) 63 84 88 57,
(mobile): (+47) 91 88 17 77.
Telefax.: (+47) 63 81 00 76.
E-mail: [email-masked]

---

From: [email-masked]
Date: Wed, 16 May 2001 10:21:58 -0500

Inge,
Thanks for the service providers  perspective. Can you explain a little further
how you physically see this connection used by your customers?

For example, I have worked to requirements of multiple simultaneous terminals
behind a single subscription ID  in a bridging and gateway end customer
environments with consumer access devices like cable, DSL or BWA (fixed
wireless) modems. The subscriber's access connection is fixed but there can be a
subscriber Ethernet or USB LAN behind it with one "modem" gating all
transmission of LAN-ISP subscriber data. In those access technologies there are
also internal PC modems with multiple simultaneous sessions on a single
terminal. In all cases, there is still a concept of primary access terminal or
connection device.

My question is, as a service provider, do you see this market offering portable
gateways that have some well-defined customer interface like 10/100 Ethernet or
USB? If so, should there be a requirement for the portable gateway device to
have bridging or forwarding characteristics? Should a primary connection device
pass any attached device's data transparently? Should it frame the traffic?
Should all devices make their own framed connection?
Jack

[email-masked] on 05/16/2001 03:35:32 AM

Please respond to [email-masked]

Sent by:  [email-masked]

To:   [email-masked]
cc:    (Jack Fijolek/MW/US/3Com)
Subject:  [mobile-ip] NAI/need for identifiers

Inge

---

From: "Glenn Morrow" <[email-masked]>
Date: Wed, 16 May 2001 10:48:42 -0500

GM] Here is my shot at an answer:

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, May 16, 2001 3:36 AM
To: [email-masked]
Subject: [mobile-ip] NAI/need for identifiers

GM] I believe this confusion has been caused by the choice of terminology in
some of the MIP standards.

·	Subscription

GM] We need a separate id for subscription. The NAI can be used as a general
format to represent the subscription.

·	User

GM] This concept is for applications such as: SIP,H.323,IM, etc.. A network
layer-based node mobility solution can not solve the more complex user
mobility functions.

·	Terminal

GM] The MAC address identifies the node or NIC of the node. The mobile may
have many IP addresses (both multiple home and COAs). We need another
explicit field to indicate the MAC address and MAC technology for
blacklisting. I would use a generic term such as device.

·	Session

GM] The binding id can serve as the session for the network layer  service.
The applications will also have separate session ids.

GM] We have to be careful here. The service parameters related to the
functions of the network layer (ex max default bandwidth) need to be handled
in a node mobility solution. There is a little work to do at the network
layer for this. I would call this network layer service mobility.

GM]The service information related to applications should be conveyed with
the application. It must be noted that the applications must be able to
override the default service information of the network layer. This means
that some application to network layer interface must be developed to
provide this override and correlation for accounting. I would call this
application layer service mobility. The session belongs in this interface.

For reasons of number portability and competition it has to be possible to
change the subscription without changing any of the other identifiers.

GM] Yes, indeed. Thank You. I try to generalize this with the term provider
portability or mobility. Another aspect of this is when an employee changes
employers yet wishes to keep the same user identifiers and device. The
subscriber (person who pays - in this case the employer) changes. This
functionality can also be handled via the decoupling of subscription as
well.

It also has to be possible for users (and terminals) to be member of more
subscriptions at the same time. (I.e. the above bindings or relations are
many to many.)

GM] Yes, indeed. Thank You.

GM] I would like to add one more - the subscription(s) for the network
service may be different from the application service. They can also be the
same.

GM] Once again, Thank You for bringing up these points.

Glenn

---

From: "Glenn Morrow" <[email-masked]>
Date: Wed, 16 May 2001 11:15:31 -0500

Are you asking if there is a market for a mobile L2 hub/switch or router?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, May 16, 2001 10:22 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mobile-ip] NAI/need for identifiers

Inge,
Thanks for the service providers  perspective. Can you explain a little
further
how you physically see this connection used by your customers?

For example, I have worked to requirements of multiple simultaneous
terminals
behind a single subscription ID  in a bridging and gateway end customer
environments with consumer access devices like cable, DSL or BWA (fixed
wireless) modems. The subscriber's access connection is fixed but there can
be a
subscriber Ethernet or USB LAN behind it with one "modem" gating all
transmission of LAN-ISP subscriber data. In those access technologies there
are
also internal PC modems with multiple simultaneous sessions on a single
terminal. In all cases, there is still a concept of primary access terminal
or
connection device.

My question is, as a service provider, do you see this market offering
portable
gateways that have some well-defined customer interface like 10/100 Ethernet
or
USB? If so, should there be a requirement for the portable gateway device to
have bridging or forwarding characteristics? Should a primary connection
device
pass any attached device's data transparently? Should it frame the traffic?
Should all devices make their own framed connection?
Jack

---

From: Phil Roberts <[email-masked]>
Date: Wed, 16 May 2001 14:23:12 -0400

Hi Inge,

 questions and comments inline.  Hope they help.

Phil

> Sent: Wednesday, May 16, 2001 4:36 AM

No, it's a fine first attempt.  I'm not sure this mailing list is the
correct place to discuss all of these issues, but I'm not sure where to
suggest you take them.
> address are used to  meet the following requirements (which I 

Could you let us know where these requirements come from?  Are these
requirements for services your company wants to provide or from some SDO or
from your own ideas about the way services should be provided?

> subscriptions at the same time. (I.e. the above bindings or 

I'm not sure I understand everything you want to do, but I think it's safe
to say that MIP is a solution for terminal mobility.  It is a protocol for
delivering packets to the correct destination when that destination is
moving.  You asked about the use of the NAI.  The NAI extension is there to
allow users to identify themselves for the purpose of AAA authorization (and
also home address assignment).

It's not currently within our charter to tackle issues such as user to
device bindings and service provisioning and it would probably be hard to
convince me that this work would belong in this working group.

---

From: [email-masked]
Date: Wed, 16 May 2001 16:11:11 -0500

Glenn,
IMHO,  the requirements implied support for multiple "simultaneously active"
terminal devices per mobile subscriber at the same location. I am trying to
understand the bounds on the physical connection support being asked for.
Jack

"Glenn Morrow" <[email-masked]> on 05/16/2001 11:15:31 AM

Sent by:  "Glenn Morrow" <[email-masked]>

To:   [email-masked]
cc:    (Jack Fijolek/MW/US/3Com)
Subject:  RE: [mobile-ip] NAI/need for identifiers

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, May 16, 2001 10:22 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mobile-ip] NAI/need for identifiers

Inge,

---

From: "Glenn Morrow" <[email-masked]>
Date: Thu, 17 May 2001 09:24:37 -0500

Arthur, you really should do that informational draft. I think Inge is
trying to help with some real requirements.

-----Original Message-----
From: Arthur Ross [mailto:[email-masked]]
Sent: Wednesday, May 16, 2001 11:47 AM
To: [email-masked]
Subject: Re: [mobile-ip] NAI/need for identifiers

At 1:35 -0700 05/16/2001, [email-masked] wrote: 

>levels of mobility: 

[snip] 

Once again, this thread is nibbling around the edges of a much larger, very
important discussion. 

My apologies to those of you who have already seen this from my prior
posting to the SEAMOBY list, but it is germane to this thread too. 

<RANT> 

We talk at great length about hosts, mobile nodes, etc., but the notion of
"host" or "node" is getting fuzzy. Originally [ARPANET] "hosts" were big 

computers that filled rooms, had squads of people caring for & feeding them,
and the protocols were designed with that implicit mindset. But nowadays,
when the 

embodiments of the "hosts" may cost just pennies, may be flyspeck-sized, and
may 

be found in all sorts of non-traditional, often low-tech kinds of
places/things, 

the concepts need revision. 

My strong feeling is that the questions to be addressed should be things
like: 

* What are the entities that are the endpoints of the communication? When 

the address space is large enough [IPv6] to give every cell of every human 

being and every grain of sand on earth its own IP address, perhaps the 

model and uses of it need to be re-thought. 

* What is MEANT by "mobility"? Or alternatively what is it that is moving? 

I can envision many possible answers/opinions. 

* How are those endpoints identified for various purposes? A major example: 

paging - IP address, as in MIP, is [perhaps] meaningful for routing 

purposes, but meaningless in the application context. One could envision 

a concept whereby there are various "views" of the endpoint space 

applicable for different sorts of applications (e.g. routing, logical, 

name-based, geographic, organizational hierarchy, demographic group, 

etc.). In this light, paging/addressing might be viewed/implemented 

as a kind of distributed database query. 

* What is the nature of the "identity" associated with, say, individual 

humans, that provides the basis/data for authentication? I'm thinking 

of something like a great-grandson of the SIM card concept, for example 

[... or maybe you will begin every session with a request to "spit in the 

little spitoon" on your laptop for the DNA analysis that authenticates 

the session. ;-) ]. 

* Is a broader concept of the "addressable individual" needed? [I have in 

mind functional pseudo-persons, associated with business & organization 

roles, databases of various kinds, etc.] 

* Is a "discovery" functionality needed? I.e. a generic method for exposing 

the internal structure of subnets and/or databases? I.e. a way of creating 

the local streetmap of an unfamiliar neighborhood? This might be especially 

important if the "mobile" entities have internal, time-varying structure 

[think, for a simple example, of folks in vehicles on the highway, each 

potentially with his PDA, phone, medical monitoring device, plus the 

"smart car" itself, etc., all of which are communicating through a 

wireless gateway of some kind; just such things are currently under 

development]. 

* What are the business and regulatory models? Giant electro-political 

hot potato, but very important, IMHO. The regulatory folks need to clean 

up their act if the mythical "wireless Internet" is to be anything other 

than hype and snake oil. 

I have in mind here a complete re-think of the spectrum license auction 

notion. I personally believe that auctioning the ether was, and still is, 

a bad idea, not in the long term public interest. The pro-auction 

argument is that real estate-like ownership is a prerequisite if 

investors are going to pony up the huge capital expenditures needed to 

build the "next generation" networks. The fallacy here, IMHO, is the 

PSTN-centric mindset. If what you are talking about is universal, 

readily-available wirless IP service, starting from a telephone network 

is very obviously a bad way of doing it. IMHO wireless IP access 

should be viewed, for regulatory purposes, as more like a public utility 

than the proverbial "walled garden" for which the owner charges at the 

tollbooth. You could make a lot of money by letting someone charge for the 

air we breathe too, but in neither case is it good public policy. 

There are many aspects to this, and many ways of pulling it off, as I 

have tried to convince the FCC for some time now. 

* What replaces the "walled garden" wireless air interfaces? Good question. 

I have some opinions as to what it MIGHT be, but other opinions may 

[read: "undoubtedly will"] differ. This will be, I hope, the subject of 

this new "wireless internet" discussion group. 

</RANT>