Subject: RE: [mobile-ip] draft-tkn-mobileip-qosbinding-mipv6-00.txt

From: "Hemant Chaskar" <[email-masked]>
Date: Thu, 19 Jul 2001 18:48:07

Hi Hesham:

Something like that can be made to work. I have seen a scheme that transfers 
PATH and RESV State Blocks both for uplink and downlink data to new AR. New 
AR can do proxy RSVP to MAP using transferred uplink PATH State Block. 
Assuming that MAP has PATH and RESV State Blocks for downlink data, it can 
do proxy RSVP to new AR to set up the downlink path.

It may not be good idea to tie everything to BU, but indeed the scheme like 
above generates heck of a signaling. Another option to isolate these things 
from BU is to include them in normal data packets as h-b-h option.

By the way, does uplink data necessarily go through MAP? If not, then 
including h-b-h QoS object for uplink data in local BU does not work in the 
first place. May be the authors of the draft can clarify this point.

Hemant

>From: "Hesham Soliman  (ERA)" <[email-masked]>
>Reply-To: [email-masked]
>To: "[email-masked]'" <[email-masked]>
>Subject: RE: [mobile-ip] draft-tkn-mobileip-qosbinding-mipv6-00.txt
>Date: Thu, 19 Jul 2001 19:16:27 +0200
>
>	Hello Hemant,
>
> > >
> > > > You draft says that the QoS object can be transferred from old AR to 
>new
> > >AR
> > > > by context tranfer framework. In that case, who sends BU to MAP? In
> > >other
> > > > words, it is not possible that the MN sends BU and AR "fills in" the 
>QoS
> > > > object h-b-h option as it changes IP packet length and disturbs the
> > > > authentication calculation.
> > > >
> > >	=> This is one way of doing it and we are puttnig it in the appendix
> > >	of HMIPv6:
> > >
> > >	- oAR triggers the handover by sending a Prrtradv
> > >	- In the mean time the oAR does the CT. Note that the oAR should 
>already
> > >	  have the QoS objects/attributes.
> > >	- The MN sends a BU, not to the oAR but to the MAP before
> > >	  it moves. This BU can include a H-B-H option.
> > >
> >
> > [Hemant] This BU MUST go through new AR towards MAP, so that it follows 
>the
> > same path as the packets would follow from the new AR. Is this satisfied 
>in
> > the above scheme?
> >
>	=> No. If you want it to go through the nAR then you can use the Network
>	determined model in the Fast Handoffs draft and send the BU to the
>	MAP after you move.
>	However, this goes back to my question about the use of the router
>	alert option. Would something like the following work:
>
>	- oAR sends Prrtradv
>	- oAR does the CT to nAR
>	- MN sends a normal BU to the MAP (no QoS)
>	- nAR does a proxy RSVP to the MAP to set the outbound link
>	- For inbound traffic it is more difficult, perhaps one handwaving idea
>	  would be to get oAR to do transfer the QoS context to the MAP as well ?
>
>	I'm just not sure whether linking everything to the BU is useful.
>
>	Hesham
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp