One document matched: draft-deng-alto-p2p-ext-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2234.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="yes" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-deng-alto-p2p-ext-00.txt" ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title>End Point Properties for Peer Selection</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Lingli Deng" initials='L.'
surname="Deng">
<organization>China Mobile</organization>
<address>
<email> denglingli@chinamobile.com</email>
</address>
</author>
<author fullname="Haibin Song" initials='H.'
surname="Song">
<organization>Huawei</organization>
<address>
<email>haibin.song@huawei.com</email>
</address>
</author>
<date day="13" month="February" year="2014" />
<!-- Meta-data Declarations -->
<area></area>
<workgroup>ALTO</workgroup>
<keyword></keyword>
<abstract>
<t> The initial purpose for ALTO protocol is to provide better than random peer selection for p2p networks.
The peer selection method does not only depend on the peer location, but also on other properties of a peering
node. In this document, we define the possible ALTO endpoint property extensions that will impact peer selection.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t> The initial purpose for ALTO protocol is to provide better than random peer selection for p2p networks.
The peer selection method does not only depend on the peer location, but also on other properties of a peering
node. In this document, we define the possible ALTO endpoint property extensions that will impact peer selection.
</t>
</section>
<section title="Terminology">
<t>ALTO: application layer traffic optimization. For ALTO protocol,
please refer to <xref target="I-D.ietf-alto-protocol"></xref>.</t>
<t>DSL: Digital subscriber line, is a family of technologies that provide Internet
access by transmitting digital data over the wires of a local telephone network.</t>
<t>FTTB: Fiber To The Building, refers to fiber reaches the boundary of the building.</t>
<t>FTTH: Fiber To The Home, refers to figure reaches the the boundary of the living space.</t>
</section>
<section title="End Point Extensions">
<t> This document provides three endpoint property extensions for ALTO protocol.
</t>
<section title="Endpoint Property Type: p2p_caching">
<t> As described in <xref target="I-D.draft-deng-alto-p2pcache"></xref>, P2P caching node can also act as p2p peers
in a p2p network. If a p2p caching peer is located near the edge of the network, it will reduce the backbone traffic,
as well as the uploading traffic. For example, [RFC7069] provides one example of such caching nodes. P2P caching
peers usually have higher priority than the ordinary peers for serving a content request so as to optimize the
network traffic. So it's necessary for the endpoint property to support this indication.
</t>
<t> The value for this property is either "true" or "false", in ASCII. If the peer in question is actually a caching node,
the value of this property wrt the peer is set to "true".
</t>
</section>
<section title="Endpoint Property Type: battery_limited">
<t> Another important endpoint property that will impact peer selection is what kind of power supply the peer has.
It can be either the electric power or the battery supply. And most of the time, it is obvious that electric power
supplied nodes are more likely online longer than those battery supplied nodes. And most of the nowadays intelligent
equipments are aware of their power supply type. But it is necessary that whether or not the power supply of a peer
is limited by its battery can be queried through some method.
</t>
<t> The value for this property is either "true" or "false", in ASCII. If the peer in question is actually battery-limited,
the value of this property wrt the peer is set to "true".
</t>
</section>
<section title="Endpoint Property Type: network_access">
<t> The third important endpoint property that will impact peer selection is the node access type. If it is a node
owned by home user, the access type can be DSL, or FTTB, or FTTH. If it is deployed in a data center, we can specify
a special access type for it, because it is more robust, and is more likely to have more network resources than home
users. A p2p application may have its own algorithm for peer selection if this information can be provided.
</t>
<t> The value for this property can be enumerated as "adsl", "ftth", "fttb", "dc", and etc.
</t>
</section>
</section>
<section title="Security Considerations">
<t>The indication of new endpoint properties to the ALTO clients may set targets for the malicious nodes to hack.</t>
</section>
<section title="IANA Considerations">
<t>This document adds the following new endpoint property type to the existing registry created by ALTO protocol
<xref target="I-D.ietf-alto-protocol"></xref>.</t>
<figure align="center">
<artwork align="left">
<![CDATA[
+---------------+---------------------------------------+
|Identifier |Intended Semantics |
+---------------+---------------------------------------+
|p2p_caching |Whether the peer is a network cache, |
| |value is "true" or "false", in ASCII. |
+---------------+---------------------------------------+
|power_supply |Whether the peer is battery-limited, |
| |value is "true" or "false", in ASCII. |
+---------------+---------------------------------------+
|network_access |The type of access network of the peer,|
| |value is enumerated as "adsl", "ftth", |
| |"fttb", "dc", in ASCII. |
+---------------+---------------------------------------+
]]>
</artwork>
<postamble></postamble>
</figure>
</section>
<!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
<?rfc needLines="8" ?>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
<reference anchor="I-D.ietf-alto-protocol">
<front>
<title>ALTO Protocol</title>
<author initials="R." surname="Alimi">
<organization></organization>
</author>
<author initials="R." surname="Penno">
<organization></organization>
</author>
<author initials="Y." surname="Yang">
<organization></organization>
</author>
<date month="January" year="2014" />
</front>
<seriesInfo name="draft-ietf-alto-protocol-25" value="(work in progress)" />
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC7069">
<front>
<title>DECoupled Application Data Enroute (DECADE)</title>
<author initials="R." surname="Alimi" fullname="R. Alimi">
<organization/>
</author>
<author initials="A." surname="Rahman" fullname="A. Rahman">
<organization/>
</author>
<author initials="D." surname="Kutscher" fullname="D. Kutscher">
<organization/>
</author>
<author initials="Y." surname="Yang" fullname="Y. Yang">
<organization/>
</author>
<author initials="H." surname="Song" fullname="H. Song">
<organization/>
</author>
<author initials="K." surname="Pentikousis" fullname="K. Pentikousis">
<organization/>
</author>
<date year="2013" month="November"/>
</front>
<seriesInfo name="RFC" value="7069"/>
<format type="TXT" octets="81867" target="http://www.rfc-editor.org/rfc/rfc7069.txt"/>
</reference>
<reference anchor="I-D.draft-deng-alto-p2pcache">
<front>
<title>Considerations for ALTO with network-deployed P2P caches</title>
<author initials="L." surname="Deng">
<organization></organization>
</author>
<author initials="W." surname="Chen">
<organization></organization>
</author>
<author initials="Q." surname="Yi">
<organization></organization>
</author>
<date month="February" year="2014" />
</front>
<seriesInfo name="draft-deng-alto-p2pcache-03 " value="(work in progress)" />
</reference>
</references>
</back>
<!-- Here we use entities that we defined at the beginning. -->
<!-- Change Log
v00 2006-03-15 EBD Initial version
v01 2006-04-03 EBD Moved PI location back to position 1 -
v3.1 of XMLmind is better with them at this location.
v02 2007-03-07 AH removed extraneous nested_list attribute,
other minor corrections
v03 2007-03-09 EBD Added comments on null IANA sections and fixed heading capitalization.
Modified comments around figure to reflect non-implementation of
figure indent control. Put in reference using anchor="DOMINATION".
Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH Major changes: shortened discussion of PIs,
added discussion of rfc include.
v05 2007-03-10 EBD Added preamble to C program example to tell about ABNF and alternative
images. Removed meta-characters from comments (causes problems). -->
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:59:21 |