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.