| |
| RFC 2600 | Internet Official Protocol Standards |
| |
|
|
This memo is published by the RFC Editor in accordance with Section 2.1 of "The Internet Standards Process -- Revision 3", RFC 2026, which specifies the rules and procedures by which all Internet standards are set. This memo is prepared by the RFC Editor for the IESG and IAB. Please see http://www.rfc-editor.org for later updates to this document. [STANDARDS-TRACK] |
|
| |
| RFC 2601 | ILMI-Based Server Discovery for ATMARP |
| |
| Authors: | M. Davison. |
| Date: | June 1999 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2601 |
|
This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate ATMARP servers. |
|
| |
| RFC 2602 | ILMI-Based Server Discovery for MARS |
| |
| Authors: | M. Davison. |
| Date: | June 1999 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2602 |
|
This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate MARS servers. |
|
| |
| RFC 2603 | ILMI-Based Server Discovery for NHRP |
| |
| Authors: | M. Davison. |
| Date: | June 1999 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2603 |
|
This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate NHRP servers. |
|
| |
| RFC 2604 | Wireless Device Configuration (OTASP/OTAPA) via ACAP |
| |
|
|
Wireless carriers today are faced with creating more efficient distribution channels, increasing customer satisfaction, while also improving margin and profitability. Industry trends are pushing the sale of handsets further into the retail channel. The cost and effort of provisioning handsets, activating users, and updating handset parameters can be greatly reduced by using over-the-air activation mechanisms. A comprehensive and extensible means for over-the-air provisioning and handset parameter updating is required.
One approach is to purchase EIA/TIA/IS-683A (Over-the-air ServiceProvisioning of Mobile Stations in Spread Spectrum Systems) equipment. The cost of this has led carriers to seek alternative solutions. A very viable means for providing over-the-air (OTA) provisioning is to leverage the rollout of IS-707 data services equipment, which most carriers are in the process of deploying. This paper presents an approach to OTA provisioning that utilizes the deployment of IS-707 to deliver OTA provisioning and parameter upgrading.
IS-707 data services makes available several methods of providing over-the-air provisioning and parameter updating. A well thought-out approach utilizing Internet-based open standard mechanisms can provide an extensible platform for further carrier service offerings, enhanced interoperability among back-end services, and vendor independence.
This paper describes a viable and attractive means to provideOTASP/OTAPA via IS-707, using the ACAP [ACAP] protocol. |
|
| |
| RFC 2605 | Directory Server Monitoring MIB |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This memo obsoletes RFC 1567, "X.500 Directory Monitoring MIB". This memo extends that specification to a more generic MIB for monitoring one or more directory servers each of which may support multiple access protocols. The MIB defined in this memo will be used in conjunction with the NETWORK-SERVICES-MIB [19] for monitoringDirectory Servers. |
|
| |
| RFC 2606 | Reserved Top Level DNS Names |
| |
|
|
To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented. |
|
| |
| RFC 2607 | Proxy Chaining and Policy Implementation in Roaming |
| |
| Authors: | B. Aboba, J. Vollbrecht. |
| Date: | June 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2607 |
|
This document describes how proxy chaining and policy implementation can be supported in roaming systems. This memo provides information for the Internet community. |
|
| |
| RFC 2608 | Service Location Protocol, Version 2 |
| |
|
|
The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet need little or no static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration. |
|
| |
| RFC 2609 | Service Templates and Service: Schemes |
| |
| Authors: | E. Guttman, C. Perkins, J. Kempf. |
| Date: | June 1999 |
| Formats: | txt json html |
| Updates: | RFC 2165 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2609 |
|
The "service:" URL scheme name is used to define URLs (called"service: URLs" in this document) that are primarily intended to be used by the Service Location Protocol in order to distribute service access information. These schemes provide an extensible framework for client-based network software to obtain configuration information required to make use of network services. When registering a service: URL, the URL is accompanied by a set of well-defined attributes which define the service. These attributes convey configuration information to client software, or service characteristics meaningful to end users.
This document describes a formal procedure for defining and standardizing new service types and attributes for use with the"service:" scheme. The formal descriptions of service types and attributes are templates that are human and machine understandable.They SHOULD be used by administrative tools to parse service registration information and by client applications to provide localized translations of service attribute strings. |
|
| |
| RFC 2610 | DHCP Options for Service Location Protocol |
| |
| Authors: | C. Perkins, E. Guttman. |
| Date: | June 1999 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2610 |
|
The Dynamic Host Configuration Protocol provides a framework for passing configuration information to hosts on a TCP/IP network.Entities using the Service Location Protocol need to find out the address of Directory Agents in order to transact messages. Another option provides an assignment of scope for configuration of SLP User and Service Agents. |
|
| |
| RFC 2611 | URN Namespace Definition Mechanisms |
| |
| Authors: | L. Daigle, D. van Gulik, R. Iannella, P. Faltstrom. |
| Date: | June 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3406 |
| Also: | BCP 0033 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2611 |
|
The URN WG has defined a syntax for Uniform Resource Names (URNs)[RFC2141], as well as some proposed mechanisms for their resolution and use in Internet applications ([RFC2168, RFC2169]). The whole rests on the concept of individual "namespaces" within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed ([RFC2288]), and this document lays out general definitions of and mechanisms for establishing URN "namespaces". |
|
| |
| RFC 2612 | The CAST-256 Encryption Algorithm |
| |
| Authors: | C. Adams, J. Gilchrist. |
| Date: | June 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2612 |
|
There is always a desire in the Internet community for unencumbered encryption algorithms with a range of key sizes that can provide security for a variety of cryptographic applications and protocols.
This document describes an existing algorithm that can be used to satisfy this requirement. Included are a description of the cipher and the key scheduling algorithm, the s-boxes, and a set of test vectors (Appendix A). |
|
| |
| RFC 2613 | Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0 |
| |
| Authors: | R. Waterman, B. Lahaye, D. Romascanu, S. Waldbusser. |
| Date: | June 1999 |
| Formats: | txt html json |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 2613 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing remote network monitoring devices in switched networks environments. |
|
| |
| RFC 2614 | An API for Service Location |
| |
| Authors: | J. Kempf, E. Guttman. |
| Date: | June 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2614 |
|
The Service Location Protocol (SLP) provides a new way for clients to dynamically discovery network services. With SLP, it is simple to offer highly available services that require no user configuration or assistance from network administrators prior to use. This document describes standardized APIs for SLP in C and Java. The APIs are modular and are designed to allow implementations to offer just the feature set needed. In addition, standardized file formats for configuration and serialized registrations are defined, allowing SLP agents to set network and other parameters in a portable way. The serialized file format allows legacy services to be registered withSLP directory agents in cases where modifying the legacy service program code is difficult or impossible, and to portably exchange a registration database. |
|
| |
| RFC 2615 | PPP over SONET/SDH |
| |
|
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.This document describes the use of PPP over Synchronous OpticalNetwork (SONET) and Synchronous Digital Hierarchy (SDH) circuits.
This document replaces and obsoletes RFC 1619. See section 7 for a summary of the changes from RFC 1619. |
|
| |
| RFC 2616 | Hypertext Transfer Protocol -- HTTP/1.1 |
| |
| Authors: | R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. |
| Date: | June 1999 |
| Formats: | txt ps html pdf json |
| Obsoletes: | RFC 2068 |
| Obsoleted by: | RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235 |
| Updated by: | RFC 2817, RFC 5785, RFC 6266, RFC 6585 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 2616 |
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.
HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068 [33]. |
|
| |
| RFC 2617 | HTTP Authentication: Basic and Digest Access Authentication |
| |
|
|
"HTTP/1.0", includes the specification for a Basic AccessAuthentication scheme. This scheme is not considered to be a secure method of user authentication (unless used in conjunction with some external secure system such as SSL [5]), as the user name and password are passed over the network as cleartext.
This document also provides the specification for HTTP's authentication framework, the original Basic authentication scheme and a scheme based on cryptographic hashes, referred to as "DigestAccess Authentication". It is therefore also intended to serve as a replacement for RFC 2069 [6]. Some optional elements specified byRFC 2069 have been removed from this specification due to problems found since its publication; other new elements have been added for compatibility, those new elements have been made optional, but are strongly recommended.
Like Basic, Digest access authentication verifies that both parties to a communication know a shared secret (a password); unlike Basic, this verification can be done without sending the password in the clear, which is Basic's biggest weakness. As with most other authentication protocols, the greatest sources of risks are usually found not in the core protocol itself but in policies and procedures surrounding its use. |
|
| |
| RFC 2618 | RADIUS Authentication Client MIB |
| |
|
|
This memo defines a set of extensions which instrument RADIUS authentication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS authentication clients. |
|
| |
| RFC 2619 | RADIUS Authentication Server MIB |
| |
|
|
This memo defines a set of extensions which instrument RADIUS authentication server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS authentication servers. |
|
| |
| RFC 2620 | RADIUS Accounting Client MIB |
| |
|
|
This memo defines a set of extensions which instrument RADIUS accounting client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS accounting clients. |
|
| |
| RFC 2621 | RADIUS Accounting Server MIB |
| |
|
|
This memo defines a set of extensions which instrument RADIUS accounting server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS accounting servers. |
|
| |
| RFC 2622 | Routing Policy Specification Language (RPSL) |
| |
| Authors: | C. Alaettinoglu, C. Villamizar, E. Gerich, D. Kessens, D. Meyer, T. Bates, D. Karrenberg, M. Terpstra. |
| Date: | June 1999 |
| Formats: | txt html json |
| Obsoletes: | RFC 2280 |
| Updated by: | RFC 4012, RFC 7909 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2622 |
|
RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at theAutonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. |
|
| |
| RFC 2623 | NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5 |
| |
| Authors: | M. Eisler. |
| Date: | June 1999 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2623 |
|
This memorandum clarifies various security issues involving the NFS protocol (Version 2 and Version 3 only) and then describes how theVersion 2 and Version 3 of the NFS protocol use the RPCSEC_GSS security flavor protocol and Kerberos V5. This memorandum is provided so that people can write compatible implementations. |
|
| |
| RFC 2624 | NFS Version 4 Design Considerations |
| |
| Authors: | S. Shepler. |
| Date: | June 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2624 |
|
The main task of the NFS version 4 working group is to create a protocol definition for a distributed file system that focuses on the following items: improved access and good performance on theInternet, strong security with negotiation built into the protocol, better cross-platform interoperability, and designed for protocol extensions. NFS version 4 will owe its general design to the previous versions of NFS. It is expected, however, that many features will be quite different in NFS version 4 than previous versions to facilitate the goals of the working group and to address areas that NFS version 2 and 3 have not.
This design considerations document is meant to present more detail than the working group charter. Specifically, it presents the areas that the working group will investigate and consider while developing a protocol specification for NFS version 4. Based on this investigation the working group will decide the features of the new protocol based on the cost and benefits within the specific feature areas. |
|
| |
| RFC 2625 | IP and ARP over Fibre Channel |
| |
| Authors: | M. Rajagopal, R. Bhagwat, W. Rickard. |
| Date: | June 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4338 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2625 |
|
Fibre Channel (FC) is a high speed serial interface technology that supports several higher layer protocols including Small ComputerSystem Interface (SCSI) and Internet Protocol(IP). Until now, SCSI has been the only widely used protocol over FC. Existing FC standards[3] do not adequately specify how IP packets may be transported overFC and how IP addresses are resolved to FC addresses. The purpose of this document is to specify a way of encapsulating IP and AddressResolution Protocol(ARP) over Fibre Channel and also to describe a mechanism(s) for IP address resolution. |
|
| |
| RFC 2626 | The Internet and the Millennium Problem (Year 2000) |
| |
| Authors: | P. Nesser II. |
| Date: | June 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2626 |
|
The Year 2000 Working Group (WG) has conducted an investigation into the millennium problem as it regards Internet related protocols.This investigation only targeted the protocols as documented in theRequest For Comments Series (RFCs). This investigation discovered little reason for concern with regards to the functionality of the protocols. A few minor cases of older implementations still using two digit years (ala RFC 850) were discovered, but almost allInternet protocols were given a clean bill of health. Several cases of "period" problems were discovered, where a time field would "roll over" as the size of field was reached. In particular, there are several protocols, which have 32 bit, signed integer representations of the number of seconds since January 1, 1970 which will turn negative at Tue Jan 19 03:14:07 GMT 2038. Areas whose protocols will be effected by such problems have been notified so that new revisions will remove this limitation. |
|
| |
| RFC 2627 | Key Management for Multicast: Issues and Architectures |
| |
| Authors: | D. Wallner, E. Harder, R. Agee. |
| Date: | June 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2627 |
|
This report contains a discussion of the difficult problem of key management for multicast communication sessions. It focuses on two main areas of concern with respect to key management, which are, initializing the multicast group with a common net key and rekeying the multicast group. A rekey may be necessary upon the compromise of a user or for other reasons (e.g., periodic rekey). In particular, this report identifies a technique which allows for secure compromise recovery, while also being robust against collusion of excluded users. This is one important feature of multicast key management which has not been addressed in detail by most other multicast key management proposals [1,2,4]. The benefits of this proposed technique are that it minimizes the number of transmissions required to rekey the multicast group and it imposes minimal storage requirements on the multicast group. |
|
| |
| RFC 2628 | Simple Cryptographic Program Interface (Crypto API) |
| |
| Authors: | V. Smyslov. |
| Date: | June 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2628 |
|
This document describes a simple Application Program Interface to cryptographic functions. The main purpose of such an interface is to separate cryptographic libraries from internet applications, thus allowing an independent development of both. It can be used in various internet applications such as [IPsec], [ISAKMP], [IKE],[TLS]. |
|
| |
| RFC 2629 | Writing I-Ds and RFCs using XML |
| |
|
|
This memo presents a technique for using XML (Extensible MarkupLanguage) as a source format for documents in the Internet-Drafts(I-Ds) and Request for Comments (RFC) series. |
|
| |
| RFC 2630 | Cryptographic Message Syntax |
| |
|
|
This document describes the Cryptographic Message Syntax. This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary messages.
The Cryptographic Message Syntax is derived from PKCS #7 version 1.5 as specified in RFC 2315 [PKCS#7]. Wherever possible, backward compatibility is preserved; however, changes were necessary to accommodate attribute certificate transfer and key agreement techniques for key management. |
|
| |
| RFC 2631 | Diffie-Hellman Key Agreement Method |
| |
| Authors: | E. Rescorla. |
| Date: | June 1999 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2631 |
|
This document standardizes one particular Diffie-Hellman variant, based on the ANSI X9.42 draft, developed by the ANSI X9F1 working group. Diffie-Hellman is a key agreement algorithm used by two parties to agree on a shared secret. An algorithm for converting the shared secret into an arbitrary amount of keying material is provided. The resulting keying material is used as a symmetric encryption key. The Diffie-Hellman variant described requires the recipient to have a certificate, but the originator may have a static key pair (with the public key placed in a certificate) or an ephemeral key pair. |
|
| |
| RFC 2632 | S/MIME Version 3 Certificate Handling |
| |
|
|
S/MIME (Secure/Multipurpose Internet Mail Extensions), provides a method to send and receive secure MIME messages. Before using a public key to provide security services, the S/MIME agent MUST certify that the public key is valid. S/MIME agents MUST use PKIX certificates to validate public keys as described in the Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL Profile. [STANDARDS-TRACK] |
|
| |
| RFC 2633 | S/MIME Version 3 Message Specification |
| |
|
|
This document describes a protocol for adding cryptographic signature and encryption services to MIME data. [STANDARDS-TRACK] |
|
| |
| RFC 2634 | Enhanced Security Services for S/MIME |
| |
|
|
This document describes four optional security service extensions for S/MIME. [STANDARDS-TRACK] |
|
| |
| RFC 2635 | DON'T SPEW A Set of Guidelines for Mass Unsolicited Mailings and Postings (spam*) |
| |
|
|
This document explains why mass unsolicited electronic mail messages are harmful in the Internetworking community. It gives a set of guidelines for dealing with unsolicited mail for users, for system administrators, news administrators, and mailing list managers. It also makes suggestions Internet Service Providers might follow. |
|
| |
| RFC 2636 | Wireless Device Configuration (OTASP/OTAPA) via ACAP |
| |
|
|
Wireless carriers today are faced with creating more efficient distribution channels, increasing customer satisfaction, while also improving margin and profitability. Industry trends are pushing the sale of handsets further into the retail channel. The cost and effort of provisioning handsets, activating users, and updating handset parameters can be greatly reduced by using over-the-air activation mechanisms. A comprehensive and extensible means for over-the-air provisioning and handset parameter updating is required.
One approach is to purchase EIA/TIA/IS-683A (Over-the-air ServiceProvisioning of Mobile Stations in Spread Spectrum Systems) equipment. The cost of this has led carriers to seek alternative solutions. A very viable means for providing over-the-air (OTA) provisioning is to leverage the rollout of IS-707 data services equipment, which most carriers are in the process of deploying. This paper presents an approach to OTA provisioning that utilizes the deployment of IS-707 to deliver OTA provisioning and parameter upgrading.
IS-707 data services makes available several methods of providing over-the-air provisioning and parameter updating. A well thought-out approach utilizing Internet-based open standard mechanisms can provide an extensible platform for further carrier service offerings, enhanced interoperability among back-end services, and vendor independence.
This paper describes a viable and attractive means to provideOTASP/OTAPA via IS-707, using the ACAP [ACAP] protocol. |
|
| |
| RFC 2637 | Point-to-Point Tunneling Protocol (PPTP) |
| |
| Authors: | K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, G. Zorn. |
| Date: | July 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2637 |
|
This document specifies a protocol which allows the Point to PointProtocol (PPP) to be tunneled through an IP network. PPTP does not specify any changes to the PPP protocol but rather describes a new vehicle for carrying PPP. A client-server architecture is defined in order to decouple functions which exist in current Network AccessServers (NAS) and support Virtual Private Networks (VPNs). The PPTPNetwork Server (PNS) is envisioned to run on a general purpose operating system while the client, referred to as a PPTP AccessConcentrator (PAC) operates on a dial access platform. PPTP specifies a call-control and management protocol which allows the server to control access for dial-in circuit switched calls originating from a PSTN or ISDN or to initiate outbound circuit- switched connections. PPTP uses an enhanced GRE (Generic RoutingEncapsulation) mechanism to provide a flow- and congestion-controlled encapsulated datagram service for carrying PPP packets. |
|
| |
| RFC 2638 | A Two-bit Differentiated Services Architecture for the Internet |
| |
| Authors: | K. Nichols, V. Jacobson, L. Zhang. |
| Date: | July 1999 |
| Formats: | txt ps json html pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2638 |
|
This document was originally submitted as an internet draft inNovember of 1997. As one of the documents predating the formation of the IETF's Differentiated Services Working Group, many of the ideas presented here, in concert with Dave Clark's subsequent presentation to the December 1997 meeting of the IETF Integrated Services WorkingGroup, were key to the work which led to RFCs 2474 and 2475 and the section on allocation remains a timely proposal. For this reason, and to provide a reference, it is being submitted in its original form.The forwarding path portion of this document is intended as a record of where we were at in late 1997 and not as an indication of future direction.
The postscript version of this document includes Clark's slides as an appendix. The postscript version of this document also includes many figures that aid greatly in its readability. |
|
| |
| RFC 2639 | Internet Printing Protocol/1.0: Implementer's Guide |
| |
|
|
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document contains information that supplements the IPP Model and Semantics [RFC2566] and the IPP Transport and Encoding [RFC2565] documents. It is intended to help implementers understand IPP/1.0 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]Rationale for the Structure and Model and Protocol for the InternetPrinting Protocol [RFC2568]Internet Printing Protocol/1.0: Model and Semantics [RFC2566]Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]Mapping between LPD and IPP Protocols [RFC2569]
The document, "Design Goals for an Internet Printing Protocol", takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The design goals document calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0.
The document, "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for theIETF working group's major decisions.
The document, "Internet Printing Protocol/1.0: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer and a Job. TheJob supports multiple documents per Job. The model document also addresses how security, internationalization, and directory issues are addressed.
The document, "Internet Printing Protocol/1.0: Encoding andTransport", is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It also defines the encoding rules for a new Internet media type called"application/ipp".
The document, "Mapping between LPD and IPP Protocols", gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon) implementations. |
|
| |
| RFC 2640 | Internationalization of the File Transfer Protocol |
| |
|
|
The File Transfer Protocol, as defined in RFC 959 [RFC959] and RFC1123 Section 4 [RFC1123], is one of the oldest and widely used protocols on the Internet. The protocol's primary character set, 7 bit ASCII, has served the protocol well through the early growth years of the Internet. However, as the Internet becomes more global, there is a need to support character sets beyond 7 bit ASCII.
This document addresses the internationalization (I18n) of FTP, which includes supporting the multiple character sets and languages found throughout the Internet community. This is achieved by extending theFTP specification and giving recommendations for proper internationalization support. |
|
| |
| RFC 2641 | Cabletron's VlanHello Protocol Specification Version 4 |
| |
| Authors: | D. Hamilton, D. Ruffen. |
| Date: | August 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2641 |
|
The VlanHello protocol is part of the InterSwitch Message Protocol(ISMP) which provides interswitch communication between switches running Cabletron's SecureFast VLAN (SFVLAN) product. Switches use the VlanHello protocol to discover their neighboring switches and establish the topology of the switch fabric. |
|
| |
| RFC 2642 | Cabletron's VLS Protocol Specification |
| |
| Authors: | L. Kane. |
| Date: | August 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2642 |
|
The Virtual LAN Link State Protocol (VLSP) is part of the InterSwitchMessage Protocol (ISMP) which provides interswitch communication between switches running Cabletron's SecureFast VLAN (SFVLAN) product. VLSP is used to determine and maintain a fully connected mesh topology graph of the switch fabric. Each switch maintains an identical database describing the topology. Call-originating switches use the topology database to determine the path over which to route a call connection.
VLSP provides support for equal-cost multipath routing, and recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. |
|
| |
| RFC 2643 | Cabletron's SecureFast VLAN Operational Model |
| |
| Authors: | D. Ruffen, T. Len, J. Yanacek. |
| Date: | August 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2643 |
|
Cabletron's SecureFast VLAN (SFVLAN) product implements a distributed connection-oriented switching protocol that provides fast forwarding of data packets at the MAC layer. The product uses the concept of virtual LANs (VLANs) to determine the validity of call connection requests and to scope the broadcast of certain flooded messages. |
|
| |
| RFC 2644 | Changing the Default for Directed Broadcasts in Routers |
| |
|
|
This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. This memo provides information for the Internet community. |
|
| |
| RFC 2645 | ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses |
| |
| Authors: | R. Gellens. |
| Date: | August 1999 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2645 |
|
This memo proposes a new service, On-Demand Mail Relay (ODMR), which is a profile of SMTP, providing for a secure, extensible, easy to implement approach to the problem. [STANDARDS-TRACK] |
|
| |
| RFC 2646 | The Text/Plain Format Parameter |
| |
|
|
This memo proposes a new parameter to be used with Text/Plain, and, in the presence of this parameter, the use of trailing whitespace to indicate flowed lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain. [STANDARDS-TRACK] |
|
| |
| RFC 2647 | Benchmarking Terminology for Firewall Performance |
| |
| Authors: | D. Newman. |
| Date: | August 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2647 |
|
This document defines terms used in measuring the performance of firewalls. It extends the terminology already used for benchmarking routers and switches with definitions specific to firewalls. [STANDARDS-TRACK] |
|
| |
| RFC 2648 | A URN Namespace for IETF Documents |
| |
|
|
A system for Uniform Resource Names (URNs) must be capable of supporting new naming systems. As an example of proposing a new namespace, this document proposes the "ietf" namespace. This namespace consists of the RFC family of documents (RFCs, STDs, FYIs, and BCPs) developed by the IETF and published by the RFC Editor, the minutes of working groups (WG) and birds of a feather (BOF) meetings that occur during IETF conferences, and the Internet Drafts published by the Internet Drafts Editor. Both the current URN framework andURN syntax support this namespace. |
|
| |
| RFC 2649 | An LDAP Control and Schema for Holding Operation Signatures |
| |
| Authors: | B. Greenblatt, P. Richard. |
| Date: | August 1999 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2649 |
|
In many environments clients require the ability to validiate the source and integrity of information provided by the directory. This document describes an LDAP message control which allows for the retrieval of digitally signed information. This document defines anLDAP v3 based mechanism for signing directory operations in order to create a secure journal of changes that have been made to each directory entry. Both client and server based signatures are supported. An object class for subsequent retrieval are "journal entries" is also defined. This document specifies LDAP v3 controls that enable this functionality. It also defines an LDAP v3 schema that allows for subsequent browsing of the journal information. |
|
| |
| RFC 2650 | Using RPSL in Practice |
| |
| Authors: | D. Meyer, J. Schmitz, C. Orange, M. Prior, C. Alaettinoglu. |
| Date: | August 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2650 |
|
This document is a tutorial on using the Routing Policy SpecificationLanguage (RPSL) to describe routing policies in the Internet RoutingRegistry (IRR). We explain how to specify various routing policies and configurations using RPSL, how to register these policies in theIRR, and how to analyze them using the routing policy analysis tools, for example to generate vendor specific router configurations. |
|
| |
| RFC 2651 | The Architecture of the Common Indexing Protocol (CIP) |
| |
| Authors: | J. Allen, M. Mealling. |
| Date: | August 1999 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2651 |
|
The Common Indexing Protocol (CIP) is used to pass indexing information from server to server in order to facilitate query routing. Query routing is the process of redirecting and replicating queries through a distributed database system towards servers holding the desired results. This document describes the CIP framework, including its architecture and the protocol specifics of exchanging indices. |
|
| |
| RFC 2652 | MIME Object Definitions for the Common Indexing Protocol (CIP) |
| |
| Authors: | J. Allen, M. Mealling. |
| Date: | August 1999 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2652 |
|
The Common Indexing Protocol (CIP) is used to pass indexing information from server to server in order to facilitate query routing. The protocol is comprised of several MIME objects being passed from server to server. This document describes the definitions of those objects as well as the methods and requirements needed to define a new index type. |
|
| |
| RFC 2653 | CIP Transport Protocols |
| |
| Authors: | J. Allen, P. Leach, R. Hedberg. |
| Date: | August 1999 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2653 |
|
This document specifies three protocols for transporting CIP requests, responses and index objects, utilizing TCP, mail, and HTTP.The objects themselves are defined in [CIP-MIME] and the overall CIP architecture is defined in [CIP-ARCH]. |
|
| |
| RFC 2654 | A Tagged Index Object for use in the Common Indexing Protocol |
| |
| Authors: | R. Hedberg, B. Greenblatt, R. Moats, M. Wahl. |
| Date: | August 1999 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2654 |
|
This document defines a mechanism by which information servers can exchange indices of information from their databases by making use of the Common Indexing Protocol (CIP). This document defines the structure of the index information being exchanged, as well as the appropriate meanings for the headers that are defined in the CommonIndexing Protocol. It is assumed that the structures defined here can be used by X.500 DSAs, LDAP servers, Whois++ servers, CSO Ph servers and many others. |
|
| |
| RFC 2655 | CIP Index Object Format for SOIF Objects |
| |
| Authors: | T. Hardie, M. Bowman, D. Hardy, M. Schwartz, D. Wessels. |
| Date: | August 1999 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2655 |
|
This document describes SOIF, the Summary Object Interchange Format, as an index object type in the context of the CIP framework. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2656 | Registration Procedures for SOIF Template Types |
| |
| Authors: | T. Hardie. |
| Date: | August 1999 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2656 |
|
The Summary Object Interchange Format [Ref. 1] was first defined by the Harvest Project [Ref 2.] in January 1994. SOIF was derived from a combination of the Internet Anonymous FTP Archives IETF WorkingGroup (IAFA) templates [Ref 3.] and the BibTeX bibliography format[Ref 4.]. The combination was originally noted for its advantages of providing a convenient and intuitive way for delimiting objects within a stream, and setting apart the URL for easy object access or invocation, while still preserving compatibility with IAFA templates.
SOIF uses named template types to indicate the attributes which may be contained within a particular summary object. Within the context of a single application, private agreement on the definition of template types has been adequate. As SOIF objects are moved among applications, however, the need for standard, well-specified, and easily identifiable template types increases. This need is particularly intense in the context of query referral, where knowledge of an attribute's definition and the allowed data types for specific values is crucial. For a discussion of this in the context of the Common Indexing Protocol, see [Ref. 1].
The registration procedure described in this document is specific toSOIF template types. There is ongoing work within the IETF to specify a more generic schema registration facility[Ref. 5]. It is not yet clear whether the results of that work will encompass the ability to register entities like SOIF template types. If it does so, the registration of SOIF template types may be shifted to that method and registry. Should that occur, appropriate pointers will be created in cooperation with the Registrar to ensure that no registrations are lost. |
|
| |
| RFC 2657 | LDAPv2 Client vs |
| |
| Authors: | the Index Mesh. R. Hedberg. |
| Date: | August 1999 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2657 |
|
LDAPv2 clients as implemented according to RFC 1777 [1] have no notion on referral. The integration between such a client and anIndex Mesh, as defined by the Common Indexing Protocol [2], heavily depends on referrals and therefore needs to be handled in a special way. This document defines one possible way of doing this. |
|
| |
| RFC 2658 | RTP Payload Format for PureVoice(tm) Audio |
| |
| Authors: | K. McKay. |
| Date: | August 1999 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2658 |
|
This document describes the RTP payload format for PureVoice(tm) Audio. [STANDARDS-TRACK] |
|
| |
| RFC 2659 | Security Extensions For HTML |
| |
| Authors: | E. Rescorla, A. Schiffman. |
| Date: | August 1999 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2659 |
|
This memo describes a syntax for embedding S-HTTP negotiation parameters in HTML documents. S-HTTP, as described by RFC 2660, contains the concept of negotiation headers which reflect the potential receiver of a message's preferences as to which crypto- graphic enhancements should be applied to the message. This document describes a syntax for binding these negotiation parameters to HTML anchors.
1. Introduction
2. Anchor Attributes
We define the following new anchor (and form submission) attributes:
DN -- The distinguished name of the principal for whom the request should be encrypted when dereferencing the anchor's url.This need not be specified, but failure to do so runs the risk that the client will be unable to determine the DN and therefore will be unable to encrypt. This should be specified in the form of RFC1485, using SGML quoting conventions as needed.
NONCE -- A free-format string (appropriately SGML quoted) which is to be included in a SHTTP-Nonce: header (after SGML quoting is removed) when the anchor is dereferenced.
CRYPTOPTS -- Cryptographic option information as described in
[SHTTP]. Specifically, the <cryptopt-list&rt; production. |
|
| |
| RFC 2660 | The Secure HyperText Transfer Protocol |
| |
| Authors: | E. Rescorla, A. Schiffman. |
| Date: | August 1999 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 2660 |
|
This memo describes a syntax for securing messages sent using theHypertext Transfer Protocol (HTTP), which forms the basis for theWorld Wide Web. Secure HTTP (S-HTTP) provides independently applicable security services for transaction confidentiality, authenticity/integrity and non-repudiability of origin.
The protocol emphasizes maximum flexibility in choice of key management mechanisms, security policies and cryptographic algorithms by supporting option negotiation between parties for each transaction. |
|
| |
| RFC 2661 | Layer Two Tunneling Protocol "L2TP" |
| |
| Authors: | W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter. |
| Date: | August 1999 |
| Formats: | txt html json |
| Updated by: | RFC 9601 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2661 |
|
This document describes the Layer Two Tunneling Protocol (L2TP). STD51, RFC 1661 specifies multi-protocol access via PPP [RFC1661]. L2TP facilitates the tunneling of PPP packets across an intervening network in a way that is as transparent as possible to both end-users and applications. |
|
| |
| RFC 2662 | Definitions of Managed Objects for the ADSL Lines |
| |
| Authors: | G. Bathrick, F. Ly. |
| Date: | August 1999 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2662 |
|
This document defines a standard SNMP MIB for ADSL lines based on the ADSL Forum standard data model. [STANDARDS-TRACK] |
|
| |
| RFC 2663 | IP Network Address Translator (NAT) Terminology and Considerations |
| |
| Authors: | P. Srisuresh, M. Holdrege. |
| Date: | August 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2663 |
|
Network Address Translation is a method by which IP addresses are mapped from one realm to another, in an attempt to provide transparent routing to hosts. Traditionally, NAT devices are used to connect an isolated address realm with private unregistered addresses to an external realm with globally unique registered addresses. This document attempts to describe the operation of NAT devices and the associated considerations in general, and to define the terminology used to identify various flavors of NAT. |
|
| |
| RFC 2664 | FYI on Questions and Answers - Answers to Commonly Asked "New Internet User" Questions |
| |
|
|
This memo provides an overview to the new Internet User. The intended audience is the common Internet user of today, thus it attempts to provide a more consumer oriented approach to the Internet rather than going into any depth about a topic. Unlike its predecessors, this edition seeks to answer the general questions that an unsophisticated consumer would ask as opposed to the more pointed questions of a more technically sophisticated Internet user. Those desiring a more in-depth discussion are directed to FYI 7 that deals with intermediate and advanced Q/A topics. A conscious effort has been made to keep this memo brief but at the same time provide the new user with enough information to generally understand theInternet. |
|
| |
| RFC 2665 | Definitions of Managed Objects for the Ethernet-like Interface Types |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This memo obsoletes RFC 2358, "Definitions of Managed Objects for theEthernet-like Interface Types". This memo extends that specification by including management information useful for the management of 1000Mb/s and full-duplex Ethernet interfaces.
Ethernet technology, as defined by the 802.3 Working Group of theIEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflects a certain stage in the evolution ofEthernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and HubMIB Working Group, in order to reflect the evolution of Ethernet technology. |
|
| |
| RFC 2666 | Definitions of Object Identifiers for Identifying Ethernet Chip Sets |
| |
| Authors: | J. Flick. |
| Date: | August 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2666 |
|
This memo defines OBJECT IDENTIFIER values for use with network management protocols in the Internet community. In particular, it contains registered OID values for use with the dot3StatsEtherChipSet object in the EtherLike-MIB [16]. These registrations have been split from [16] into a separate document for maintenance purposes. |
|
| |
| RFC 2667 | IP Tunnel MIB |
| |
|
|
This memo defines a Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 networks. [STANDARDS-TRACK] |
|
| |
| RFC 2668 | Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) |
| |
| Authors: | A. Smith, J. Flick, K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie, S. Roberts. |
| Date: | August 1999 |
| Formats: | txt html json |
| Obsoletes: | RFC 2239 |
| Obsoleted by: | RFC 3636 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2668 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This memo obsoletes RFC 2239, "Definitions of Managed Objects forIEEE 802.3 Medium Attachment Units (MAUs) using SMIv2". This memo extends that specification by including management information useful for the management of 1000 Mb/s MAUs.
Ethernet technology, as defined by the 802.3 Working Group of theIEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflects a certain stage in the evolution ofEthernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and HubMIB Working Group, in order to reflect the evolution of Ethernet technology. |
|
| |
| RFC 2669 | DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a basic set of managed objects for SNMP- based management of DOCSIS 1.0 compliant Cable Modems and Cable ModemTermination Systems.
This memo specifies a MIB module in a manner that is compliant to theSNMP SMIv2 [5][6][7]. The set of objects is consistent with the SNMP framework and existing SNMP standards.
This memo is a product of the IPCDN working group within the InternetEngineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@terayon.com and/or the author. |
|
| |
| RFC 2670 | Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a basic set of managed objects for SNMP- based management of MCNS/DOCSIS compliant Radio Frequency (RF) interfaces.
This memo specifies a MIB module in a manner that is compliant to theSNMP SMIv2 [5][6][7]. The set of objects are consistent with theSNMP framework and existing SNMP standards.
This memo is a product of the IPCDN working group within the InternetEngineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@terayon.com and/or the author. |
|
| |
| RFC 2671 | Extension Mechanisms for DNS (EDNS0) |
| |
|
|
The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow clients to advertise their capabilities to servers. This document describes backward compatible mechanisms for allowing the protocol to grow. |
|
| |
| RFC 2672 | Non-Terminal DNS Name Redirection |
| |
|
|
This document defines a new DNS Resource Record called "DNAME", which provides the capability to map an entire subtree of the DNS name space to another domain. [STANDARDS-TRACK] |
|
| |
| RFC 2673 | Binary Labels in the Domain Name System |
| |
|
|
This document defines a "Bit-String Label" which may appear within domain names. This new label type compactly represents a sequence of "One-Bit Labels" and enables resource records to be stored at any bit- boundary in a binary-named section of the domain name tree. [STANDARDS-TRACK] |
|
| |
| RFC 2674 | Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions |
| |
| Authors: | E. Bell, A. Smith, P. Langille, A. Rijhsinghani, K. McCloghrie. |
| Date: | August 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4363 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2674 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets.In particular, it defines two MIB modules for managing the new capabilities of MAC bridges defined by the IEEE 802.1D-1998 MACBridges and the IEEE 802.1Q-1998 Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. One MIB module defines objects for managing the 'Traffic Classes' and 'EnhancedMulticast Filtering' components of IEEE 802.1D-1998. The other MIB module defines objects for managing IEEE 802.1Q VLANs.
Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. This memo also includes severalMIB modules in a manner that is compliant to the SMIv2 [V2SMI].
This memo supplements RFC 1493 [BRIDGEMIB] and (to a lesser extent)RFC 1525 [SBRIDGEMIB]. |
|
| |
| RFC 2675 | IPv6 Jumbograms |
| |
| Authors: | D. Borman, S. Deering, R. Hinden. |
| Date: | August 1999 |
| Formats: | txt html json |
| Obsoletes: | RFC 2147 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2675 |
|
A "jumbogram" is an IPv6 packet containing a payload longer than65,535 octets. This document describes the IPv6 Jumbo Payload option, which provides the means of specifying such large payload lengths. It also describes the changes needed to TCP and UDP to make use of jumbograms.
Jumbograms are relevant only to IPv6 nodes that may be attached to links with a link MTU greater than 65,575 octets, and need not be implemented or understood by IPv6 nodes that do not support attachment to links with such large MTUs. |
|
| |
| RFC 2676 | QoS Routing Mechanisms and OSPF Extensions |
| |
| Authors: | G. Apostolopoulos, S. Kamat, D. Williams, R. Guerin, A. Orda, T. Przygienda. |
| Date: | August 1999 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2676 |
|
This memo describes extensions to the OSPF [Moy98] protocol to support QoS routes. The focus of this document is on the algorithms used to compute QoS routes and on the necessary modifications to OSPF to support this function, e.g., the information needed, its format, how it is distributed, and how it is used by the QoS path selection process. Aspects related to how QoS routes are established and managed are also briefly discussed. The goal of this document is to identify a framework and possible approaches to allow deployment ofQoS routing capabilities with the minimum possible impact to the existing routing infrastructure.
In addition, experience from an implementation of the proposed extensions in the GateD environment [Con], along with performance measurements is presented. |
|
| |
| RFC 2677 | Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP) |
| |
| Authors: | M. Greene, J. Cucchiara, J. Luciani. |
| Date: | August 1999 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2677 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for the Next HopResolution Protocol (NHRP) as defined in RFC 2332. |
|
| |
| RFC 2678 | IPPM Metrics for Measuring Connectivity |
| |
| Authors: | J. Mahdavi, V. Paxson. |
| Date: | September 1999 |
| Formats: | txt html json |
| Obsoletes: | RFC 2498 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2678 |
|
This memo defines a series of metrics for connectivity between a pair of Internet hosts. [STANDARDS-TRACK] |
|
| |
| RFC 2679 | A One-way Delay Metric for IPPM |
| |
| Authors: | G. Almes, S. Kalidindi, M. Zekauskas. |
| Date: | September 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7679 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2679 |
|
This memo defines a metric for one-way delay of packets across Internet paths. [STANDARDS-TRACK] |
|
| |
| RFC 2680 | A One-way Packet Loss Metric for IPPM |
| |
| Authors: | G. Almes, S. Kalidindi, M. Zekauskas. |
| Date: | September 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7680 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2680 |
|
This memo defines a metric for one-way packet loss across Internet paths. [STANDARDS-TRACK] |
|
| |
| RFC 2681 | A Round-trip Delay Metric for IPPM |
| |
| Authors: | G. Almes, S. Kalidindi, M. Zekauskas. |
| Date: | September 1999 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2681 |
|
This memo defines a metric for round-trip delay of packets across Internet paths. [STANDARDS-TRACK] |
|
| |
| RFC 2682 | Performance Issues in VC-Merge Capable ATM LSRs |
| |
| Authors: | I. Widjaja, A. Elwalid. |
| Date: | September 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2682 |
|
VC merging allows many routes to be mapped to the same VC label, thereby providing a scalable mapping method that can support thousands of edge routers. VC merging requires reassembly buffers so that cells belonging to different packets intended for the same destination do not interleave with each other. This document investigates the impact of VC merging on the additional buffer required for the reassembly buffers and other buffers. The main result indicates that VC merging incurs a minimal overhead compared to non-VC merging in terms of additional buffering. Moreover, the overhead decreases as utilization increases, or as the traffic becomes more bursty. |
|
| |
| RFC 2683 | IMAP4 Implementation Recommendations |
| |
|
|
The IMAP4 specification describes a rich protocol for use in building clients and servers for storage, retrieval, and manipulation of electronic mail. Because the protocol is so rich and has so many implementation choices, there are often trade-offs that must be made and issues that must be considered when designing such clients and servers. This document attempts to outline these issues and to make recommendations in order to make the end products as interoperable as possible. This memo provides information for the Internet community. |
|
| |
| RFC 2684 | Multiprotocol Encapsulation over ATM Adaptation Layer 5 |
| |
| Authors: | D. Grossman, J. Heinanen. |
| Date: | September 1999 |
| Formats: | txt html json |
| Obsoletes: | RFC 1483 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2684 |
|
This memo replaces RFC 1483. It describes two encapsulations methods for carrying network interconnect traffic over AAL type 5 over ATM.The first method allows multiplexing of multiple protocols over a single ATM virtual connection whereas the second method assumes that each protocol is carried over a separate ATM virtual connection. |
|
| |
| RFC 2685 | Virtual Private Networks Identifier |
| |
| Authors: | B. Fox, B. Gleeson. |
| Date: | September 1999 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2685 |
|
Virtual Private IP networks may span multiple Autonomous Systems orService Providers. There is a requirement for the use of a globally unique VPN identifier in order to be able to refer to a particularVPN (see section 6.1.1 of [1]). This document proposes a format for a globally unique VPN identifier. |
|
| |
| RFC 2686 | The Multi-Class Extension to Multi-Link PPP |
| |
| Authors: | C. Bormann. |
| Date: | September 1999 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2686 |
|
A companion document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDNB-channels, and sub-T1 links [1]. The main components of the architecture are: a real-time encapsulation format for asynchronous and synchronous low-bitrate links, a header compression architecture optimized for real-time flows, elements of negotiation protocols used between routers (or between hosts and routers), and announcement protocols used by applications to allow this negotiation to take place.
This document proposes the fragment-oriented solution for the real- time encapsulation format part of the architecture. The general approach is to start from the PPP Multilink fragmentation protocol[2] and provide a small number of extensions to add functionality and reduce the overhead. |
|
| |
| RFC 2687 | PPP in a Real-time Oriented HDLC-like Framing |
| |
| Authors: | C. Bormann. |
| Date: | September 1999 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2687 |
|
A companion document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDNB-channels, and sub-T1 links [1]. The main components of the architecture are: a real-time encapsulation format for asynchronous and synchronous low-bitrate links, a header compression architecture optimized for real-time flows, elements of negotiation protocols used between routers (or between hosts and routers), and announcement protocols used by applications to allow this negotiation to take place.
This document proposes the suspend/resume-oriented solution for the real-time encapsulation format part of the architecture. The general approach is to start from the PPP Multilink fragmentation protocol[2] and its multi-class extension [5] and add suspend/resume in a way that is as compatible to existing hard- and firmware as possible. |
|
| |
| RFC 2688 | Integrated Services Mappings for Low Speed Networks |
| |
| Authors: | S. Jackowski, D. Putzolu, E. Crawley, B. Davie. |
| Date: | September 1999 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2688 |
|
A set of companion documents describe an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDNB-channels, and sub-T1 links [1, 2, 3, 4]. The main components of the architecture are: a set of real-time encapsulation formats for asynchronous and synchronous low-bitrate links, a header compression architecture optimized for real-time flows, elements of negotiation protocols used between routers (or between hosts and routers), and announcement protocols used by applications to allow this negotiation to take place.
This document defines the service mappings of the IETF IntegratedServices for low-bitrate links, specifically the controlled load [5] and guaranteed [6] services. The approach takes the form of a set of guidelines and considerations for implementing these services, along with evaluation criteria for elements providing these services. |
|
| |
| RFC 2689 | Providing Integrated Services over Low-bitrate Links |
| |
| Authors: | C. Bormann. |
| Date: | September 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2689 |
|
This document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDN B- channels, and sub-T1 links. It covers only the lower parts of theInternet Multimedia Conferencing Architecture [1]; additional components required for application services such as InternetTelephony (e.g., a session initiation protocol) are outside the scope of this document. The main components of the architecture are: a real-time encapsulation format for asynchronous and synchronous low- bitrate links, a header compression architecture optimized for real- time flows, elements of negotiation protocols used between routers(or between hosts and routers), and announcement protocols used by applications to allow this negotiation to take place. |
|
| |
| RFC 2690 | A Proposal for an MOU-Based ICANN Protocol Support Organization |
| |
| Authors: | S. Bradner. |
| Date: | September 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2690 |
|
This is a copy of the proposal for an MOU-based Protocol Supporting Organization that was submitted to ICANN on April 23, 1999. This memo provides information for the Internet community. |
|
| |
| RFC 2691 | A Memorandum of Understanding for an ICANN Protocol Support Organization |
| |
| Authors: | S. Bradner. |
| Date: | September 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2691 |
|
This is the text of the Memorandum of Understanding (MoU) that was signed by ICANN, the IETF, the ITU-T, W3C and ETSI on July 14, 1999 in Oslo. This MoU creates the Protocol Support Organization (PSO) within the Internet Corporation for Assigned Names and Numbers(ICANN). This MoU was developed by representatives of the IETF, ITU,W3C, ETSI, and ICANN with the help of Jorge Contreras of Hale andDorr.
MEMORANDUM OF UNDERSTANDING
July 14, 1999
ICANN Protocol Supporting Organization
(1) Purpose and Scope
(a) The Protocol Support Organization (PSO) will be a consensus- based advisory body within the ICANN framework.
(b) The PSO will establish a "Protocol Council" and host an annual open meeting (the "General Assembly").
(c) The purpose of this Memorandum of Understanding (MOU) is to establish a set of principles that ICANN and the StandardsDevelopment Organizations who have signed below (the SigningSDOs) will use in forming and operating the PSO
(2) Composition and Action of Protocol Council
(a) Size. Each Signing SDO will appoint two (2) members to theProtocol Council, each such member to serve for a time period determined by such Signing SDO.
(b) Each Signing SDO shall be responsible for choosing its members of the Protocol Council in a manner of its own choosing, and in accordance with its own open procedures.Each Signing SDO may remove or replace one or both of its members on the Protocol Council in its discretion. EachSigning SDO must notify the Protocol Council Secretary andICANN when it changes its members and, in addition, must ratify its choices at least annually.
(c) Selection and Appointment. Concurrently with the posting of notice of the date of the annual meeting of the PSO GeneralAssembly on the PSO Web Site, ICANN and the Protocol Council shall make an open call for nominations to any potential vacancies on the Protocol Council. Any nominations received will be forwarded to the Signing SDOs eligible to appoint members (i.e., they do not already have two members on theProtocol Council) for their consideration.
(d) Action by Protocol Council. Unless otherwise specified in this MOU, all actions of the Protocol Council shall be taken by majority vote of the total number of members. Action may be taken at any meeting of the Protocol Council, which may be by telephone conference in which all participants can hear the others. Meetings of the Protocol Council may be called by request of any three members of the Protocol Council, with at least 45 days for physical meetings or fifteen (15) days for telephonic or other electronic meetings prior written notice to each of the other members. In order to conduct business at any meeting of the Protocol Council, at least a quorum of members must be present; a quorum shall be present when at least majority of the members of the Protocol Council are present, and when such members represent at least 3/4ths of the Signing SDOs.
(e) Web Site. The Protocol Council will arrange for the establishment and maintenance of a Web site devoted to PSO activities and news.
(f) Secretary. The Protocol Council will have a Secretary to coordinate administrative matters relating to the PSO andProtocol Council. The Secretary's term of office shall be one year. The position of Secretary will rotate among the
Signing SDOs, with the initial Secretary to be selected by the IETF, and subsequent Secretaries to be appointed by a randomly selected Signing SDO that has not appointed theSecretary in the current rotation.
(g) No Compensation. Neither the Secretary, nor any ProtocolCouncil member or designated ICANN Board member shall be entitled to any compensation or reimbursement of expenses from the PSO. The PSO shall not be required to obtain insurance coverage for, or to indemnify, the members of theProtocol Council or persons acting in any other capacity by or for the PSO.
(3) ICANN Directors
(a) The Protocol Council will appoint Directors to the ICANNBoard of Directors in accordance with the By-laws of ICANN, for such terms as are specified by such By-laws. ICANN will notify the Protocol Council of any vacancies on the ICANNBoard which may be filled by the Protocol Council.
(b) The Protocol Council will conduct an open call for nominations for any open PSO seats on the ICANN Board. EachSigning SDO is entitled to nominate candidates by procedures of its own choosing. Additionally, nominations from the public at large will be allowed under conditions to be defined by the Protocol Council. The Protocol Council will select the PSO nominees to the ICANN Board from among these nominees. ICANN Directors selected by the Protocol Council may, but need not, be members of the Protocol Council or anySDO.
(c) No more than 2 PSO-nominated Directors may be residents of the same Geographic Region (as defined in the ICANN By-laws).
(d) The ICANN Directors appointed by the Protocol Council will not represent the PSO on the ICANN Board, but will function as full Directors of ICANN.
(4) Duties of Protocol Council
(a) Advisory Role. The Protocol Council will advise the ICANNBoard on matters referred to the Protocol Council by theICANN Board relating to the assignment of parameters forInternet protocols.
(b) Policy Development
(i) In the tradition of the Internet, standards development policies and conflict resolution mechanisms should be created and utilized by those institutions most directly involved, without undue interference from centralized bodies.
(ii) The ICANN By-laws vest in the PSO the primary responsibility for developing and recommending substantive policies in the area of protocol parameter assignment.
(iii) The PSO is committed to the proposition that policies for parameter assignments for particular protocols are the responsibility of the individual Signing SDO that developed the protocol.
(iv) The Protocol Council, and, when requested, ICANN, will be available as needed by the Signing SDOs to develop policies and procedures for conflict resolution betweenSigning SDOs.
(v) Any such policies and procedures will be adopted only with the agreement of all SDOs.
(5) Annual Open Meeting
(a) The Protocol Council will periodically convene an open meeting ("General Assembly") for promoting discussion and receiving input regarding the work of the PSO.(b) A General Assembly will be held at least once per year, and will permit open participation by all interested individuals.(c) Each annual General Assembly will be hosted by a Signing SDO in conjunction with one of its major meetings, as determined by the Protocol Council (with an effort to hold no 2 consecutive General Assemblies in the same GeographicRegion.)(d) It is expected that the major organizations within theInternet protocol standards development community will provide the constituency of the General Assembly.
(6) Open Proceedings and Documents
(a) Communications between ICANN and the Protocol Council. All official communications between ICANN and the ProtocolCouncil will be made public on the PSO web site. In the event that ICANN requests that a communication be kept confidential, the Protocol Council will honor this request for a fixed period of time not to exceed one year, and then make the communication public.
(b) Protocol Council Proceedings. All meetings of the ProtocolCouncil and official discussions of Protocol Council business will be conducted or reported on a publicly-archived mailing list accessible through the PSO web site.
(c) Meeting Announcements. The schedule and agenda for the PSOGeneral Assembly will be posted on the PSO Web Site at least90 days in advance of the meeting date. Notice of ProtocolCouncil meetings will be posted on the PSO Web at least 45 days before each physical meeting or fifteen (15) days before any telephonic or other electronic meeting, or such shorter time period agreed upon by each of the Signing SDOs. The minutes from all PSO meetings will be publicly posted on thePSO web site within 30 days of the meeting.
(7) Review and Modification of MOU. ICANN and the Signing SDOs will periodically review the results and consequences of their cooperation under this MOU. When appropriate, the signatories will consider the need for improvements in the MOU and make suitable proposals for modifying and updating the arrangements and scope of the MOU. Any modification to the MOU must be approved by all signatories.
(8) Standards Development Organizations
(a) The initial signatories to this MOU shall include ICANN and the Signing SDOs who have signed below. Each Signing SDO must be an international, Internet-related standards development organization that establishes that it meets the criteria for SDOs set forth below.
(i) SDOs must be open, international, voluntary technical standard and technical specification development organizations which:
(A) Develop standards and/or specifications for use over the public Internet.
(B) Can demonstrate active membership in the IP-related standards and/or specification development process of more than 800 individuals, if individual memberships are used by the organization, or 80 companies, if corporate memberships are used by the organization.
(C) Has been in operation for 3 or more years at the time of their application.
(D) Can demonstrate that there is significant deployment of its standards on the Internet.
(E) The significant protocols controlled by the organization can be implemented without paying a licensing fee to the organization.
(ii) Open, international, voluntary standards organizations are defined as international organizations that plan, develop or establish voluntary standards. An organization shall be considered open and international if its standards and/or specifications development process is open to any person or organization of any nationality on equitable terms. An organization shall be considered voluntary if it makes no claim to compel use of its standards and specifications. Additionally, to be considered 'international', an organization's voting (or other "full") membership must include individuals or companies primarily located in at least three different Geographic Regions and at least two different countries within each of those GeographicRegions.
(b) New Signatories
(i) Any organization that believes it satisfies the SDO qualifications set forth above may apply in writing to the Protocol Council to become a party to this MOU.In order for an organization to become a party to thisMOU, all then-existing MOU signatories must agree that such organization qualifies as an SDO.
(ii) Rejected applicants can appeal to the ICANN Board, which may override such a rejection if the ICANN Board finds, by at least a two-thirds vote, that the organization meets the SDO criteria set forth above.
(iii) Any organization that is accepted as an SDO under thisMOU must execute a copy of this MOU, and agree to be bound by all of its terms and conditions, upon which it shall be considered a Signing SDO for all purposes under this MOU.
(9) General. This MOU does not constitute any of the parties as a partner, joint venture, agent, principal or franchisee of any other party. The waiver of any provision of this MOU on any occasion shall not constitute a waiver for purposes of any other occasion. No party may transfer or assign any interest, right or obligation arising under this MOU without the prior written consent of each other party to this MOU.
IN WITNESS WHEREOF, this Memorandum of Understanding is executed this 14 day of July 1999 by the undersigned, acting through their duly authorized representatives:
INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERSBy: (signature)Name: Michael W. RobertsTitle: Interim President / CEO
INTERNET ENGINEERING TASK FORCEBy: (signature)Name: Fredrick J. BakerTitle: Chair, IETF
INTERNATIONAL TELECOMMUNATIONS UNIONBy: (signature)Name: Houlin Zhao, on behalf of Secretary-General of ITUTitle: Director, TSB
WORLD WIDE WEB CONSORTIUMBy: (signature)Name: Henrik Frystyk NielsenTitle: HTTP Activity Lead
EUROPEAN TELECOMMUNICATIONS STANDARDS INSITITUTEBy: (signature)Name: Bridget CosgraveTitle: Deputy Director General |
|
| |
| RFC 2692 | SPKI Requirements |
| |
| Authors: | C. Ellison. |
| Date: | September 1999 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2692 |
|
The IETF Simple Public Key Infrastructure [SPKI] Working Group is tasked with producing a certificate structure and operating procedure to meet the needs of the Internet community for trust management in as easy, simple and extensible a way as possible.
The SPKI Working Group first established a list of things one might want to do with certificates (attached at the end of this document), and then summarized that list of desires into requirements. This document presents that summary of requirements. |
|
| |
| RFC 2693 | SPKI Certificate Theory |
| |
| Authors: | C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, T. Ylonen. |
| Date: | September 1999 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2693 |
|
The SPKI Working Group has developed a standard form for digital certificates whose main purpose is authorization rather than authentication. These structures bind either names or explicit authorizations to keys or other objects. The binding to a key can be directly to an explicit key, or indirectly through the hash of the key or a name for it. The name and authorization structures can be used separately or together. We use S-expressions as the standard format for these certificates and define a canonical form for thoseS-expressions. As part of this development, a mechanism for deriving authorization decisions from a mixture of certificate types was developed and is presented in this document.
This document gives the theory behind SPKI certificates and ACLs without going into technical detail about those structures or their uses. |
|
| |
| RFC 2694 | DNS extensions to Network Address Translators (DNS_ALG) |
| |
| Authors: | P. Srisuresh, G. Tsirtsis, P. Akkiraju, A. Heffernan. |
| Date: | September 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2694 |
|
Domain Name Service (DNS) provides name to address mapping within a routing class (ex: IP). Network Address Translators (NATs) attempt to provide transparent routing between hosts in disparate address realms of the same routing class. Typically, NATs exist at the border of a stub domain, hiding private addresses from external addresses. This document identifies the need for DNS extensions to NATs and outlines how a DNS Application Level Gateway (DNS_ALG) can meet the need.DNS_ALG modifies payload transparently to alter address mapping of hosts as DNS packets cross one address realm into another. The document also illustrates the operation of DNS_ALG with specific examples. |
|
| |
| RFC 2695 | Authentication Mechanisms for ONC RPC |
| |
| Authors: | A. Chiu. |
| Date: | September 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2695 |
|
This document describes two authentication mechanisms created by Sun Microsystems that are commonly used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocol. This memo provides information for the Internet community. |
|
| |
| RFC 2696 | LDAP Control Extension for Simple Paged Results Manipulation |
| |
| Authors: | C. Weider, A. Herron, A. Anantha, T. Howes. |
| Date: | September 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2696 |
|
This document describes an LDAPv3 control extension for simple paging of search results. This memo provides information for the Internet community. |
|
| |
| RFC 2697 | A Single Rate Three Color Marker |
| |
| Authors: | J. Heinanen, R. Guerin. |
| Date: | September 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2697 |
|
This document defines a Single Rate Three Color Marker (srTCM), which can be used as component in a Diffserv traffic conditioner [RFC2475,RFC2474]. The srTCM meters a traffic stream and marks its packets according to three traffic parameters, Committed Information Rate(CIR), Committed Burst Size (CBS), and Excess Burst Size (EBS), to be either green, yellow, or red. A packet is marked green if it doesn't exceed the CBS, yellow if it does exceed the CBS, but not the EBS, and red otherwise. |
|
| |
| RFC 2698 | A Two Rate Three Color Marker |
| |
| Authors: | J. Heinanen, R. Guerin. |
| Date: | September 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2698 |
|
This document defines a Two Rate Three Color Marker (trTCM), which can be used as a component in a Diffserv traffic conditioner[RFC2475, RFC2474]. The trTCM meters an IP packet stream and marks its packets based on two rates, Peak Information Rate (PIR) andCommitted Information Rate (CIR), and their associated burst sizes to be either green, yellow, or red. A packet is marked red if it exceeds the PIR. Otherwise it is marked either yellow or green depending on whether it exceeds or doesn't exceed the CIR. |
|
| |
| RFC 2699 | Request for Comments Summary RFC Numbers 2600-2699 |
| |
| Authors: | S. Ginoza. |
| Date: | May 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2699 |
|
|
|
