|
|
| About site: Internet/RFCs/2101 - 2200 - RFC 2113 |
Return to Computers also Computers
|
| About site: http://www.faqs.org/rfcs/rfc2113.html |
Title: Internet/RFCs/2101 - 2200 - RFC 2113 IP Router Alert Option. D. Katz. February 1997.
|
|
|
|
|
MultiMedia_Soft Main activity is the development of multimedia oriented software components (mainly ActiveX controls) for Windows 95/98/2000/NT 4.0.
| Time_Consultant Offers online time tracking and billing software. Includes tour, screenshots and online demo.
| Dafont Archive of freely downloadable fonts. Browse by alphabetical listing, by style, by author or by popularity. [Windows, MacOS]
| My_iPhone_Tricks Weblog site with focus on customization and accessory reviews.
| RTaz_Consulting_Services,_Inc_ Offers design and consulting services. Based in Sugarland, Texas, United States.
| Diverse_Net_Option Provide web design, domain registration, and hosting services. Located in Laguna Niguel, California, United States.
|
|
| Alexa statistic for http://www.faqs.org/rfcs/rfc2113.html |
Please visit: http://www.faqs.org/rfcs/rfc2113.html
|
| Related sites for http://www.faqs.org/rfcs/rfc2113.html |
| ReplayTV Information on ReplayTV Digital Video Recorder set-top box for personal video recording, broadband internet, and streaming video. | | MTS_by_Mark_Riordan A collection of information and links on MTS and MERIT (Michigan Educational and Research Information Triad) Network, including the MTS Help section with its description of MTS commands and related us | | Screen_Capture Software for capturing images for documentation. A captured image is stored in the clipboard for a future processing by any of the available tool. | | MyWebPage_at_Netscape 20Mb. Banner ad at top of each page. Browser uploads. URL: 'http://webpages.netscape.com/yoursite/'. | | PragmaDigm_Practical_Software_Solutions Windows software, featuring DocsPDite a complete document management software solution. In addition our popular random password generator, free address book and cadfile viewer is available. | | Face_Recognition_Homepage Aims to provide scientists with the relevant information in the area of face recognition. It is intended to be an information pool for this community. | | elastiC_World Portable, extensible, embeddable, high level, interpreted, object-oriented, C-like syntax, fast GC, functional programming support, namespaces. Has documentation, FAQ, code samples, downloads, license | | MoodSmilies Display your mood with a smiley in your blog. Free. | | Ampronix,_Inc Offers medical monitors and industrial video printers, VCR repair as well as CRT tubes and flat panel. | | Stojanovic,_Zoran Curriculum Vitae, research, publications. | | Who_is_Selling_SCO_Stock? Two outside stockholders, John R. Wall, Morgan Keegan & Co., decided to dump 1 million shares they held. SCO executed full registration process, at its expense, to facilitate this, yet proceeds go | | RFC_1851 The ESP Triple DES Transform. P. Karn, P. Metzger, W. Simpson. September 1995. | | Integrity_Computer_Services_Inc ICS offers Wireless Internet Access, Web Site Design and Hosting, eCommerce Web Sites, Online Registration Systems, and Custom iHTML Programming Services. | | Shelter_Island_Graphics Provides graphic design for web and print media. Based in Shelter Island, New York, United States. | | Desert_Creations Offers design, scripring, database development, and hosting services. Located in Tucson, Arizona, United States. | | Digital-Time Services offered include: design, Active Server Page development, e-commerce, domain registration, hosting, promotion, and search engine submission. Site in English and Italian. | | Pragya_Net_Technology Offers software development, web design, hosting and maintenance. | | Arthur_Derk\'s_Perl_Scripts_and_Programs Scripts created by a systems/network engineer whose hobbies include Perl. | | WyPy One of the shortest known wikis, it is only 11 lines long and implements all the Wiki Principles | | FTPGetter Automated FTP program which is intended to upload or download files between FTP servers and local or network workstation drives. |
|
This is websites2007.org cache of m/ as retrieved on 2008.09.07 websites2007.org's cache is the snapshot that we took of the page as we crawled the web. The page may have changed since that time.
|
RFC 2113 (rfc2113) - IP Router Alert Option@import 'http://faqs.org/abstracts/css/default.css';@import 'http://faqs.org/search.css';function erfc(s){document.write("[ RFC Index | RFC Search | Usenet FAQs | Web FAQs | Documents | Cities ]Alternate Formats: rfc2113.txt | rfc2113.txt.pdfRFC 2113 - IP Router Alert OptionSearch the Archives  Display RFC by number RFC2113 - IP Router Alert OptionNetwork Working Group D. KatzRequest for Comments: 2113 cisco SystemsCategory: Standards Track February 1997 IP Router Alert OptionStatus of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.Abstract This memo describes a new IP Option type that alerts transit routers to more closely examine the contents of an IP packet. This is useful for, but not limited to, new protocols that are addressed to a destination but require relatively complex processing in routers along the path.1.0 Introduction A recent trend in routing protocols is to loosely couple new routing functionality to existing unicast routing. The motivation for this is simple and elegant -- it allows deployment of new routing functionality without having to reinvent all of the basic routing protocol functions, greatly reducing specification and implementation complexity. The downside of this is that the new functionality can only depend on the least common denominator in unicast routing, the next hop toward the destination. No assumptions can be made about the existence of more richly detailed information (such as a link state database). It is also desirable to be able to gradually deploy the new technology, specifically to avoid having to upgrade all routers in the path between source and destination. This goal is somewhat at odds with the least common denominator information available, since a router that is not immediately adjacent to another router supporting the new protocol has no way of determining the location or identity of other such routers (unless something like a flooding algorithm is implemented over unicast forwarding, which conflicts with the simplicity goal). One obvious approach to leveraging unicast routing is to do hop-by- hop forwarding of the new protocol packets along the path toward the ultimate destination. Each system that implements the new protocol would be responsible for addressing the packet to the next system in the path that understood it. As noted above, however, it is difficult to know the next system implementing the protocol. The simple, degenerate case is to assume that every system along the path implements the protocol. This is a barrier to phased deployment of the new protocol, however. RSVP [1] finesses the problem by instead putting the address of the ultimate destination in the IP Destination Address field, and then asking that every RSVP router make a "small change in its ... forwarding path" to look for the specific RSVP packet type and pull such packets out of the mainline forwarding path, performing local processing on the packets before forwarding them on. This has the decided advantage of allowing automatic tunneling through routers that don't understand RSVP, since the packets will naturally flow toward the ultimate destination. However, the performance cost of making this Small Change may be unacceptable, since the mainline forwarding path of routers tends to be highly tuned--even the addition of a single instruction may incur penalties of hundreds of packets per second in performance.2.0 Router Alert Option The goal, then, is to provide a mechanism whereby routers can intercept packets not addressed to them directly, without incurring any significant performance penalty. This document defines a new IP option type, Router Alert, for this purpose. The Router Alert option has the semantic "routers should examine this packet more closely". By including the Router Alert option in the IP header of its protocol message, RSVP can cause the message to be intercepted while causing little or no performance penalty on the forwarding of normal data packets. Routers that support option processing in the fast path already demultiplex processing based on the option type field. If all option types are supported in the fast path, then the addition of another option type to process is unlikely to impact performance. If some option types are not supported in the fast path, this new option type will be unrecognized and cause packets carrying it to be kicked out into the slow path, so no change to the fast path is necessary, and no performance penalty will be incurred for regular data packets. Routers that do not support option processing in the fast path will cause packets carrying this new option to be forwarded through the slow path, so no change to the fast path is necessary and no performance penalty will be incurred for regular data packets.2.1 Syntax The Router Alert option has the following format: +--------+--------+--------+--------+ |10010100|00000100| 2 octet value | +--------+--------+--------+--------+ Type: Copied flag: 1 (all fragments must carry the option) Option class: 0 (control) Option number: 20 (decimal) Length: 4 Value: A two octet code with the following values: 0 - Router shall examine packet 1-65535 - Reserved2.2 Semantics Hosts shall ignore this option. Routers that do not recognize this option shall ignore it. Routers that recognize this option shall examine packets carrying it more closely (check the IP Protocol field, for example) to determine whether or not further processing is necessary. Unrecognized value fields shall be silently ignored. The semantics of other values in the Value field are for further study.3.0 Impact on Other Protocols For this option to be effective, its use must be mandated in protocols that expect routers to perform significant processing on packets not directly addressed to them. Currently such protocols include RSVP [1] and IGMP [2].4.0 Security Considerations If the Router Alert option is not set and should be set, the behavior of the protocol using the Router Alert, e.g., RSVP or IGMPv2, will be adversely affected since the protocol relies on the use of the Router Alert option. If the Router Alert option is set when it should not be set, it is likely that the flow will experience a performance penalty, as a packet whose Router Alert option is set will not go through the router's fastpath and will be processed in the router more slowly than if the option were not set.5.0 References [1] Braden, B. (ed.), L. Zhang, D. Estrin, S. Herzog, S. Jamin, "Resource ReSerVation Protocol (RSVP)," work in progress, March 1996. [2] Fenner, W., "Internet Group Management Protocol, Version 2 (IGMPv2)," work in progress, October 1996.Author's Address Dave Katz cisco Systems 170 W. Tasman Dr. San Jose, CA 95134-1706 USA Phone: +1 408 526 8284 Email: dkatz@cisco.com Previous: RFC 2112 - The MIME Multipart/Related Content-type Next: RFC 2114 - Data Link Switching Client Access Protocol [ RFC Index | RFC Search | Usenet FAQs | Web FAQs | Documents | Cities ] © 2008 FAQS.ORG. All rights reserved. |
|
| |
IP | Router | Alert | Option. | D. | Katz. | February | 1997. |
|
http://www.faqs.org/rfcs/rfc2113.html
RFC 2113 2008 September
dvd rental
dvd
IP Router Alert Option. D. Katz. February 1997.
Rules
|
© 2008 Internet Explorer 5+ or Netscape 6+
|
|
Recommended Sites: 1.
Arts -
Business -
Computers -
Games -
Health -
Home -
Kids and Teens -
News -
Recreation -
Reference -
Regional -
Science -
Shopping -
Society -
Sports -
World
Miss Gallery
- Top Anime Hentai
- DVD rental by mail
- Comcast - Credit Card Consolidation - Loans - Słownik angielski - Golf Store
|
