S.E. Deering. Host extensions for IP multicasting. rfc 1112, Internet Engineering Task Force, August 1989.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....Routing, Cache Management I. INTRODUCTION Along with the advancement in wireless networking technologies, the mobile population of the Internet is expected to contain over a billion wireless devices, such as telephone handsets, in the near future. Therefore this research deals only with IPv6 [6], because IPv6 has scale advantages such as huge address space and plug and play support. In addition, IPv6 is expected to promote wireless computing and is deployed rapidly due to IPv4 address insufficiency. Current research of mobility protocol called Mobile IPv6 is almost ready for a ....

S. Deering and R. Hinden. Internet Protocol, Version 6 (ipv6) Specification. Request for Comments (Draft Standard) 2460, Internet Engineering Task Force, December 1998.

....host. Should a packet bounce, the correspondent host may ask the home agent what the current address of the mobile host is. This approach puts more strain on the correspondent host, and an upgrade to the network layer in the correspondent host is necessary. In Internet Protocol version 6(IPv6)[10], the next generation of IP, mobility as per mobile IP with route optimization is included. Here a correspondent host or a router can cache the current address of the mobile host, and forward packages directly rather than through the home agent. Implementing route optimizing in IPv6 holds more ....

Stephen E. Deering and Robert M. Hinden. Internet Protocol version 6 (IPv6) specication. Internet Engineering Task Force, December 1998.

.... typically rely on the Real time Transport Protocol (RTP) for data transmission and on its accompanying Real time Transport Control Protocol (RTCP) for the distribution of feedback and control information [21] Both RTP and RTCP originally assumed the availability of a shared multicast channel [7], allowing for efficient many to many communication among session participants; any group member could communicate with all others by simply sending to a multicast address and the routing level architecture would efficiently distribute the data. The primary function of RTCP is to periodically ....

....and group sizes. We conclude with Section 5 on related work, and Section 6, on the contributions and future directions of our research. 2. RTCP Protocol Extensions In traditional RTP RTCP, the data and control share a many to many communication channel, such as that provided by IP multicast [7]. The channel allows not only the bidirectional flow of communication from sources to receivers and vice versa, but also direct receiver to receiver communication over a single channel. Uni directional and asymmetric broadcast architectures often lack these features. In this section, we propose ....

S. Deering. Host extensions for IP multicasting. Request for Comments 1054, Internet Engineering Task Force, Aug. 1989.

....of Route Optimization for Mobile IP in the Internet today is that of providing authentication for all messages that affect the routing of datagrams to a mobile node [91, pp. 23] IPv6 The IETF has standardized the next version of the IP protocol, IPv6, which provides a number of enhancements [26]. The current version, which we refer to simply as IP, is properly known as IPv4. Because IPv6 provides native support for multiple simultaneous host addresses, route optimization does not require further modifying IPv6 hosts of course, IPv6 itself requires a massive overhaul of the entire ....

Stephen E. Deering and Robert M. Hinden. Internet protocol, version 6 (IPv6) specification. RFC 2460, Internet Engineering Task Force, December 1998.

....to affect the same triangle routing. 2.2. 6 Multicast mobility Mysore and Bharghavan propose an approach to network layer mobility that avoids the need for a home agent or a new protocol for binding updates entirely [76] They issue each mobile host a permanent Class D IP multicast address [25] that serves as an end point identifier. If multicast were widely deployed, this approach might hold promise; because a multicast EID has the benefit of being directly routable by the routing infrastructure, it removes the need for an explicit careof address. Instead, it places the burden of ....

....application end points. 147 Instead, multi party applications may maintain sessions consisting of multiple end points. Because the semantics of connectivity, session suspension, and end point tracking are unclear in this environment, Migrate does not support applications that use multicast [25]. Extending Migrate s notion of a session include more than two end points is an area for future research. In addition to applications that maintain state across multiple end points, some applications maintain no session state whatsoever. The most notable example of this class of application is ....

Stephen E. Deering. Host extensions for IP multicasting. RFC 1122, Internet Engineering Task Force, August 1989.

....crucial to improve the service eciency of hot videos. Thus, requests by multiple clients for the same video arriving within a short time interval can be batched together and serviced using a single stream. This is referred to as batching . The multicast facility of modern communication networks [24, 25, 59] o ers an ecient means of one to many data transmission. The basic idea is to avoid transmitting the same packet more than once on each link of the network by having branch routers duplicate and then send the packet over multiple downstream branches. Multicast can signi cantly improve the VoD ....

S. Deering, \Host extensions for IP multicasting," Internet Engineering Task Force (IETF), RFC 1112, August 1989.

....of time, its state in the CM is purged. Appli cations can also use the cm mtu( call to obtain the maximum transmission unit (MTU, the largest unfragmented datagram size) to a destination. Inside the CM, this is either pre configured or obtained using path MTU discovery to the receiver and cached [25]. 2.1.2 Data transmission There are three ways in which an application can use the CM to transmit data. These allow a variety of adaptation strategies, depending on the nature of the client application and its software structure. i) Buffered send. This API is similar to a con ventional ....

MOGUL, J., AND DEERING, S. Path MTU Discovery. Internet Engineering Task Force, Nov 1990. RFC 1191.

....becomes a prevalent mode of communication. Often the transmitted data is streamed and has considerable band width. To avoid having to send the data separately to each receiver, several multicast routing protocols have been proposed and deployed, typically in the IP layer. Examples include [12, 13, 23, 16, 6]) The underlying principle of multicast communication is that each data packet sent from the source reaches a number of receivers. Securing multicast communication introduces a number of difficulties that are not encountered when trying to secure unicast communication. See [9] for a taxonomy of ....

S. E. Deering. Host extensions for IP multicasting. Request for Comments (Standard) 1112, Internet Engineering Task Force, Aug. 1989.

....opinion or policies, either expressed or implied of the US government or any of its agencies, DARPA, NSF, USPS. width. To avoid having to send the data separately to each receiver, several multicast routing protocols have been proposed and deployed, typically in the IP layer. Examples include [12, 13, 23, 16, 6]) The underlying principle of multicast communication is that each data packet sent from the source reaches a number of receivers. Securing multicast communication introduces a number of difficulties that are not encountered when trying to secure unicast communication. See [9] for a taxonomy of ....

S. E. Deering. Host extensions for IP multicasting. Request for Comments (Standard) 1112, Internet Engineering Task Force, Aug. 1989.

....[2] 3] Network and transport protocol support for voice over IP in cellular systems has not yet been fully developed and optimized. Traditional TCP IP support cannot be used because TCP can never provide usable lower delay bounds for voice packets. UDP IP support, especially in IPv6[4], provides a service that can throw away whole voice packets when bit errors are detected. Cellular networks make this last problem signi cant since bit errors occur frequently. The checksumming policy in UDP makes the problem even worse, since speech codecs designed for use in cellular ....

Stephen Deering and Robert Hinden, Internet Protocol, Version 6 (IPv6), Request for Comments RFC 2460, Internet Engineering Task Force, December 1998.

....to disable the UDP checksum. This, however, is not an acceptable solution as errors can not be tolerated in the UDP and RTP headers. Disabling the UDP checksum means that errors in headers will not be detected with potentially disastrous consequences. Moreover, in the next generation of IP, IPv6 [13], the UDP checksum is mandatory because the IP header checksum has been eliminated. What is needed is a transport protocol capable of delivering partially damaged payloads to codecs that permit this, while protecting vital header fields with a checksum. The new UDP protocol formerly known as ....

....protocols[43, 44, 41] Network and transport protocol support for voice over IP in cellular systems has not yet been fully developed and optimized. Traditional TCP IP support cannot be used because TCP can never provide usable lower delay bounds for voice packets. UDP IP support, especially in IPv6[13], provides a service that can throw away whole voice packets when bit errors are detected. Cellular networks make this last problem significant since bit errors occur frequently. The checksumming policy in UDP makes the problem even worse, since speech codecs designed for use in 35 cellular ....

Stephen Deering and Robert Hinden. Internet Protocol, Version 6 (IPv6). Request for Comments RFC 2460, Internet Engineering Task Force, December 1998.

....To provide cost e#cient networking in this environment, it is essential to use that spectrum as e#ciently as possible. The Internet protocols were designed for networks with di#erent properties than a bandwidth constrained wireless system. Protocol headers in many of the Internet protocols ([41, 43, 44, 12, 50]) are generous in size, which have motivated the design of several header compression algorithms ( 28, 16, 10] There is also ongoing work on an architecture for robust, tra#c specific, header compression algorithms within the IETF [49] Of the existing algorithms, the only one which is widely ....

Stephen Deering and Robert Hinden. Internet Protocol, Version 6 (IPv6) Specification. Request for Comments RFC 1883, Internet Engineering Task Force, December 1995.

....becomes a prevalent mode of communication. Often the transmitted data is streamed and has considerable bandwidth. To avoid having to send the data separately to each receiver, several multicast routing protocols have been proposed and deployed, typically in the IP layer. Examples include [12, 13, 23, 16, 6]) The underlying principle of multicast communication is that each data packet sent from the source reaches a number of receivers. Securing multicast communication introduces a number of difficulties that are not encountered when trying to secure unicast communication. See [9] for a taxonomy of ....

S. E. Deering. Host extensions for IP multicasting. Request for Comments (Standard) 1112, Internet Engineering Task Force, Aug. 1989.

....and neither does IPv6. For applications and their end hosts, end to end measurements may be the only way of measuring network performance, especially when there is no provision inside the network to give information about the current status of the network to users without access to the routers. [11]. There are two modes of network performance measurement: active and passive. Active measurement tools generate packets and inject them to the network for the purpose of performance evaluation. All of the tools listed above are passive, since they do not generate traffic, but merely monitor the ....

Deering, S., and Hinden, R. Internet Protocol, version 6 (IPv6) specification. RFC 1883, Internet Engineering Task Force, December 1995.

....between minimum and maximum signal level, ranging from 32768 to 32767. Schulzrinne Casner Expires May 2002 [Page 19] INTERNET DRAFT draft draft ietf avt pro le new 12.ps November 20, 2001 eld eld name bits eld eld name bits 1 LARc[0] 6 39 xmc[22] 3 2 LARc[1] 6 40 xmc[23] 3 3 LARc[2] 5 41 xmc[24] 3 4 LARc[3] 5 42 xmc[25] 3 5 LARc[4] 4 43 Nc[2] 7 6 LARc[5] 4 44 bc[2] 2 7 LARc[6] 3 45 Mc[2] 2 8 LARc[7] 3 46 xmaxc[2] 6 9 Nc[0] 7 47 xmc[26] 3 10 bc[0] 2 48 xmc[27] 3 11 Mc[0] 2 49 xmc[28] 3 12 xmaxc[0] 6 50 xmc[29] 3 13 xmc[0] 3 51 xmc[30] 3 14 xmc[1] 3 52 xmc[31] 3 15 xmc[2] 3 53 ....

....many packets, either desired or undesired. Network layer authentication may be used to discard packets from undesired sources, but the processing cost of the authentication itself may be too high. In a multicast environment, pruning of speci c sources may be implemented in future versions of IGMP [24] and in multicast routing protocols to allow a receiver to select which sources are allowed to reach it. 11 Full Copyright Statement Copyright (C) The Internet Society (2001) All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works ....

S. Deering, \Host Extensions for IP Multicasting," Request for Comments RFC 1112, STD 5, Internet Engineering Task Force, Aug.

....to packetize the data that contain information across twoVOPs since loss of such a packet will corrupt both VOPs. With these considerations, wechoose packet size to be the minimum of the currentVOP size and the path MTU. The path MTU can be found through the mechanism proposed by Mogul and Deering [17]. In the case when path MTU information is not available, the default MTU, i.e. 576 bytes, will be used. When a VOP is too large to t into a single packet, it is necessary to break it up into multiple segments and use multiple packets. We try to minimize both the number of packets generated for ....

J. Mogul and S. Deering, \Path MTU discovery," RFC 1191, Internet Engineering Task Force, Nov. 1990.

....ne permettent pas de supporter les r#seaux mobiles ef cacement. Nous montrons en particulier que Mobile IPv6 n est pas dimensionn# pour le support de r#seaux mobiles de grande taille et qu il introduit des probl#mes d authentication. 1 Introduction La mobilit# des noeuds dans IPv4 et IPv6 [2] est g#r#e par Mobile IP (protocoles Mobile IPv4 [8] Mobile IPv4 avec optimisation de routage [6] et Mobile IPv6 [3] L objectif de ces protocoles est de permettre aux noeuds mobiles de conserver une connectivit# permanente # l Internet sans rupture des connections en cours lors de leurs ....

S. Deering and R. Hinden. Internet Protocol Version 6 (IPv6) Specication. Request For Comments 2460, Internet Engineering Task Force (IETF), December 1998.

....known session leader who initiates and maintains groups for each active session occurring within its administrative scope. The identity and location the session leader is configured at each host. Users initiate communication with an Antigone group through the socket s and setsockopt s (IGMP join [8]) calls. A background thread created during the Application socket s Library Antigone 2.0 IP Stack Kernel User Space Figure 9: The Socket s Library acts as a bump in the stack by redirecting all multicast traffic towards the Antigone interfaces. socket s call receives and sends all ....

S. Deering. Host Extensions for IP Multicasting. Internet Engineering Task Force, August 1989. RFC 1112.

....This paper proposes a solution that combines multicast routing with Mobile IPv6 to support mobile networks in the Internet. Keywords : Mobile networks, IPv6, Mobile IP, Multicast, Routing 1. Introduction Mobile IPv4 [13] and Mobile IPv6 [4] have introduced mobility support for IPv4 and IPv6 [3] nodes respectively. The purpose of mobility support is to provide continuous Internet connectivity to mobile nodes. Mobile IP is a solution to support mobile nodes but does not handle mobile networks. There are situations where an entire network might move and attach to different places in the ....

S. Deering and R. Hinden. Internet Protocol Version 6 (IPv6) Specification. Request For Comments 2460, Internet Engineering Task Force (IETF), December 1998.

....to disable the UDP checksum. This, however, is not an acceptable solution as errors can not be tolerated in the UDP and RTP headers. Disabling the UDP checksum means that errors in headers will not be detected with potentially disastrous consequences. Moreover, in the next generation of IP, IPv6 [4], the UDP checksum is mandatory because the IP header checksum has been eliminated. What is needed is a transport protocol capable of delivering partially dam aged payloads to codecs that permit this, while protecting vital header elds with a checksum. Protocol boosters for operation over ....

Stephen Deering and Robert Hinden, iInternet Protocol, Version 6 (IPv6),j Request for Comments RFC 2460, Internet Engineering Task Force, December 1998.

....Generated Addresses (CGA) Address Based Keys (ABK) General Terms Security, Standardization Keywords Neighbor Discovery, Router Discovery, Duplicate Address Detection, Autoconfiguration, Identity Based Cryptosystems. 1. INTRODUCTION Ten years ago, when the basic design for IPv6 [1][2] was being decided, it was hardly possible to foresee the kinds of wireless environments that are now being considered for use with IPv6. Correspondingly, the IPv6 functions that manage the local link were designed with physically protected, trustworthy links in mind. However, now people are ....

S. Deering and R. Hinden, Internet Protocol, Version 6 (IPv6) Specification, RFC2460, Internet Engineering Task Force, December 1998.

....802.11 standard supports three different physical layer protocols, Direct Sequence Spread Spectrum, Frequency Hopping Spread Spectrum, and Infrared transmission. In our network, we only use Frequency Hopping. On top of our LAN and MAN network infrastructure, a next generation IP network (IPv6)[1] is built to gain operational experience with mobility support with IPv6 in a seamless network environment. Terminals shall stay in touch with the network without user reconfiguration across a heterogeneous network environment, supporting both wired and wireless attachment. As an example, the ....

S. Deering and R. Hinden, Internet Protocol, Version 6 (IPv6) Specification. Internet Engineering Task Force, RFC 1883, December 1995.

....is not intended as a multi hop ad hoc routing protocol like the one described by Johnson and Maltz [8] In fact, a multi hop ad hoc routing protocol may be layered on top of our link layer protocol. The protocol is based on the axiom, I beacon, therefore I am . The ICMP router discovery packet [5] ( beacon ) used in Mobile IP has been extended to include the MAC and IP addresses of the sender, and authentication information that can be used to verify the beacon. The protocol requires that all nodes, both agents and mobile nodes, beacon. The protocol is similar to the ISO ES IS protocol ....

S. Deering. ICMP Router Discovery Messages. Request for Comments, RFC 1256, Internet Engineering Task Force, Sep 1991. Xerox PARC.

No context found.

S.E. Deering. Host extensions for IP multicasting. rfc 1112, Internet Engineering Task Force, August 1989.

No context found.

S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Speci cation. rfc 2460, Internet Engineering Task Force, December 1998.

No context found.

S. Deering, W. Fenner, and B. Haberman. Multicast Listener Discovery (MLD) for IPv6. rfc 2710, Internet Engineering Task Force, October 1999.

No context found.

S. Deering, W. Fenner, B. Haberman, Multicast listener discovery (MLD) for IPv6, RFC 2710. Internet Engineering Task Force (October 1999).

No context found.

S. Deering, R. Hinden, Internet Protocol, Version 6 (IPv6) Specification, RFC 2460, Internet Engineering Task Force (December 1998).

No context found.

S.E. Deering. Host extensions for IP multicasting. rfc 1112, Internet Engineering Task Force, August 1989.

No context found.

S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Speci cation. rfc 2460, Internet Engineering Task Force, December 1998.

No context found.

S. Deering, W. Fenner, and B. Haberman. Multicast Listener Discovery (MLD) for IPv6. rfc 2710, Internet Engineering Task Force, October 1999.

No context found.

S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. RFC 2460, Internet Engineering Task Force, Dec. 1998.

No context found.

S. Deering, W. Fenner, and B. Haberman. Multicast Listener Discovery (MLD) for IPv6. RFC 2710, Internet Engineering Task Force, October 1999.

No context found.

S. Deering and R. Hinden, RFC 2460, Internet Protocol, Version 6 (IPv6) Specification, Internet Engineering Task Force, December 1998.

No context found.

S. Deering, W. Fenner, and B. Haberman. Multicast Listener Discovery (MLD) for IPv6, October 1999. Internet Engineering Task Force, RFC 2710, STD 1.

No context found.

S. Deering. Host Extensions for IP Multicasting, August 1989. Internet Engineering Task Force, RFC 1112, STD 5.

No context found.

S. Deering. Host Extensions for IP Multicasting, August 1989. Internet Engineering Task Force, RFC 1112, STD 5.

No context found.

S. Deering. Icmp router discovery messages. RFC 1256, Internet Engineering Task Force, September 1991.

No context found.

S. Deering, W. Fenner, and B. Haberman. Multicast listener discovery (MLD) for IPv6. RFC 2710, Internet Engineering Task Force, October 1999.

No context found.

S. E. Deering. Host extensions for IP multicasting. RFC 1112, Internet Engineering Task Force, August 1989.

No context found.

S. Deering, Editor. ICMP Router Discovery Messages. Internet Engineering Task Force, RFC 1256, September 1991.

No context found.

S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. Internet Engineering Task Force, RFC 2460, December 1998.

No context found.

S. Deering et al. ICMP router discovery messages. RFC 1256, Internet Engineering Task Force, Sep. 1991. URL http://www.rfc-editor.org/rfc/rfc1256.txt.

No context found.

S. E. Deering and R. Hinden. Internet protocol, version 6 (ipv6) specification. RFC 2460, Internet Engineering Task Force, December 1998.

No context found.

S. Deering. Host Extensions for IP Multicasting. Internet Engineering Task Force, August 1989. RFC 1112.

No context found.

S. Deering. Host extensions for IP multicasting. Request for Comments (Standard) RFC 1112, Internet Engineering Task Force, August 1989.

No context found.

Steve Deering. Host extensions for IP multicasting. RFC 1112, Internet Engineering Task Force, August 1989. Available from ftp://ds.internic.net/ rfc/rfc1112.txt.

No context found.

S. Deering. Host extensions for IP multicasting. Internet Engineering Task Force (IETF), RFC 1112, August 1989.

No context found.

Deering, S. and Hinden, R., Internet Protocol Version 6 (IPv6) Specification, The Internet Engineering Task Force, Network Working Group, Request for Comments 2460, December 1998.

No context found.

S. Deering, R. Hinden Internet Protocol, Version 6 (IPv6) Speci cation RFC 2460, Internet Engineering Task Force, Dec. 1994. http://www.ietf.org/rfc/rfc2460.txt?number=2460

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC