|
|
| |
|
The Open Grid Service Architecture (OGSA) is called the next generation grid standard architecture that evolves from the five level hourglass model structures used to ensuring quality of service a across a grid computing network.
|
|
|
|
 |
|
|
| |
|
WSRF (Web Services Resource Framework) defines conventions for managing "state" so that applications can reliably share changing information.
|
|
|
|
|
|
|
| |
|
WS-Notification is a family of related specifications that define a standard Web services approach to notification using a topic-based publish/subscribe pattern. It includes: standard message exchanges to be implemented by service providers that wish to participate in Notifications, standard message exchanges for a notification broker service provider (allowing publication of messages from entities that are not themselves service providers), operational requirements expected of service providers and requestors that participate in notifications, and an XML model that describes topics. The WS-Notification family of documents includes three normative specifications: WS-BaseNotification, WS-BrokeredNotification, and WS-Topics.
Web Services Distributed Management (WSDM) technical committee produced two specifications : Management Using Web services (MUWS) and Management Of Web Services (MOWS). MUWS defines how an Information Technology resource connected to a network provides manageability interfaces such that the IT resource can be managed locally and from remote locations using Web services technologies. The MOWS specification is based on the concepts and definitions expressed in the MUWS specification.
|
|
|
|
|
|
|
| |
|
Existing transport protocols have limitations when they are used in new application domains and for new network technologies. TCP survived the days of low bandwidth and low latency, but for several reasons it is not able to efficiently cope with today's evolving environment. Standard TCP does not scale well in high bandwidth, large round-trip time networks. A lot of efforts are going on to improve performance for bulk data transfer in such networks. To solve the aforementioned problems, two main approaches are proposed: one focuses on a modification of TCP and specifically the AIMD algorithm, the other proposes the introduction of totally new transport protocols. With the large deployment of optical networks and grid applications, this is again a very active research area in networks.
In the context of very high-speed environments, performances or loss can also occur due to problems at the host (sender or receiver side). This document reviews and compares different emerging alternatives that try to solve this and other problems, such as HS-TCP, Scalable TCP, FAST TCP, BIC & CUBIC, Westwood+, UDP lite, RB UDP, TSUNAMI, UDT, RAP, TFRC, TEAR, LDA+, XCP, CADPC/PTP, SCTP, DCCP and GRIDFTP.
|
|
|
|
|
|
|
| |
|
A Grid resource reservation API should provide two capabilities. First, it should allow users to make reservations either in advance of when the resource is needed or at the time that the user needs it. Second, the same API should be capable of making and manipulating a reservation regardless of the type of the underlying resource.
This document presents an advance reservation API, and uses the Resource Specification Language (RSL) to describe a reservation request. It will be useful for different advance reservation systems to provide the same interface. It also provides an interface which is expected to serve well for 2-5 years, at which point a new interface will be developed to reflect new understanding. The API can be considered a RPC mechanism to communication with a reservation manager, which controls reservations for a resource.
To create a flexible architecture that supports co-allocation, resource location, and resource acquisition steps, the document proposes a layered architecture with three levels of APIs and one level of low-level mechanisms. When users desire advance reservations for multiple resources and different kinds of resources at the same time, they will build tools on top of the Grid Advance Reservation API.
|
|
|
|
|
|
|
| |
|
The Grid High-Performance Networking (GHPN) Research Group focuses on the relationship between network research and Grid application and infrastructure development.
|
|
|
|
|
|
|
| |
|
Network services are specialized in the handling of network-related or network resident resources. A network service is further labeled as a Grid network service whenever it has roles and/or interfaces that are deemed to be specific to a Grid infrastructure. This document provides a high-level, structured description of some well-understood Grid network services use cases. Use cases are divided in two groups: path-oriented and knowledge-based.
Path-oriented use cases illustrate a number of use cases aiming at the usage of different types of network connectivity as follows: visualization session, large data streaming coordinated with job execution, high energy physics file replica management use cases, emergency medical technician application with integrated wireless sensors, distributed aircraft maintenance environment (DAME), networked supercomputing and very long baseline interferometry.
Knowledge-based use cases include use cases that are about the collection and usage of network performance information as passively monitored data, administrative setup of schedules of measurements and service optimization.
|
|
|
|
|
|
|
| |
|
Overall definition and description of IPTV in the business role model.
|
|
|
|
|
|
|
| |
|
The Datagram Congestion Control Protocol (DCCP) is a transport protocol that implements bidirectional, unicast connections of congestion-controlled, unreliable datagrams. It provides the unreliable flows of datagrams, reliable handshakes for connection setup and teardown, reliable negotiation of options, mechanisms allowing servers to avoid holding state for unacknowledged connection attempts and already-finished connections, congestion control incorporating Explicit Congestion Notification (ECN) and the ECN Nonce, acknowledgement mechanisms communicating packet loss and ECN information, optional mechanisms that tell the sending application which data packets reached the receiver and whether those packets were ECN marked, corrupted, or dropped in the receive buffer, Path Maximum Transmission Unit (PMTU) discovery and a choice of modular congestion control mechanisms.
DCCP is intended for applications such as streaming media that can benefit from control over the tradeoffs between delay and reliable in-order delivery. It provides built-in congestion control. It also implements reliable connection setup, teardown, and feature negotiation.
|
|
|
|
|
|
|
| |
|
The TCP-like Congestion Control CCID sends data using a close variant of TCP's congestion control mechanisms. CCID 2 is suitable for senders who can adapt to the abrupt changes in congestion window typical of TCP's Additive Increase Multiplicative Decrease (AIMD) congestion control, and useful for senders who would like to take advantage of the available bandwidth in an environment with rapidly changing conditions.
CCID 2, TCP-like Congestion Control, is appropriate for DCCP flows that would like to receive as much bandwidth as possible over the long term, consistent with the use of end-to-end congestion control. CCID 2 flows must also tolerate the large sending rate variations characteristic of AIMD congestion control.
Applications that simply need to transfer as much data as possible in as short a time as possible should use CCID 2. It is also recommended over CCID 3 for applications where halving the sending rate in response to congestion is not likely to interfere with application-level performance. An additional advantage of CCID 2 is that its TCP-like congestion control mechanisms are reasonably well understood, with traffic dynamics quite similar to those of TCP.
|
|
|
|
|
|
|
| |
|
TFRC is a receiver-based congestion control mechanism that provides a TCP-friendly sending rate while minimizing the abrupt rate changes characteristic of TCP or of TCP-like congestion control.
|
|
|
|
|
|
|
| |
|
This RFC describes an internet anycasting service for IP. The primary purpose is to establish the semantics of an anycasting service within an IP internet. This memo describes an experimental service and does not propose a protocol. This memo is produced by the Internet Research Task Force (IRTF).
|
|
|
|
|
|
|
| |
|
The Internet Group Management Protocol (IGMP) is used by IPv4 systems to report their IP multicast group memberships to any neighbouring multicast routers.
|
|
|
|
|
|
|
| |
|
TFRC was designed to be reasonably fair when competing for bandwidth with TCP flows, but to avoid the abrupt changes in the sending rate characteristic of TCP's congestion control mechanisms.
|
|
|
|
|
|
|
| |
|
The objectives of FTP are 1) to promote sharing of files (computer programs and/or data), 2) to encourage indirect or implicit (via programs) use of remote computers, 3) to shield a user from variations in file storage systems among hosts, and 4) to transfer data reliably and efficiently. FTP, though usable directly by a user at a terminal, is designed mainly for use by programs.
|
|
|
|
|
|
|
| |
|
Guaranteed service provides firm (mathematically provable) bounds on end-to-end datagram queueing delays. This service makes it possible to provide a service that guarantees both delay and bandwidth.
|
|
|
|
|
|
|
| |
|
Internet traffic engineering is defined as that aspect of Internet network engineering dealing with the issue of performance evaluation and performance optimization of operational IP networks. Traffic Engineering encompasses the application of technology and scientific principles to the measurement, characterization, modeling, and control of Internet traffic.
|
|
|
|
|
|
|
| |
|
GridFTP protocol combines portions of RFC 959 "FILE TRANSFER PROTOCOL (FTP)", RFC 2228 "FTP Security Extensions", RFC 2389 "Feature negotiation mechanism for the File Transfer Protocol", an IETF draft "FTP Extensions", and several additional proposed extensions. This combination of features will allow secure, fast, efficient, flexible, and extensible data transfer and data access.
|
|
|
|
|
|
|
| |
|
RFC 4960 obsoletes RFC 2960 and RFC 3309 and describes the stream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications.
|
|
|
|
|
|
|
| |
|
RFC 3448 specifies TCP-Friendly Rate Control (TFRC). Instead of specifying a complete protocol, this document simply specifies a congestion control mechanism that could be used in a transport protocol such as RTP, in an application incorporating end-to-end congestion control at the application level, or in the context of endpoint congestion management.
|
|
|
|
|
|
|
