Context Transfer

As mentioned earlier, to minimize the period of disruption that the user experiences during a handover, some optimizations, such as fast and low-latency handovers, were on Mobile IP

L2 association L2 connection L3 connection beacon beacon CARD request CARD request CARD reply CARD reply Mobile IP signaling MN OAP OAR CAP1 CAR1 CAP2 CAR2

Figure 5.8 Determination of target AR for handover with the help of the CARD protocol. The MN interacts with its current AR (old AR) for CARD inquiries

procedures. However, as mentioned earlier, these methods simply attempted to re-establish the layer-3 forwarding paths quicker. They did nothing for the re-establishment of network services, such as security or QoS treatment at the new point of attachment. When the MN is using a network feature such as QoS treatment for its packets, the network maintains some state relating to these features. These states are abstracted into what is called the MN’s context. When the MN moves to a new network, the new network must recreate the states for a variety of features (context) to be able to provide the service to the MN after the handover and in a consistent manner. This is where context transfer comes in. Even though designing an efficient and secure context transfer process is a tricky job, the basic motivation for context transfer is rather simple: When the MN moves to a new network, if the mobile’s context is transferred to the new network, the features can easily be installed in the network and if done in a time-efficient manner, the user’s session can continue seamlessly following or even during the handover. Hence the context transfer is defined as follows:

Context transfer is a process by which the old point of attachment transmits the feature states related to the MN to the new point of attachment, so that the MN and the new point of attachment do not have to engage in additional signaling (following the completion of handover signaling) to re-establish these features.

It should be noted that, initially, there was controversy over which entity would be respon- sible for the context transfer, since it is not always the case that the point of attachment (which may even be a dumb device) is the entity that holds the states. There were debates on whether the context transfer should be between more centralized management entities at each of the networks or between layer-2 APs or layer 3-ARs. Finally, it was decided that the context transfer would be performed between layer-3 entities at the edge of the network (ARs). This would, however, require that the state would have to be present at the AR prior to the context transfer.

There have been several proposals for context transfer, some of which (such as TEXT [TEXTDR]) have tried to accomplish simultaneous context transfer and traffic forwarding even during the handover. Finally, the IETF seamless mobility working group [SEAMOBY] came up with an experimental specification of a context transfer protocol (CTP) [CTP3374] that is a waiting RFC status at the time of writing.

As mentioned earlier, there could be many different network services (features in context transfer terminology) that have to be performed for the applications that the mobile user is running. Each of these features is defined by a specific protocol. For instance, if header compression is deployed on the packet headers, the robust header compression (Rohc) protocol may be used for this purpose. The context that would allow header compression operation to run seamlessly on a new processing entity within the new network would also have to be defined by the specifics of Rohc. In a similar manner, a QoS service that is deployed through a QoS-specific protocol needs to define its own feature-specific context. For handover, this would mean the context for each of these features must be transferred to the new AR and from there be forwarded to the entity that is responsible for processing that feature. Since each of these protocols is standardized by other standard authorities such as other groups in IETF, it is up to those standard authorities to define the exact context for the feature that their protocol provides. For instance, the working group responsible for the QoS protocol would have to standardize exactly which states could be transferred to establish QoS provisioning services at the new AR.

Context transfer designers did not have the authority to define the context for any specific feature. So they defined a standardized format with which the designers of each feature protocol need to comply in order to use CTP for their protocol. This format is called a context data block (CTB) and is formatted as shown in Figure 5.9.

The feature profile type (FPT) is a number assigned by IANA (Internet assigned number authority) to each feature protocol that needs to have its context data transferred through context transfer protocol. The Presence Vector provides the freedom of sending specific parts of context data if required.

By using CTB and FPT, CTP provides facilities for multiplexing context from a variety of different features, so that as many features as required can restart after the handover as quickly as possible. When sending a CTP message (request or response) in which context is relevant for multiple features, the multiplexing is simply done by stacking the context data block for each feature one after another. For requests, the CTBs would only include the first 4 octets, while for response messages, that carry the actual context data, the full CTB including feature data is included.

5.3.2.1 Design Considerations

As one can imagine, defining the data blocks and passing them back and forth is not rocket science and has been achieved by endless application and transport protocols. The main point with context transfer is how it is tied to the rest of the handover procedures so that context transfer by itself does not create additional latency, state mismatch, or security compromises. Hence timing of various actions and the entities that control them and the underlying trust relationships are very important:

● Controlling entity: Depending on the choice made for architectural or business reasons, either the network or the MN can control the handover. This has always been a source of contention in standard bodies. We will not go through the pros or cons here, since that discussion is usually never-ending. The choice of entity initiating the context transfer process may also depend on the affiliation of the designer with the network manufacturer or the MN manufacturer. Hence, we will not issue a verdict on our favorite alternative either. We simply mention that either the network or the MN can initiate the context transfer procedure and warn the designers that. their decision will definitely have timing and security implications, either way. In that discussion, the network is represented by either the previous AR (pAR) or the new AR (nAR) in the handover process.

● Choice of triggers: The timing of the context transfer is very important. Context transfer should start as soon as possible so that when Mobile IP signaling is complete and the new paths for both layer-2 and layer-3 forwarding have been established, as little time as

FPT Length P Reserved Presence vector (if P=1) Feature data (actual context)

possible is wasted on re-establishing the service features. Starting too late in conjunction with possible retransmission would defeat the purpose of context transfer. The end user might as well establish the context directly with the new point of attachments. Choices of triggers are typically the same as those for fast handovers. Typically the best triggers are provided by layer-2 protocols and examples are those that provide information on the quality of the signal at the link level, such as those indicating when the link to the old AP is going down or is already down, or those indicating when a new link to a new AP is visible, or when a new link is established. Another trigger issue is security. To avoid denial of service attacks, the trigger must come from a trusted source, i.e. either from an internal driver (inside the entity receiving the trigger) or from a source that can prove its identity.

● Feature type: Various features and their protocols have different degrees of sensitivity to timing. Some features, such as those providing security, may need to refresh their state only once during short sessions (such as re-keying procedures), while others, such as header compression or accounting protocol, change their state based on every traffic packet that has been forwarded. This means various protocols have different life-times associated with the state that they want the CTP to transfer to. For instance, an old AR cannot forward an accounting state (such as the number of packets forwarded on behalf the MN) to the new AR and then keep sending more data packets to the MN until the connec- tion goes down. This means that the timing of the transfer of context is also dependent on the feature type. At least, this means context transfer cannot be done too early either.

● Reliability: As with any protocol, whose purpose is transport of data blocks, reliability is important for CTP. Nobody can use the faulty state to re-establish a feature state machine. However, reliability has always been a great source of contention for design of CTP. One reason is that reliability often means retransmissions, and retransmissions take time and time is a very scarce commodity that nobody has during handovers. Retransmissions may not even be allowed or simply limited to once or twice. When no re-transmission is allowed, it is important for the receiver of the context to be able to know whether it can trust the reliability of the actual transfer or not.

● Security: Apologizing to unlikely portion of our reader with background in dentistry, now we are coming to what considered as the root canal operation in the eyes of network mobility designers. Nobody likes to deal with security, especially when things need to be done quickly, but down the road problems appear if we don’t consider security issues. First, both the MN and the old AR must trust the new AR before they can send potentially sensitive material (such as keying material) to the new AR. This is partly accomplished in CTP by an authorization token. Second, even when the new AR can be trusted with the context, a sensitive context must be protected during transit from the old AR to the new AR. This would imply that security associations (such as IPSec SAs) must exist between the new AR and the old AR. However, establishment of these SAs can take a long time. For the secure context transfer to happen in a time-efficient manner, it is essential that the two ARs will have established these SAs (for instance, through IKE) prior to the handover. This will rule out CTP for time-sensitive applications between networks that do not trust each other. The final security implication is that, as mentioned above, the trigger source or the entity that requests a context transfer must be able to be trusted.

The CTP solution [CTPDR] provides several measures for dealing with these issues. Requiring the CTP messaging between the routers to be performed over SCTP (Stream Control Transport protocol) was a bold move. SCTP provides reliability and flexibility in the

timing constraints of CTP. One can argue that SCTP is a bit extreme for a lightweight application layer protocol that must be nimble and quick. Some of these decisions can be attributed to the current hype in IETF to take extreme measures for congestion control. The authors argue that CTP and its small blocks can hardly be found guilty of causing congestion in the Internet, especially given that CTP is run at the edge of the network. The flip side of argument is that one can only go so far when designing home-brewed reliability at the applica- tion layer. We leave the readers to give their own verdict over their beverage of choice in their favorite gathering place. SCTP would be too heavy to use for messaging between the MN and the routers. Hence, ICMP was suggested to carry the messaging that involves MNs.

The TEXT procedure [TEXTDR] although it never made it as a standard track document, had proposed a method to combine traffic forwarding with context transfer and handover signaling to eliminate the impact of context transfer and handover latency on traffic flow. The reader is referred to the draft as well as [RELCT] for thorough discussions and solutions on trigger, timing, and reliability issues.

5.3.2.2 Messaging Overview

As mentioned earlier, one of the important design considerations is the trigger and the entity that receives it. This could be the entity that initiates the context transfer process, even though it may not be the entity that authorizes it from both the control and security stand- point. Depending on who initiates the trigger and who authorizes a context transfer, different scenarios were envisioned. The messaging for each scenario is slightly different.