One document matched: draft-koodli-seamoby-hc-relocate-02.txt
Differences from draft-koodli-seamoby-hc-relocate-01.txt
Seamoby Working Group Manish Tiwari (Editor)
INTERNET DRAFT Trapeze Networks
23 Jun 2003 Rajeev Koodli
Charles E. Perkins
Communication Systems Laboratory
Nokia Research Center
Context Relocation for Seamless Header Compression in IP Networks
draft-koodli-seamoby-hc-relocate-02.txt
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.
This document is an individual submission for the seamoby Working
Group of the Internet Engineering Task Force (IETF). Comments should be
submitted to the seamoby@cdma2000:org mailing list.
Distribution of this memo is unlimited.
Abstract
In networks with bandwidth constraints, such as wireless cellular
networks, compression of IP and transport headers may be employed to
obtain better utilization of the available spectrum capacity. When
header compression is used along with handovers in such networks,
the header compression context needs to be relocated from one IP
access point (i.e., a router) to another in order to achieve seamless
operation. In this document, we propose a mechanism to achieve this
compression context relocation using the framework defined in [3] for
enabling authorized context transfers during node based mobility.
Contents
Status of This Memo i
Abstract i
1. Introduction 2
2. Terminology 3
3. Compression Profiles and Compression Profile Types 4
3.1. Handover Uplink and Downlink CPT . . . . . . . . . . . . 6
3.2. New-IP-Address-Uplink Extension . . . . . . . . . . . . . 6
3.3. Tunneling Extension for Downlink . . . . . . . . . . . . 8
3.3.1. Extension for packets tunneled to MN's new IP
Address . . . . . . . . . . . . . . . . . . . . . 8
3.3.2. Handling packets tunneled to MN's New Access Router 9
4. Compression Context Transfer with Handover signaling 10
5. Header Compression Option Processing Rules at Routers 11
6. Message Formats 12
6.1. Header Compression Context Transfer Reply Option . . . . 13
7. Configurable Parameters 15
8. Security Considerations 15
9. IANA Considerations 15
A. Context Transfer Data Reply Message Status codes 16
A.1. Compression Profile Unavailable Acknowledgment Code 16
A.2. Resource Unavailable Error Code . . . . . . . . . . . . . 17
A.3. Bad Format Error Code . . . . . . . . . . . . . . . . . . 17
Addresses 19
1. Introduction
In IP networks, header compression may be employed to obtain
better utilization of the link layer for delivering useful payload to
applications. Such header compression may include the IP layer and the
transport layers such as UDP/RTP and TCP, and in the future, perhaps
application layers (such as http). A good example of a network that
may employ header compression is a cellular network where the limited
link bandwidth makes the use of header compression quite compelling. In
such a network, a Mobile Node (MN), which is attached to the cellular
network through an air interface, could change its point of attachment
(and hence potentially the IP access router as well) due to mobility
of the user. This device mobility then requires transfer of header
compression state from one network element to another in order to
seamlessly continue existing compression contexts.
Consider the scenario shown in Figure 1. Prior to handover, the
Previous Access Router(pAR) maintains a compression context for both the
downlink and uplink packets. When handover takes place, for seamless
operation, the New Access Router(nAR) must have appropriate compression
state. When it does not possess this state, some uplink packets can get
discarded while downlink packets are sent uncompressed until context is
re-established at the nAR.
| +------------+
+-+ <.... | Previous | <==== < ====>: Uncompressed
| | ---------- | Access | ------ > ----\ packet stream
+-+ ....> | Router | ====> < \ ....>: Compressed
MN | (pAR) | \ packet stream
| +------------+ +---------------+
| | IP | Correspondent |
| | Network | Node(CN) |
V | +---------------+
| /
| +------------+ /
+-+ <==== | New | <==== < /
| | ---------- | Access | ------ > ----/
+-+ ....> | Router | <
MN | (nAR) |
.+------------+
.
.
.
.
V discard
Figure 1: Effect of Handover on Header Compression
As an example of the difference that context transfer can make, consider the
following example. In IPv6, the traffic for real time, voice over IP flows
with no header compression consist of a 60 byte IPv6 header, an 8 byte
UDP header, a 12 byte RTP header, and a (approximately) 20 byte payload [1].
With header compression, the traffic consists of a single byte header followed
by the 20 byte payload. Voice over IP packets are typically sent once every
20 to 60 ms. Figuring on a 40 ms. packet transmission rate and no header
compression, a host performing voice over IP requires about 16 kbps just for
IP headers alone, without even considering the data payload. Cellular channels
for ATM-based voice today average about 9.6 kbps, so it would require about
1.6 sec. to transmit just the header. Since establishing a new header context
requires up to 4 packets, a host performing a voice over IP call interrupted by
handover would require approximately 6.6 seconds until the performance of
the channel with header compression was re-established. During this time,
the user will notice gaps and other artifacts in the conversation. With header
compression, transmitting the data payload would require approximately 8 kbps
on a 9.6 kbps channel, well within the channel limitations. If context transfer
can re-establish header compression without requiring the host to perform a full
context re-establishment, the difference in the quality of the perceived voice
signal to the user can be quite dramatic.
Observe that context re-establishment is always an alternative to
context relocation. The crucial distinction is that of performance
benefits that context relocation, if engineered well, could offer to
transport layers. At the same time, it is extremely important to
note that the ability to establish packet forwarding through route
establishment is the basic necessity without which ``treating packets
with feature contexts'' is not feasible. When contexts are not present,
a transport layer can always re-establish them. It, however, cannot
establish basic network layer connectivity, which is handled by the IP
layer mobility process. Hence, any context transfer must not inhibit
the (mobility) process from expeditiously establishing the connectivity.
It should however, be capable of making use of the mobility process to
effect ``fast context transfers''.
This document specifies a mechanism to relocate header compression
state from the pAR to the nAR in order to achieve seamless operation of header
compression during handovers. For this purpose, we make use of the context
transfer framework defined in [3] and specific options for header compression
defined in this document.
As defined here, header compression contexts are created or destroyed
always as a result of application events. In particular, a fresh
compression context is never created except by some event that can be
associated with a change in state related to some application. This
means that new header compression state is typically not created nor is
destroyed as part of a context transfer. We use this observation to
effect a substantial simplification for the control structures needed
during handovers, at the cost of the need for additional specification
for the creation and destruction of header compression contexts. The
specification for the latter protocol operations is outside the scope
of this document; they need to be closely aligned with results to be
obtained in the ``Robust Header Compression'' [rohc] working group.
Furthermore, such protocol specifications should be associated with
an appropriate programming interface in order to be effectively used
by applications.
2. Terminology
We define the following terms for use in this document.
New Access Router (nAR)
The router to which the MN attaches after handover
Previous Access Router (pAR)
The MN's default router prior to handover
New access address (Naddr) The access IP address of the Mobile
Node (MN) when attached to the link served by the New
Router
Previous access address (Paddr)
The access IP Address of the Mobile Node (MN) when
attached to the link served by the pAR
Context Identifier (CID)
A 16-bit unsigned integer that identifies a particular
header compression context.
Compression Profile Type (CPT)
A 16-bit unsigned integer that indicates the type of
header compression (see section 3).
3. Compression Profiles and Compression Profile Types
A compression profile specifies the structure of the state variables
which are used for header compression. The Compression Profile Type
(CPT) provides a way to indicate which compression profile is in use
for a particular packet stream. For seamless header compression, the
compression engines located at separate network nodes must agree on the
structure of these state variables. When the target compression engine
receives the compression state from the appropriate handover message,
it will instantiate an instance of a compression state machine for the
packet stream in question. That new state machine will be created with
the values of the state variables taken from the header compression
option contained in the context transfer message, and interpreted
according to the data structure and format selected by the CPT.
The CPT defined here maps, one-to-one, to the ``Profile'' defined
in [1]. However, a Profile in [1] is embedded within a packet type,
e.g., an IR packet. A CPT on the other hand, is visible to the context
transfer code for demultiplexing the contexts.
Possible types for the CPT are:
0: reserved
1: IPv4 header compression
2: IPv6 header compression
3: IPv4/UDP/RTP header compression
4: IPv6/UDP/RTP header compression
5: IPv4/TCP header compression
6: IPv6/TCP header compression
Each CPT value is allocated by IANA. The size of each of compression
profile is fixed. A value of zero has special meaning in suboption
processing as outlined in Section 6. Note that CPTs may be used in
options and suboptions specified as part of protocols outside the scope
of this document.
We specify the Compression Profiles for uplink (from the MN towards
the nAR) packet streams as well as for downlink (packets destined
towards the MN) during handover. These Compression Profiles, as we
mentioned at the begining of this section, specify the compression
context for the particular CPT.
In the following, we provide the definitions for IPv6/UDP/RTP CPT.
3.1. Handover Uplink and Downlink CPT
The pAR sends the Context Transfer Data(CTD) message containing both
the static chain and the dynamic chain as part of the compression context.
This compression context block is shown in Figure 2. For details
regarding the individual fields in the compression context block, see [1],
section 5.7.7. The CPT type is set to CPT-v6-RTP.
Two new [rohc] Profiles, IR-CT-U and IR-CT-D, are defined to
distinguish these contexts from those normally sent by a mobile node.
The `D' bit MUST be set to one to include the dynamic chain, which
needs to be padded appropriately depending on the entries in the Generic
Extension Header list. Note that the payload only carries the UDP and
RTP static and dynamic header chains. The payload length field is
inferred from the length field of the corresponding CTP message.
When the MN undergoes handover and acquires a new IP address, it MUST
send a new extension specified below. This packet contains the new IP
address of the MN, and other possible extensions defined in Section
5.7.5 in [1].
3.2. New-IP-Address-Uplink Extension
When the compressor module in the MN determines that only its source
address is different for an existing packet stream, it sends this
extension in any appropriate packet. This particular extension is
currently not defined in [1]. We show the existing format in Figure 3
and identify our extension.
TC The IPv6 Traffic Class bit. If set, the extension
includes the new absolute value
HL The IPv6 Hop Limit bit. If set, the extension includes
the new absolute value
DF Don't Fragment bit. Recast to New IP address extension.
If set, the extension includes the new absolute value
NH The IPv6 Next Header bit. If set, the extension includes
the new absolute value
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Type (TBD) ! Length ! CPT-v6-RTP !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Add-CID Octet |1 1 1 1 1 1 0 1| 0-2 octets of CID info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Profile=IR-CT-U| CRC | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ``Static Chain'' |
| [version field, flow label, next header, |
~ previous IP address of the MN, ~
| IP address of the correspondent node] | Uplink
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ context
| ``Dynamic Chain'' |
| [Traffic Class, Hop Limit, |
~ Generic Extension Header List ~
| (e.g., Home Address Destination option) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ``Paload'' |
| UDP static chain |
| UDP dynamic chain |
~ RTP static chain ~
| RTP dynamic chain |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Add-CID Octet |1 1 1 1 1 1 0 1| 0-2 octets of CID info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Profile=IR-CT-D| CRC | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ``Downlink Context'' |
| [Same fields as in Uplink Context |
~ Generic Extension Header List contains routing header ~
| for MIPv6 packets] | Downlink
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ context
Figure 2: Composition of Uplink and Downlink Contexts
IPX The IPv6 Extension Header bit. If set, the extension
includes the new absolute values of extension headers.
NBO See [1]
RND See [1]
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | 1 | S |R-TS | Tsc | I |ip=1 | rtp |
+-----+-----+-----+-----+-----+-----+-----+-----+
| TC | HL | DF=1| NH | IPX | NBO | RND | ip2 | (Inner IP header flags)
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
~ Other fields conditionally present ~
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
~ New IP address ~
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 3: New IP Address Extension
The first byte contains fields defined in [1] as-is. The Don't
Fragment (DF) bit is not applicable to IPv6. We recast this bit
to indicate ``New IP address'', which is included following other
information that may be present. Note that the MN may also send other
updates including Hop Limit, Traffic Class etc.
3.3. Tunneling Extension for Downlink
Sometimes, the pAR may tunnel packet to the MN. For
example, in fast handovers, the pAR tunnels packets either
directly to the MN's new IP address or to the nAR. In basic
mobile ip handovers, the MN may send a binding update to the Previous
Router requesting forwarding packets sent to its previous IP address.
The pAR then tunnels those packets to the MN's new IP
address. In the following, we provide new tunneling extensions that the
nAR uses when it receives packets from the pAR.
3.3.1. Extension for packets tunneled to MN's new IP Address
Observe that the nAR possesses (or should possess) the context
state necessary for compressing packets destined to the MN's previous IP
address. When it receives a packet tunneled to the MN's new IP address,
it must send the information pertaining to the outer IP header to the MN
since the latter does not possess the context for it. The extension in
Figure 4 allows the nAR to send only a subset of the outer header
fields (Traffic Class and Hop Limit fields), thus substantially reducing
the overhead.
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | 1 | S |R-TS | Tsc | I |ip=1 | rtp |
+-----+-----+-----+-----+-----+-----+-----+-----+
| TC | HL |DF=0 | NH | IPX | NBO | RND|ip2=1| (Inner IP header flags)
+-----+-----+-----+-----+-----+-----+-----+-----+
|TC=1 |HL=1 |DF=0 | NH | IPX | NBO | RND | 0 | (Outer IP header flags)
+-----+-----+-----+-----+-----+-----+-----+-----+
| Other fields that may be present |
~ (Seq Num, Timestamp, Inner IP header fields) ~
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| Traffic Class field for the outer IP header |
+-----+-----+-----+-----+-----+-----+-----+-----+
| Hop Limit field for the outer IP header |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 4: Tunneling to New IP Address Extension
When the MN receives the above extension, it recognizes the presence
of a tunneling extension for a packet stream that did not include
encapsulation before. The compression module infers the rest of the
fields. The source IP address is that of its pAR, the
destination address is its own new IP address, the Next Header is IPv6,
Version field is 6 and the flow label is assumed to be zero. Using the
inferred values as well as the received values, the compression module
constructs the outer IP header. The inner IP header is constructed
based on the context present and optionally the values received in the
extension header.
3.3.2. Handling packets tunneled to MN's New Access Router
The pAR may tunnel packets destined for the MN's previous
IP address to the MN's nAR, which in turn forwards the packet
to the MN. In such a case, the nAR processes the inner packet
using the context present and sends the compressed packet alone (without
any encapsulation extensions) to the MN (perhaps with some extensions).
Thus, there is no separate extension necessary for this case.
4. Compression Context Transfer with Handover signaling
In this section, we provide an illustration of how the compression
context defined in the previous section can be carried along-with
handover signaling. We use context transfer protocol for mobile nodes
for our illustration here.
The pAR transfers header compression contexts either upon receiving a Context
Transfer Request (CT Request) from the nAR, or upon receiving an internally
generated trigger (e.g., a link layer trigger). In the first case, the pAR
receives a Context Transfer Request(CT Request) from the nAR. In the CT-Request
message, nAR suplies the MN's previous IP address, the context type for
header-compression, and a token authorizing context transfer
as mentioned in [3]. In response to the CT Request message, pAR transmits a
Context Transfer Data (CTD) message that includes the MN's previous IP address
and the header compression contexts. In the second case, if the pAR receives an
internally generated trigger, it may predictively transmit the CTD message to
the potential nAR.
Sometimes the transfer of compression contexts prior to the MN's
arrival at the New Router may not be possible. In such a case, the MN
may request the New Router to fetch the contexts from the Previous
Router using the Context Transfer Start Request (CTSR) Message.
The nAR in turn, can then send the CT Request message to the pAR to trigger
the transfer of compression state. The context transfer protocol [3] provides
more details on the various scenarios.
5. Header Compression Option Processing Rules at Routers
When pAR receives a CT Request message, it MUST verify the authentication
token of the CT Request according to its security association with the mobile
node. If the authentication token is valid, pAR MUST subsequently
return the requested header compression state as a context block in Context
Transfer Data (CTD) message.
The new access router (nAR) obeys the following:
1. If the required header compression state for the MN is available,
the nAR MUST make the contexts available to the MN as
soon as the authorization (when present) is successful.
It MAY simply start sending the compressed packets.
2. If the compression state requested by a mobile node is not
already available from a CTD message received from the Previous
Router, the nAR MUST formulate the corresponding CT Request message
to obtain the requested header compression state from the Previous
Router either in response to the corresponding Context Transfer Start
Request (CTSR) message from the MN, or in response to an internally
generated trigger.
After sending CT Data message for header compression, pAR MUST maintain
the header compression contexts for HC_CONTEXT_SAVE_TIME in order to recover
from lost CT Data messages. pAR SHOULD also maintain the contexts until
HC_CONTEXT_PURGE_TIME. After that time, pAR MUST purge all context
associated to the mobile node.
6. Message Formats
Header compression options and suboptions are defined below for use in
CT data messages. The general format for the options is shown in Figure 5.
We assume that the 'V' bit specified in the definition of Context data block in
[3] is always set to 0.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HCOpt Type | HCOpt Len | HCOpt Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Header Compression Options, Suboptions,
and Extensions Format
6.1. Header Compression Context Transfer Reply suboption
The Header Compression Context Transfer Reply (HCRep)
suboption is defined for pAR to transfer state to nAR in the CT data
message. The HCRep suboption includes the necessary state
for nAR to ``carry-over'' header compression.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CID | CPT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Compression State Variables ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Header Compression Reply Data Elements
The Option Type and Option Length fields of HCRep are
followed by blocks consisting of [CID, CPT, Header Compression State
variables] tuple(s). Each block has the format illustrated in figure 6.
CID Compression Context Identifier
CPT Compression Profile Type
Header Compression State Variables
Values for header compression state variables, in the
format defined by the CPT
The CID and CPT are 16-bit fields. For a particular CPT, the size of
header compression state variables field is fixed; this allows inclusion
of multiple tuples without requiring a length indicator.
If the suboption length is zero, it indicates that pAR cannot supply
the required header compression state to nAR. When the value of CPT is
zero in a tuple, it indicates that the pAR cannot supply state information
for the associated compression context identified by the CID.
The processing of this suboption depends on the availability of
required header compression state, and is done in accordance with
requirements outlined in subsection 5.
7. Configurable Parameters
The nodes supporting mobility defined in this document SHOULD be able
to configure the parameters outlined below as well as those in [4]. Each
table entry contains the name of the parameter and the default value.
Parameter Name Default Value
-------------------------------------------------
HC_CONTEXT_SAVE_TIME 2000 milliseconda
HC_CONTEXT_PURGE_TIME 5000 milliseconds
8. Security Considerations
All context transfer for header compression MUST be secured by use of
the Authentication token specified in all CTP packets [3].
Thus, no additional vulnerability has been introduced.
9. IANA Considerations
The Compression Profile Type (CPT) defined in this document requires
IANA Type numbers.
References
[1] C. Bormann and et al. RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed
(work in progress). Technical report, Internet Engineering Task
Force.
draft-ietf-rohc-rtp-09.txt, 2001.
[2] S. Kent and R. Atkinson. IP Authentication Header. Request for
Comments (Proposed Standard) 2402, Internet Engineering Task
Force, November 1998.
[3] J. Loughney and et al. Context Transfer Protocol.
Internet Draft, Internet Engineering Task Force.
draft-ietf-seamoby-ctp-01.txt, March 2003.
[4] R. Koodli and C. Perkins. A Framework for Smooth Handovers
with Mobile IPv6 (work in progress). Internet Draft, Internet
Engineering Task Force.
draft-koodli-mobileip-smoothv6-01.txt, November 2000.
[5] G. Tsirtsis and et al. Fast Handovers for Mobile IPv6(work in
progress). Internet Draft, Internet Engineering Task Force.
draft-designteam-fast-mipv6-01.txt, February 2001.
A. Context Transfer Data Reply Message Status codes
A.1. Compression Profile Unavailable Acknowledgment Code
Code: 02 (CPT_UNAVAILABLE)
The above code is returned as part of the CTDR message if atleast
one of the CPTs specified in the CT data message are not supported by
the nAR.
A.2. Resource Unavailable Error Code
Code: 01 (RESOURCE_UNAVAILABLE)
The RESOURCE_UNAVAILABLE error is returned when no resources are available.
This code indicates that nAR does not have the resources required to set up header
compression context(s) for this MN. The MN MUST deactivate the previous
compression state. It MAY either start sending full headers in this
case, or it may re-negotiate with nAR to activate a new compression
profile.
A.3. Bad Format Error Code
Code: 03 (BAD_FORMAT)
This error indicates that the context transfer data message was poorly
formatted. If a router does not understand the format of a particular
suboption, it sends a CTDR message with this code.
Acknowledgements
The authors would like to thank James Kempf, DoCoMo USA Labs, for the
numerical example in Section 1.
Addresses
Questions about this memo can be directed to the authors:
Rajeev Koodli
Communications Systems Lab
Nokia Research Center Manish Tiwari
313 Fairchild Drive Trapeze Networks
Mountain View, California 94043 5753 W. Las Positas Blvd.
USA Pleasanton, California 94588
Phone: +1-650 625-2359 USA
EMail: rajeev.koodli@nokia.com Phone: +1-925 474-2278
Fax: +1 650 625-2502 EMail: manish@trapezenetworks.com
Charles E. Perkins
Communications Systems Lab
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA
Phone: +1-650 625-2986
EMail: charliep@iprg.nokia.com
Fax: +1 650 625-2502
| PAFTECH AB 2003-2026 | 2026-04-24 03:10:17 |