6LowPAN Network Working Group Gohel Bakul Chandulal Internet draft Dhananjay Singh Expires: January 30, 2012 Future Internet Team, National Institute for Mathematical Science, Daejeon, South Korea July 25,2011 Global connectivity for 6lowpan draft-singh-6lowpan-global-connectivity-01.txt Abstract This document describes the short AID (adaptation identifier) in place of full IPv6 address, related AID-IPv6 address translation mechanism and frame format of it for effective IPv6 header compression when a IEEE 802.15.4 node communicate with a IPv6 domain. AID generated by IN-node (a node inside the lowpan) for corresponding IPv6 address of OUT-node (a node outside the lowpan), and AID-IPv6 translation table maintained at gateway and IN-node. Conversely packet carries an AID value in place of OUT-node IPv6 address in adaptation header, and translated back to IPv6 at gateway though AID-IPv6 translation table. Also in this document, effective frame format design specified for adaptation layer for global as well as local communication Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current. 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." Chandulal & Singh Expires: January 30, 2012 [Page 1] Internet-Draft Global Connectivity July 2011 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Terminology 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 [RFC2119]. Readers are expected to be familiar with all the terms and concepts that are discussed in "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" [RFC4919], and "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944]. AID: Adaptation Identifier IN-node: a IEEE 802.15.4 node within the PAN (personal area network) OUT-node: Any node outside the PAN, connected with IN-node through IPv6 Domain IN-bound traffic: Flow of packet from outside PAN (OUT-node) to inside PAN (IN-node) OUT-bound traffic: Flow of packet from inside PAN (IN-Node) to outside the PAN (OUT-node) AITT: AID-IPv6 Translation Table Chandulal & Singh Expires: January 30, 2012 [Page 2] Internet-Draft Global Connectivity July 2011 Table of content 1 Problem Statement.................. . . ............3 2 Adaptation Identifier (AID).........................4 2.1 Presence of IN-node link layer address and AID..5 2.2 drawback of use of AID value for IN-node........5 2.3 AID value Generation............................6 2.4 AID field & AITT................................6 3 AID messages & AID values mechanism.................7 3.1 AID messages....................................8 3.2 Mechanism of AID value..........................8 3.3 Time stamping & deletion of AID in AID-IPv6 Translation table...............................8 4 Frame Format........................................9 4.1 6lowpan TCP/IP Stake............................9 4.2 AID-IPv6 address Translation Table (AITT).......9 4.3 Adaptation Layer Header........................10 5 Mobility and Header compression ...................13 6 Header compression efficiency......................15 7 Formal Syntax......................................15 8 Security Considerations............................15 9 IANA Considerations................................16 10 References........................................16 10.1 Normative references..........................16 10.2 Informative Reference.........................16 1. Problem statements 6lowpan developed with aim to provide internet connectivity to lowpan (IEEE 802.15.4 network), so IN-node communicates with OUT-node in IPv6 domain. Maximum physical layer packet size of IEEE 802.15.4 is 127 byte, and it left only 102 byte for layers above the MAC layer. Link layer security further consumes 21 byte. IPv6 header is 40 octets in length, and leaves only 41 octets for upper layer. So HC1 header compression was proposed to reduce the IPv6 header size. Further MTU size of IPv6 packet is over 1280 bytes. So it requires fragmentation and reassembling of IPv6 packet. For these reasons an adaptation layer was proposed to accommodate IPv6 packet over IEEE 802.15.4 network. Chandulal & Singh Expires: January 30, 2012 [Page 3] Internet-Draft Global Connectivity July 2011 +-------------+ +----------+ +---------+ | AID Frame | |Gateway | | IPv6 | | IEEE |<-->|AID<->IPv6|<-->| Network | | 802.15.4 | | | | | +-------------+ +----------+ +---------+ Figure 1. Global connectivity [RFC 4944, RFC 6282] define the IPv6 header compression scheme to reduce the size of IPv6 header, and able to compress 40 byte header minimum up to 2 byte. One byte for header compression filed and one byte for hop limit (inline). Field that cannot be compressed is placed inline next to compressed header within the adaptation frame. When a node communicates across IPv6 internet, it requires full IP address of OUT-node, so full IP address has to put into the inline according to HC1 & 6lowpan_IPHC compression scheme. Due to the state less auto configuration properties, some way we can save 8 byte or 14 byte for a IN-node IPv6 addresses, depending on EUI-64 addressed or 16 bit short address used for IN-node. So actual compression for IPv6 addresses of IN-node and OUT-node are up to 20-26 byte / 32 byte with compression scheme, But it is not efficient compression for global communication. To tackle this problem, In [I-D. Global connectivity in 6LoWPAN] author proposed a short length AID assignment at gateway to map unique IPv6 address to achieve good IPv6 addresses compression for global communication. Conversely, packet within PAN carries short length AID in place of full fledges IPv6 address and convert to full IPv6 address at gateway to route over internet. For IN-bound IPv6 packet, procedure is just reverse. In [I-D. Global connectivity in 6LoWPAN], Author proposed two AID, one for Source and one for Destination and mechanism to generate AID for unique IPv6 address. But, Author does not provide any information regarding frame format with AID, presence of link-addresses in adaptation layer, AID field size as well as mobility scenario and AID mechanism. 2 Adaptation Identifier (AID) In [I-D. Global connectivity in 6LoWPAN] author proposed a two AID value for source and destination node IPv6 address. But Use of AID for an IN-node is inappropriate which cause extra load on adaptation header, extra management and lead to certain difficulties in handling it. AID only require for OUT-node, and translation between AID and IPv6 address take place at gateway. Following session explain AID requirements, size of AID field and AID-IPv6 address translation table (AITT). Chandulal & Singh Expires: January 30, 2012 [Page 4] Internet-Draft Global Connectivity July 2011 2.1 Presence of IN-node link layer address and AID When the frame contains only AID value and does not contain IN-node link layer address, lead to certain issues. Following issues suggest the requirement of link-layer address in adaptation header. (1) In case of any desyncronization between the node and gateway regarding AID value, particularly happen in case of a PAN with multiple gateways and IN-node mobility scenario in which If AID value does not exist at gateway , it cannot reply back without source link layer address. (2) Identify the packet whether it is come from an associate node or not. So each frame SHOULD contain originator IN-node link layer address regardless of AID value. 2.2 drawback of use of AID value for IN-node (1) Due to the stateless auto configurability characteristics of IPv6 address, we can configure IPv6 address from link-layer ID or Interface Identifier of a node and prefix ID of gateway. So use of AID for IN-node is illogical in presence (section 2.1) of IN-node link layer address in adaptation header. (2) 16 bit short ID for a node in PAN was chosen to support 2^16 nodes in PAN. If we use AID for IN-nodes, minimum length of AID field should be 16 bit. Still it is larger and does not provide effective compression Above mentioned reasons (section 2.1 & 2.2) suggests that AID value for IN-node IPv6 address SHOULD not use and link-layer ID of IN-node SHOULD be present in packet. Chandulal & Singh Expires: January 30, 2012 [Page 5] Internet-Draft Global Connectivity July 2011 2.3. AID value Generation In [I-D. Global connectivity in 6LoWPAN] author mentioned that new AID value for IPv6 address is generated by gateway. It works fine in static network and network with single gateways. But, in case of PAN with multiple gateways or mobility within the network, if new AID value is generated by gateway, different gateways generate different AID values for same OUT-node IPv6 address, which complicates the AID value management. Also, it obviates the need of AID generation by gateway each time whenever mobile IN-node visit different network. 2.4 AID field & AITT Now it is clear that AID value SHOULD use for IPv6 address of OUT-node only. But the question is what will be the size of AID field and AITT format. Let's look at different possible scenario. (1) PAN with single or few destinations In many practical situations, data collected though sensors and send it to one central storage system, so all nodes within the PAN communicate only one or few node outside the PAN. In this scenario, AID table format shown in figure 2, is sufficient and efficient. As there are only few destinations, shorter AID field required. +---------------------------------+ | AID | IPv6 address | Time-Stamp | +---------------------------------+ Figure 2 AITT without Link-Layer ID (2) PAN, with multiple destinations In this scenario, above mentioned table format can work, but due to larger no. of destinations, require larger AID field size. But we can reduce the no. of AID values requirement hence size of AID field by taking the AID value in combination with link-layer ID of IN-node (fig 3). In another term, maximum number of connections to OUT-node, from an IN-node is always less than or equal to connection from all IN-node. This scheme is particularly yielding when different IN-nodes or group of IN-nodes communicate with corresponding different OUT-nodes. It is also efficient for first scenario. Chandulal & Singh Expires: January 30, 2012 [Page 6] Internet-Draft Global Connectivity July 2011 (3)Combination of link-layer ID with AID value in AITT increases the uniqueness of AID value in AITT (fig 3). +-------------------------------------------------+ | Link-Layer ID | AID | IPv6 address | Time-Stamp | +-------------------------------------------------+ Figure 3. AITT without Link-Layer ID 3. AID messages & AID values mechanism 3.1 AID messages 3.1.1 AID update message When, IN-node get AID request message (contain IPv6 address of OUT-node) from gateway, IN-node search for existing AID value for corresponding IPv6 address. If it does not present, IN-node generate a new AID value. IN-node sends Updated information to gateway through AID update message. AID update message contains AID value, IPv6 address, time-stamp and hope limit information. Similarly, when gateway is received IPv6 request message from IN-node, gateway reply back IPv6 address corresponding to AID value through AID update message. 3.1.2 AID request message When AID value does not exist for IPv6 address of IN-bound packet at gateway, it sends the AID request message to IN-node for AID value corresponding to IPv6 address. This message contains IPv6 address and in response, IN-node returns the corresponding AID update message. AID request message contains IPv6 address. Chandulal & Singh Expires: January 30, 2012 [Page 7] Internet-Draft Global Connectivity July 2011 3.1.3 IPv6 request message When AID value does not exist at gateway or IN-node on receiving AID frame, receiving node sends IPv6 request message to sender to request IPv6 address corresponding to AID value. In response, sender node return AID update message. IPv6 request message contains AID value. 3.2 Mechanism of AID value 3.2.1 For Out bound traffic 1. When IN-node wants to send packet to OUT-node, first it checks the existence of AID value for OUT-node IPv6 address in AITT. 2a. if AID value Present at IN-node for corresponding IPv6 address, it send the AID packet to gateway. But, if gateway does not have AID value, it sends IPv6 request message for corresponding AID value to IN-node, and IN-Node reply back AID Update message 2b. if AID value does not present at IN-node, it generates the new AID value for OUT-node IPv6 address and send AID update message to gateway. 3.2.2 For In bound traffic 1. When Gateway received the packet from OUT-node, it checks the existence of AID value for OUT-node IPv6 address in AITT. 2a. if AID value present at gateway, it send the packet in AID frame to IN-node. But, if IN-node does not have AID value, it send request message to gateway for corresponding IPv6 address. Gateway reply backs the AID update message. 2b. if AID value does not present at gateway, it requests a AID value for given IPv6 address to IN-node, and IN-node reply back AID update message. 3.3 Time stamping & deletion of AID in AID-IPv6 translation table Whenever IN-Node generate AID, it also time-stamp the AID value simultaneously and send it with AID update message. Whenever transaction (during packet transmission) or updation take place in AITT, time-stamp field set back to initial value in correspond AID value. If AID value does not utilized for some threshold period, corresponding row is deleted. Chandulal & Singh Expires: January 30, 2012 [Page 8] Internet-Draft Global Connectivity July 2011 4 Frame Format 4.1. 6lowpan TCP/IP Stake In figure 4, TCP/IP stake shown for AID based 6lowpan. Physical and MAC layer are similar to IEEE 802.15.4 standards. Adaptation layer lies above the MAC layer and use AID frame structure for OUT-node (global communication) and Local frame structure for IN-node. Routing is take place at adaptation layer and mesh under & mesh over routing is an administrator choice. in both case, packet has to reach at adaptation layer. Transport layer mainly use compressed header format. Security layer is optional. Application layer keep at top above, and only required application are kept according to need. +-------------------------------------------------+ | Application Layer | | (Restricted Applications ) | |-------------------------------------------------| | Security Layer | Transport Layer | | (Optional) | (Compressed Header) | | |--------------------------------| | | |AID Frame |Mesh | | | Adaptation |----------|under | | | Layer |LocalFrame|routing | |-------------------------------------------------| | MAC layer (IEEE 802.15.4) | |-------------------------------------------------| | PHY layer (IEEE 802.15.4) | +-------------------------------------------------+ Figure 4. AID based 6lowpan TCP/IP stake 4.2 AID-IPv6 address Translation Table (AITT) AITT translate the IPv6 address to corresponding AID value and vice versa (fig 5 & 6). It is present in IN-node as well as gateway, but AID frame to IPv6 packet and vice-versa translation take place at the gateway using AID-IPv6 table. Chandulal & Singh Expires: January 30, 2012 [Page 9] Internet-Draft Global Connectivity July 2011 +------------------------------------------------------+ |Link-Layer ID|Bit|AID|IPv6 address|hop limit|Timestamp| +------------------------------------------------------+ Figure 5. AITT for Gateway +----------------------------------------+ |Bit|AID|IPv6 address|hop limit|Timestamp| +----------------------------------------+ Figure 6. AITT for IN-Node Link Layer ID of IN-nodes: 16 bits short ID or 64 bit Interface Identifier of IN-node Bit: Length of AID field in bits (1,2,4,8 bit(s)) AID: AID value IPv6 address: IPv6 address of corresponding OUT-Node Hop limit: Hope limit for out bound traffic Timestamp: Time of last use of AID 4.3. Adaptation Layer Header Adaptation layer header contains Dispatch field, followed by AID or Local mesh frame and fragmentation header which is optional (fig 7). Dispatch value gives Idea about which type of frame following next (fig 8). Fragmentation header is optional, only present when payload is large and required fragmentation. It is according to [rfc 4944] +--------------------------------------------+ | Dispatch | AID, LMF | Fragmentation header | | | BCH | (optional) | +--------------------------------------------+ Figure 7. Adaptation layer header 4.3.1 Dispatch field Dispatch field specify the frame type or field carried in to the adaptation header that follow after the dispatch. Chandulal & Singh Expires: January 30, 2012 [Page 10] Internet-Draft Global Connectivity July 2011 +----------------------------------------------------+ | Dispatch | Header Type | |----------------------------------------------------| | 00 000000 | NALP - Not a lowpan frame | | 01 000001 | IPv6 -IPv6 uncompressed frame | | 01 000010 | AID_1 -AID frame_1_bit_field_size | | 01 000011 | AID_2 -AID frame_2_bit_field_size | | 01 000101 | AID_3 -AID frame_4_bit_field_size | | 01 000110 | AID_4 -AID frame_8_bit_field_size | | ********* | Reserved | | 10 100001 | BCF - Broadcast Frame | | 10 100011 | LMF - Local Mesh Frame | | ******** | Reserved | | 01 111111 | ESC - Additional dispatch byte follows | +----------------------------------------------------+ Figure 8. Dispatch Type 4.3.2 AID frame Whenever communication takes place between the IN-node and OUT-node, AID frame is used. Frame contains the AID value for corresponding IPv6 address. +-----------------------------------------------+ | 01 000010 | | | | 01 000011 | AID frame | Fragmentation header | | 01 000101 | header | (optional) | | 01 000110 | | | +-----------------------------------------------+ Figure 9 (a). Dispatches for AID frame Chandulal & Singh Expires: January 30, 2012 [Page 11] Internet-Draft Global Connectivity July 2011 +---------------------------------------------------------+ |Bound| I | G | NH | Fr |hopeleft| LL ID | AID | | (1) |(1)|(1)| (4)| (1)| (4) | (16 or 64) | (1,2,3,8) | +---------------------------------------------------------+ Figure 9 (b). AID frame Header Bound: 0- Outbound packet from PAN (Forward to Gateway) 1- Inbound packet to PAN (Forward to IN-node at Link Layer ID address) Fr: 0- No fragmentation header follows 1- fragmentation header follows I: 0- 16 bit short ID in II ID field 1- 64 bit interface identifier in II ID field G: 0- Any gateways 1- Gateway specified (next to the AID field) NH: First Bit 0- No Traffic class & flow label 1- Traffic class & flow label field in Inline Second Bit 0- no more header compression 1- HC2 header compression bits Third & Fourth Bits 00- Additional header follow 01- UDP 10- ICMP 11- TCP Hopeleft: (4 bits) Hope left within the PAN LL ID: 16 bits short ID or 64 bits Link Layer ID AID: AID value Chandulal & Singh Expires: January 30, 2012 [Page 12] Internet-Draft Global Connectivity July 2011 4.3.3 If gateway specified (G set 1) +----------------------------------------+ | Dispatch | AID header | F | Gateway ID | +----------------------------------------+ Figure 10. Gateway specified AID frame header F: 0- 16 bit address of Gateway 1- 64 bit address of Gateway Gateway ID: 16 bits or 64 bits address of Gateway 4.3.4 Local Mesh Frame Whenever communication occurs between the IN-nodes, Local mesh Frame should use. As in this scenario, AID is not required. +----------------------------------------------------+ | 01 100010 | LMS header | Fragmentation Header | | | | (optional) | +----------------------------------------------------+ Figure 11. (a) Local mesh frame +---------------------------------------------------+ | V | F | NH | Fr |hopeleft| source | Dest | |(1)|(1)| (4)| (1)| (4) | (16 or 64) |(16 or 64) | +---------------------------------------------------+ Figure 11. (b) LMS header V: 0- 16 bit originator ID in source field 1- 64 bit EUI ID in source field F: 0- 16 bit originator ID in Destination field 1- 64 bit EUI ID in Destination field NH: Same as in section 4.3.2 Hopleft: Hop count (within the mesh) Source: 16 bits short or 64 bits EUI address of originator IN-node Dest: 16 bits short or 64 bits address of final destination IN-node Chandulal & Singh Expires: January 30, 2012 [Page 13] Internet-Draft Global Connectivity July 2011 4.3.5 Local Broadcast frame Whenever mesh routing required flooding mechanism, for that broadcast header is defined in figure xx. It contains dispatch type followed by sequence number of message. +--------------------------+ | 01 100000 | Sequence No. | +--------------------------+ Figure 12. Local Broadcast Header Sequence No: This 8-bit field SHALL be incremented by the Originator whenever it sends a new mesh broadcast 5. Mobility and Header Compression Aforesaid, IPv6 Header compression scheme in 6lowpan mainly relies on compression of source IPv6 address using stateless auto configuration properties and short ID of node. When node is mobile, network prefix is going change when node enters into another network. Different protocols for mobility management such as MIPv6, and PMIPv6 [RFC 3775, RFC 5213] have been proposed and mainly rely on the source node prefix information. Recently, location ID separation protocol [I-D farinacci-lisp] which employs host ID apart from network prefix for management of mobility. As the compressed packet (RFC 6282) does not have any such network information during global communication, 6lowpan does not support mobility with compressed packet. It is possible that when node moves to another network, and node associates with gateway, they exchange necessary information require for node identity and mobility. In mobility scenario, it is important identify any change in network or network identify that the packet from associate node or not. Different information from which we can know the change in network as follow. - Neighbor or gateway discovery: As neighbor node changes frequently in mobility, whenever new neighbor node comes across to it, they exchange the network information. Whenever network changed, necessary messages for network information and association are carried out. But still individual packet does not contain any network information. - Security: if network employs security for association and transmission of packet, then it is possible to identify new node in network, and necessary information is exchanged. If network uses the same security across the different networks (single owner) or do not uses the security at all then we cannot get the network association information. - Specify gateway in the packet: if we specify the gateway (short ID) through which packet is routed, provides current network information and node informed if encounter a network with different gateway and then necessary association information is exchanged. But there is existing a chance that two consecutive gateway have same (short ID) and probability is 2-16 , if gateway is assigned 2 byte short ID randomly, that two consecutive gateway have same (short ID). - Host ID: Recently Locator /Host ID based approached for mobility is proposed. As the host ID is generally two long, we cannot include in packet. - Prefix in packet: if we keep the prefix into the packet, we cannot achieve efficient compression. Inclusion of Gateway short ID into the every packet of mobile node seems to be more reasonable. In this case, as described in section 4.3.2 & 4.3.3, G field set to 1 and gateway Id included into the packet. When mobile node reaches to another network and notified, node sends the association request to gateway along with home network prefix or Host ID. In return to it, gateway assigns new short ID to Node and sends it with network prefix to node. Then node sends the IPv6 address and associate AID value to newer gateway. This information is maintained in database. Remaining mobility management is carried out using MIPv6, PMIPv6 or Location/ID based approaches. Chandulal & Singh Expires: January 30, 2012 [Page 14] Internet-Draft Global Connectivity July 2011 6. Header compression efficiency. During global communication, as per header compression [RFC 6282], maximum compression of Source and destination address is 18 byte (IN-node short, 2 bytes ID + OUT node IPv6 address, 16 bytes) out of 32 byte. While in case of AID based global communication, maximum compression is 2 byte and 1 bit (IN-node short ID, 2 bytes + 1 bit AID) out of 32 byte. Further, 1 byte for dispatch and 5 byte for fragmentation header if presents. It also support the mobility across the different network with efficient header compression. 7. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234[RFC2234]. 8. Security Considerations TBD 9. IANA Considerations TBD 10. References 10.1 Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate requirement Levels", BCP 14, RFC 2119, March 1997. [ieee802.15.4] IEEE Computer Society, "IEEE Std. 802.15.4-2003", October 2003 [RFC4919] N. Kushalnagar, G. Montenegro, C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC4919, August 2007. Chandulal & Singh Expires: January 30, 2012 [Page 15] Internet-Draft Global Connectivity July 2011 10.2 Informative Reference [I-D. Global connectivity in 6LoWPAN] Hyun K. Kahng, Dae-In, Choi, Suyeon, Kim "Global connectivity in 6LoWPAN" draft-kahng-6lowpan-global-connectivity-01.txt, September 30, 2011 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Auto configuration", RFC4862, September 2007 [RFC4944] G. Montenegro, N. Kushalnagar, J. Hui, D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC4944, September 2007. [RFC 6282] J. Hui, Ed., P. Thubert, "Compression Format for IPv6 Datagrams in Low Power and Lossy Networks (6LoWPAN)", RFC 6282, June 2011 [RFC 5213] S. Gundavelli, Ed., K. Leung, V. Devarapalli, Wichorus, K. Chowdhury, Starent Networks, B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC 3775] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6" RFC 3775, June, 2004 [I-D farinacci-lisp] D. Farinacci, V. Fuller, D. Meyer, D. Lewis "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-12.txt, March 2009 Authors Address Gohel Bakul Chandulal Future Internet Team National Institute for Mathematical Scinece Daejeon, South Korea E-mail: gohel@nims.re.kr Dhananjay Singh Future Internet Team National Institute for Mathematical Scinece Daejeon, South Korea E-mail: singh@nims.re.kr Acknowledgement: This work was supported by NAP of Korea Research Council of Fundamental Science & Technology. Chandulal & Singh Expires: January 30, 2012 [Page 16]