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

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 5 Apr 2002 15:54:04 -0600

Hello Rajeev,

I agreed with everything you say below, except one thing:
CT can only transfer whatever QoS state that is usable at the newAR.
If the new network is using a different QoS technology with different
QoS parameters, then I am not sure if CT by itself can do the job, unless
you add your own mapping functionality.

BR,
Madjid

-----Original Message-----
From: Rajeev Koodli [mailto:[email-masked]]
Sent: Friday, April 05, 2002 11:01 AM
To: Gary Kenward
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Hello,

well, if the issue is QoS establishment after handover,

- CT is applicable for establishing QoS state at the AR
- if further signaling is desired beyond the AR, NSIS may
    consider it. I don't see how _signaling_ for QoS establishment
    beyond AR is relevant for seamoby.

CAR _discovery_ could exchange QoS capability as one of the
parameters that might then be fed to a selection algorithm. Any
signaling for actually establishing QoS itself beyond the AR
should be outside the scope of seamoby..

Regards,

-Rajeev

Gary Kenward wrote:

>
>
> Hemant:
>
>   Just a point of clarification, but as I understand CARD (and
> I don't understand it well), it is not a QoS negotiation
> protocol. The main application that you are referring to primarily
> arises out of a perceived need to determine at the MN the best link
> layer to handover over to when inter-technology handovers are
> involved.
> It can be applied to intra-technology handovers, but the value in
> that situation is highly questionable (e.g. since it is a discovery
> protocol, the implication is that the purpose is to determine the
> choice of channels available; for intra-technology handovers, there
> are many, many reasons why this "choice" may not be available).
>
>   There is a requirement, 5.1.2, which seems to imply NSIS involvement
>
> during/after a handover. John has stated that this is not the
> intention
> (please correct me if I have this wrong John), in which case I think
> 5.1.2 needs to be clarified.
>
>   Specifically, is NSIS to be used to negotiated new QoS for an
> existing flow after a handover, or is it specifically for establishing
>
> QoS for a new flow? I don't think the answer is boolean: the role
> of NSIS in QoS re-negotiation is still open, I believe, and clearly
> handover is a dynamic situation that could cause the QoS provided to
> change.
>
>   I have been told there is no issue, but here's a frightening
> scenario:
>
>         - a handover takes place, and context transfer has been used
> to
>        move the QoS context to the new routers (by the requirements
> for
>        CT this could be intra-, or inter- technology. Some of us
> believe
>        that for "seamless" handovers, the context will be available at
>
>        routers before the first packets need to be forwarded. This
> implies
>        that there is a relationship, probabilistic perhaps, between
>        the handover process and the target ARs for CT.
>
>      - CARD is used by the MN to influence the handover decision (it
>        is not clear to me how this happens, but it seems clear that
>        for a more "seamless" handover, the MN should chose an AR that
>        has received the appropriate context; if not, then what?
>
>      - NSIS kicks in and starts re-negotiating QoS because of changes
>        introduced by the handover;
>
>   How do these three protocols interact to produce predictable
> outcomes?
> Or, perhaps, the question is, how do the functional entities
> associated
> with the three protocols interact before, during and after a handover?
>
> If it the interaction is within the functional entities, the
> respective
> wg's could declare the issue out of scope, but this approach does not
> sit well with me, for it seems to defer the problem to the people who
> have to implement this "stuff".
>
>   Am I imagining things?
>
> Cheers,
> Gary
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: April 4, 2002 22:33
> > To: [email-masked]
> > Subject: RE: [NSIS] Establishing QoS after handoff.
> >
> >
> > Hi Sharif:
> >
> > There is currently a debate going on in Seamoby as to whether
> > this QoS negotiation be covered by NSIS or Seamoby (CAR
> > discovery protocol).
> >
> > IMHO it should be covered by CAR discovery and not NSIS. CAR
> > discovery is supposed to identify candidate access routers
> > for handoff and QoS is an important property for candidacy.
> >
> > Br,
> > Hemant
> >
> > -----Original Message-----
> > From: ext Shahrier, Sharif M.
> > [mailto:[email-masked]]
> > Sent: Thursday, April 04, 2002 3:35 PM
> > To: Shahrier, Sharif M.
> > Cc: [email-masked]'
> > Subject: [NSIS] Establishing QoS after handoff.
> >
> >
> >
> > I have a question for clarification.
> >
> > I think it was stated that NSIS should only be concerned with the
> > establishment of QoS after handoff.
> >
> > This is inconvienent with respect to IP-level QoS
> > negotiation, which ideally
> > should be done before handoff has taken place.
> >
> > QoS negotiation is in the current requirements draft.
> >
> > So, NSIS signaling protocol development should be concerned
> > with activity
> > before handoff occurs.
> >
> > Sharif.
> >
> >
> >
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> >
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> >

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

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

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 05 Apr 2002 14:45:57 -0800

Hello Madjid,

> you add your own mapping functionality.

This would be an example where the new AR sends a
notification to the MN so that the MN can take
appropriate action (for instance, attempt to
re-create the context).

Regards,

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 05 Apr 2002 14:45:57 -0800

Hello Madjid,

Regards,

-Rajeev