Internet-Draft Arup Acharya, C&C Research Labs, NEC USA Expiration Date: Rajiv Dighe, C&C Research Labs, NEC USA January 1998 Furquan Ansari, C&C Research Labs, NEC USA July 1997 IPSOFACTO: IP Switching Over Fast ATM Cell Transport Status of This Memo This document is an Internet-Draft. 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." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document describes a method for mapping IP flows to ATM switches. No signaling is necessary to setup a path through ATM switches. Switch controllers run a IP routing protocol and execute IP forwarding. The Ipsofacto component is responsible for mapping a IP flow to a switched path. The focus of this document is primarily on switching IP multicast. Mechanisms for switching unicast flows are also described. Table of Contents 1. Introduction 2. Basic operation 3. Related Schemes 4. Switch configuration 5. Protocol Independent Multicast-Dense Mode 6. Protocol Independent Multicast-Sparse Mode 7. Switching Unicast flows 7.1 TCP Optimizations 7.2 Fixed Length IP routing tag 7.3 Optimizing Mobile-IP flows 7.4 Aggregation through IP-in-IP encapsulation 7.5 Merging aggregated flows through a multipoint-to-point tunnel 7.6 Handling Route Changes Acharya, Dighe, Ansari Expires: January 1998 [Page 1] 8. Conclusions 9. Security Considerations 10. Intellectual Property Considerations 11. Acknowledgments 12. References 13. Authors' Addresses 1. Introduction IPSOFACTO is a methodology for executing the IP protocol stack directly on ATM switches. The ATM signaling stack is not used. This draft describes how IP multicast and unicast may be mapped directly to ATM switches. The target scenario consists of (a) a cloud of ATM switches running the IP protocol stack and optionally, (b) hosts that are directly connected to this cloud. Each switch in this cloud runs the IP protocol stack along with an Ipsofacto component for mapping IP flows to switched paths. The description in this draft assumes configuration (a). 2. Basic Operation The basic premise of operation for Ipsofacto is that all unused VCs on a input port of a switch are mapped to the switch control processor (Fig. 1). --------------------- | IP | IPSOFACTO | --------------------- | Switch Controller | --------------------- | | \ /|\ \ / | \ \_______unused VC=1 Port1 --/-----\--- Port3 ----------- | /Switch \ |------------ -/---------\- __________/ | \ unused VC=1 | | Port2 | unused VC=1 FIGURE 1 A cell-level switched path for data forwarding is established in the following way. A sender selects an unused VC on an outgoing link to forward the first packet of a new flow. This is received by the switch processor at the downstream end of the link, which then selects Acharya, Dighe, Ansari Expires: January 1998 [Page 2] outgoing links based on its IP routing tables, and an unused VC for each selected link. This first packet is then forwarded by the processor on the selected outgoing links by picking an unused VC on each link (Fig. 2). --------------------- | IP | IPSOFACTO | --------------------- | Switch Controller | --------------------- ========> (IP forwarding) Pkt1 | Pkt1 / | \ / | \.............unused VC=1 Port1 ---/-------- Port3 -----------| / SWITCH |------------ ------ -/--------- | Pkt1.........../ | ----- unused VC=1 | Port2| FIGURE 2 Subsequently, the switch processor adds an entry in the VC tables, <{input port, input VC}, {output port, output VC}>. Following packets are then switched at the cell level, eliminating the need for packet-level forwarding at the control processor. --------------------- | IP | IPSOFACTO | --------- ||--------- | Switch Controller | --------- || -------- | || | || ADD switched path | || (port1, VC=1 --> port2, VC=1) | || |----- ||----| | __\/__|________ -----------| / SWITCH |------------ Port1 |--/---------| Port3 ___________________/ | | Port2| FIGURE 3 In contrast to data packets, which are forwarded through a switched path (following the first packet), a switched path is never created Acharya, Dighe, Ansari Expires: January 1998 [Page 3] for IP "control" messages: typically, IP "control" messages will be sent and received on a predefined "control VC", and will therefore, be forwarded through the switch processor. As a result of processing these control messages, a per-flow forwarding state may be established on the switch processor. Changes in the forwarding state,e.g. pruning an outgoing interface, is then used to modify the switched path (e.g. deleting an from the VC tables). When the forwarding state is removed from the control processor, the corresponding switched data path is released, by marking the input and output VCs as unused. For PIM, the "control" packets are distinguished from data packets, based on protocol number in the IP header. For TCP, the "control" packets may be decided based on flags in the TCP header (SYN/FIN). ICMP packets are always forwarded through the control processor. When an outgoing VC, that is currently in use, is reclaimed back, i.e. marked as 'unused', this action is preceded by marking the VC to be in 'transient' state, sending a RECLAIM message from the upstream to the downstream node, and waiting for a RECLAIM-ACK in reply. When the downstream node receives a RECLAIM message, it marks the corresponding incoming VC as 'unused', responds with a RECLAIM-ACK, followed by sending RECLAIM messages further downstream. The RECLAIM message may need to be re-sent if a RECLAIM-ACK is not received within a specified interval. Once the RECLAIM-ACK is received, the VC is marked as 'unused' at the upstream node. Note that it may not be necessary to send a per-VC RECLAIM and RECLAIM-ACK, and instead, a single RECLAIM and RECLAIM-ACK message may contain multiple VC numbers; this cuts down the inter-switch control traffic at the expense of delayed reclamation. A RECLAIM message is triggered as a result of some protocol action at the controller, e.g. an outgoing branch of a switched path may be removed because a PIM "Prune" message was received. It is not necessary that the RECLAIM is only sent from the upstream to the downstream node; the downstream node may initiate the RECLAIM as well. In this draft, the terms 'marking a VC unused' or 'reclaiming a VC' implicitly imply that RECLAIM and RECLAIM-ACK message exchange has been completed. 3. Related Schemes Unlike MPOA [MPOA], Ipsofacto does not use ATM signaling to setup switched paths for IP flows. Ipsofacto is similar in spirit to Ipsilon's IP switching [Ipsilon] [IFMP] and Toshiba's CSR [CSR]. Ipsilon selects the VC for switching a flow from the downstream node, while CSR selects the VC at the upstream node. Both use a notification protocol (IFMP for Ipsilon, FANP [FANP] for CSR) to inform the upstream/ downstream neighbour of the selected VC. Ipsofacto informs the downstream node of the selected VC implicitly through usage. Other related proposals include Tag-switching [TAG] and ARIS [ARIS]: both pre-establish switched paths based on routing information. Acharya, Dighe, Ansari Expires: January 1998 [Page 4] 4. Switch configuration Each port of a switch is assigned to be an IP interface. Incoming cells on all unused VCs are directed to the control processor. When a packet is received on a unused VC, the incoming VC and port number information associated with the packet is made available to the Ipsofacto layer. Ipsofacto layer keeps track of all unused VCs on each port, and maintains a flow-table which maps a flow to a switched path. e.g. ---> <{input port, input VC}, list of {output port, out VC} pairs> The flow-id is constructed from the source/destination IP addresses and port numbers along with the incoming TTL value on the packet. Although not strictly necessary, we will assume that there is a dedicated control VC between neighbouring switches. Typically, the control VC will be used to forward IP multicast "control" messages (i.e. PIM packets with protocol number 103) between adjacent switches. In effect, each switch together with its IP/Ipsofacto layers appears as a network router to its adjacent switches/hosts. 5. Protocol Operation: Mapping PIM Dense Mode [PIM-DM] flows in Ipsofacto When there exists no forwarding cache entry at a switch controller for a multicast flow, the first data packet for that flow will install a forwarding cache for the flow at the controller, as specified by the protocol operation for Protocol-Independent-Multicast(Dense Mode). The VC# and the port number (selected by the upstream switch controller) on which the data packet is received, is available to Ipsofacto. Additionally, for each outgoing interface in the newly created multicast forward cache, Ipsofacto selects an unused VC to forward the packet to the downstream switch controller. At this time, it adds an entry in the flow-table, mapping the flow-id to a switched path {, list of }, and adds entries in the hardware VC routing tables corresponding to {, list of }. Subsequent packets in the flow are not processed by the controller, and are switched at the cell level making use of the hardware multicast capability of the ATM switching fabric. In essence, the IP multicast routing protocol is used to establish the multicast forwarding state at the switch controller,while Ipsofacto maps this state to a point-to-multipoint VC within the switching fabric. In PIM-DM, the forwarding state for a flow is associated with an expiration timer. This timer is restarted whenever a data packet is being forwarded. However, in Ipsofacto, packets subsequent to the first are not forwarded through the switch controller. Therefore, the rule for handling a timer expiration is as follows: when the timer expires, the controller checks the corresponding switched path for any cell forwarding activity since the last expiration. If cells have been Acharya, Dighe, Ansari Expires: January 1998 [Page 5] forwarded in the interim period, the timer is restarted. Else, both the forwarding state and the switched path are deleted. The list of outgoing interfaces associated with a forwarding cache entry, may be modified by arrival of Prune and Graft messages. The corresponding switched path is modified as follows: for a Prune message, the for the interface on which the Prune is received, is deleted from the VC tables, i.e. the corresponding branch of the point-to-multipoint VC is deleted. If after deletion of the branch, no more outgoing branches remain (i.e. the forwarding state is now a negative cache entry), then the switched path is deleted, and the the incoming VC is marked as unused, i.e. it points to the switch controller. When a Graft message for a group G is received, PIM-DM will add the received interface to the outgoing interface list for all (S,G) forwarding entries. Ipsofacto complements this action, by picking an unused VC and adding a branch to the corresponding switched path, for each of the (S,G) entries modified by the Graft message. If the (S,G) entry is a negative cache entry, then no switched path will exists for the (S,G) entry and Ipsofacto will not take any action; a new switched path will be created when with the arrival of the first packet. Note that Ipsofacto does not change PIM protocol actions associated with PIM control messages; Ipsofacto only determines how the resulting multicast forwarding state needs to be mapped to a switched path. Ipsofacto supports Distance-vector multicast routing protocol (DVMRP) [DVMRP] in a similar fashion. 6. Mapping PIM Sparse Mode [PIM-SM] operation under Ipsofacto PIM-SM creates a shared forwarding tree rooted at a Rendezvous Point (RP) with receivers at the leaves. It allows for individual receivers to bypass the shared tree and instead receive data packets on a source-specific tree. Unlike PIM-DM, forwarding entries at intermediate routers are created by sending explicit Join messages towards the RP (shared tree) or the source (source specific tree), from last-hop routers. Ipsofacto maps the shared forwarding entry on the RP-tree to per-source switched paths at intermediate switches. This is a slight departure from traditional packet-level routers which maintain a common (*,G) packet-level multicast forwarding state: under Ipsofacto, the forwarding state at the switch processor is shared by all (*,G) flows, but cell-level switched paths are kept separate for each (S,G) flow. The reason for separating the switched paths is that PIM-SM uses the shared tree to reach all receivers by default, while simultaneously using part of the shared tree to reach a subset of the receivers for specific senders. Therefore, an intermediate node on the tree may contain forwarding entries of the form (S,G) (with RPT-bit set) and (*,G) : though the incoming interface for both entries may be the same, their outgoing interfaces will differ. The decision whether Acharya, Dighe, Ansari Expires: January 1998 [Page 6] to use a (S,G) entry or (*,G) entry is taken on a per-packet basis, using the source address of the packet. But, such a decision cannot be made when forwarding data (cells) in a switched path, since the data packet is not forwarded through the switch processor . Hence, under Ipsofacto, instead of using a common point-to-multipoint switched path, a separate switched path is used for each multicast flow. Under Ipsofacto, the first data packet for a multicast flow is handled similarly for both PIM-DM and PIM-SM. The outgoing interfaces, on which to forward the packet further, is selected from the multicast forwarding entry, and a switched path is added to the VC tables. A corresponding entry (, list of ) is added to the flow-table. Unlike PIM-DM, where each multicast forwarding entry corresponds to a single entry in the flow table, each multicast forwarding entry (e.g. (*,G)) in PIM-SM may be associated with multiple flows (switched paths) and therefore, multiple entries in the flow-table. This one-to-many association between multicast forwarding entries and switched paths is explicitly recorded in the flow-table. When a Prune or a Join message affects a multicast forwarding entry, the associated entries in the flow-table will be modified accordingly, e.g. if an outgoing interface is pruned, then for each switched path associated with that forwarding entry, the corresponding will be deleted from the switched path. Analogously, for a Join, an unused VC will be selected on the outgoing port (interface) and added to the switched paths associated with the affected forwarding entry. There are two special interactions that need to be considered for PIM-SM. The first occurs when an intermediate router is in the midst of switching from the shared tree to a source specific tree for a particular (S,G) flow. When the first data packet arrives on the source-specific tree, PIM-SM triggers a Prune message to be sent on the shared tree. Under Ipsofacto, this implies that the existing flow-specific switched path associated with the shared tree will no longer be used: the switched path (and the flow table entry) may directly be reclaimed when the Prune message is sent, or allowed to time out. Note that the arrival of the data packet on the source-specific tree will lead to a new switched path being setup. The second interaction occurs at the Rendezvous Point (RP). The RP may receive data packets from a sender either encapsulated as unicast (Register) packets or as native multicast (which typically happens when the RP has joined the source-specific tree). In the former case, the RP cannot created switched paths for specific flows: it must decapsulate the packet first. Further, the flow table entry will now contain a list of pairs; there is no incoming port,VC. For packets belonging to the same flow, the RP must use the same VC on a outgoing port for successive packets. This VC is recorded in the flow table. In the latter case, i.e. when the RP receives a native multicast packets, it creates a switched path as mentioned earlier. Acharya, Dighe, Ansari Expires: January 1998 [Page 7] 7. Switching unicast flows Mapping the first data packet of a unicast flow to a switched path is similar to that for a multicast flow. IP routing determines the outgoing port, Ipsofacto selects an unused VC on that port and adds a switched path {, }. Unlike the case for multicast, where PIM control messages are implicitly used to refresh the switched path, switched paths for unicast flows require a separate refresh protocol. The downstream endpoint of a switched path, periodically monitors traffic on the , checks if the received packet header matches the expected header, and if so, sends a REFRESH message to the upstream node. Intermediate nodes need only forward the REFRESH message upstream; it is not necessary to locally monitor traffic activity. When the downstream endpoint of a switched path decides not to send a REFRESH message upstream, it may optionally send a RECLAIM instead to speed up the process of path teardown. Other alternatives to refresh the switched paths are also possible, such as using IFMP or FANP for refreshing the switched unicast paths. 7.1 Optimizations for TCP flows For TCP flows, data transfer is preceded by a three-way handshake. Under Ipsofacto, the switched path is setup when the first packet (SYN) is forwarded; thus, an end-to-end switched path is available prior to data transfer. The teardown of the switched path (i.e marking the switched path VC as unused at each hop) can be hastened by sending the FIN and the ack to the FIN packets through the switch controller instead of the switched path, i.e these packets are treated as "control" packets. The switched path can be reclaimed at a node after the FIN from each endpoint, and the corresponding acks have been forwarded through the controller. This optimization works only at nodes where the forwarding path for the TCP flow is symmetric, i.e. the incoming port for one direction of the flow is same as the outgoing port for the reverse direction, and vice-versa. 7.2 FLIRT (Fixed Length Ip Routing Tag) The first packet of a flow requires an IP routing table lookup at each hop within the Ipsofacto cloud. This longest-prefix match can be replaced by an exact match on fixed number of bits by attaching a fixed-length tag with each packet. The tag-switching architecture [TAG] uses a tag distribution protocol [TDP] to distribute a consistent set of tags. However, when using ATM switches as Tag-switch-routers (TSR), the tag also defines the VC on which the packet is forwarded under the Tag Switching architecture. Under Ipsofacto, the VC selected for forwarding a packet is decoupled from the tag: the VC selection is implicitly by usage, as explained earlier. Regardless of the VC selected on the outgoing link, the upstream switch may optionally insert a FLIRT before the IP packet Acharya, Dighe, Ansari Expires: January 1998 [Page 8] within a AAL5 frame. (Absence of FLIRT is represented by zero-ing out the bits of the fixed length field). The FLIRT on an incoming packet is then used to decide the outgoing FLIRT and the outgoing port without doing a IP table lookup. Before forwarding the packet, the FLIRT is replaced with the new value. If the FLIRT is absent (as may be the case when the first packet is lost), normal IP route lookup is performed. In future, the FLIRT may be extended to hold additional fields, e.g. id of the ingress point to the Ipsofacto cloud, flow type (host pair, port pair, IP-in-IP), QoS parameters. 7.3 Optimizing Mobile-IP flows In scenarios where a switch processor acts as the home agent for a mobile host[Mobile-IP], it may optionally speed up the process of tearing down a switched path (leading to the previous location of the mobile host). For flows initiated from a correspondent host, the packet is addressed to the mobile host's home address, which is then intercepted by the home agent when the mobile host is not at home. The home agent then forwards the packet after encapsulating with the mobile host's current foreign address. Under Ipsofacto, this leads to two switched paths, one from the correspondent host to the home agent and the second, from the home agent to the mobile's current location. The second switched path is setup by using the outer source/destination address of the encapsulated packet as the flow-id (i.e there are no transport port numbers), and in effect, aggregates all flows to the mobile into a single switched path. When the mobile host changes its foreign address, it must send a Registration Notification to its home agent; the home agent replies with Registration Reply to the mobile host's foreign address. If the registration is accepted, then the switched path leading to the mobile host's previous foreign address is no longer useful. In this situation, Ipsofacto may optionally send RECLAIM messages to the downstream nodes of the existing switched paths leading to the mobile host's previous location. The new switched path is automatically setup when the first packet addressed to the mobile host's new foreign address is forwarded. For each incoming flow, in general, it is not possible to bridge to the incoming switched paths and outgoing (aggregated) switched path, since the home agent must encapsulate each packet with the mobile's foreign address. Specific optimizations are presently under study. 7.4 Aggregating multiple unicast flows into a single switched path As the previous section points out, it is possible to use IP-in-IP mechanism to aggregate multiple flows with a common pair of entry and exit points into the Ipsofacto cloud. This requires support from the routing protocol operating in the Ipsofacto cloud, for the entry point Acharya, Dighe, Ansari Expires: January 1998 [Page 9] to learn the exit point for a given flow; all flows with a common exit point can then be aggregated using IP-in-IP encapsulation. It is also possible to use VP switching within the Ipsofacto cloud, instead of using IP-in-IP encapsulation. In this case, the entry router would assign a different VC# for a new flow, but assign a VP# already in-use for flows that share a common exit point. The VPI field is used to switch flows with a common entry and exit routers, within the cloud, while the VCI field is used to locally demultiplex individual flows at the exit router. This would require the exit router to "learn" and cache the flow-to-VC mapping: when a new flow is received at the exit router for which it has no flow-to-VC binding, it installs such a binding from the IP header and the incoming VC. For each VC that is bound to a flow, it must then periodically reassemble cells from that VC to a packet and refresh/replace the corresponding flow-to-VC binding. Alternatively, a specific VC may be reserved within each VP for the entry point to periodically update/refresh the exit point of current flow-to-VC bindings. 7.5 Merging encapsulated flows: multipoint-to-point aggregation The previous sub-section briefly outlined how multiple flows with common entry and exit points may be aggregated to a single flow using IP-in-IP encapsulation. Multiple such flows, each from a different entry point, but with a common exit point out of the Ipsofacto cloud, may also be merged in the following way: at a switch N, which has an existing switched path for an IP-in-IP flow F to exit point B, may select the same outgoing VC as F for a new flow F1 to the same exit point B. First, this requires VC-merge capability at intermediate switches to avoid cell-interleaving. Second, when the REFRESH message from B is forwarded on the reverse path (as that of the switched path), a hop-count needs to be included in the message, which is incremented after each hop. This enables B to decide if the remaining TTL value on the new incoming flow is no less than the hop-count on the REFRESH message. If so, the incoming flow may be merged into the existing flow. Third, at each merge point, such as N, traffic activity on each incoming branch needs to be monitored periodically. When a REFRESH message is received from the downstream node, N forwards it along each incoming branch after incrementing the hop count if there was traffic activity on that branch within the last k periods. 7.6 Routing table changes/ Loop detection and/or avoidance Solutions for efficiently handling changes in IP routing tables require further study. One approach is to leave an existing switched path untouched in spite of a change in the corresponding IP route, if intermediate switch controllers on the path continue to receive REFRESH messages from downstream. Alternatively, when a routing table entry is updated, all affected switched paths may be forced to go through IP forwarding by marking the incoming and outgoing VC(s) of the path as unused. Acharya, Dighe, Ansari Expires: January 1998 [Page 10] 8. Conclusion This draft presented a scheme for mapping IP flows to ATM switches, with special emphasis on IP multicast. Mechanisms for mapping unicast flows, refreshing unicast switched paths, handling flows leading to mobile hosts and fixed length tags to speed up routing were outlined. 9. Security Considerations Security considerations are not addressed in this document. 10. Intellectual Property Considerations NEC may seek patent or other intellectual property protection for some aspects discussed in this document. 11. Acknowledgments The authors would like to acknowledge the following people for discussions on the contents and/or inputs to this draft: Dipankar Raychaudhuri, Kojiro Watanabe, Bala Rajagopalan, Kazuhiko Isoyama, Toshiya Aramaki, Ajay Bakre, Atsushi Iwata and Hiroshi Suzuki. The authors thank Hideyuki Sakaguchi, Joe Darabpour, Bun Mizuhara, and Youichi Ohteru for supplying us with switch software for prototyping Ipsofacto. 12. References [DVMRP] T. Pusateri, "Distance Vector Multicast Routing Protocol", Internet Draft , Juniper Networks, February 1997 [TAG] Y. Rekhter, B. Davie, D. Katz, E.Rosen, G. Swallow, "Cisco Systems' Tag Swicthing Architecture Overview", RFC 2105, Cisco Systems, Inc., February 1997 [TDP] P. Doolan, B. Davie, D. Katz, Y. Rekhter, E. Rosen, "Tag Distribution Protocol", , Cisco Systems,Inc., May 1997 [FANP] K. Nagami, Y. Katsube, Y. Shobatake, A. Mogi, S. Matsuzawa, T. Jinmei, H. Esaki, "Toshiba's Flow Attribute Notification Protocol (FANP) Specification", RFC 2129, Toshiba R&D Center, April 1997 [CSR] Y. Katsube, K. Nagami, H. Esaki, "Toshiba's Router Architecture Extensions for ATM : Overview" , RFC 2098, Toshiba R&D Center, February 1997 [ARIS] Arun Viswanathan, Nancy Feldman, Rick Boivie, Rich Woundy, "ARIS: Aggregate Route-Based IP Switching", Internet-Draft, , IBM Corp., March 1997 Acharya, Dighe, Ansari Expires: January 1998 [Page 11] [IFMP] P. Newman, B. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall, "Ipsilon Flow Management Protocol Specification of IPv4 Version 1.0", RFC 1953, Ipsilon,Sprint, May 1996 [Ipsilon] P.Newman, G. Minshall and T. Lyon, "IP switching: ATM Under IP", Submitted to IEEE/ACM Transactions on Networking [PIM-SM] D.Estrin et al. "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2117 [PIM-DM] Steven Deering et. al. "Protocol Independent Multicast version2, Dense Mode Specification", , IETF Draft, May 1997 [MPOA] ATM Forum, "Multiprotocol Over ATM version 1.0 (Baseline Text Version 16)", Andre N. Fredette, Editor. [IPIP] C. Perkins, "IP Encapsulation within IP", RFC 2003, October 1996 [Mobile-IP] C. Perkins, Editor, "IP Mobility Support", RFC 2002, October 1996 13. Authors' Addresses Arup Acharya C&C Research Labs, NEC USA 4 Independence Way, Princeton NJ 08540, USA Phone: +1 609 951 2992 Email: arup@ccrl.nj.nec.com Rajiv Dighe C&C Research Labs, NEC USA 4 Independence Way, Princeton NJ 08540, USA Phone: +1 609 951 2982 Email: rsd@ccrl.nj.nec.com Furquan Ansari C&C Research Labs, NEC USA 4 Independence Way, Princeton NJ 08540, USA Phone: +1 609 951 2965 Email: furquan@ccrl.nj.nec.com