Hello Martti
At Thu, 13 Apr 2006 11:23:30 +0300,
Martti Kuparinen wrote:
>
> Ryuji Wakikawa wrote:
>
> > So, bulk registration for CN needs more discussion
whether it's really need.
> > If yes, which RO mechanism we should support?
>
> >From the bytes-sent-between-the-nodes point of view
bulk registration is really
> beneficial and makes a lot sense.
>
> We have made some performance analysis on the bulk
registration so you (=this
> list) can expect a draft next week...
Yes, i'll wait for that.
> > I would like to support bulk registration to HA,
but not to CN at this point.
> > RO mechanism is not completed yet, except for RR.
If we exclude bulk registation to CN,
> > we can produce signle document
>
> Personally I'm fine with this (to get things started)
but I also would like to
> see the BIDA option in the draft so we can correctly
see what CoAs were
> successfully registered and which not.
agree.
How about HA include BIDA option only when there is an
error.
When an error is occurred, BA looks like
+---------------------+---------------+----------------+
|BA (status=Bulk fail)|BIDA(BID,Error)| BIDA(BID,Error)|
+---------------------+---------------+----------------+
Otherwise, HA replies with
+------------------------+
|BA (status=Bulk success)|
+------------------------+
This can save certain bits.
> Binding Unique Identifier Acknowledgement sub-option
(BIDA)
>
> 0 1 2
3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
6 7 8 9 0 1
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type = TBD |
Length |
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
> | Binding Unique ID (BID) | Status |
Reserved |
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
> ...
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
> | Binding Unique ID (BID) | Status |
Reserved |
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
>
> And while suggesting things, I think we really should
not reuse the ACoA option
> when doing bulk registration (which could confuse
legacy HAs/CNs) but have these
> two options instead of your proposed BID option:
>
> Home Binding Unique Identifier sub-option (HBID)
>
> 0 1 2
3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
6 7 8 9 0 1
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type = TBD |
Length |
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
> | Binding Unique ID (BID) | Priority |C|
Reserved |
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
> |
|
> +
+
> |
|
> + Care-of Address
+
> |
|
> +
+
> |
|
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
THis is useful only when bulk Reg is used. When MN does
separate registration,
128bit is useless, since CoA is in IPv6 header.
So I want to go with a new CoA option instead of ACoA
option, which
format should be same as ACoA except for type value.
> Correspondent Binding Unique Identifier sub-option
(CBID)
>
> 0 1 2
3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
6 7 8 9 0 1
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type = TBD |
Length |
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
> | Binding Unique ID (BID) | Priority |
Reserved |
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
>
>
> Later, when we come up with a solution for the CN bulk
registration we can
> modify the CBID option and not mess with the HBID
option.
I prefer using the same option for both HA and CN. We can
carrry more
infromation by defining a new sub-option if necessary.
ryuji
> Martti
>
> _______________________________________________
> Monami6 mailing list
> Monami6 ietf.org
> https:
//www1.ietf.org/mailman/listinfo/monami6
>
_______________________________________________
Monami6 mailing list
Monami6ietf.org
https:
//www1.ietf.org/mailman/listinfo/monami6
|