One document matched: draft-jeong-eman-network-proxy-protocol-01.txt
Differences from draft-jeong-eman-network-proxy-protocol-00.txt
Network Working Group S. Jeong
Internet-Draft ETRI
Intended status: Informational February 25, 2013
Expires: August 29, 2013
Network Proxy Protocol
draft-jeong-eman-network-proxy-protocol-01.txt
Abstract
In the current Internet, it is implicitly assumed that a network node
is always active so that it can receive the incoming packets at any
time. Current networking services and applications are commonly
designed to be fully available at all times with minimal response
times. This assumption keeps network nodes from entering sleeping
mode in order to reduce energy consumption. Further, during sleeping
mode, network nodes may not immediately respond to the incoming
packets or even lose them. If network nodes are allowed to go into a
sleeping mode, they can effectively reduce energy consumption during
idle period. Network proxy allows to delegate network node's traffic
processing to an external system within a network, so that the nodes
maintain network presence during their sleep. This document
describes communication mechanism between network nodes and proxy in
order to accelerate the wider deployment of network proxy mechanism.
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 August 29, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Jeong Expires August 29, 2013 [Page 1]
Internet-Draft Network Proxy February 2013
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
3. Overview of Network Proxy . . . . . . . . . . . . . . . . . . 6
4. Network Proxy Operation . . . . . . . . . . . . . . . . . . . 8
5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
Jeong Expires August 29, 2013 [Page 2]
Internet-Draft Network Proxy February 2013
1. Introduction
Information and Communications Technology (ICT) sector is facing
rapid growth and consuming a lot of power in order to provide large
bandwidth and complex application services.
According to an ITU-T report, wired and wireless networks consume
large amount of power and the amount of green-house gas emissions
caused by ICT sector is estimated 2% of total man-made emissions. It
is also estimated that network sector including network equipment and
equipment connected to networks contributes to 4% of world power
consumption. Further, it is observed that the power consumption is
higher at access networks and users, so how to reduce the power
consumption in these areas is becoming an important issue [ITU].
According to recent surveys, network equipment show a constant power
consumption profile irrespective of their utilization level, i.e.,
energy-agnostic power profile. Such equipment represent the worst
case in terms of utilization and power consumption profile. On the
contrary, ideally, energy-aware equipment represent power consumption
pattern proportional to their utilization or offered load. Practical
approaches for realizing the energy-aware equipment are implementing
multi-stepped power profiles in order to adapt to the utilization
level [EPC][GreenSurvey][EEE].
There is another researh direction for improving energy efficiency of
network equipment using network proxy technology
[I-D.winter-energy-efficient-internet][PROXZZZY][NCP]. Network proxy
describes technologies that maintain network connectivity for other
devices so that these can go into low power sleep modes. This mainly
targets the reduction of unnecessary energy waste through edge
devices.
There are typically two types of network proxies: internal and
external, respectively.
o Internal Proxy: proxy functionality is implemented within the ICT
product, such as network interface card.
o External Proxy: proxy functionality is placed within other network
equipment such as switch and external server in networks.
This document describes a protocol that is need for communication
between external proxies and network hosts.
ECMA International has published a proxying document [PROXZZZY].
This specification describes an overall architecture for network
proxying and provides capabilities that a proxy may expose to a host.
Jeong Expires August 29, 2013 [Page 3]
Internet-Draft Network Proxy February 2013
Also, information that must be exchanged between a host and a proxy,
and required and optional behavior of a proxy during its operation
are described.
Within IETF, there are several documents related with the
functionality of network proxy
[RFC6762][RFC6763][I-D.cheshire-edns0-owner-option]. These documents
defines DNS messages-based service discovery mechanisms, which can be
used for facilitating various services. These mechanisms may be used
for providing some of network proxy functionality, but generalized
network proxy functionality is not fully supported.
Generalized network proxy is capable of providing full network
presence for a broad range of network protocols and applications.
The generalized network proxy include a list of packet types that may
require routine reply, autogeneration, and wakeup, as well as the
detailed steps and methods for state information transfer each
requires [EEEC].
It is well known that many network hosts are in active state in order
to maintain network presence and this behavior hinders hosts from
entering energy saving state. Even when a node is idle with no
running applications, background traffic is received that needs to be
processed which inhibits the node from sleeping. Network proxy is
one of the possible solutions for resolve this issue. The general
framework of network proxy was developed, but the control and
communication mechanisms between network hosts and proxies has not
been developed. Thus, in order to promote the wider deployment of
network proxy mechanism, the control and communication protocol
should be specified.
This document defines a control protocol for external network proxy
operation and relevant messages in order to increase energy
efficiency of network hosts.
Jeong Expires August 29, 2013 [Page 4]
Internet-Draft Network Proxy February 2013
2. Conventions and 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].
Jeong Expires August 29, 2013 [Page 5]
Internet-Draft Network Proxy February 2013
3. Overview of Network Proxy
Network proxy refers to a set of mechanisms dedicated to put network
interfaces and network nodes into energy saving sleeping mode.
Energy consumption in sleeping mode is less than active mode in
general, so the longer the sleeping periods is, the higher the
achievable energy saving can be. The network proxy enables network
nodes to maintain network connectivity during sleep period. Figure 1
shows the typical operational scenario of network proxy [PROXZZZY].
When a host wants to enter sleeping mode, the host delivers its
network status and state to a network proxy and goes into sleeping
mode. Then, the network proxy responds to periodic messages on
behalf of the host in sleeping mode. If the proxy receives a message
that it cannot process, it sends a wake-up message to the host so
that the host can process the message after wake-up.
Host Proxy Network
| |
| |
| Full Network Connectivity |
|<-------------------------------------->|
| |
Enter | | |
Sleeping| Context Exchange | |
Mode |<------------------>| |
| | |
In | | |
Sleep | |Selective Net.Conn.|
Mode | |<----------------->|
. | | |
. | | |
| | Wake-up Event |
| Wake-up |<------------------|
|<-------------------| |
| | |
| Network Connectivity Resumed |
Wake-up |<-------------------------------------->|
| |
Figure 1: Operational scenario of network proxy
According to the survey, even though a host is in idle mode,
background network traffic is received and needs to be processed,
which prevents the host from going into sleeping mode. Also, it is
known that most of the incoming traffic received during the host's
idle period may be simply dropped or do not require more than a
minimal computation and response. For instance, most broadcast
packets or traffic related to port scanning may simply be ignored.
Jeong Expires August 29, 2013 [Page 6]
Internet-Draft Network Proxy February 2013
Usual exchanges, such as Address Resolution Protocol (ARP)
processing, Internet Control Message Protocol (ICMP) echo answering
or Dynamic Host Configuration Protocol (DHCP) rebinding, are simple
tasks that could be easily performed directly by network proxy. The
idea behind network proxy is delegating the processing of such
traffic. Processing can imply plain filtering or may require simple
responses (e.g., in the case of ARP, ICMP, DHCP), or even more
complex task. Such tasks can be delegated from the CPUs of hosts to
an external network proxy in networks [GreenSurvey].
The following list summarizes requirement status about what types of
protocols network proxy should support [PROXZZZY]. Among them, this
document describes ARP related operation first and other mandatory
protocols will be defined later version of this document.
Mandatory 1: Media (802.3, 802.11)
Mandatory 2: IPv4 ARP
Mandatory 3: IPv6 Neighbor Discovery
Mandatory 4: Wake Packets
Option 1: DNS
Option 2: DHCP
Option 3: IGMP
Option 4: MLD
Option 5: Remote Access using SIP and IPv4
Option 6: Remote Access using Teredo for IPv6
Option 7: SNMP
Option 8: Service Discovery using mDNS
Option 9: Name Resolution with LLMNR
Jeong Expires August 29, 2013 [Page 7]
Internet-Draft Network Proxy February 2013
4. Network Proxy Operation
This section describes network proxy operation between proxy server
and network nodes to support mandatory protocols. Figure 2 shows
network proxy operations for IPv4 ARP. When a network host wants to
enter sleeping mode in order to save energy, the host exchanges Proxy
Solicitation and Advertisement messages with network proxy in
network. Proxy may be implemented as a function within a switch or
router, or it may be implemented as a separate server. Proxy
Solicitation message queries to network, whether network proxy
functionality can be supported within the host's network. If there
is a network proxy that can provide proxy functionality, it replies
to the host by using Proxy Advertisement message. Network proxy
supports required functional behavior defined in [PROXZZZY] in order
to support IPv4 ARP.
After the network proxy discovery procedure, the host sends Sleep
Request message to network proxy. The Request message contains the
host's MAC address(es) and IP address(es). After receiving the Sleep
Confirm message from the network proxy, the host enters sleeping
mode. Then the network proxy discards ARP Request messages sent from
other hosts in the network. By doing so, the host can sleep without
receiving or processing ARP broadcast message not destined to the
node itself. If the network proxy receives an ARP request message
for sleeping host, it sends a reply message on behalf of the sleeping
hosts using the host's MAC and IP address. When the network proxy
receives a packet that it cannot process, the proxy sends a Wake-up
packet to the sleeping host in order to wake it up. During its
wake-up process, proxy may buffer additional packets destined to the
sleeping hosts. After the sleeping node wakes up it can communicate
with remote hosts. When Sleep Timer expires, the sleeping host wakes
up and sends a Wake-up Report message to the network proxy. Then,
the network proxy cleans up the state information for the sleeping
host and replies with Wake-up confirm message.
Note that Figure 2 shows network proxy operation for processing ARP
messages and operation for other mandatory protocols specified in
[PROXZZZY] will be defined later version of this document.
Jeong Expires August 29, 2013 [Page 8]
Internet-Draft Network Proxy February 2013
Sleeping Network Remote
Host Proxy Host
| | |
| Proxy Solicitation | |
|------------------->| |
| Proxy Advertisement| |
|<-------------------| |
| Full Network Connectivity |
|<-------------------------------------->|
| Sleep Request | |
|------------------->| |
| Sleep Confirm | |
|<-------------------| |
| | ARP Request for |
| | Sleeping Host |
| |<------------------|
| | ARP Reply for |
| | Sleeping Host |
| |------------------>|
| | |
++|++++++++++++++++++++|+++++++++++++++++++|++
+ | |Packet for Sleeping| +
+ | | Host that Proxy | +
Case1 + | | cannot process | +
+ | Wake-up Packet |<------------------| +
+ |<-------------------| | +
++|++++++++++++++++++++|+++++++++++++++++++|++
++|++++++++++++++++++++|+++++++++++++++++++|++
+ | Wake-up Report | | +
Case2 + |------------------->| | +
+ | Wake-up Confirm | | +
+ |<-------------------| | +
++|++++++++++++++++++++|+++++++++++++++++++|++
| Exchange State | |
| Information | |
|<------------------>| |
| Full Network Connectivity |
|<-------------------------------------->|
| |
Figure 2: Network proxy operation for IPv4 ARP
Jeong Expires August 29, 2013 [Page 9]
Internet-Draft Network Proxy February 2013
5. Message Formats
Figure 3 depicts two types of new ICMP messages for Proxy Request/
Reply messages. The messages are defined as follows.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Sub-Type | Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (variable size) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Proxy request message
Type <TBD> (Proxy Request)
<TBD> (Proxy Reply)
Code 0 Success
1 Fail
Checksum The 16-bit one's complement of the one's
complement sum of the ICMP message, starting with
the ICMP Type.
Message Sub-Type 1 Proxy Solicitation Message
2 Proxy Advertisement Message
3 Sleep Request Message
4 Sleep Confirm Message
5 Wake-up Report Message
6 Wake-up Confirm Message
Transaction ID Unique identifier created each time a host starts
proxy operation
Options Optional data for Sub-Type messages
Figure 4 shows the Option format for Sub-Type messages. The Option
format is defined as a TLV format.
Jeong Expires August 29, 2013 [Page 10]
Internet-Draft Network Proxy February 2013
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 4: Option format
Type Indicates the particular sub-type option.
1 Proxy Solicitation Option
2 Proxy Advertisement Option
3 Sleep Request Option
4 Sleep Confirm Option
5 Wake-up Report Option
6 Wake-up Confirm Option
Length Indicates the length (in bytes) of the data field
within this option. The length does not include
the Type and Length bytes.
Data The particular data associated with this option.
This field may be zero or more bytes in length.
The format and length of the data field is
determined by the type and length fields.
Figure 5 depicts Option format of Proxy Solicitation Sub-Type
message. The sub-type message is broadcasted in order to discover
proxy in networks. It contains 2 bytes Identifier and 2 bytes
sequence number. Currently the detail of Identifier has not been
developed, but its format and allocation method will be determined
later.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Proxy solicitation option
Figure 6 shows Option format for Proxy Advertisement Sub-Type message
used for notifying the Proxy Server's presence in network. It is
periodically broadcasted to networks and unicasted to a network node
Jeong Expires August 29, 2013 [Page 11]
Internet-Draft Network Proxy February 2013
that sent a Proxy Solicitation message. The Advertisement message
contains the address of Proxy Server's IP address(es) and
Preference(s).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Num. of Addr |Addr Entry Size|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Proxy Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proxy Address 1 | Address Preference 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Preference 1 | Proxy Address 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proxy Address 2 | Address Preference 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Preference 2 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Proxy advertisement option
Figure 7 shows Option format for Sleep Request Sub-Type message. The
message is unicasted to Proxy Server and it informs the client's
entering to sleep mode. Hardware Address Type indicates hardware
address type of client. Protocol Type contains protocol address
type. H/W length means the length of hardware address. Finally,
number of addresses indicates the number of hardware and protocol
pairs.
Jeong Expires August 29, 2013 [Page 12]
Internet-Draft Network Proxy February 2013
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Hardware Address Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Type | H/W Length | Protocol Len. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Address | Sender Hardware Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Hardware Address 1 | Sender Protocol Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Protocol Address 1 | Sender Hardware Address 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Hardware Address 2 | Sender Protocol Address 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Protocol Address 2 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Sleep request option
Figure 8 describes Option format for Sleep Confirm Sub-Type message
that is sent from a Proxy Server to Client as a response of Sleep
Request message. Code indicates the result of Sleep Request
operation. 0 indicates success and 1 indicates failure. Client
Identifier is a unique ID for identifying Client and will be
allocated by Proxy Server.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Client Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Sleep confirm option
Figure 9 depicts Option format for Wake-up report message. It is
sent by a client to Proxy Server in order to notify the wake-up event
of the client. It is unicasted to the Proxy Server. Client
Identifier is the same Identifier assigned by Sleep Confirm message.
Jeong Expires August 29, 2013 [Page 13]
Internet-Draft Network Proxy February 2013
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Client Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Wake-up report option
Figure 10 shows Option format for Wake-up Confirm message. It is
unicasted to a Client as a reply of the Client's Wake-up Report
message. Code 0 means success and 1 means failure. Client
Identifier is the same Identifier assigned by Sleep Confirm message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Client Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Wake-up confirm option
Jeong Expires August 29, 2013 [Page 14]
Internet-Draft Network Proxy February 2013
6. Security Considerations
[TBD]
Jeong Expires August 29, 2013 [Page 15]
Internet-Draft Network Proxy February 2013
7. IANA Considerations
[TBD]
Jeong Expires August 29, 2013 [Page 16]
Internet-Draft Network Proxy February 2013
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[EEE] "802.3az-2010", IEEE std , 2010.
[EEEC] Nordman, B. and K. Christensen, "Improving the Energy
Efficiency of Ethernet-Connected: A Proposal for
Proxying", Ethernet Alliance , September 2007.
[EPC] Barroso, L. and U. Holzle, "The Case for Energy-
Proportional Computing", Proc. IEEE International
Conference on Network Protocols (ICNP) , December 2007.
[GreenSurvey]
Bianzino, A., Chaudet, C., Rossi, D., and J. Rougier, "A
survey of green networking research", IEEE Communications
Surveys Tutorials , 2012.
[I-D.cheshire-edns0-owner-option]
Cheshire, S. and M. Krochmal, "EDNS0 OWNER Option",
draft-cheshire-edns0-owner-option-00 (work in progress),
July 2009.
[I-D.winter-energy-efficient-internet]
Winter, R., Jeong, S., and J. Choi, "Towards an Energy-
Efficient Internet",
draft-winter-energy-efficient-internet-01 (work in
progress), October 2012.
[ITU] "Resolution 73 - Information and communication
technologies and climate change", October 2008.
[NCP] Jimeno, M., Christensen, K., and B. Nordman, "A Network
Connection Proxy to Enable Hosts to Sleep and Save
Energy", Proc. IEEE Internat. Performance Computing and
Communications Conf , 2008.
[PROXZZZY]
"ProxZZZy for sleeping hosts", ECMA International ECMA-
393, June 2012.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
Jeong Expires August 29, 2013 [Page 17]
Internet-Draft Network Proxy February 2013
February 2013.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013.
[SKILL] Nedevschi, S., Liu, J., Nordman, B., Ratnasamy, S., and N.
Taft, "Skilled in the Art of Being Idle: Reducing Energy
Waste in Networked Systems", Proc. USENIX Symposium on
Networked Systems Design and Implementation , 2009.
Jeong Expires August 29, 2013 [Page 18]
Internet-Draft Network Proxy February 2013
Author's Address
Sangjin Jeong
ETRI
218 Gajeongno, Yuseong
Daejeon, 305-700
Korea
Phone: +82 42 860 1877
Email: sjjeong@etri.re.kr
Jeong Expires August 29, 2013 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-23 02:59:01 |