Subject: Re: [DNA] RE: Review of link-information from Pekka Savola

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Sun, 01 May 2005 15:22:25 +0300

[email-masked] wrote:
> Hi,
> 
> Some comments on the 3GPP part of this draft. I think the
> text should also mention that the PDP context creation can
> be network originated. Also at least since Release-99 it has
> been possible to create secondary PDP contexts and more than
> one primary PDP context. IMO those should be addresses.
> 
> In the case of secondary PDP context creation the MT has been
> configured with a functional IP address (including the IPv6 case).
> The IP address of the primary PDP context is assigned to
> secondary contexts.
> 
> For additional primary PDP contexts the MT is assigned a new
> additional IP address. Thus it is possible to receive link-up
> notification while already being able to send/receive IP packets
> through existing PDP contexts. Also vice versa for link-down
> notifications.
> 

Would it make sense to make each PDP context to look like an interface 
of its own?

/Tero

---

From: [email-masked]
Date: Mon, 02 May 2005 00:39:17 +0300

Tero,

Making each PDP context look like an interface of its own would probably
be ok -- at least for primary contexts. I don't know how that would fit
for the secondary contexts, where these secondary contexts share the
same IP address of their primary (i.e. the address is known and
functional).

Cheers,
	Jouni

> -----Original Message-----
> From: Tero Kauppinen (JO/LMF) [mailto:[email-masked]] 
> Sent: 1. toukokuuta 2005 15:22
> To: Korhonen, Jouni /TeliaSonera Finland Oyj
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [DNA] RE: Review of link-information from Pekka Savola
> 
> text should 
> > also mention that the PDP context creation can be network 
> originated. 
> > Also at least since Release-99 it has been possible to create 
> > secondary PDP contexts and more than one primary PDP context. IMO 
> > those should be addresses.
> > 
> > The IP address of the primary PDP context is assigned to secondary 
> > contexts.
> > 
> Would it make sense to make each PDP context to look like an 
> interface of its own?
> 
> /Tero
>

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Mon, 02 May 2005 10:23:11 +0200

> From: [email-masked] [mailto:[email-masked]]
> Sent: 2. toukokuuta 2005 7:07
> To: [email-masked]; Tero Kauppinen (JO/LMF)
> Subject: RE: [DNA] RE: Review of link-information from Pekka Savola
> 
> Jouni & Tero,
> 
> Some discussion of the relationship of primary & secondary PDP
contexts
> would be good.  Basically, they fate-share; so if something is
detected
> on a Primary PDP context, it would also be applicable for any of its
> Secondary PDP contexts.  That applies for Link UP and Link Down.
>
Jouni & John,

Sorry, this doesn't exactly fall under the topic but I just wanted to
write it down since we were talking about PDP contexts.

Actually while discussing this with Jari Arkko we started to think that
running DNA on an interface configuring an address from a PDP context is
unnecessary (e.g. a phone. On a laptop with a GPRS card the node still
runs pppd.). There is no need to question the address you get from the
context. If the address differs from the previous one then it just is
different and the node uses it.

The situation is different if you are running PPP with your phone (or
with a GPRS card) which is using a PDP context to configure the link. We
have previously seen (thanks to my foolish mails) that the laptop indeed
gets the address from a router advertisement. The laptop doesn't know
about the link technology below PPP and can't make any assumptions
regarding address changes. In that case DNA is required.

> John
Tero

---

From: [email-masked]
Date: Tue, 03 May 2005 08:32:09 +0300

Tero,

> How do these PDP contexts look alike from system point of view? On a
> phone the application can actually see different PDP contexts and can
> choose to use one for signaling and another for some other 
> purposes but
> how do they behave, for example, on a Linux machine? Does each PDP
> context map to one PPP connection thus resulting in multiple PPP
> connections?

A Linux machine cannot see the PDP context that has been setup by 
the phone.  If the phone has multiple PDP for applications running
on the phone, those are not available to a laptop, for example.

Phones running the Symbian OS have way of handling these multiple
PDP contexts; there are a number of other embedded operator systems
that handle these in a vendor specified manner.

So, I think we have two cases here:

1) Laptop case which uses PPP from the laptop, no open issues here,
   I think.
2) Phone application case: some issues here, I think.  

What I assume we want to do is "detect network attachment" on the links.  For
2G & 3G GPRS, the link is essentially a PDP context.  There are two types of 
PDP contexts, a Primary PDP Context and a Secondary PDP Context.   Secondary
PDP contexts get their IP address from the Primary PDP context.  

I have a general question for the WG, are we focusing on only the initial DNA
procedure or are we considering on-going DNA procedures?  By way of an example,
what I mean is that if you start a 2G GPRS session, you create a primary PDP
context, get an IPv6 address, potentially run DNA (maybe not in that order).  
However, there are many reasons why that PDP context might be interupted.
A normal voice call usually will pause the PDP context as most phones don't
support concurrent voice and data connections in 2G.  After the call ends,
you might want to run DNA again, to ensure that you have a network connection.
Likewise, if you go through a tunnel, you might lose the network connection,
so you probably want to run DNA when you come out of the tunnel.

Anyhow, if the above scenarios are of relevance to the WG, I can double check
on the correct PDP context terminalogy and references; then supply text.

John

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Tue, 03 May 2005 07:19:18 +0200

choose to use one for signaling and another for some other purposes but

/Tero

> From: Alper Yegin [mailto:[email-masked]]
> Sent: 3. toukokuuta 2005 2:56
> To: [email-masked]; [email-masked]; Tero
Kauppinen
> (JO/LMF)
> Cc: [email-masked]; [email-masked];
[email-masked]
> If the secondary PDP contexts share the same "IP configuration" as the
> primary one, couldn't we simply just look at the latter one to
generate
> L2 event notifications? Isn't this what matters in the context of DNA?
> 
> Alper
> 
> 
> > Sent: Sunday, May 01, 2005 9:07 PM
> > To: [email-masked]; [email-masked]

---

From: [email-masked]
Date: Tue, 03 May 2005 10:58:27 +0300

> context map to one PPP connection thus resulting in multiple PPP

I don't know of any GPRS cards that are currently supporting multiple
PDP contexts. If there were, I'd assume that each PPP connection would
be a primary PDP context, so that their would be no correlation between
any of them; each would have seperate IP addresses.

John

---

From: [email-masked]
Date: Tue, 03 May 2005 11:05:12 +0300

Alper,

> primary one, couldn't we simply just look at the latter one to generate

I think that would be sufficient.  Since secondary PDP contexts fate share
with the Primary PDP context that they belong to, sharing L2 event notifications
is fine.  One slight twist is that Secondary PDP contexts can still exist
after a Primary PDP context is removed; all the IP config data still remains
valid. 

John

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Tue, 03 May 2005 10:24:12 +0200

> However, even with an active PDP context, it is possible that the link
isn't
> active; for example if the GGSN goes down, then UE might still be in
the
> PDP Context active state but there are no resources available.
> 
> To repeat your question:
> 
> > The motivation of DNA can also be seen as a way to find an
> > answer to the question: "I was previously using this address, can I
> > still use it on this network too?"
> 
> You would need to re-run DNA everytime the PDP context state is
changed, in
> my opinion.

What would the node gain by running DNA every time the PDP context state
changes? Would DNA be used to detect if the link is useable in this
case? I'm just trying to understand the motivation.

Tero

---

From: [email-masked]
Date: Tue, 03 May 2005 12:51:33 +0300

Hi Jari,

> >However, even with an active PDP context, it is possible 
> that the link isn't
> >active; for example if the GGSN goes down, then UE might 
> still be in the 
> But isn't IPv6 NUD the right protocol to use when ensuring
> that you still have connectivity to the GGSN? At least that's
> what we wrote in RFC 3316...

You are correct.
 
> >You would need to re-run DNA everytime the PDP context state 
> is changed, in
> >my opinion.
> >  
> >
> The way that I see this is that the point of DNA is to detect
> changes in (a) prefixes that affect the host's addresses, and
> (b) routers that the host uses as default routers.
> 
> Now, when you are on a point-to-point link such as PDP context
> or PPP, there isn't much use for part b, so we are primarily interested
> in part a.
> 
> My understanding of the PDP context procedure is that in
> the establishment procedure (that runs on lower layers) you
> get a prefix that is unique to you. Furthermore, as specified
> in RFC 3316 there are some rules that prevent the same
> interface ID from being assigned on the same link; that's
> why DupAddrDetectTransmits can be set to zero.
> 
> My understanding is also that the 3GPP specifications
> require the network to never change the prefixes on
> a live PDP context (or if they are changed, the context
> needs to be shut down first).
> 
> As a result, I have trouble seeing why we'd need to run
> DNA on a phone that is connected to a GSM/UMTS network
> via a PDP context. NUD yes. L2 signaling to set up yes.
> But no DNA. Or am I missing something?

Actually, I think your analysis is correct. NUD is sufficient
here.
 
> (On a laptop connected over PPP this is a different matter.
> The laptop has no knowledge of what the L2 really is at the
> other end.)

Correct, just PPP knowledge.

John

---

From: [email-masked]
Date: Wed, 04 May 2005 15:09:21 +0300

Jari,

> I admit it sounds scarier. But I didn't actually intend to turn off
> IPv6 altogether if you hit a link that doesn't appear to be doing v6.
> Just v6 on that link! The situation is similar to detecting a 
> "link down" on
> an interface. If you have other interfaces, you keep on using them.
> (Or you turn on your other interfaces because of this; this is one
> of the reasons why you'd want to know you have no IPvx service.)
> If you do not have any other interfaces, you hold on to your session
> state and addresses for a while, in case things change for the
> better. Finally, home addresses and sessions on top of them should
> survive in any case.

I think that sounds reasonable.  The IPv6 Link would be marked as down;
another interface could be started a virtual interface for a transition
mechanism could then be substituted.

John

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Wed, 04 May 2005 16:30:45 +0200

> mechanism could then be substituted.

True. It should probably remain down until another link-up notification
is received or when the node mysteriously receives an RA without first
receiving a notification, i.e. the case when IPv6 router functionality
is suddenly enabled.

Tero