RE: CTP Issue 29: CTP spec needs an example

James,

I think that this is a useful example to give as an appendix, so I 
think we should add it.

thanks,
John

> -----Original Message-----
> From: ext James Kempf [mailto:[email protected]]
> Sent: 16 September, 2003 18:45
> To: [email protected]
> Subject: [Seamoby] CTP Issue 29: CTP spec needs an example
> 
> 
> At the Vienna IETF meeting, we discussed the need for some 
> example of CTP in
> order to show readers (and the IESG in particular) what the 
> benefits of CTP
> are for smoothing handover. Header compression was discussed but some
> technical issues were raised that may take a while to work 
> through, so it
> seems like header compression might not be simple enough. 
> While Rajeev is
> working through those issues, a simpler example that we could 
> include in the
> CTP document would be useful so that we can advance the CTP 
> document sooner.
> Multicast was suggested as an example. Below is text for an 
> appendix to the
> CTP spec for an example involving MLD state CT. Note that 
> this text is not
> meant to be normative, but might be usefully separated out 
> into an actual
> protocol when and if CTP goes to PS.
> 
> Comments?
> 
>             jak
> 
> ====================================
> Multicast Listener Context Transfer
> ===================================
> 
> Introduction
> ------------
> 
> As an example of how context transfer can improve the 
> performance of IP
> layer handover, we consider transferring IPv6 MLD state [1]. 
> MLD state is a
> particularly good example because every IPv6 node must perform two MLD
> messaging sequences on the wireless link to establish itself as an MLD
> listener prior to performing router discovery [2] or duplicate address
> detection [3] or before sending/receiving any 
> application-specific traffic
> (including Mobile IP handover signaling, if any). The node 
> must subscribe to
> the All Nodes Multicast Address and the Solicited Node 
> Multicast Address as
> soon as it comes up on the link. In addition, any application-specific
> multicast addresses must be re-established as well. Context 
> transfer can
> significantly speed up re-establishing multicast state by 
> allowing the nAR
> to initialize MLD for a node that just completed handover; 
> without any MLD
> signaling on the new wireless link. The same approach could 
> be used for
> transferring multicast context in IPv4.
> 
> An approximate qualitative estimate for the amount of savings 
> in handover
> time can be obtained as follows. MLD messages are 24 bytes, 
> to which the
> IPv6 header, 40 bytes, and a required Routing Header Type 0, 
> 24 bytes, must
> be added (because there will be no header compression on the 
> new link), for
> a total MLD message size of 88 bytes per message per 
> subscribed address. RFC
> 2710 recommends that nodes send 2 to 3 MLD Report messages per address
> subscription, since the Report message is unacknowledged. 
> Assuming 2 MLD
> messages sent per address subscription, the mobile node would 
> need to send a
> total of 4 MLD messages for the two pre-router discovery 
> multicast addresses
> (All Nodes Multicast Address and Solicited Node Multicast 
> Address for the
> link local address). This gives a total of 176 bytes per 
> subscribed address
> or 352 bytes over the wireless link for both the pre-router discovery
> multicast addresses. The amount of time saved will, of 
> course, depend on the
> wireless link bandwidth, but some representative numbers can 
> be obtained by
> assuming bandwidths of 20 kbps or 100 kbps. The former is 
> approximate for a
> narrowband 3G cellular link and the latter for a moderately 
> utilized 802.11b
> WLAN link, both running Voice over IP (VoIP). With these two 
> bit rates, the
> savings from not having to perform the pre-router discovery 
> messages are
> 140.8 msec. and 28.2 msec., respectively. If any application-specific
> multicast addresses were subscribed, the amount of time saved could be
> substantially more. Considering most ATM-based 3G voice 
> cellular protocols
> try to keep total voice handover delay less than 40-80 msec., 
> MLD signaling
> could have a large impact on the performance of inter-subnet 
> VoIP handover.
> 
> The Protocol
> ------------
> 
> The context-specific data field for MLD context transfer 
> included in the CTP
> Context Data Block message for a single IPv6 multicast address has the
> following format:
> 
>        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
>       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                                                       
>         |
>       +             Subnet Prefix on nAR Wireless Interface   
>         +
>       |                                                       
>         |
>       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                                                       
>         |
>       +                                                       
>         +
>       |                                                       
>         |
>       +               Subscribed IPv6 Multicast Address       
>         +
>       |                                                       
>         |
>       +                                                       
>         +
>       |                                                       
>         |
>       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> The Subnet Prefix on nAR Wireless Interface field contains a 
> subnet prefix
> that identifies the interface on which multicast routing should be
> established. The Subscribed IPv6 Multicast Address field contains the
> multicast address for which multicast routing should be established.
> 
> The pAR sends one MLD context block per subscribed IPv6 
> multicast address.
> 
> Router MLD State Machine Interactions
> -------------------------------------
> 
> No changes are required in the MLD state machine for the routers.
> 
> Upon receipt of a CTP Context Data Block for MLD, if the 
> router is in the No
> Listeners Present state, it transitions to the Listeners 
> Present state for
> the Subscribed IPv6 Multicast Address on the wireless 
> interface specified by
> the Subnet Prefix on nAR Wireless Interface and starts its 
> timer, as if it
> had received a Report message in the No Listeners Present 
> state. If the
> router is in the Listeners Present state for the multicast address, it
> remains in that state but restarts the timer, as if it had 
> received a Report
> message in that state.
> 
> If more than one MLD router is on the link, a router 
> receiving a MLD context
> data block SHOULD send a CTP Context Data Block for the 
> Subscribed IPv6
> Multicast Address and the Subnet Prefix on nAR Wireless 
> Interface to other
> MLD routers on the link. A router receiving an MLD context 
> data block MAY
> send a proxy MLD Report message instead, if wireless 
> bandwidth is not an
> issue. Since MLD routers do not keep track of which nodes are 
> listening to
> multicast addresses, only whether a particular multicast 
> address is being
> listened to, proxying the subscription should cause no difficulty.
> 
> [1] Deering, S., Fenner, W., and Haberman, B., " Multicast Listener
> Discovery (MLD) for IPv6," RFC 2710, October, 1999.
> 
> [2] Narten, T., Nordmark, E., and Simpson. W., "Neighbor 
> Discovery for IP
> Version 6 (IPv6)," RFC 2461, December, 1998.
> 
> [3] Thompson, S., and Narten, T., "IPv6 Address 
> Autoconfiguration," RFC
> 2462, December, 1998.
> 
> 
> _______________________________________________
> Seamoby mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/seamoby
>