[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMOusecase
Hi Desire,
> > Its not clear what would cause the home agent to stop
> forwarding for a
> > particular mobile network prefix and revoke that prefix using a BRI
> > message. It can done, but is it really required?
> [Desire]: An example could be that the HA want to assign an
> unused MNP to another MR.
Unused MNP? Once a MNP is allocted to the mobile router, it is free to
use it as it wants. There is no such thing as an unued NMP. The home
agent does not re-cycle that.
> Another possibility is that the HA
> want to stop serving as a NEMO HA for the MR without stopping
> normal MIPv6 services for the MR. In this case, the HA can
> revoke all the MNPs.
Switching from NEMO HA to MIPv6 HA shouldn't be allowed. If this
happens, the mobile router should be forced to bootstrap an appropriate
HA again. Not force the mobile router to operate as a mobile node.
Vijay
> > If the mobile network prefix is assigned to the mobile router using
> > binding acknowledgement, then I can see the BRI message
> being used to
> > revoke a particular prefix. But if DHCP prefix delegation
> is used for
> > assigning the prefixes, does it make sense to the BRI message for
> > revoking a prefix?
> [Desire]: I agree that using BRI for MNP revocation is more
> evident when the MNP is assigned using BAck. However, there
> could be a case where DHCP is used but the selected HA is not
> the DHCP server or delegating router in case of PD. In this
> scenario, the HA can send the BRI to revoke the MNP then the
> MN can start DHCP operation to release the prefix.
> >
> > Vijay
> >
> > > -----Original Message-----
> > > From: mext-bounces at ietf.org [mailto:mext-bounces at ietf.org]
> > On Behalf
> > > Of Ahmad Muhanna
> > > Sent: Monday, December 01, 2008 7:23 PM
> > > To: Desire Oulai; mext at ietf.org
> > > Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports
> > > NEMOusecase
> > >
> > > Hi Desire,
> > >
> > > Added a relative subject.
> > >
> > > I guess the usecase is clear and it makes sense to me.
> > > We can add some text similar to yours to capture this
> functionality
> > > under the HA and MN operations after the conclusion of the WGLC..
> > >
> > > BTW: Is there anyone who thinks that we should not add
> this usecase?
> > >
> > > Regards,
> > > Ahmad
> > >
> > >
> > >
> > >
> > > ________________________________
> > >
> > > From: Desire Oulai [mailto:desire.oulai at ericsson.com]
> > > Sent: Monday, December 01, 2008 2:46 PM
> > > To: mext at ietf.org
> > > Cc: Muhanna, Ahmad (RICH1:2H10)
> > > Subject:
> > >
> > >
> > >
> > > Hi Ahmad, All,
> > >
> > > The Binding revocation draft does not mention
> > revocation related to
> > > NEMO. If used as is, the BRI will revoke the binding
> > between the MR's
> > > HoA and CoA. I think it's woth adding another level of
> revocation:
> > > revocation of Mobile Network Prefixes. A HA may decide to stop
> > > forwarding data to the CoA for certain MNPs and BR could be
> > used for
> > > that. Here is a proposed text for a new section:
> > >
> > > "In case of NEMO protocol, the HA follows the same
> > procedure as MIPv6
> > > if the goal is to revoke the binding between the Mobile
> > Router's HoA
> > > and CoA. It is also possible to have finer granularity of
> > revocation
> > > targeting the Mobile Network Prefixes assigned to the
> > Mobile Router.
> > > In this case, the HA sends a BRI message including one or
> more MNP
> > > options with the A bit set and the Revocation Trigger set
> > to a proper
> > > value, e.g. Administrative Reasons. When receiving this
> BRI, the MR
> > > deletes the MNP(s) from the Prefix Information field in
> the Binding
> > > Update List and responds with a BRA message.
> > > The BRA MUST include the MNP(s) contained in the BRI."
> > >
> > > Also, Mobile network Prefix should be addes as valid option in
> > > section "6.2. Binding Revocation Acknowledgement Message".
> > >
> > > BR
> > > Desire
> > >
> > >
> >
>
_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext