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

From: "Hesham Soliman (ERA)" <[email-masked]>
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

---

From: Xiaoming Fu <[email-masked]>
Date: Fri, 20 Jul 2001 17:21:44 +0200

>         alert option. Would something like the following work:
- What's Prrtradv? Prefix Router Renumbering advertisement or...?
- To whom? If I'm right you're intending to use this message to notify
  nAR to pre-configure its operation for upcoming CT? Why not CT
protocol
  do it upon the nAR's request?

>           would be to get oAR to do transfer the QoS context to the MAP as well ?
Using bi-directional QoS objects only once from nAR to MAP (whether via
CT or 
not) is enough, since we can setup the QoS status for downlink (as well
as uplink) 
traffic while the QoS option travels towards the MAP.

>         I'm just not sure whether linking everything to the BU is useful.
Agreed. But we think BU+QoS is a nice feature to atomize the operation.
And when multiple hirarchies of MAPs are used - if QoS check failed
somewhere
the closest next MAP may reject this binding.

Xiaoming