Re: DoCoMo Implementation Issues with CTP

Rajeev,

Could you suggest some text for the draft that clarifies this point?

            jak

----- Original Message ----- 
From: "Rajeev Koodli" <[email protected]>
To: "Raghu" <[email protected]>
Cc: "James Kempf" <[email protected]>; <[email protected]>
Sent: Thursday, February 19, 2004 5:01 PM
Subject: Re: [Seamoby] DoCoMo Implementation Issues with CTP


> 
> Hello Raghu,
> 
> 
> Raghu wrote:
> 
> > >
> > > - 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.
> > >
> > IP Version flag in the draft indicates whether the IP Version
> > can be either IPv4 or IPv6 or both(IPv4 & IPv6).
> > When MN is assigned both IPv4 & IPv6 addresses,
> > it is assumed that AR also has both IPv4 & IPv6 addresses.
> > When MN moves, sending two CT messages for the same MN
> > is unnecessary. Hence to avoid this, either IP version flag
> >
> 
> hmm.. This is perhaps a misunderstanding.
> The `V' bits indicate whether contexts corresponding to
> both IPv4 and IPv6 addresses (as well as the addresses
> themselves) are present. The (P)CTD message itself
> can be either IPv4 or IPv6. You may observe that the
> Source and Destination IP addresses for all the messages
> are absent. I cannot say this is intentional, but the result is
> that the messages themselves can be carried in IPv4 or IPv6
> packets.
> 
> 
> > should not support both IPv4 & IPv6 at the same time or
> > the draft should mention, which IP version to take precedence.
> >
> 
> Hopefully, the above explanation clarifies..(i.e., IP version of
> the packets carrying CTP messages is independent of the
> `V' bits).
> 
> Length field increase (below) is okay.
> 
> -Rajeev
> 
> 
> >
> > > - Isn't MTU a consideration in increasing the size of the
> > >     Length field to 16 bits ?
> > >
> >
> > Since CTP is an application layer program, I guess
> > supporting upto 16bits is more reasonable for the
> > following reasons
> > 1. UDP supports upto 16bits
> > 2. As more Feature profiles are defined more
> >     contexts in the same CTP needs to be transferred.
> >
> > As per the sections 2.4 & 2.5 in the draft
> > "message length in units of 8", Padding bytes
> >  are required for both CDB & CT Messages.
> > These padding bytes get critical when we are
> > reaching the maximum size ie 2048 bytes.
> >
> 
>