Subject: RE: [Seamoby] Issue 2: CTAR Response Needed

From: [email-masked]
Date: Fri, 27 Jun 2003 21:53:10 +0300

Hi James,

That is a good suggestion, I will try to work that in.

John

> -----Original Message-----
> From: ext James Kempf [mailto:[email-masked]]
> Sent: 27 June, 2003 18:53
> To: Loughney John (NRC/Helsinki); Perkins Charles (IPRG)
> Cc: [email-masked]
> Subject: Re: [Seamoby] Issue 2: CTAR Response Needed
> 
> 
> OK.
> 
> Do you think it might make sense to put a flag in CTAR so the 
> MN can say
> whether or not it wants to receive a reply? I believe there 
> is such in  BU
> for MIP.  That way, if only header compression were being 
> done, the flag
> could be off, whereas if something like QoS were done that 
> needed a reply,
> the flag could be on.
> 
>             jak
> 
> ----- Original Message ----- 
> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, June 27, 2003 4:00 AM
> Subject: RE: [Seamoby] Issue 2: CTAR Response Needed
> 
> 
> > Hi all,
> >
> > I am adding this message to CTP.  My assumption is that 
> this is purely an
> informative message, which can be disregarded by the MN if 
> the MN has other
> information.
> >
> > br,
> > John
> >
> > 2.4.2 Context Transfer Activate Acknowledge (CTAA) Message
> >
> > This is an informative message sent nAR to the MN to 
> acknowledge a CTAR
> message. Acknowledgement is optional, since the MN may have 
> already moved
> and may not receive the reply. This message may include a list of FPT
> (feature profile types) that were not transferred successfully.
> >
> >  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
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |        Message Type           |reserve|       Length          |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |             Mobile Node's Previous IP Address                 |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |                   Previous Router IP Address                  |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |Type=Auth-Token| Type Len      |        Replay                 |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |                    MN Authorization Token                     |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |                Failed Context Type (if present)               |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |            Next Failed Context Type (if present)              |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |                           ........                            |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > The message data for CTAR is the Mobile Node's Previous IP Address,
> Previous Router's IP address, MN Authorization Token, 
> followed by a list of
> context types that were not successfully transferred.  If no 
> context types
> are specified, then all contexts for the mobile node are considered
> successfully transferred.
> >
> >
> 
> 
> _______________________________________________
> Seamoby mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/seamoby
> 

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