Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

From: "Gary Kenward"<[email-masked]>
Date: Tue, 9 Apr 2002 14:30:51 -0400

James:

  Sorry, but I am a bit confused (as usual), are you saying
then that doing these functions with the CT protocol is less
heavyweight, and thus preferable?

  The default action, always, is for the session to be dropped.
This will ultimately force the MN to take action (oh, ok, some
MNs will simply halt and catch fire). Anything more then dropping
the session is simply to improve the handover performance under
various conditions. Typically, when one gets into exception scenarios,
the solutions become too complex or degrade performance too much 
to be justified against the potential gains. A classic example is
run time type/value checking in C/C++. 

  If there are no recovery mechanisms for the potential faults 
you describe, then does it make sense to build one into CT?
On the other hand, if these mechanisms are built into the handover
algorithm, or into the session support, then putting it into CT
would be redundant, would it not?

Gary

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: April 8, 2002 21:12
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri
> Madjid-MNAKHJI1
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> 
> 
> Gary,
> 
> When you say "handover failure" I think Mobile IP, and there 
> is already
> some signaling available in FMIPv6/BETH to do this. This 
> signaling does
> not extend to attributes of the IP service like whether or not the MN
> can connect to the network, what class of QoS service it gets, and any
> other security, etc.. There is currently no way to signal that the
> network expects the MN to reestablish these, except to say that the MN
> has entered a new AAA domain and should therefore perform 
> network entry
> from scratch. This seems a little too heavyweight to me.
> 
>             jak
> 
> ----- Original Message -----
> From: "Gary Kenward" <[email-masked]>
> To: "'James Kempf'" <[email-masked]>; "'Rajeev Koodli'"
> <[email-masked]>; "Nakhjiri Madjid-MNAKHJI1"
> <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Monday, April 08, 2002 1:21 PM
> Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> 
> 
> > James:
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:[email-masked]]
> > > Sent: April 8, 2002 15:55
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri
> > > Madjid-MNAKHJI1
> > > Cc: [email-masked]; [email-masked]; [email-masked]
> > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> > >
> > >
> > >
> > > > As I outlined in one of my other posts, why would you
> > > perform CT to an
> > > > AR that did not have the necessary capabilities. Is 
> this actually
> > > about
> > > > CAR failure??
> > > >
> > >
> > > Yes and no.
> > >
> > > Suppose the MN is expecting CT to be performed and it is not
> > > because the
> >
> > A nit, but the MN does not expect CT. The MN expects continuous
> > service (i.e. seamless service), and knows nothing about how it is
> > supported (it could be provisioned).
> >
> > > new AR can't interpret the context.
> > > The old AR may discover this via CAR, but if there is no way to
> > > communicate it to the MN, then the MN can't know to perform the
> > > signaling from scratch on the new AR.  One could either inform the
> MN
> > > beforehand to do the signaling, as is done with FMIPv6/BETH, or
> signal
> > > the MN on the new AR.
> > >
> > > For dynamic failures, such as when the AR runs out of Gold Class
> > > service, the signaling could only be done afterwards.
> >
> > I understand these scenarios, but I do not understand what they have
> > to do with CT. CT has never intended to be an MN signalling 
> protocol.
> > Let me try a counter example: the service authorization fails. Would
> > a CT message saying the AA context transfer failed be of much use
> > to the MN? No, because the problem wasn't with the context, it was
> with
> > a disconnect between the service request and authorization 
> profile for
> > that MN.
> >
> > There is a need for a "handover failure" indication message to the
> > MN (indicating full or partial handover failure), but this message
> should
> > be part of a different protocol from CT.
> >
> > Gary
> >
> > >
> > >             jak
> > >
> >
>

---

From: "James Kempf" <[email-masked]>
Date: Tue, 9 Apr 2002 12:00:31 -0700

Gary,

> heavyweight, and thus preferable?

No, I'm saying that "dropping the session" is more heavyweight. And what
do you mean by a session anyway?
IP is connectionless.

I think what you mean is that all feature contexts for the MN revert to
the startup state, namely gone.

> run time type/value checking in C/C++.

My point is, if the MN never finds out about this, then it can't take
any action.

> would be redundant, would it not?

I'm not saying that there should be recovery built into CT. What I am
saying is
that the MN has got to know when it has to redo signaling in order to
reestablish
stuff like it's AAA state or it's QoS state.

We went through this exact conversation on the MIP list with respect to
BETH. The
MN doesn't get involved in handover with BETH, so it needs to be
informed when
BETH handover fails (in practice, we tell it when BETH handover is about
to fail).
Then it can do standard MIP signaling in order to get a care of address.

I'm willing to grant that having CT do feature by feature failure
notification doesn't make sense,
but I still think there needs to be some way to tell the MN that
seamlessness has failed
or is about to fail so it can take the right steps to restart the
original network admission
procedure.

I think this is needed if for no other reason than when the MN reaches
the edge of the operator's
domain, if the operator doesn't have the right business agreements with
the next operator, the MN
has got to know to redo network entry, i.e. AAA from scratch, QoS from
scratch, etc.

            jak

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis