Internet Draft Madjid Nakhjiri Shreesha Ramanna draft-nakhjiri-seamoby-ppp-ct-00.txt Motorola Inc. Category: Internet draft December 2002 Expires: May 2003 Enhanced PPP link re-establishment using context transfer Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Many of todayĘs networks use PPP as a means of providing access links to remote users. In case a PPP user is mobile and performs a subnet handover, it needs to tear down and re-establish of its PPP link with the network. PPP link re-establishment is an elaborate procedure (as explained in a later section of this document) involving multiple messages. This will lead in an extended service disruption as due to the round trip time involved in the messaging as well extensive radio bandwidth usage. Of this reason, we consider PPP to be a prime candidate for context transfer [1-3]. The proposal in this document can reduce the number of PPP establishment messages by 50%-100. Furthermore, it will save significant amount of time in PPP state machine transitions, due to the multiphase nature of PPP. Reliability and timing issues of PPP context transfer are also discussed. Table of Contents Enhanced PPP link re-establishment using context transfer.........1 Status of this Memo................................................1 Abstract...........................................................1 Table of Contents..................................................1 Nakhjiri Internet Draft - Expires May 2003 1 Internet Draft PPP context transfer December 2002 1. Introduction.................................................2 2. Conventions used in this document............................3 3. Terminology..................................................3 4. PPP overview.................................................4 4.1. Most common PPP negotiation parameters......................4 5. The PPP context transfer concept.............................5 5.1. Benefits of PPP context transfer............................6 5.2. Generic PPP context transfer scenario.......................6 5.3. Complete PPP parameter transfer Scenario....................8 5.4. LCP and IPCP Context transfer scenario......................8 5.5. LCP and Authentication context transfer (NCP negotiated)...9 6. PPP context transfer procedure and issues....................9 6.1. PPP context transfer timing.................................9 6.2. PPP context transfer procedure.............................10 6.3. PPP context transfer reliability...........................10 6.4. PPP context synchronization issues.........................11 6.5. Irrelevant context.........................................11 7. Messaging...................................................11 7.1. General context transfer messaging.........................11 8. Security Considerations.....................................12 9. Acknowledgments.............................................12 10. References..................................................12 11. Contact Information.........................................13 1. Introduction Low bandwidth in many cellular environments generally imposes an upper limit on the amount of signaling that can be done over the air during handover critical path. This and the large amount of latency involved in layer 3 handovers (such as Mobile IP), has been the motivation for the optimization efforts such as, fast Mobile IP handovers [4-5] and context transfer [1-3] in IETF. Generally, the goal for context transfer (explained thoroughly in [1]) has been to reduce the need for re-negotiation of protocol variables, after the MN moves to a new AR. This is accomplished by having the old AR transfer the MNĘs so-called context to the new AR at some point (in conjunction to handover). The general requirements for this procedure are a work in progress [2]. Many of wireless access networks, specifically 3G cellular networks, providing data service to mobile users, rely on point to point protocol (PPP) for establishment of a link between a mobile user and a network access node (For convenience we conceptualize this node to be an access router.). PPP provides a means of negotiation of link parameters, layer 2 framing mechanisms, network layer mechanisms and in some cases authentication. This means, establishment of a PPP link between a network access node and a user involves a series of negotiations, so that both peers can agree on a set of link, identification, and network parameters that are acceptable to both parties. Nakhjiri Internet Draft - Expires May 2003 2 Internet Draft PPP context transfer December 2002 The amount of signaling required for PPP tear down and re- establishment would create a too excessive latency for low bandwidth wireless links in conjunction with inter-AR handovers. Of this reason, we consider PPP to be a prime candidate for context transfer. In other word, based on an inter-AR dialog through which the PPP related parameters, that are common between oldAR and newAR during the current PPP session, would be transferred from the old AR to the new AR. This would eliminate the need for the MN to renegotiate these parameters with the new AR after a handover. The main purpose of this document is to show the details of such PPP context transfer. We also show how much saving in bandwidth and delay is provided by a PPP context transfer. The approach shown here, could also serve as guide for designing context transfer mechanisms for other protocols. A generic solution for context transfer based is proposed in [3], where examples of context transfer messages formats, including headers, payloads as well as discussions on CT timing and reliability issues are provided in detail. The standardization of the generic context transfer protocol is also a work in progress in Seamoby WG. Hence, we suffice to discuss only the specific issues that might arise for a PPP context transfer implementation, while leaving the bit exact form of messages for a later phase. Section 3 of this document defines terminology used in this document. Section 4 provides an overview of the PPP. Section 5 describes PPP parameters and various scenarios based on which different subsets of PPP parameters can be included in context transfer. Section 6 covers some context transfer issues that are specific to PPP and need to be taken into account during more detailed design stages. Section 7 contains specific details for formatting PPP context and context transfer messaging. Section 8 discusses CT security issues. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [5]. 3. Terminology Most of the terminology in this draft is in accordance with Mobile IP and Seamoby WG drafts ([1]-[5]). Hence, only PPP related terminology is covered here: LCP Link control protocol: The link layer protocol and parameter negotiation phase. Nakhjiri Internet Draft - Expires May 2003 3 Internet Draft PPP context transfer December 2002 NCP Network control Protocol: The network protocol negotiation phase of PPP negotiation 4. PPP overview Many of access networks, providing data service to mobile or remote users, rely on point-to-point protocol (PPP) [6-10] for establishment of a link between a nomadic/ mobile user and a network access node (usually access router). Prior to link establishment, PPP provides means for the user and network to negotiate acceptable link parameters, layer 2 framing and network layer mechanisms and in some cases authentication. These negotiations, which are carried by configuration message exchange between mobile user and network, take place through 3 separate phases: 1-Link establishment phase, called LCP (link control protocol) negotiations, which includes negotiating layer 2 link parameters, such as maximum frame size. Once LCP negotiation is complete, the PPP state machine moves to LCP UP state and starts the authentication phase. 2-Authentication phase includes negotiation of the type of authentication accepted by the server. In some of todayĘs networks this phase is bypassed or combined with LCP phase, for instance Mobile IP users might rely on AAA or other Mobile IP authentication mechanisms. While the non-Mobile IP based users need to rely on PPP for authentication related message exchanges. Once the authentication negotiations are complete, the PPP state machine moves to authentication UP and starts the NCP phase. 3-Network protocol negotiation phase (NCP), with for IP network, means IP control protocol (IPCP). During this phase, network layer parameters, such as IP address and type of supported IP header compression are communicated. Once the negotiation within each phase is complete, the PPP state machine transits to the next phase and state. This means all parameters during each phase must have been negotiated successfully, in order for the PPP state machine to move to the next state (more on state transition issues later). 4.1. Most common PPP negotiation parameters In the following, we describe the most common PPP parameters (not a comprehensive list of all PPP parameters), specifically those negotiated when establishing PPP links for access to CDMA networks. 1-SYNC_MAP (This option identifies the character set, which needs to be escaped during framing.) Nakhjiri Internet Draft - Expires May 2003 4 Internet Draft PPP context transfer December 2002 2-PROTOCOL_FIELD_COMPRESSION (PPP header compression depending on the value of the header) 3-ADDRESS FIELD COMPRESSION (Address and control field from HDLC) 4-MRU (max receive Unit=max size of PPP information field) 5-Magic number 6-Van Jacobson Header Compression 7-AUTH_TYPE (to negotiation authentication protocol, such as CHAP) and Challenge during Authentication 8-New AR IP Address and userĘs IP address (in case it is simple IP user) Besides the 8 parameters mentioned above, there may be other less common parameters, such as: 9- PPP in-activity timer 10- PPP session timer that may need to be transferred as part of PPP context. As an example, we will discuss the two parameters mentioned above in more details in PPP timing issues section. 5. The PPP context transfer concept It is observed that, even excluding radio resources setup latencies, PPP negotiations with a cellular network over a low bandwidth radio link introduce delays typically in the order of few seconds. This latency would increase to even higher values when retransmissions due to adverse radio link conditions or failed negotiations are needed. If the user is forced to do an inter-AR handover (for a Mobile IP user, this may translate to an FA handover), the user needs to close the existing PPP link with the prior AR and re-establish a new PPP connection with the new AR. While the PPP establishment's high setup times might be accepted during an initial data application startup, during a handover they might lead to unacceptable interruptions or even session failures (depending on the application settings). Furthermore, significant amount of valuable air bandwidth must be allocated to PPP re-establishment message exchange. In addition, once voice over IP is implemented over cellular systems, such setup times would not be acceptable for a voice application. This draft proposes that, the old AR transfers most of its information about its PPP link with a mobile user to the new AR (over the wired network). Once the transfer of the PPP variables is complete, the new AR should be capable of omitting negotiation of many already known PPP parameters from the PPP re-establishment procedure with the mobile user. This will eliminate or reduce the need for many PPP negotiation messages between mobile and the new AR, once the mobile user arrives at new AR subnet. Nakhjiri Internet Draft - Expires May 2003 5 Internet Draft PPP context transfer December 2002 The old AR could start transferring mobileĘs PPP state to the new AR based either based on an internal trigger, a request from new AR, or alternatively a request from MN. The details of various alternatives for context transfer start are explained in [3]. 5.1. Benefits of PPP context transfer The motivation for this proposal is to reduce the delay caused by PPP re-negotiation in conjunction with network layer handovers. In absence of PPP context transfer mechanism, prior to establishing layer 3 routing for the MN at new AR (completion of L3 handoff), all the link layer, authentication and network layer states must be negotiated between the MN and new AR. This means, not only PPP setup and L3 establishments must happen in sequence, but also, PPP negotiation cannot start until the new L2 link between MN and new AR is up. Using PPP context transfer would provide a set of benefits that are mentioned earlier, such as efficiency of radio resource utilization (eliminating many of over-the-air PPP negotiation messages) as well as reducing messaging latency. Furthermore, employing TEXT [3] as a method of choice for PPP context transfer has a significant added benefit, Since data is being transmitted through a tunnel from old AR to new AR and to MN, PPP context transfer can happen without data flow disruption, which means most of PPP link establishment actions are done outside timing critical path and based on MNĘs traffic load. In the following we go through a set of issues that need consideration in designing an optimized and robust PPP context transfer. In the following subsections we describe various scenarios for PPP context transfer depending on the availability of various PPP parameters. 5.2. Generic PPP context transfer scenario Section 4.1 describes the most commonly negotiated parameters during a PPP setup (mentioned in the following for convenience): 1-SYNC_MAP 2-PROTOCOL_FIELD_COMPRESSION 3-ADDRESS FIELD COMPRESSION 4-MRU 5-Magic number 6-Van Jacobson Header Compression 7-AUTH_TYPE 8-new AR IP Address. 9-MIP Flag: set for mobile IP users, cleared for simple IP user. The parameter 9 is included of following reason: User IP address is part of PPP negotiation, only if the user does not support mobile IP, i.e. it is using static address. In that case, we could argue that user doesnĘt perform any Mobile IP Nakhjiri Internet Draft - Expires May 2003 6 Internet Draft PPP context transfer December 2002 handovers. However, some operators network perform other type of handovers even for simple IP users The application and signaling of PPP context transfer for such users may need specific optimization. For mobile IP users on the other hand, many systems suggest that the user sends a 0000 address as part of registration request and receives a home address as part of registration reply. Such signaling needs not be included as part of PPP context transfer. So from now on, we will only include new AR IP address as part of IPCP negotiations and add a parameter 9 as guidance for newAR. Parameters 1-4 do not change during a typical subnet handover, and hence need not be renegotiated after a handover. Also implementation of magic number changes is a legacy issue of limited security value (the magic number is sent over the clear and can easily be sniffed. Hence from a security standpoint it is only slightly stronger than a sequence number). Since this proposal aims to eliminate the need for complete PPP tear down and re-establishment, there would be no need for creation of new random magic number. Parameter 9 will also be transferred. The generic context transfer scenario suggests transferring the first 5 parameters from old AR to new AR as soon as the either AR receives indication for a need for mobile user to handover to a new AR. In this scenario, only the following parameters will remain to be negotiated after the completion of PPP context transfer: 1-Van Jacobson Header Compression 2-AUTH_TYPE, Challenge (during authentication protocol) 3-new AR IP. Depending on the PPP implementation and system design, some of the above parameters may stay unchanged or may be transmitted through other means. Hence, as explained in the following, we can diverge from the generic scenario to a few more optimized scenarios, which lead to either complete elimination or greatly simplified and expedited PPP re-negotiations. Note, application of various context transfer scenarios implies that either the oldAR is aware of PPP capabilities of the newAR (through a pre-configured record, or through an centralized administrative process) or through an initial handshaking mechanism through which the new AR responds to a query from old AR about the capabilities of new AR. If the capability of new AR is known by oldAR, the latter needs to only selectively transfer context that is useful at new AR. In case new AR capability is not known to oldAR, the latter needs to send a superset of applicable PPP context through PPP context transfer. Upon receiving the PPP context, the new AR may discard the context data it does not find useful (an example, is in case authentication data sent by old AR is not useful at new AR). Nakhjiri Internet Draft - Expires May 2003 7 Internet Draft PPP context transfer December 2002 5.3. Complete PPP parameter transfer Scenario This scenario is the most extreme case, since it completely eliminates PPP negotiations. All the necessary information for the PPP state machine can be transferred from the old AR to the new AR. Hence, the PPP state machine at the new AR can achieve its steady state without the need for any negotiating messaging after the mobile moves from the old AR to the new AR. For this scenario to appear, all the following conditions must be met 1. New AR also supports the same header compression method that the old AR and mobile were using prior to handover and the old AR is aware of this. 2. PPP based authentication phase can be bypassed at the new site. In case the user is relying on Mobile IP and AAA mechanisms and if the old and new AR are aware of the type of mobile stack, the authentication offered by second phase of PPP can be bypassed. Note: Simple IP users, who may still rely on PPP authentication, cannot bypass this phase. 3. No IPCP negotiation is necessary, e.g. new AR IP address can be communicated through non-PPP means (such as agent advertisements) or new AR IP address is know by old AR through candidate AR discovery procedures. Once the PPP parameters and state information are transferred and in place, the PPP state machine at the new AR can simply move to the same state at which the old AR PPP state machine resided. This would save great amount of time usually needed for PPP state machine to transition through all the initial state to get to the completely functional state. It also saves over several seconds of handover time as well as eliminates scheduling RF resources just for PPP negotiations. In this case, the following parameters are sent along with parameters 1-5 mentioned in the generic case to the new AR: -VJ header compression parameters (to save radio bandwidth) -AUTH_TYPE -MIP flag 5.4. LCP and IPCP Context transfer scenario This is the scenario for which the entire LCP and IPCP negotiations can be eliminated through transfer of LCP and IPCP context, but the authentication phase of PPP cannot be bypassed. There might several reasons for this -The mobile relies on PPP authentication and the parameters from old AR cannot be used by the new AR, due to security reasons, or due to a different type of authentication at new AR. -The mobile does not rely on PPP authentication, however the information about the preferred authentication type cannot be conveyed/used by the new AR. In such cases PPP authentication messaging needs to happen between MN and the new AR. However, some suggestions to ease the Nakhjiri Internet Draft - Expires May 2003 8 Internet Draft PPP context transfer December 2002 authentication process (such as supported authentication types by MN) can be transferred from oldAR to newAR, if desired. Note, that PPP negotiation cannot be completely eliminated in this case, but PPP CT still achieves elimination of LCP and IPCP phases. Also note that, although, the IPCP parameters are in place, the PPP state machine cannot pass beyond LCP Up phase, since authentication message must be completed before the state machine can advance to IPCP setup. 5.5. LCP and Authentication context transfer (NCP negotiated) This is the case, where both LCP and authentication phase can be eliminated (see 5.3 for more explanation) by using context transfer, but the NCP (IPCP for IP networks) phase negotiations still need to be performed for PPP link establishment. Examples of this scenario are when -Header compression scheme supported at newAR is unknown or known to be different from that at oldAR. -NewAR IP address is not known and must be communicated directly to the mobile user during PPP negotiations. 6. PPP context transfer procedure and issues 6.1. PPP context transfer timing As mentioned above using TEXT for PPP context transfer reduces the impact of PPP re-establishment on flow of traffic. Traffic to and from MN can flow via old AR through the bi-directional tunnel, BET [4] between old AR and new AR, while PPP context is being transferred from oldAR to newAR. Prior to establishment of PPP link between MN and new AR, the MN relies on its PPP link with oldAR, while taking advantage of secure air link (physical and radio link protocol) with new AR. This way the MN does not have to establish a PPP link with newAR in order to receive its traffic through BET. However, before MN starts messaging exchange with new AR, in order to acquire its new CoA address, the PPP link must be established between MN and new AR (Mobile IP sits on the top of PPP in the protocol stack). This is means PPP context transfer must be completed, before MN starts new CoA acquisition, before the bi-directional tunnel is down. This is the fundamental differentiator between PPP context and other contexts, which can be transferred even during CoA acquisition signaling. The previous discussion means the following can be used as triggers for PPP context transfer: -Start of BET establishment signaling: In most of cases (except when PPP timers are to be transferred) the PPP parameters are static throughout the lifetime of the bi-directional tunnel. In those cases, the same triggers used for BET establishment can be used to start PPP context transfer. Nakhjiri Internet Draft - Expires May 2003 9 Internet Draft PPP context transfer December 2002 -BET lifetime expiration: Expiration of the bi-directional tunnel can be used as the trigger for PPP context transfer start. However, the oldAR needs to request extension of tunnel lifetime from new AR. -Physical link release indications: When the MN data session goes dormant, i.e. MN traffic subsides. In cellular networks, due to the low bandwidth nature of the link, such indications are readily available in a timely manner. Examples are release of allocated Walsh codes in CDMA and release of allocated time slots in TDMA systems. Once, the PPP context is transferred to the new AR, the Old AR (anchor AR) is responsible for the PPP termination (through the newAR to MN via the tunnel) and the newAR needs to download and install the MN's PPP context, before MN starts new CoA acquisition procedure to assume newAR as its default router. 6.2. PPP context transfer procedure The following describes the steps in the PPP context transfer: 1-Old AR or new AR receives trigger (source trigger or target trigger, respectively) for handover and starts establishing the bi-directional tunnel. 2-Bidirectional tunnel is in place (PPP context transfer can happen along with tunnel establishment signaling if needed. however, we prefer to do PPP context transfer at some later point, depending on the flow of data traffic as explained earlier and in [3-4]. 3- PPP context transfer signaling, (Note that the trigger for PPP context transfer can be expiration of tunnel lifetime. In that case, we assume the tunnel can be extended). One implication of source or target trigger is that either the Old AR pushes the Context transfer to the newAR or the newAR requests the oldAR to transfer the Context. 4- PPP context installation, this stage could include PPP message exchange between MN and new AR depending on the extent of PPP context transferred from old AR. 5- MN starts signaling for new CoA acquisition (the traffic through the tunnel may or may not continue). Transfer of non-PPP context can happen during this stage. 6.3. PPP context transfer reliability It is required of the context transfer mechanism to deliver PPP context reliably to avoid the need for PPP re-negotiation by MN at the new AR. It is expected that even if a few rounds of retransmissions over the wired link (between oldAR and newAR) will be more efficient than PPP re-negotiation between MN and newAR. We suggest that the reliability mechanisms proposed in our general context transfer proposal [3] will be used for PPP. Both the old and newAR need to support reliable context transfer. The Nakhjiri Internet Draft - Expires May 2003 10 Internet Draft PPP context transfer December 2002 reliability required flag (R) needs to be set. In case dynamic PPP context (such as timer values) is being transferred, update flag (U) needs to be set as well to allow transmission of refreshed timer values. 6.4. PPP context synchronization issues Most of PPP context data at each AR (not during AR handover) is static for entire session. Hence most of the transferred PPP context will not change with time or data traffic as long as the mobile doesnĘt perform another handover. This also means in case of transmission failures, PPP context can be simply retransmitted and updates would not be needed. The exception to this rule is the case when PPP timers are used. The use of these timers is explained below. The PPP session itself is of limited lifetime. This lifetime is monitored using two parameters 1) PPP inactivity timer 2) PPP session timer/ Mobile IP registration lifetime In case of Mobile IP users, the PPP inactivity timer is ignored by AR and Mobile IP registration lifetime is used instead of PPP session timer. This means in case of mobile IP users, none of the PPP timers need to be maintained and hence the PPP context is completely static. In case of simple IP, these timers are maintained and the count value of these timers must be transferred as part of PPP context to the new AR. Since, for retransmissions, the values of the timers need to be refreshed and hence updates are required. 6.5. Irrelevant context If the new AR is requiring PPP based authentication or header compression mechanisms different from those used by old AR, the authentication and header compression context information will be irrelevant and SHOULD not be transferred to newAR. 7. Messaging 7.1. General context transfer messaging The message flow for generic context transfer as well as context transfer header, described in [3] applies to PPP. Note however, that the PPP context transfer needs to happen reliably and hence the otherwise optional reliability mechanism for a generic context transfer protocol MUST be applied for PPP. This means the following values in the CT header and payload needs to be configured: -R flag in CT header MUST be set to indicate that the message includes a feature (PPP) that requires reliability. Nakhjiri Internet Draft - Expires May 2003 11 Internet Draft PPP context transfer December 2002 - The feature profile type or FPT for PPP would be called PPT, i.e. PPP profile type. This would be indicated in PPP data option (part of CT payload). -R flag in PPP data option (part of CT payload) MUST be set to indicate PPP reliability requirement. -U flag MUST be set in case PPP timer values are being transferred. In that case Feature Context data timestamp MUST be added as well. -Furthermore 3 new flags are added to the PPP data option to indicate which PPP type parameter is being transferred. L flag: If set, means an LCP parameter option is included. A flag: set, means authentication parameter option included. N flag: set, means network parameter option included. The combination of flags also indicates the type of PPP context transfer scenario (as explained earlier) as follows L A N Scenario 0 0 0 Reserved for Generic scenario 1 0 1 LCP and IPCP parameter transfer 1 1 0 LCP and authentication transfer 1 1 1 Complete PPP parameter transfer 8. Security Considerations General security considerations for context transfer are discussed in details in [3]. PPP context is deemed as sensitive, hence, PPP context transfer must happen in a secure manner based on security associations between the new AR-old AR. Any signaling between MN and newAR (such as context transfer start request) MUST be protected through radio interface security mechanisms. 9. Acknowledgments We are grateful to our colleague Ajoy Singh for discussions on the topics covered in this paper. 10. References [1] J. Kempf, "Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network ",RFC 3374, September 2002. [2] G. Kenward, "General Requirements for Context Transfer", Internet Draft, Internet Engineering Task Force, draft-ietf- seamoby-ct-reqs-05.txt, October 2002. [3] M. Nakhjiri, ęęTime Efficient context Transfer (TEXT)ĘĘ, Internet Draft, Internet Engineering Task Force, draft- nakhjiri-seamoby-text-ct-01.txt, September 2002. [4] James Kempf et al., "Bi-directional Edge Tunnel Handover for IPv6", Internet Draft, Internet Engineering Task Force, draft-kempf-beth-ipv6-00.txt, June 2001 [5] G. Dommety et al, "Fast Handovers for Mobile IPv6", Internet Draft, Internet Engineering Task Force, draft-ietf-mobileip- fast-mipv6-02.txt, July 2001. Nakhjiri Internet Draft - Expires May 2003 12 Internet Draft PPP context transfer December 2002 [6] J. Carlson, ęęPPP Design, Implementation, and DebuggingĘĘ, Addison Wesley Professional, Jan 2001. [7] Simpson, ęęPoint to point protocol", RFC 1661, July 1994 [8] G. McGregor, ęęThe PPP Internet Protocol Control Protocol (IPCP)ĘĘ, RFC 1332, May 1992. [9] V. Jacobson, "Compressing TCP/IP Headers for low speed Serial links," RFC 1144, February 1990. [10 S. Casner and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999 11. Contact Information Madjid Nakhjiri Motorola Inc. 1301 East Algonquin Road, Room 2246 Schaumburg, IL 60196 Phone: 847-632-5030 Email: Madjid.Nakhjiri@motorola.com Ramanna Shreesha Motorola Inc. 1501 West Shure Drive, Arlington Heights, IL 60004 Phone: 847-632-2671 Email: Shreesha.Ramanna@motorola.com Nakhjiri Internet Draft - Expires May 2003 13