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

From: "James Kempf" <[email-masked]>
Date: Fri, 27 Jun 2003 08:53:26 -0700

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

---

From: [email-masked]
Date: Fri, 27 Jun 2003 14:00:01 +0300

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

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

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.