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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 19 Jul 2001 20:59:43 +0200

> 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.
> 
	=> That should work also.

> 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.
> 
	=> Actually no, it doesn't go through the MAP, unless the network
	uses the MAP as a border router as well. Which eliminates 
	the point of my earlier proposal about using the BUs to the MAP. 
	I think I need more caffeine :)))

	Hesham

> >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