Re: [Seamoby] DoCoMo Implementation Issues with CTP

[Rajeev Koodli <[e-mail]>]

Jim,

the suggested changes are okay. I am curious about couple
of suggestions however..

- When both IPv4 and IPv6 addresses are used in CTD,
 "Processing the address of the opposite
version in the stack is complicated. " Could you elaborate on
this ? I can see that once IP (v4 or v6) stack demultiplexes the
packet to belong to a CTP client, it would just forward the block
to a CTP module (a daemon for instance), which could then
process contexts associated with both the addresses.

- Isn't MTU a consideration in increasing the size of the
    Length field to 16 bits ?

Thanks,

-Rajeev


James Kempf wrote:

> DoCoMo is in the process of implementing CTP, and we came up with the
> following list of issues in the spec. Since none of them seem particularly
> large, Allison suggested that we simply update the current version of the
> document (which is now under review by the ROHC WG) in place, without reving
> the document to a new version. She will make the changes.
> Below, a list of the issues and suggested changes to the document to address
> them.
>
> Any comments? Please let me know by March 6.
>
>             jak
>
> -------------------------------------------
>
> 1) Section 2.5.1, pg. 10; Section 2.5.2, pg. 11; Section 2.5.3, pg. 12;
> Section 2.5.4, pg. 13; Section 2.5.6, pg. 15 - 'V' flag
>
> The spec allows CTP messages to carry both IPv4 and IPv6 addresses, but as a
> practical matter in the implementation, a CTP message will be sent to the
> IPv4 or IPv6 address of a router. Processing the address of the opposite
> version in the stack is complicated. Suggestion is to only allow IPv4 or
> IPv6 addresses, but keep the flag field size at 2 bits in case further
> experience shows that there are reasons why both might be sent. The router
> can issue separate messages if both addresses must be changed,  Suggested
> change in text:
>
> Replace: "When set to '10', indicate presence of both IPv6 and IPv4 Previous
> (New) addresses."
> With: "Values of '10' and '11' are reserved".
>
> 2) Section 2.5.3, pg. 12 - Length of Algorithm field in CTD message block.
>
> The length of the algorithm field in the CTD message block is shown as 17
> bits. It should be 16.
>
> 3) Section 2.5.1, pg. 10; Section 2.5.2, pg. 11; Section 2.5.3, pg. 12;
> Section 2.5.4, pg. 13; Section 2.5.6, pg. 15 - Length field.
>
> The size of the message length field is currently 8 bits, and the units for
> the length are in 8 octet words. This allows a maximum of 2048 octets, which
> might not be enough for bundling large amounts of context if padding is
> required. Suggestion is to increase the size of the field and make it be
> units of octets, for a total of 65535 octets. This would only involve moving
> the flags into the Reserved field, and would not otherwise modify the
> message.
>
> Replace: In message diagram blocks, move Length to be 16 bits rather than 8.
>
> Replace: "Length    message length in units of 8 octet words"
> With: "Length    message length in units of octets"
>
> 4) Section 2.5.1. pg. 9; Section 2.5.2, pg. 11; Section 2.5.3, pg. 12;
> Section 2.5.4, pg. 13; Section 2.5.5, pg. 14; Section 2.4.6, pg. 15 - IP
> address field size.
>
> The message block diagrams show the size of the IP address fields as 4
> octets, but if the IP address is for IPv6, it will be 16.
>
> Replace: In the message block diagrams, replace the final "|" with a "~" to
> indicate a variable length field. Indicate variable length field by putting
> "(4 or 16 octets)" after the text in the field.
>
> 5) Section 2.5.3, pg. 12 - Key field in message diagram
>
> Only 4 bytes are shown for the key field, but the key size field allows
> 65535. The message diagram needs to be changed.
>
> Replace: In the message diagram, replace the final "|" with a "~" to
> indicate a variable length field. Indicate the variable length field by
> putting "(variable)" after the text in the field.
>
> _______________________________________________
> Seamoby mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/seamoby


_______________________________________________
Seamoby mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/seamoby