Internet DRAFT - draft-kutscher-decade-protocol

draft-kutscher-decade-protocol






Network Working Group                                        D. Kutscher
Internet-Draft                                            M. Stiemerling
Intended status: Standards Track                              J. Seedorf
Expires: April 26, 2012                                              NEC
                                                        October 24, 2011


                 Design Considerations for a DECADE SDT
                   draft-kutscher-decade-protocol-00

Abstract

   This memo provides some considerations for the design of a specific
   DECADE protocol.

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."

   This Internet-Draft will expire on April 26, 2012.

Copyright Notice

   Copyright (c) 2011 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.








Kutscher, et al.         Expires April 26, 2012                 [Page 1]

Internet-Draft                 SDT Design                   October 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conceptual DECADE Protocols  . . . . . . . . . . . . . . . . .  3
   3.  Object Naming and Addressing . . . . . . . . . . . . . . . . .  4
     3.1.  Object Naming  . . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Object Addressing  . . . . . . . . . . . . . . . . . . . .  6
   4.  Authentication and Access Control  . . . . . . . . . . . . . .  7
   5.  General SDT Considerations . . . . . . . . . . . . . . . . . .  8
     5.1.  Dealing with Application Contexts, Resource Collection
           and Other Structure  . . . . . . . . . . . . . . . . . . .  8
     5.2.  Server-to-Server Communication . . . . . . . . . . . . . .  9
     5.3.  Recommendations  . . . . . . . . . . . . . . . . . . . . .  9
   6.  CDMI Considerations  . . . . . . . . . . . . . . . . . . . . .  9
     6.1.  CDMI Content Type Operations . . . . . . . . . . . . . . . 10
     6.2.  CDMI Features and SDT  . . . . . . . . . . . . . . . . . . 10
     6.3.  CDMI Containers  . . . . . . . . . . . . . . . . . . . . . 11
     6.4.  Object Identifiers in CDMI . . . . . . . . . . . . . . . . 12
     6.5.  Recommendations for SDT over CDMI  . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 13
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14




























Kutscher, et al.         Expires April 26, 2012                 [Page 2]

Internet-Draft                 SDT Design                   October 2011


1.  Introduction

   The DECADE architecture specification [refs.decadearch] describes
   fundamental principles for DECADE (naming, transport, authorization)
   and identifies a set of core components and conceptual protocols for
   accessing in-network storage.

   A few candidate technologies have been proposed for a concrete
   protocol specification, such as HTTP-based protocols [RFC2616],
   WEBDAV [RFC3744], and CDMI [refs.CDMI] for the actual transport/
   application layer functionality, as well as the NI URI scheme
   [refs.ni-core] for an URI format, and OAuth [RFC5849] for an
   authentication mechanism.

   This memo is intended to aid the discussion about how to design
   DECADE protocols, and how to leverage existing solutions best.  It
   further gives recommendation for a future Standard Data Transport
   (SDT).  These recommendations are labelled with REC_XY, where XY is a
   sequential number.

   [[Text in double square brackets (like this) is commentary.]]

   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.  [RFC2119]


2.  Conceptual DECADE Protocols

   As described in draft-ietf-decade-arch [refs.decadearch], DECADE
   conceptually consists of two functional building blocks: DRP (DECADE
   Resource Control Protocol) and SDT (Standard Data Transport).

   DRP would provide conveying authorization-relevant information to
   servers for access control functions.  As such, it is not intended as
   a stand-alone protocol but rather as a scheme that would be used by
   SDT instantiations, e.g., for passing authorization tokens from an
   Application Endpoint to a DECADE server.  For a concrete
   specification, a scheme is needed that supports the representation of
   authorization information.  That scheme should be compatible to the
   SDT instantiations that are specified (and envisioned to be
   specified).  The assumption is that there would be exactly one DRP.

   SDT is an actual protocol that Application Endpoints use for
   communicating with a DECADE server.  Furthermore, SDT can also be
   used for server-to-server communication, i.e., when DECADE servers
   want to distribute content to other DECADE servers.  A DECADE SDT
   would use an existing transport protocol and possibly an existing



Kutscher, et al.         Expires April 26, 2012                 [Page 3]

Internet-Draft                 SDT Design                   October 2011


   application layer protocol such as HTTP or NFS.  In fact, the
   conceptual DECADE SDT interactions that are defined in
   draft-decade-arch would most likely be mapped to messages, services
   etc. of such existing protocols, e.g., the SDT GET request would map
   to a HTTP GET request.  The assumption is that there can be different
   DECADE SDT specifications, i.e., leveraging different underlying
   protocols.  However it is also the assumption that there would be one
   mandatory SDT.

   REC_01: The selected DRP scheme should be compatible to the different
   envisioned SDT instantiations.

   REC_02: There should be one mandatory SDT implementation.

                         Figure 1: Recommendations


3.  Object Naming and Addressing

3.1.  Object Naming

   draft-ietf-decade-arch [refs.decadearch] outlines requirements and
   concepts for naming DECADE resources.  In essence, a DECADE name
   should be globally unique (with a high probablity), it should be
   application independent, and it should provide a name-content binding
   through the use of content hashes as part of the name.  The
   requirement for using DECADE names which are globally unique with a
   high probability stems from the envisioned usage of hashes.  Hashes
   typically ensure two items will have different hashes with a certain
   probability, but there is typically a very limited risk that those 2
   items will have the same hash value.

   A concrete control specification needs to define the concrete name
   format and possibly also baseline hashing algorithms.  The name
   format MUST be suitable for use in different possible SDT
   instantiations.

   [refs.ni-core] specifies a URI-based name format for naming objects,
   e.g., through content hashes.  NI URIs fundamentally provide an hash
   algorithm identifier, the actual digest value and can provide
   additional information such as object type information or locator
   hints.

         ni:///sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc

                     Figure 2: Example: DECADE NI URI

   The NI URI in the example above specifies SHA-256 as the hash



Kutscher, et al.         Expires April 26, 2012                 [Page 4]

Internet-Draft                 SDT Design                   October 2011


   algorithm, and provides the digest of an object.  DECADE
   implementations can generate such names independently, without
   requiring any infrastructure (when creating objects), and they can
   verify the name-content binding by calculating the hash of an
   received object and by comparing the result to the name that was used
   for the object.

   NI URIs can optionally provide authority information, i.e.,
   information about an authority that may assist applications in
   accessing the object.  DECADE should not require authority
   information to be present.

   The NI format allows the optional specification of media types (of
   the referenced objects) through the addition of parameters:

       ni:///sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?ct=image/jpeg

            Figure 3: Example: DECADE NI URI with content type

   Such information may be present in URIs, but DECADE should not
   require such information.  It is also important to note that
   parameters are not considered when testing NI URIs for identity.

   NI URIs can be mapped to HTTP URIs, and some HTTP URIs can be mapped
   to NI URIs.  This can be useful for deriving a locator for obtaining
   NI-named objects without explicit specification.  The following
   example depicts an NI URI with an authority part that is mapped to an
   HTTP URI (using the well-known convention specified in RFC 5785
   [RFC5785]).

      ni://decade127.example.com/sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc

      http://decade127.example.com/.well-known/ni/sha-256/B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc

           Figure 4: Example: DECADE NI URI mapping to HTTP URI

   There are other possibilities to derive the host name part of the
   HTTP URI (when no autority information is present in the NI URI),
   e.g., from the application context that the NI URI was used in.  For
   DECADE, we recommend that Application Endpoints that want to refer
   other Applications to a DECADE object on a specific server (assuming
   an HTTP-based SDT), provide the server host name as an authority
   element of the NI URI, as depicted above.  It should be noted that
   this only works with HTTP (or HTTPS)-based SDTs.  It is possible to
   specify additional/alternative locators using the NI parameter
   mechanisms (which will be described in a future version of this
   document).




Kutscher, et al.         Expires April 26, 2012                 [Page 5]

Internet-Draft                 SDT Design                   October 2011


   REC_03: There should be exactly one DECADE name format.

   REC_04: The DECADE name format must be suitable for use in different
   possible SDT instantiations.

   REC_05: The DECADE names should used the NI URI format.

   REC_06: DECADE should allow for different hash algorithms to be
   used. SHA-256 should be defined as MANDATORY, i.e., all applications
   that need to validate name-content binding of objects should be able
   to deal with SHA-256 hash digests.

   REC_07: DECADE should allow for different hash algorithms to be
   used. SHA-256 should be defined as MANDATORY, i.e., all applications
   that need to validate name-content binding of objects should be able
   to deal with SHA-256 hash digests.

   REC_08: DECADE should allow for different hash algorithms to be
   used. SHA-256 should be defined as MANDATORY, i.e., all applications
   that need to validate name-content binding of objects should be able
   to deal with SHA-256 hash digests.

   REC_09: In an application context where SDT==HTTP (or HTTPS), DECADE
   Application Endpoints should use the authority element in NI URIs to
   specify a HTTP server name when referring other Application Endpoints
   to a specific URL.


                         Figure 5: Recommendations

3.2.  Object Addressing

   Section Section 3.1 describes how complete objects are potentially
   named within DECADE.  However, it might be also necessary to address
   parts of a DECADE object, if such objects are accessible in parts.  A
   typical example is the usage of chunks, i.e., equal parts of a file
   used by peer-to-peer filesharing to exchange data.

   This addressing might be required if:

   o  an object is not completly loaded on a DECADE server, but DECADE
      clients should be able to retrieve it while the object is being
      retrieved by the server;

   o  DECADE clients do only need to access parts of the object, as they
      have already retrieved some other parts of the object;





Kutscher, et al.         Expires April 26, 2012                 [Page 6]

Internet-Draft                 SDT Design                   October 2011


   o  DECADE clients retrieve a particular object from multipe sources
      at the same time and thus do only require a subset from a
      particular DECADE server.


REC_10: The DECADE SDT should allow to retrieve parts of an object.
REC_11: The DECADE SDT should allow DECADE servers to specify which parts
of an object are available.
REC_12: The DECADE SDT should allow DECADE clients to request single parts
or a range of parts from the DECADE server.

           Figure 6: Recommendations with respect to Addressing


4.  Authentication and Access Control

   The DECADE architecture has a concept of token-based authentication
   and access control.  The idea is that Application Endpoints that are
   referring other Application Endpoints to a DECADE server provide
   tokens to these other Application Endpoints.  Those would use these
   tokens when communicating with a server, and the tokens would be
   meaningful to the server for making acess control decisions.

   OAuth is one particular candidate mechanism to be used for token-
   based authentication and access control.  (A detailed analysis will
   be provided in a future version of this document.)  A mechanism such
   as OAuth would be used by HTTP in specific ways, i.e., by using HTTP
   header fields -- this would be the DRP instantiation for a specific
   SDT.

   Communincating authentication information between Application
   Endpoints is out of scope for DECADE specifications; it is assumed
   that this would rely on application-specific protocols.  However,
   there are principally two options:

   o  authentication tokens in the specific application protocol; or

   o  authentication tokens in the object identifier that Application
      Endpoints use to refer other Application Endpoints to a DECADE
      server.

   Including the authentication tokens in the object would provide an
   application-protocol-independent way for communicating this
   information between Application Endpoints.  The parameter mechanism
   of NI URIs could be used for that:

      ni://decade127.example.com/sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?auth=AHFK34F




Kutscher, et al.         Expires April 26, 2012                 [Page 7]

Internet-Draft                 SDT Design                   October 2011


            Figure 7: Example: Authentication tokens in NI URIs

   For each SDT specification, there needs to be an algorithm to map the
   authentication token to specific header fields, messages, etc. of the
   particular protocol.

   REC_13: DECADE should use an NI URI parameter for representing
   authentication information in object identifiers.

                         Figure 8: Recommendations


5.  General SDT Considerations

5.1.  Dealing with Application Contexts, Resource Collection and Other
      Structure

   Fundamentally, DECADE is intended to provide access to resources
   which are distributed in in-network storage servers for different
   applications.  Such resources should be named uniquely across
   different servers, and the same resource should be accessible at
   different servers using the same name.

   Different servers, different file transfer, and different remote file
   system protocols may provide different capabilities for organizing
   resources in hierarchical structures (collections, file system
   directories etc.).  Since DECADE already provides a way to name
   resources uniquely across different servers and protocols (through
   the DECADE naming scheme), SDT (and DECADE in general) should not
   require or rely on any hierarchical name space structure.

   Application-specific structure (e.g., collecting all chunks of a
   specific media resource) should be dealt with on the application
   layer, i.e., through the use of "torrent files" or index files that
   reference the DECADE resources.

   Similarly, DECADE resources from different application contexts
   should not be distinguished by additional name components, direcory
   names etc., since the DECADE naming scheme already provides for a
   unique naming of resource across application contexts.

   Consequently, any operations on remote file system structures,
   collections etc. should be orthogonal to DECADE and not be supported
   by SDT.  Specific protocols that an SDT instantiation leverages may
   provide support for that, but we recommend that such operations are
   considered out of scope for SDT.





Kutscher, et al.         Expires April 26, 2012                 [Page 8]

Internet-Draft                 SDT Design                   October 2011


5.2.  Server-to-Server Communication

   The DECADE architecture [refs.decadearch] describes the operation of
   Server-to-Server Protocols, which are intended to enable DECADE
   servers to distribute data objects to other servers, without the need
   of Application Endpoint interaction.  One possible way of operation
   is that an Application Endpoint (client) would upload a data object
   to a DECADE server, and that server would then upload the object to
   one or more other servers, thus acting as a client to those other
   servers.  In addition, an Application Endpoint would also be able to
   request a DECADE server to download the object from another specified
   server itself.

   For specifying a concrete SDT, some design questions need to be
   taken:

   o  Is it possible to specify only one or multiple target DECADE
      servers?

   o  Most HTTP-based protocols do not support requesting/configuring
      server-to-server communication natively.  We recommend this
      feature be implemented without changing/extending those protocols.

5.3.  Recommendations

   REC_14: DECADE should not assume any structure (collections,
   containers, directories) on DECADE servers.

   REC_15: DECADE object identifiers should be flat labels.

   REC_16: It should be possible for DECADE server to distribute objects
   between servers using SDT. An SDT instantiation should provide a
   corresponding mechanism.

   REC_17: DECADE should define a way to specify (control) the
   distribution of objects between servers.

   REC_18: Server-to-Server communication should not require the
   introduction of new HTTP request types (for HTTP-based SDT).


                         Figure 9: Recommendations


6.  CDMI Considerations

   CDMI [refs.CDMI] has been considered as a candidate basis for an
   DECADE SDT instantiation.  This section discusses a few aspects and



Kutscher, et al.         Expires April 26, 2012                 [Page 9]

Internet-Draft                 SDT Design                   October 2011


   potential issues for adopting CDMI.

   In general, the assumption is that CDMI (as a certain way to leverage
   HTTP for accessing and managing cloud data) can be used for DECADE.
   Since CDMI has many features (namely the data management features)
   that are not required by DECADE, we assume that a CDMI-based SDT
   specification would specify a subset of CDMI and specify a list of
   requirements for implementations on how to use the mechanisms of the
   subset in detail.

6.1.  CDMI Content Type Operations

   CDMI provides uploading/downloading/deleting etc. data with CDMI
   content types and with non-CDMI content types.  CDMI content type
   operations use JSON to encode objects (and meta information), i.e.,
   PUT requests would encode the data object in JSON, and response
   messages to GET requests would also encode the returned object in
   JSON.  Non-CDMI content type operations may also use JSON for
   encoding certain information, for example for data object meta
   information, but the object itself would be transmitted directly in
   message bodies (as non-CMDI web servers would do).

   A CDMI-based SDT should use the non-CDMI content type operations, for
   efficiency and backwards-compatibility reasons.

6.2.  CDMI Features and SDT

   CDMI provides a broad range of feature for Cloud Data Management,
   such as:

   o  discovering capabilities of a cloud storage provider;

   o  creating a new container;

   o  creating a new data object;

   o  listing the contents of a container;

   o  reading the contents of a data object;

   o  reading the value of a data object; and

   o  deleting a data object.

   Moreover, CDMI provides a set of administrative operations, such as:

   o  managing domain objects representing the concept of administrative
      ownership (CDMI supports a hierarchy of domains and provides



Kutscher, et al.         Expires April 26, 2012                [Page 10]

Internet-Draft                 SDT Design                   October 2011


      operations to manage those);

   o  queue object resource operations, providing first-in, first-out
      access for storing and retrieving data;

   o  capability query operations, allowing a client to find out about
      the subset of CDMI features that a server supports;

   o  exporting (and configuring the exporting of) data objects to other
      protocol domains such as NFS, iSCSI, WebDAV etc.;

   o  serialization and de-serialization of data;

   o  configure access control through ACLs;

   o  retention and hold management;

   o  scope specifications to allow clients to select data objects based
      on filter/search expressions;

   o  results specifications (to enable a client to specify subsets of
      data objects to be returned);

   o  logging;

   o  notification queues (for example for notfying clients about
      changes to a file system or to certain objects); and

   o  query queues (enabling clients to requests data objects based on
      meta data or content search expressions).

   SDT over CDMI should specify a subset of these features and use the
   CDMI capability description mechanism to describe the subset of
   supported features.

6.3.  CDMI Containers

   Containers are a fundamental concept for CDMI, and they are used for
   grouping objects.  In fact, containers are CDMI objects, and they can
   be addressed and manipulated using the same CDMI operations that are
   used for data objects.

   With a flat naming scheme (as we expect DECADE to employ) there is no
   strong need for grouping objects in containers, so we recommend that
   the containers and container names should not be used for generating
   DECADE object names.





Kutscher, et al.         Expires April 26, 2012                [Page 11]

Internet-Draft                 SDT Design                   October 2011


6.4.  Object Identifiers in CDMI

   CDMI required globally unique object IDs be used for all objects
   stored on a CDMI server, which is conceptually similar to the DECADE
   architecture requirements for naming.

   In CDMI, objects are either accessible by their container-based
   hierarchical named such as
   "http://decade.example.com/root/vod/video1" or by their object ID
   such as "http://decade.example.com/root/cdmi_objectid/647284746393",
   with "647284746393" being the object ID.

   CDMI specifies how object IDs should be generated.  Object ID are
   variable length byte sequences with a maximum length of 40 bytes, and
   they provide the following structure:

   ___________________________________________________________
   |   0    | 1 | 2 | 3|   4    |  5   |6|7| 8| 9|10|..|38|39|
   |Reserved|Enterprise|Reserved|Length|CRC| opaque data     |
   | (zero) |  Number  | (zero) |      |   |                 |
   -----------------------------------------------------------

                    Figure 10: CDMI Object ID structure

   Although CDMI Objects IDs could provide content hashes (in the opaque
   data fields), these IDs are not directly compatible to the current NI
   URI format.  It is possible to convey the additional information of
   CDMI IDs in NI URIs, employing the extension mechanismsm, but
   syntactically, the NI URI would be different.

   Although applications can treat these IDs as opaque bit strings, the
   format enables integrity checking for those applications that need
   it.  In CDMI, the assumption is that the *server* generate these IDs,
   for example upon having received the object from a client over the
   upload interface.  This server-based ID generation is the direct
   opposite of the client-based ID generation that we expect for DECADE.

6.5.  Recommendations for SDT over CDMI

   REC_19: The difference between CDMI's object ID syntax and the NI URI
   syntax should be addressed by either adapting CDMI's syntax or by
   defining a bijective mapping between CDMI and NI URIs.

   REC_20: CDMI containers should not be used.

   REC_21: CDMI should only by used in the non-CDMI content type mode

                        Figure 11: Recommendations



Kutscher, et al.         Expires April 26, 2012                [Page 12]

Internet-Draft                 SDT Design                   October 2011


7.  Security Considerations

   Several security considerations need to be investigated for a DECADE
   SDT protocol and for DECADE in general.  First, proper access control
   to objects stored at DECADE servers must be provided (OAuth is a
   means to do this, but the specific security implications for using
   OAuth in the context of DECADE need to be considered, and potential
   attacks need to be analyzed and described).  Second, the potential
   for Denial-of-Service attacks on DECADE servers must be minimized.
   Finally, the integrity of data items stored at DECADE servers must be
   maintained, and clients must have a way to verify the integrity of
   data items they retrieve from a DECADE server (hash-based or self-
   certifying schemes as a component of the DECADE name space can be a
   means to provide these requirements, but the specific implications
   and potential attacks on data integrity need to be condidered
   carefully and described in detail).  Future versions of this document
   will study these security aspects in more detail.

   Also, SDT over HTTP-based protocols MUST support HTTPS.  How
   applications choose whether to use HTTP or HTTPS will be discussed in
   a future version of this document.


8.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC3744]  Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
              Distributed Authoring and Versioning (WebDAV)
              Access Control Protocol", RFC 3744, May 2004.

   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
              Uniform Resource Identifiers (URIs)", RFC 5785,
              April 2010.

   [RFC5849]  Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849,
              April 2010.

   [refs.CDMI]
              "CDMI", HTML http://www.snia.org/cdmi, September 2011.

   [refs.decadearch]
              Alimi, R., Yang, Y., Rahman, A., Kutscher, D., and HP.



Kutscher, et al.         Expires April 26, 2012                [Page 13]

Internet-Draft                 SDT Design                   October 2011


              Liu, "DECADE Architecture", draft-ietf-decade-arch-03
              (work in progress), September 2011.

   [refs.ni-core]
              Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., and
              P. Hallam-Baker, "The Named Information (ni) URI Scheme:
              Core Syntax", draft-farrell-decade-ni-00 (work in
              progress), October 2011.


Appendix A.  Acknowledgments

   Dirk Kutscher is partially supported by the SAIL project (Scalable
   and Adaptive Internet Solutions, http://www.sail-project.eu), a
   research project supported by the European Commission under its 7th
   Framework Program (contract no. 257448).

   Jan Seedorf and Martin Stiemerling are partially supported by the
   COAST project (COntent Aware Searching, retrieval and sTreaming,
   http://www.coast-fp7.eu), a research project supported by the
   European Commission under its 7th Framework Program (contract no.
   248036).

   The views and conclusions contained herein are those of the authors
   and should not be interpreted as necessarily representing the
   official policies or endorsements, either expressed or implied, of
   the SAIL or the COAST project or the European Commission.


Authors' Addresses

   Dirk Kutscher
   NEC
   Kurfuersten-Anlage 36
   Heidelberg,
   Germany

   Phone:
   Email: kutscher@neclab.eu
   URI:   http://dirk-kutscher.info/











Kutscher, et al.         Expires April 26, 2012                [Page 14]

Internet-Draft                 SDT Design                   October 2011


   Martin Stiemerling
   NEC
   Kurfuersten-Anlage 36
   Heidelberg,
   Germany

   Phone:
   Email: martin.stiemerling@neclab.eu
   URI:   http://ietf.stiemerling.org


   Jan Seedorf
   NEC
   Kurfuersten-Anlage 36
   Heidelberg,
   Germany

   Phone:
   Email: seedorf@neclab.eu
































Kutscher, et al.         Expires April 26, 2012                [Page 15]