Network Working Group V. Narayanan Internet-Draft A. Swaminathan Intended status: Informational Qualcomm, Inc. Expires: January 1, 2010 June 30, 2009 Enhanced Client Support for RELOAD draft-vidya-p2psip-eclients-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 Internet-Draft will expire on January 1, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow Narayanan & Swaminathan Expires January 1, 2010 [Page 1] Internet-Draft E-Client Support for RELOAD June 2009 modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Abstract RELOAD [1] defines a class of devices termed as clients that may attach to peers and use the overlay, without having to provide overlay routing or storage. These devices may attach to the identity owner on the overlay or to any arbitrary peer. This document provides a mechanism to attach to any arbitrary peer with some state on the overlay for routing purposes. This avoids needing application specific means of providing a destination list for contact information for the client and also inherently handles client mobility. Narayanan & Swaminathan Expires January 1, 2010 [Page 2] Internet-Draft E-Client Support for RELOAD June 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Summary of Operation . . . . . . . . . . . . . . . . . . . . . 4 4. Peer-to-Peer Network Protocol for eClient Operation . . . . . 7 4.1. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Leaving the Overlay . . . . . . . . . . . . . . . . . . . 9 4.3. Impact of Churn on eClients . . . . . . . . . . . . . . . 9 4.3.1. Update Messages . . . . . . . . . . . . . . . . . . . 10 4.3.2. eClient Mobility . . . . . . . . . . . . . . . . . . . 10 4.3.3. Graceful DAP Leave on Overlay . . . . . . . . . . . . 11 4.3.4. Abrupt DAP Leave on Overlay . . . . . . . . . . . . . 12 4.3.5. OAP Change due to a New Peer . . . . . . . . . . . . . 12 4.3.6. Graceful OAP Leaves . . . . . . . . . . . . . . . . . 13 4.3.7. Abrupt OAP Leaves . . . . . . . . . . . . . . . . . . 13 4.4. Message Routing at DAP . . . . . . . . . . . . . . . . . . 13 4.5. Message Routing at OAP . . . . . . . . . . . . . . . . . . 13 4.6. eClient and DAP Authorization . . . . . . . . . . . . . . 14 5. Multiple Overlays Considerations . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 8. Normative References . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Narayanan & Swaminathan Expires January 1, 2010 [Page 3] Internet-Draft E-Client Support for RELOAD June 2009 1. Introduction Enhanced Client (eClient) operation allows a node to connect to an overlay via an arbitrary peer on the overlay, without having to use the node that owns its identity. In the design covered by [1], n client always attached to the overlay using its identity owner, termed here as the Overlay Attachment Point (OAP). The downside of this approach is that the client still has to maintain an active IP connection to the OAP, and these two nodes may be topologically very far away. Sometimes, such a connection may not even be feasible due to the presence of NATs. If the client can choose a topologically close node as its attachment point, especially a node it can directly attach to (e.g., via Bluetooth), there may be significant benefits. For instance, the client may be able to attach to multiple overlays using the same node as its attachment point (e.g., a mobile phone may always use a laptop belonging to the same owner). This may be true even when the two devices are not in range of each other to use a direct link for communication. Here, the client does not incur a per-overlay connection overhead and this can result in significant power savings. In short, benefits for an eClient are potential power savings due to having a single connection and lower latency due to potential proximity of the point of attachment to the overlay. Attachment to an arbitrary peer can also be supported in an alternate fashion. For instance, [1] alludes to the client always providing its reachability information in the form of a destination list, including its point of attachment as one of the node ids in the list. The downside of this is that, if the client is mobile, it needs to update all data stored in the overlay with its new contact information, in order to receive request messages coming to it. This can prove to be quite expensive and is undesirable. This draft describes an approach that handles mobility for the client, thereby removing any impact of mobility on the information stored by the client on the overlay. 2. 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 RFC 2119 [2]. 3. Summary of Operation Narayanan & Swaminathan Expires January 1, 2010 [Page 4] Internet-Draft E-Client Support for RELOAD June 2009 +--------+ +--------+ +--------+ | Node 20|-----------| Node 30|------------| Node 40| +--------+ +--------+ +--------+ | | | | +--------+ +--------+ +--------+ | Node 70|-----------| Node 60|------------| Node 50| +----+---+ +--------+ +---+----+ | | +---------+ | Node 24 | +---------+ Node 24: eClient Node 20: Overlay Attachment Point (OAP) Node 70: Direct Attachment Point (DAP) Figure 1: eClient, OAP and DAP Enhanced clients (eClients) are functionally similar to peers. The eClient has one route for the overlay. An eClient attaches to an overlay using a node that does not own its identity. This node is termed the Direct Attachment Point (DAP). The node that owns the eClient's identity is termed the Overlay Attachment Point (OAP). The eClient only maintains connectivity to the DAP. When the eClient connects to the DAP via an interface such as Bluetooth, an active IP connection may not even be required - the connection may be setup when there are datagrams to send to/from the eClient. When there is an active IP connection to the DAP, the Client is also expected to send the ping packet (to keep the connection alive) to the DAP. The eClient may not actively send ping packets if it can track the connection via other means (e.g., if it is over Bluetooth and there are no intervening NAT nodes, an active ping should not be required). Behavior on such links, however, is not specified in this document. The OAP is not always present in message exchanges with the eClient. The OAP is in the path for any message sent to the eClient that is either a response routed in an asymmetric fashion or an unsolicited request. The join process of an eClient as specified in this document differs slightly from that documented in [1]. The discovery of the DAP itself is outside the scope of this document. The DAP serves as the bootstrap peer for the joining process. The join process results in creation of state both at the DAP and the Narayanan & Swaminathan Expires January 1, 2010 [Page 5] Internet-Draft E-Client Support for RELOAD June 2009 OAP. This is part of the reason that acting as a DAP is at the discretion of a given node. Nodes may offer to act as a DAP to specific eClients - section Section 4.6 describes an access control mechanism that is employed to restrict the DAP functionality to certain eClients. During the join process, the eClient indicates that it wishes to join using a DAP - this allows the DAP and OAP to create appropriate state. The OAP creates forwarding state for the eClient with the bootstrapping DAP as the next hop. The OAP also creates a connection to the DAP. If the OAP is unable to establish a connection to the DAP, it uses overlay routing to reach the DAP. The DAP and OAP do not communicate to any other nodes within the overlay about the presence of an eClient. The OAP stores all ResourceIds that the eClient owns according to the overlay implementations. From the point of view of the rest of the overlay, the OAP owns the identity space and all messages to the identity space arrive at the OAP. The OAP satisfies all STORE, FETCH, FIND and STAT messages associated with the identity assigned to an eClient for the purposes of the rest of the overlay. The OAP uses the associated DAP as the next hop to route messages destined to the eClient. The DAP is responsible to maintain the list of eClients attached to it. Similarly, the OAP is responsible for maintaining the eClient and its associated for message routing purposes. When the root of the eClient's NodeId changes (due to a new node joining as a successor or predecessor to the current OAP), the OAP also changes. To facilitate the transfer of OAP functionality, the current OAP sends an update message to the DAP of the eClient. Details are in Section 4.3.5. A node that wishes to join the overlay as an eClient determines for itself whether it wishes to use a DAP to do so. This decision process is outside the scope of this document itself. If the DAP becomes unreachable (i.e., the eClient declares it unreachable due to a timeout), the eClient must re-join the overlay via a bootstrap peer or another DAP. If the OAP abruptly leaves the overlay, the DAP will timeout the OAP. The DAP must indicate an unreachable OAP to the eClient using an update message. The client then re-sends a Join message and establishes state with a new OAP. For an eClient to join the overlay as a peer, it must leave and re- join the overlay. It sends a leave to the DAP, indicating that it is leaving the overlay as an eClient. The DAP and in turn the OAP clean up state associated with the eClient. The eClient should then send another Join message to the OAP, indicating that it is joining as a Narayanan & Swaminathan Expires January 1, 2010 [Page 6] Internet-Draft E-Client Support for RELOAD June 2009 peer. It may send this message through the DAP itself if connectivity to the DAP is still available. This document does not specify when the eClient-DAP connection can be terminated. This is a local determination at the entities and they may choose to keep the connection alive even when there are no overlays that the eClient is a member of. However, at that point, the DAP does not accept any overlay specific messages (other than Join messages) from the node. Messages sent by the eClient will be natively routed on the overlay at the DAP, thereby incurring no additional hops. Responses sent to the eClient, if routed using symmetric routing, will traverse the same path as the requests, thereby also reaching the eClient with no additional hops. However, for all responses routed in an asymmetric fashion and all other unsolicited requests sent to the eClient, the messages will be routed to the OAP. Since the OAP has state corresponding to the eClient, it will route the messages to the DAP for delivery to the eClient. In the event that the OAP has a direct connection with the DAP, it will be used to forward the message and this allows message routing with only one extra hop than the average number of hops for overlay routing. If the OAP failed to establish a direct connection with the DAP, this message will be routed via the overlay to the DAP. In this case, the messages will incur twice the average number of hops to be routed to the eClient. On the OAP establishing a direct connection to the DAP, it is worth noting that there is no extra overhead compared to supporting a client. Instead of maintaining a connection to the client in the normal case, the OAP maintains a connection to the DAP. The DAP, on the other hand, maintains extra connections for the eClient and the OAP - however, it is assumed that the DAP intended to provide this service to the eClient. 4. Peer-to-Peer Network Protocol for eClient Operation The basic client operation defined in [1] allows client attachment to the OAP. This section describes the P2P network protocol elements necessary for the eClient operation. The basic protocol for peers is as specified in [1] and it is assumed that all routing peers that are part of the overlay support the protocol for eClient operation. eClients provide and receive services on the overlay without having to incur the cost of overlay routing or storage for other nodes. In order to support the eClient behavior, minor changes are required to the join process and the message routing process at the OAP. The data management procedures (STORE, FETCH, etc.) at the eClient remain Narayanan & Swaminathan Expires January 1, 2010 [Page 7] Internet-Draft E-Client Support for RELOAD June 2009 exactly the same as that defined for peers in [1]. eClients obtain overlay node identities just like peers do. By virtue of this, the enrollment procedure is identical for all nodes. The join procedure is a bit modified for an eClient and the section below describes that process. All data management operations to/from an eClient are indistinguishable from those of a peer for all nodes in the overlay, excluding the OAP and DAP. Some additional procedures are defined for routing at the OAP, which are also described below. 4.1. Bootstrapping struct { NodeID node; } DAPNodeInformationElement; An eClient does not need to discover any bootstrap peers for an overlay. Instead, it performs DAP discovery to find a DAP and obtain the necessary information about the DAP. An eClient that has pre- configured information about a DAP may use that to connect to it. The eClient then sends a Join request message to the DAP, indicating that it wishes to join as an eClient using the peer as the DAP. It indicates joining as an eClient by setting the NodeType in the Join message to "eClient" and includes a DAPNodeInformationElement as part of the Join request message. The eClient also includes the DAP Node ID in the destination list of the message. The DAP acts as a bootstrap peer for this join process and forwards the message to the admitting peer. If the DAP requires authorization of the eClient before it can provide the DAP service, the Join request message MUST contain a DAP Authorization Payload that allows authorization. When present, the DAP SHOULD verify the authorization, remove the DAP Authorization Payload and forward the Join request to the admitting peer if successful. Section 4.6 describes the authorization procedure between the DAP and eClient. The admitting peer serves as the OAP for the eClient. After processing the Join request and authorizing the join itself, the OAP creates state for the eClient, with the DAP as its next hop, in its Overlay Client Table. It then sends a Join response to the eClient, routed back through the DAP. Note that this is no different from routing a regular Join response to a bootstrap peer. At this point, the OAP and DAP go through the Attach process to establish a direct connection, if there is no direct connection already available between these nodes. The OAP checks for existing state for the eClient - if it finds none, it will create new state. If state Narayanan & Swaminathan Expires January 1, 2010 [Page 8] Internet-Draft E-Client Support for RELOAD June 2009 exists, it MUST update itself with the new state. The eClient must retain the OAP information specific to an overlay for use in Leave messages. Note that it is possible that the OAP and DAP are unable to establish a connection. This may be the case when they are both behind NATs that make such a connection difficult and they are unable to find a relay that allows a successful connection. In such cases, the OAP routes all messages to the DAP via the overlay. So, the join process completes after a successful Join response is sent, without waiting for the attach process between the OAP and DAP to complete successfully. When there is no direct connection between the DAP and OAP, the DAP MUST send periodic PING messages to determine OAP departures from the overlay. The recommended interval for these PING messages is 3 seconds. The DAP and the OAP MUST NOT send any update messages to other peers in the overlay as a result of an eClient joining the overlay. The DAP simply updates its overlay client and connection tables with the eClient and OAP information. The eClient does the same. The OAP updates its overlay client and connection tables with the appropriate DAP information as the next hop for the eClient. 4.2. Leaving the Overlay When the eClient wishes to leave the overlay, it SHOULD send a Leave Request message to the DAP, addressed to the OAP. The DAP, after processing the Leave Request, MUST forward the message to the OAP. The OAP MUST respond with a Leave Response message and remove state associated with the eClient. The OAP MAY choose to keep the connection to the DAP (if the DAP allows that) to use it as an additional finger for routing purposes. The DAP MUST forward the Leave Response to the eClient, assuming it is still connected to the eClient. The DAP should also remove state corresponding to the eClient. 4.3. Impact of Churn on eClients The eClients will be affected any time there are changes to the identity ownership around its node ID region or any time there is a change with the DAP. For instance, state on the appropriate OAP needs to be created for the DAP when the OAP changes. The client needs to find an alternate means to attach to the overlay when it is no longer attached to the DAP. The following cases are described in what follows: Narayanan & Swaminathan Expires January 1, 2010 [Page 9] Internet-Draft E-Client Support for RELOAD June 2009 o eClient loses connectivity to the DAP o DAP leaves or loses connectivity to the overlay while maintaining connectivity to eClient o A new peer joined the overlay with an identity that lies between the identities of an eClient and its OAP o The OAP of an eClient performs a graceful leave from the overlay o The OAP of an eClient abruptly leaves the overlay or fails 4.3.1. Update Messages struct { reserved (0), peer (1), client (2), eClient (3), OAP (4), DAP (5), (255) } NodeType */Needs to be in RELOAD for client support/* struct { reserved (0), available (1), timeout (2), unavailable (3), attachmentchange (4), (255) } NodeStatus struct { NodeID node; NodeType type; NodeStatus status; } OtherNodeStatus struct { OtherNodeStatus status} eClientChordUpdateReq More than one OtherNodeStatus elements may be present in an eClientChordUpdateReq message. The eClientChordUpdateAns is an empty message. These update messages are used to signal state changes from churn as described in the following sections. 4.3.2. eClient Mobility If the eClient is connected to the DAP, it may lose connectivity by moving away from range of the DAP or for other reasons. Also, mobility may cause the eClient to want to use a different DAP, join Narayanan & Swaminathan Expires January 1, 2010 [Page 10] Internet-Draft E-Client Support for RELOAD June 2009 at the OAP or as a routing peer. In the case where the eClient still wishes to use the current DAP, the eClient may restart a TCP connection to the IP address it has for the DAP. Unless the DAP is also mobile, it is reasonable to expect that the eClient can reconnect to the address it used for the DAP. Once a connection is set up, the eClient MUST send a Join Request message to the DAP. Since the DAP is aware of state at the OAP, the DAP SHOULD send a Join Response, without forwarding the message to the OAP. If the eClient successfully connects to the DAP again before the DAP times out its eClient state, the eClient can be back on the overlay without having to re-join on the overlay. It is recommended that the DAP maintain the eClient state and the connection to the OAP for a period of time (say, 60 seconds) even after it detects loss of connectivity with the eClient. If the eClient does not reconnect before the timer expires, the DAP MUST indicate to the OAP that the eClient left. The DAP does this by sending an eClientChordUpdate message indicating that the eClient has left the overlay (by setting the NodeStatus to Unavailable in the payload). The OAP, upon receiving this message SHOULD remove the eClient from its Overlay Client Table and send an eClientChordUpdate response message to the DAP. The DAP-OAP connection may also be removed at this point, if there is no other use for the connection. If the OAP receives a Join request from the eClient via a different DAP or through a BP for join at the OAP itself while it still has state for the old DAP, it MUST replace the old state with the state for the new join process. This may happen before the DAP has timed out the client - hence, the OAP MUST send an eClientChordUpdate request message to the DAP, indicating that the eClient changed its point of attachment. The DAP, upon receiving this message MUST remove the eClient from its Overlay Client Table and send an eClientChordUpdate response message to the OAP. 4.3.3. Graceful DAP Leave on Overlay If the DAP is leaving the overlay, but still has a connection to an eClient, it MUST notify the eClient by sending a Leave message to it. This indicates that the DAP no longer has any neighbors on the overlay, thereby indicating that it can no longer reach the overlay. The DAP MUST also send a Leave Request message to the OAP to clean up the state it has at the OAP. The OAP, upon receiving the Leave message from the DAP, MUST remove the eClient's entry from its Overlay Client Table and return a Leave Response. The eClient, if it still wishes to attach to the overlay, must do so Narayanan & Swaminathan Expires January 1, 2010 [Page 11] Internet-Draft E-Client Support for RELOAD June 2009 by re-joining the overlay, either via another DAP or at the OAP, using a bootstrap peer. 4.3.4. Abrupt DAP Leave on Overlay If the DAP leaves the overlay abruptly, but is still connected to the eClient, it MUST send a Leave message to the eClient as explained in the case above. However, it will not be able to send a Leave message to the OAP and hence, the OAP will still have state corresponding to the eClient/DAP. When the connection to the DAP times out at the OAP, the OAP SHOULD route messages to the overlay while its eClient state is still present - this is needed, since the break of a connection isn't indicative of the DAP having left the overlay by itself. When the OAP times out the DAP (for e.g., when it has attempted connecting again without success or when it has timed out the PING messages to the DAP), it SHOULD remove state for the DAP and the associated eClient. If the eClient attempted to join the overlay before the OAP removed state for it, the OAP will see another Join request for the eClient, either from a new DAP or from a BP, indicating a join at the OAP itself. In this case, the OAP MUST replace the old state it has for the eClient with the new state that results from this join process. Also, the OAP will try to send an eClientChordUpdate request to the DAP, since the OAP will not be able to tell the difference between an eClient move and a DAP leave in this case. 4.3.5. OAP Change due to a New Peer struct { reserved (0), successor (1), predecessor (2), finger (3), OAP (4), DAP (5), eClient (6), (255) } AttachPurpose */Needs to be in RELOAD for client support/* When the OAP changes due to churn in the region and a new peer takes over the ownership for the eClient's identity, the state needs to be transferred to the new OAP and it needs to establish a connection with the DAP. The old OAP sends an eClientChordUpdate Request message to the new OAP, indicating the DAP's identity. The old OAP MUST also include the eClient's identity in the message along with it. The eClient identity is included in a second OtherNodeStatus structure, immediately after the previous one with the DAP identity. The new OAP, after creating state for the eClient, MUST send an Narayanan & Swaminathan Expires January 1, 2010 [Page 12] Internet-Draft E-Client Support for RELOAD June 2009 Attach Request to the DAP. This document introduces an AttachPurpose structure in the Attach Request message to indicate why a particular node is seeking a connection with another node. In this case, the Attach must indicate that it is connecting as the new OAP for the eClient the DAP serves. Once the connection is established, the new OAP has fully taken over for the eClient. The connection between the DAP and the old OAP may also be torn down at this point. 4.3.6. Graceful OAP Leaves When an OAP gracefully leaves an overlay, it typically sends a Leave request message to all its neighbors. In addition, the OAP MUST send a Leave Request message to the eClient, along with information about its successor, which will be the new OAP for the eClient. When the eClient receives such a Leave Request, it must send a Join Request message again through the DAP. The DAP SHOULD route the Join message on the overlay towards the new OAP. 4.3.7. Abrupt OAP Leaves An abrupt leave or a failure of an OAP implies that there is no active messaging from the OAP to the DAP, indicating that an OAP change is required. In this case, the DAP will detect the absence of the OAP due to a PING timeout indicating that the OAP is unreachable. When this happens, the DAP MUST send an eClientChordUpdate Request to the eClient, indicating that the OAP is unreachable. The eClient then MUST restart the eClient join sequence via the DAP to find the new OAP. When the DAP and OAP do not have a direct connection, the timeout of the OAP can be detected by a lack of response for three PING requests in a row. 4.4. Message Routing at DAP The DAP is responsible for routing all messages from the eClient on the overlay. However, the DAP should only route messages on the overlay if the eClient has actually joined the overlay. Hence, the DAP must keep track of the overlays that the eClient has joined through it and drop all messages that may be sent to other overlays. The overlay network id is available from the header of the messages sent, which can be used to identify whether the eClient is a member of the particular overlay. 4.5. Message Routing at OAP The messages sent to the eClient on the overlay will arrive at the OAP by default overlay routing. The OAP, upon receiving a message, MUST consult its Overlay Client Table before the Routing or Narayanan & Swaminathan Expires January 1, 2010 [Page 13] Internet-Draft E-Client Support for RELOAD June 2009 Connection Tables. For messages destined to the eClient, the OAP will find a match in its Overlay Client Table. It can then route the message to the DAP. If it has a direct connection to the DAP, it forwards the message to the DAP. However, when no direct connection to the DAP is available, the OAP MUST insert the DAP's node identity in the destination list of the message before routing it on the overlay. If a destination list is already present in the message, it needs to be modified to include the DAP as an intermediate destination. The DAP will follow normal routing procedures to deliver the message to the eClient. When the DAP and OAP have a direct connection, they may use that even for regular routing, by creating entries in the Connection and Routing Tables. Note that typically, the Routing Table is a combination of the Neighbor Table and the Finger Table. However, implementations must not treat the DAP connection as another finger, since that will throw off size estimation algorithms significantly if those were employed for any purpose. 4.6. eClient and DAP Authorization struct { reserved (0), HMAC_SHA1 (1), (255) } MACAlgorithm struct { uint8 KeyIDLength; uint16 KeyID; MACAlgorithm algorithm; opaque mac; } eClientDAPAuth o Key ID Length: Length of the key ID in octents o Key ID: This is an index to the PSK used to compute the MAC. This may be a numeric index or a user name. The eClient and DAP are responsible for the uniqueness of the Key ID. o MAC Algorithm: The algorithm used to compute the MAC. This document defines the following values: 0 - Reserved 1 - HMAC_SHA1 Narayanan & Swaminathan Expires January 1, 2010 [Page 14] Internet-Draft E-Client Support for RELOAD June 2009 o MAC: The message authentication code calculated on the entire Join message (inclusive of all fields except the MAC in this payload) using the MAC algorithm indicated. The MAC algorithm should be indicative of the length of the MAC and hence, any truncation should be represented as a different algorithm. The DAP may have a policy that restricts the service to be offered to only select eClients. Further, the eClient may only want to use certain devices as DAPs. For this purpose, the protocol optionally supports an authorization mechanism between the eClient and DAP. This is a shared secret based mechanism, where the eClient and DAP are expected to have a PSK for this purpose. When authorization is required, the eClient should include the eClientDAPAuth Payload in the Join Request message. The DAP, upon receiving the Join Request message, will process this payload to verify if authorization succeeds. If it is successful, it will strip off this payload before forwarding the message along to the OAP. Note that this payload MUST NOT be included in computing the message signature itself. When the DAP receives the Join Response message from the OAP, it should include an eClientDAPAuth Payload to it before sending it to the eClient. If the eClientDAPAuth Payload was present in the Join request message, it MUST be included in the Join Response message as well. The Join messages are exchanged in a secure channel between the eClient and the DAP (this is not unlike the exchange between any JP and BP). Typically, this is a TLS/DTLS channel. However, when the eClient and DAP are directly connected and in the presence of link layer security (e.g., 802.11i or equivalent), no TLS/DTLS may be required. Other channel security properties for the eClientDAPAuth structure are provided by TLS/DTLS or link layer security. In other words, replay protection, liveness or confidentiality are provided by virtue of this exchange happening within a secure channel. 5. Multiple Overlays Considerations The eClient may utilize the same DAP to join multiple overlays. In such cases, it is possible to only use a single connection between the eClient and DAP itself for all overlays. This is also feasible when the link between the eClient and the DAP is a local one such as Bluetooth. The overlay network id in the messages provides a means of identifying which overlay a message is sent to, thereby still providing a means to demultiplex messages belonging to different overlays, even though a single connection is used. Narayanan & Swaminathan Expires January 1, 2010 [Page 15] Internet-Draft E-Client Support for RELOAD June 2009 6. IANA Considerations TBD 7. Acknowledgments Early versions of this document were reviewed by Dave Craig and Arvind Krishna. This document also benefited from design discussions with Ranjith Jayaram and Lakshminath Dondeti. 8. Normative References [1] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", draft-ietf-p2psip-base-02 (work in progress), March 2009. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Vidya Narayanan Qualcomm, Inc. 5775 Morehouse Dr San Deigo, CA USA Email: vidyan@qualcomm.com Ashwin Swaminathan Qualcomm, Inc. 5775 Morehouse Dr San Deigo, CA USA Phone: +1 858-845-8775 Email: sashwin@qualcomm.com Narayanan & Swaminathan Expires January 1, 2010 [Page 16]