| |
| RFC 2100 | The Naming of Hosts |
| |
| Authors: | J. Ashworth. |
| Date: | April 1 1997 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
This RFC is a commentary on the difficulty of deciding upon an acceptably distinctive hostname for one's computer, a problem which grows in direct proportion to the logarithmically increasing size of the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 2101 | IPv4 Address Behaviour Today |
| |
| Authors: | B. Carpenter, J. Crowcroft, Y. Rekhter. |
| Date: | February 1997 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
The main purpose of this note is to clarify the current interpretation of the 32-bit IP version 4 address space, whose significance has changed substantially since it was originally defined. A short section on IPv6 addresses mentions the main points of similarity with, and difference from, IPv4. |
|
| |
| RFC 2102 | Multicast Support for Nimrod : Requirements and Solution Approaches |
| |
| Authors: | R. Ramanathan. |
| Date: | February 1997 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
Nimrod does not specify a particular solution for multicasting.Rather, Nimrod may use any of a number of emerging multicast techniques. We identify the requirements that Nimrod has of a solution for multicast support. We compare existing approaches for multicasting within an internetwork and discuss their advantages and disadvantages. Finally, as an example, we outline the mechanisms to support multicast in Nimrod using the scheme currently being developed within the IETF - namely, the Protocol Indpendent Multicast(PIM) protocol. |
|
| |
| RFC 2103 | Mobility Support for Nimrod : Challenges and Solution Approaches |
| |
| Authors: | R. Ramanathan. |
| Date: | February 1997 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
We discuss the issue of mobility in Nimrod. While a mobility solution is not part of the Nimrod architecture, Nimrod does require that the solution have certain characteristics. We identify the requirements that Nimrod has of any solution for mobility support.We also classify and compare existing approaches for supporting mobility within an internetwork and discuss their advantages and disadvantages. Finally, as an example, we outline the mechanisms to support mobility in Nimrod using the scheme currently being developed within the IETF - namely, the Mobile-IP protocol. |
|
| |
| RFC 2104 | HMAC: Keyed-Hashing for Message Authentication |
| |
| Authors: | H. Krawczyk, M. Bellare, R. Canetti. |
| Date: | February 1997 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength ofHMAC depends on the properties of the underlying hash function. |
|
| |
| RFC 2105 | Cisco Systems' Tag Switching Architecture Overview |
| |
| Authors: | Y. Rekhter, B. Davie, D. Katz, E. Rosen, G. Swallow. |
| Date: | February 1997 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
This document provides an overview of a novel approach to network layer packet forwarding, called tag switching. The two main components of the tag switching architecture - forwarding and control - are described. Forwarding is accomplished using simple label-swapping techniques, while the existing network layer routing protocols plus mechanisms for binding and distributing tags are used for control. Tag switching can retain the scaling properties of IP, and can help improve the scalability of IP networks. While tag switching does not rely on ATM, it can straightforwardly be applied to ATM switches. A range of tag switching applications and deployment scenarios are described. |
|
| |
| RFC 2106 | Data Link Switching Remote Access Protocol |
| |
| Authors: | S. Chiang, J. Lee, H. Yasuda. |
| Date: | February 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2114 |
| Status: | INFORMATIONAL |
|
This memo describes the Data Link Switching Remote Access Protocol that is used between workstations and routers to transport SNA/NetBIOS traffic over TCP sessions. Any questions or comments should be sent to drap@cisco.com. |
|
| |
| RFC 2107 | Ascend Tunnel Management Protocol - ATMP |
| |
| Authors: | K. Hamzeh. |
| Date: | February 1997 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
This document specifies a generic tunnel management protocol that allows remote dial-in users to access their home network as if they were directly attached to the home network. The user's client software uses an address contained in the home network address space for the remote access. Packets to and from the home network are tunneled by the Network Access Server (NAS) to which the user connects and a Home Agent (HA) on the user's home network. This allows for the support of access to Virtual Private Networks and also allows for the use of protocols other than IP to be carried over the tunnel. An example of how the RADIUS (Remote Authentication Dial InUser Service) can be used to provide the necessary configuration information to support this service is also provided. |
|
| |
| RFC 2108 | Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2 |
| |
| Authors: | K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie. |
| Date: | February 1997 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1516 |
| Status: | PROPOSED STANDARD |
|
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 objects for managing IEEE 802.3 10 and 100Mb/second baseband repeaters based on IEEE Std 802.3 Section 30, "10& 100 Mb/s Management," October 26, 1995. |
|
| |
| RFC 2109 | HTTP State Management Mechanism |
| |
| Authors: | D. Kristol, L. Montulli. |
| Date: | February 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2965 |
| Status: | PROPOSED STANDARD |
|
This document specifies a way to create a stateful session with HTTP requests and responses. It describes two new headers, Cookie and Set- Cookie, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal, but it can interoperate with HTTP/1.0 user agents that use Netscape's method. [STANDARDS-TRACK] |
|
| |
| RFC 2110 | MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML) |
| |
| Authors: | J. Palme, A. Hopmann. |
| Date: | March 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2557 |
| Status: | PROPOSED STANDARD |
|
Although HTML [RFC 1866] was designed within the context of MIME, more than the specification of HTML as defined in RFC 1866 is needed for two electronic mail user agents to be able to interoperate usingHTML as a document format. These issues include the naming of objects that are normally referred to by URIs, and the means of aggregating objects that go together. This document describes a set of guidelines that will allow conforming mail user agents to be able to send, deliver and display these objects, such as HTML objects, that can contain links represented by URIs. In order to be able to handle inter-linked objects, the document uses the MIME type multipart/related and specifies the MIME content-headers "Content-Location" and "Content-Base". |
|
| |
| RFC 2111 | Content-ID and Message-ID Uniform Resource Locators |
| |
| Authors: | E. Levinson. |
| Date: | March 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2392 |
| Status: | PROPOSED STANDARD |
|
The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message. |
|
| |
| RFC 2112 | The MIME Multipart/Related Content-type |
| |
| Authors: | E. Levinson. |
| Date: | March 1997 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1872 |
| Obsoleted by: | RFC 2387 |
| Status: | PROPOSED STANDARD |
|
The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts.This document defines the Multipart/Related content-type and provides examples of its use. |
|
| |
| RFC 2113 | IP Router Alert Option |
| |
| Authors: | D. Katz. |
| Date: | February 1997 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
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. |
|
| |
| RFC 2114 | Data Link Switching Client Access Protocol |
| |
| Authors: | S. Chiang, J. Lee, H. Yasuda. |
| Date: | February 1997 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2106 |
| Status: | INFORMATIONAL |
|
This memo describes the Data Link Switching Client Access Protocol that is used between workstations and routers to transport SNA/NetBIOS traffic over TCP sessions. Any questions or comments should be sent to dcap@cisco.com. |
|
| |
| RFC 2115 | Management Information Base for Frame Relay DTEs Using SMIv2 |
| |
| Authors: | C. Brown, F. Baker. |
| Date: | September 1997 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1315 |
| Status: | DRAFT STANDARD |
|
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 Frame Relay interfaces on DTEs. [STANDARDS-TRACK] |
|
| |
| RFC 2116 | X.500 Implementations Catalog-96 |
| |
| Authors: | C. Apple, K. Rossen. |
| Date: | April 1997 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1632 |
| Also: | FYI 0011 |
| Status: | INFORMATIONAL |
|
This document is a revision to [RFC 1632]: A Revised Catalog ofAvailable X.500 Implementations and is based on the results of data collection via a WWW home page that enabled implementors to submit new or updated descriptions of currently available implementations ofX.500, including commercial products and openly available offerings.[RFC 1632] is a revision of [RFC 1292]. We contacted each contributor to [RFC 1632] to request an update and published the URL of the WWW home page survey template in several mailing lists to encourage the submission of new product descriptions.
This document contains detailed description of 31 X.500 implementations - DSAs, DUAs, and DUA interfaces. |
|
| |
| RFC 2117 | Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification |
| |
| Authors: | D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei. |
| Date: | June 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2362 |
| Status: | EXPERIMENTAL |
|
This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2118 | Microsoft Point-To-Point Compression (MPPC) Protocol |
| |
| Authors: | G. Pall. |
| Date: | March 1997 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links.
This document describes the use of the Microsoft Point to PointCompression protocol (also referred to as MPPC in this document) for compressing PPP encapsulated packets. |
|
| |
| RFC 2119 | Key words for use in RFCs to Indicate Requirement Levels |
| |
| Authors: | S. Bradner. |
| Date: | March 1997 |
| Formats: | txt pdf |
| Also: | BCP 0014 |
| Status: | BEST CURRENT PRACTICE |
|
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: |
|
| |
| RFC 2120 | Managing the X.500 Root Naming Context |
| |
| Authors: | D. Chadwick. |
| Date: | March 1997 |
| Formats: | txt pdf |
| Status: | EXPERIMENTAL |
|
The X.500 Standard [X.500 93] has the concept of first level DSAs, whose administrators must collectively manage the root naming context through bi-lateral agreements or other private means which are outside the scope of the X.500 Standard.
The NameFLOW-Paradise X.500 service has an established procedure for managing the root naming context, which currently uses Quipu proprietary replication mechanisms and a root DSA. The benefits that derive from this are twofold:
- firstly it is much easier to co-ordinate the management of the root context information, when there is a central point of administration,
- secondly the performance of one-level Search operations is greatly improved because the Quipu distribution and replication mechanism does not have a restriction that exists in the 1988 and1993 X.500 Standard.
The NameFLOW-Paradise project is moving towards 1993 ISO X.500Standard replication protocols and wants to standardise the protocol and procedure for managing the root naming context which will be based on 1993 X.500 Standard protocols. Such a protocol and procedure will be useful to private X.500 domains as well as to the InternetX.500 public domain. It is imperative that overall system performance is not degraded by this transition.
This document describes the use of 1993 ISO X.500 Standard protocols for managing the root context. Whilst the ASN.1 is compatible with that of the X.500 Standard, the actual settings of the parameters are supplementary to that of the X.500 Standard. |
|
| |
| RFC 2121 | Issues affecting MARS Cluster Size |
| |
| Authors: | G. Armitage. |
| Date: | March 1997 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
IP multicast over ATM currently uses the MARS model [1] to manage the use of ATM pt-mpt SVCs for IP multicast packet forwarding. The scope of any given MARS services is the MARS Cluster - typically the same as an IPv4 Logical IP Subnet (LIS). Current IP/ATM networks are usually architected with unicast routing and forwarding issues dictating the sizes of individual LISes. However, as IP multicast is deployed as a service, the size of a LIS will only be as big as aMARS Cluster can be. This document provides a qualitative look at the issues constraining a MARS Cluster's size, including the impact of VC limits in switches and NICs, geographical distribution of cluster members, and the use of VC Mesh or MCS modes to support multicast groups. |
|
| |
| RFC 2122 | VEMMI URL Specification |
| |
| Authors: | D. Mavrakis, H. Layec, K. Kartmann. |
| Date: | March 1997 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
A new URL scheme, "vemmi" is defined. VEMMI is a new international standard for on-line multimedia services, that is both an ITU-T (International Telecommunications Union, ex. CCITT) International Standard (T.107) and an European Standard (ETSI European Telecommunications Standard Institute) standard (ETS 300 382, obsoleted by ETS 300 709). [STANDARDS-TRACK] |
|
| |
| RFC 2123 | Traffic Flow Measurement: Experiences with NeTraMet |
| |
| Authors: | N. Brownlee. |
| Date: | March 1997 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
This memo records experiences in implementing and using the TrafficFlow Measurement Architecture and Meter MIB. It discusses the implementation of NeTraMet (a traffic meter) and NeMaC (a combined manager and meter reader), considers the writing of meter rule sets and gives some guidance on setting up a traffic flow measurement system using NeTraMet. |
|
| |
| RFC 2124 | Cabletron's Light-weight Flow Admission Protocol Specification Version 1.0 |
| |
| Authors: | P. Amsden, J. Amweg, P. Calato, S. Bensley, G. Lyons. |
| Date: | March 1997 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
Light-weight Flow Admission Protocol, LFAP, allows an external FlowAdmission Service (FAS) to manage flow admission at the switch, allowing flexible Flow Admission Services to be deployed by a vendor or customer without changes to, or undue burden on, the switch.
Specifically, this document specifies the protocol between the switchConnection Control Entity (CCE) and the external FAS. Using LFAP, aFlow Admission Service can: allow or disallow flows, define the parameters under which a given flow is to operate (operating policy) or, redirect the flow to an alternate destination. The FAS may also maintain details of current or historical flows for billing, capacity planning and other purposes. |
|
| |
| RFC 2125 | The PPP Bandwidth Allocation Protocol (BAP) / The PPP Bandwidth Allocation Control Protocol (BACP) |
| |
| Authors: | C. Richards, K. Smith. |
| Date: | March 1997 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
This document proposes a method to manage the dynamic bandwidth allocation of implementations supporting the PPP multilink protocol[2]. This is done by defining the Bandwidth Allocation Protocol(BAP), as well as its associated control protocol, the BandwidthAllocation Control Protocol (BACP). BAP can be used to manage the number of links in a multilink bundle. BAP defines datagrams to co- ordinate adding and removing individual links in a multilink bundle, as well as specifying which peer is responsible for which decisions regarding managing bandwidth during a multilink connection. |
|
| |
| RFC 2126 | ISO Transport Service on top of TCP (ITOT) |
| |
| Authors: | Y. Pouffary, A. Young. |
| Date: | March 1997 |
| Formats: | txt pdf |
| Updates: | RFC 1006 |
| Status: | PROPOSED STANDARD |
|
This document is a revision to STD35, RFC1006 written by Marshall T.Rose and Dwight E. Cass. Since the release of RFC1006 in May 1987, much experience has been gained in using ISO transport services on top of TCP. This document refines the protocol and will eventually supersede RFC1006.
This document describes the mechanism to allow ISO Transport Services to run over TCP over IPv4 or IPv6. It also defines a number of new features, which are not provided in RFC1006.
The goal of this version is to minimise the number of changes toRFC1006 and ISO 8073 transport protocol definitions, while maximising performance, extending its applicability and protecting the installed base of RFC1006 users. |
|
| |
| RFC 2127 | ISDN Management Information Base using SMIv2 |
| |
| Authors: | G. Roeck, Ed.. |
| Date: | March 1997 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
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 minimal set of managed objects for SNMP- based management of ISDN terminal interfaces. ISDN interfaces are supported on a variety of equipment (for data and voice) including terminal adapters, bridges, hosts, and routers.
This document specifies a MIB module in a manner that is compliant to the SNMPv2 SMI. The set of objects is consistent with the SNMP framework and existing SNMP standards.
This document is a product of the ISDN MIB working group within theInternet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at isdn- mib@cisco.com and/or the author.
The current version of this document reflects changes made during the last call period and the IESG review. |
|
| |
| RFC 2128 | Dial Control Management Information Base using SMIv2 |
| |
| Authors: | G. Roeck, Ed.. |
| Date: | March 1997 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
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 used for managing demand access circuits, including ISDN.
This document specifies a MIB module in a manner that is compliant to the SNMPv2 SMI. The set of objects is consistent with the SNMP framework and existing SNMP standards.
This document is a product of the ISDN MIB working group within theInternet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at isdn- mib@cisco.com and/or the author. |
|
| |
| RFC 2129 | Toshiba's Flow Attribute Notification Protocol (FANP) Specification |
| |
| Authors: | K. Nagami, Y. Katsube, Y. Shobatake, A. Mogi, S. Matsuzawa, T. Jinmei, H. Esaki. |
| Date: | April 1997 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
This memo discusses Flow Attribute Notification Protocol (FANP), which is a protocol between neighbor nodes for the management of cut-through packet forwarding functionalities. In cut-through packet forwarding, a router doesn't have to perform conventional IP packet processing for received packets. FANP indicates mapping information between a datalink connection and a packet flow to the neighbor node and helps a pair of nodes manage the mapping information. By usingFANP, routers (e.g., CSR; Cell Switch Router) can forward incoming packets based on their datalink-level connection identifiers, bypassing usual IP packet processing. The design policy of the FANP is;
(1) soft-state cut-through path (Dedicated-VC) management(2) protocol between neighbor nodes instead of end-to-end(3) applicable to any connection oriented datalink platform |
|
| |
| RFC 2130 | The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996 |
| |
| Authors: | C. Weider, C. Preston, K. Simonsen, H. Alvestrand, R. Atkinson, M. Crispin, P. Svanberg. |
| Date: | April 1997 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
This report details the conclusions of an IAB-sponsored invitational workshop held 29 February - 1 March, 1996, to discuss the use of character sets on the Internet. It motivates the need to have character set handling in Internet protocols which transmit text, provides a conceptual framework for specifying character sets, recommends the use of MIME tagging for transmitted text, recommends a default character set *without* stating that there is no need for other character sets, and makes a series of recommendations to theIAB, IANA, and the IESG for furthering the integration of the character set framework into text transmission protocols. |
|
| |
| RFC 2131 | Dynamic Host Configuration Protocol |
| |
|
|
The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network.DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the capability of automatic allocation of reusable network addresses and additional configuration options [19]. DHCP captures the behavior ofBOOTP relay agents [7, 21], and DHCP participants can interoperate with BOOTP participants [9]. |
|
| |
| RFC 2132 | DHCP Options and BOOTP Vendor Extensions |
| |
|
|
The Dynamic Host Configuration Protocol (DHCP) [1] provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in tagged data items that are stored in the 'options' field of the DHCP message. The data items themselves are also called"options."
This document specifies the current set of DHCP options. Future options will be specified in separate RFCs. The current list of valid options is also available in ftp://ftp.isi.edu/in- notes/iana/assignments [22].
All of the vendor information extensions defined in RFC 1497 [2] may be used as DHCP options. The definitions given in RFC 1497 are included in this document, which supersedes RFC 1497. All of theDHCP options defined in this document, except for those specific toDHCP as defined in section 9, may be used as BOOTP vendor information extensions. |
|
| |
| RFC 2133 | Basic Socket Interface Extensions for IPv6 |
| |
| Authors: | R. Gilligan, S. Thomson, J. Bound, W. Stevens. |
| Date: | April 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2553 |
| Status: | INFORMATIONAL |
|
The de facto standard application program interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to supportIPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required byTCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [5]. |
|
| |
| RFC 2134 | Articles of Incorporation of Internet Society |
| |
| Authors: | ISOC Board of Trustees. |
| Date: | April 1997 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
These are the articles of incorporation of the Internet Society.They are published for the information of the IETF community at the request of the poisson working group. |
|
| |
| RFC 2135 | Internet Society By-Laws |
| |
| Authors: | ISOC Board of Trustees. |
| Date: | April 1997 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
These are the by-laws of the Internet Society, as amended, as of June1996. They are published for the information of the IETF community at the request of the poisson working group. Please refer to the ISOC web page (www.isoc.org) for the current version of the by-laws. |
|
| |
| RFC 2136 | Dynamic Updates in the Domain Name System (DNS UPDATE) |
| |
|
|
The Domain Name System was originally designed to support queries of a statically configured database. While the data was expected to change, the frequency of those changes was expected to be fairly low, and all updates were made as external edits to a zone's Master File.
Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone. Prerequisites are specified separately from update operations, and can specify a dependency upon either the previous existence or nonexistence of anRRset, or the existence of a single RR.
UPDATE is atomic, i.e., all prerequisites must be satisfied or else no update operations will take place. There are no data dependent error conditions defined after the prerequisites have been met. |
|
| |
| RFC 2137 | Secure Domain Name System Dynamic Update |
| |
| Authors: | D. Eastlake 3rd. |
| Date: | April 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3007 |
| Updates: | RFC 1035 |
| Status: | PROPOSED STANDARD |
|
Domain Name System (DNS) protocol extensions have been defined to authenticate the data in DNS and provide key distribution services[RFC2065]. DNS Dynamic Update operations have also been defined[RFC2136], but without a detailed description of security for the update operation. This memo describes how to use DNSSEC digital signatures covering requests and data to secure updates and restrict updates to those authorized to perform them as indicated by the updater's possession of cryptographic keys. |
|
| |
| RFC 2138 | Remote Authentication Dial In User Service (RADIUS) |
| |
| Authors: | C. Rigney, A. Rubens, W. Simpson, S. Willens. |
| Date: | April 1997 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2058 |
| Obsoleted by: | RFC 2865 |
| Status: | PROPOSED STANDARD |
|
This document describes a protocol for carrying authentication, authorization, and configuration information between a Network AccessServer which desires to authenticate its links and a sharedAuthentication Server. |
|
| |
| RFC 2139 | RADIUS Accounting |
| |
| Authors: | C. Rigney. |
| Date: | April 1997 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2059 |
| Obsoleted by: | RFC 2866 |
| Status: | INFORMATIONAL |
|
This document describes a protocol for carrying accounting information between a Network Access Server and a shared AccountingServer. |
|
| |
| RFC 2140 | TCP Control Block Interdependence |
| |
| Authors: | J. Touch. |
| Date: | April 1997 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
This memo makes the case for interdependent TCP control blocks, where part of the TCP state is shared among similar concurrent connections, or across similar connection instances. TCP state includes a combination of parameters, such as connection state, current round- trip time estimates, congestion control information, and process information. This state is currently maintained on a per-connection basis in the TCP control block, but should be shared across connections to the same host. The goal is to improve transient transport performance, while maintaining backward-compatibility with existing implementations.
This document is a product of the LSAM project at ISI. |
|
| |
| RFC 2141 | URN Syntax |
| |
| Authors: | R. Moats. |
| Date: | May 1997 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. This document sets forward the canonical syntax for URNs. A discussion of both existing legacy and new namespaces and requirements for URN presentation and transmission are presented. Finally, there is a discussion of URN equivalence and how to determine it. |
|
| |
| RFC 2142 | Mailbox Names for Common Services, Roles and Functions |
| |
| Authors: | D. Crocker. |
| Date: | May 1997 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
This specification enumerates and describes Internet mail addresses (mailbox name @ host reference) to be used when contacting personnel at an organization. [STANDARDS-TRACK] |
|
| |
| RFC 2143 | Encapsulating IP with the Small Computer System Interface |
| |
| Authors: | B. Elliston. |
| Date: | May 1997 |
| Formats: | txt pdf |
| Status: | EXPERIMENTAL |
|
This document outlines a protocol for connecting hosts running the TCP/IP protocol suite over a Small Computer System Interface (SCSI) bus. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 2144 | The CAST-128 Encryption Algorithm |
| |
| Authors: | C. Adams. |
| Date: | May 1997 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
There is a need in the Internet community for an unencumbered encryption algorithm 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 (Section 2), the s-boxes (AppendixA), and a set of test vectors (Appendix B). |
|
| |
| RFC 2145 | Use and Interpretation of HTTP Version Numbers |
| |
| Authors: | J. C. Mogul, R. Fielding, J. Gettys, H. Frystyk. |
| Date: | May 1997 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
HTTP request and response messages include an HTTP protocol version number. Some confusion exists concerning the proper use and interpretation of HTTP version numbers, and concerning interoperability of HTTP implementations of different protocol versions. This document is an attempt to clarify the situation. It is not a modification of the intended meaning of the existingHTTP/1.0 and HTTP/1.1 documents, but it does describe the intention of the authors of those documents, and can be considered definitive when there is any ambiguity in those documents concerning HTTP version numbers, for all versions of HTTP. |
|
| |
| RFC 2146 | U.S |
| |
| Authors: | Government Internet Domain Names. Federal Networking Council. |
| Date: | May 1997 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1816 |
| Status: | INFORMATIONAL |
|
This memo provides an update and clarification to RFC 1816. This document describes the registration policies for the top-level domain".GOV". The purpose of the domain is to provide naming conventions that identify US Federal government agencies in order to facilitate access to their electronic resources. This memo provides guidance for registrations by Federal Agencies that avoids name duplication and facilitates responsiveness to the public. It restricts registrations to coincide with the approved structure of the US government and the advice of its Chief Information Officers. Two documents are recognized as constituting documentation on the US government structure: FIPS 95-1 provides a standard recognized structure into which domain registrations for .GOV and FED.US can fit; and, the US Government Manual [3], a special publication of theFederal Register, provides official documentation of the government structure. The latter document may be subject to more timely updates than the former. Either document is suitable for determining which entities qualify for second-level domain registration within .GOV andFED.US.
As a side effect, this RFC reduces the number of .GOV and FED.US level registrations and reduces the workload on the registration authority. Previous versions of this document did not address theFED.US domain. This document anticipates the migration of the .GOV domain into the FED.US domain, in keeping with common practice on theInternet today. |
|
| |
| RFC 2147 | TCP and UDP over IPv6 Jumbograms |
| |
| Authors: | D. Borman. |
| Date: | May 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2675 |
| Status: | PROPOSED STANDARD |
|
IPv6 supports datagrams larger than 65535 bytes long, often referred to as jumbograms, through use of the Jumbo Payload hop-by-hop option. The UDP protocol has a 16-bit length field that keeps it from being able to make use of jumbograms, and though TCP does not have a length field, both the MSS option and the Urgent field are constrained by 16-bits. This document describes some simple changes that can be made to allow TCP and UDP to make use of IPv6 jumbograms. [STANDARDS-TRACK] |
|
| |
| RFC 2148 | Deployment of the Internet White Pages Service |
| |
| Authors: | H. Alvestrand, P. Jurg. |
| Date: | September 1997 |
| Formats: | txt pdf |
| Also: | BCP 0015 |
| Status: | BEST CURRENT PRACTICE |
|
This document describes the way in which the Internet White Pages Service is best exploited using today's experience, today's protocols, today's products and today's procedures. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 2149 | Multicast Server Architectures for MARS-based ATM multicasting |
| |
| Authors: | R. Talpade, M. Ammar. |
| Date: | May 1997 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
A mechanism to support the multicast needs of layer 3 protocols in general, and IP in particular, over UNI 3.0/3.1 based ATM networks has been described in RFC 2022. Two basic approaches exist for the intra-subnet (intra-cluster) multicasting of IP packets. One makes use of a mesh of point to multipoint VCs (the 'VC Mesh' approach), while the other uses a shared point to multipoint tree rooted on aMulticast Server (MCS). This memo provides details on the design and implementation of an MCS, building on the core mechanisms defined inRFC 2022. It also provides a mechanism for using multiple MCSs per group for providing fault tolerance. This approach can be used withRFC 2022 based MARS server and clients, without needing any change in their functionality. |
|
| |
| RFC 2150 | Humanities and Arts: Sharing Center Stage on the Internet |
| |
| Authors: | J. Max, W. Stickle. |
| Date: | October 1997 |
| Formats: | txt pdf |
| Also: | FYI 0031 |
| Status: | INFORMATIONAL |
|
This document is designed primarily for individuals who have limited knowledge of, or experience with, the Internet.
The purpose of this document is to provide members of the Arts andHumanities communities with an introduction to the Internet as a valuable tool, resource, and medium for the creation, presentation, and preservation of Arts and Humanities-based content.
The intended audience is practicing artists, scholars, related professionals, and others whose knowledge, expertise and support is important to ensuring that the Arts and Humanities are well-placed in the global information infrastructure. |
|
| |
| RFC 2151 | A Primer On Internet and TCP/IP Tools and Utilities |
| |
| Authors: | G. Kessler, S. Shepard. |
| Date: | June 1997 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1739 |
| Also: | FYI 0030 |
| Status: | INFORMATIONAL |
|
This memo is an introductory guide to many of the most commonly- available TCP/IP and Internet tools and utilities. It also describes discussion lists accessible from the Internet, ways to obtainInternet and TCP/IP documents, and some resources that help users weave their way through the Internet. |
|
| |
| RFC 2152 | UTF-7 A Mail-Safe Transformation Format of Unicode |
| |
| Authors: | D. Goldsmith, M. Davis. |
| Date: | May 1997 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1642 |
| Status: | INFORMATIONAL |
|
The Unicode Standard, version 2.0, and ISO/IEC 10646-1:1993(E) (as amended) jointly define a character set (hereafter referred to asUnicode) which encompasses most of the world's writing systems.However, Internet mail (STD 11, RFC 822) currently supports only 7- bit US ASCII as a character set. MIME (RFC 2045 through 2049) extendsInternet mail to support different media types and character sets, and thus could support Unicode in mail messages. MIME neither definesUnicode as a permitted character set nor specifies how it would be encoded, although it does provide for the registration of additional character sets over time.
This document describes a transformation format of Unicode that contains only 7-bit ASCII octets and is intended to be readable by humans in the limiting case that the document consists of characters from the US-ASCII repertoire. It also specifies how this transformation format is used in the context of MIME and RFC 1641,"Using Unicode with MIME". |
|
| |
| RFC 2153 | PPP Vendor Extensions |
| |
|
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection; and a family ofNetwork Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document defines a general mechanism for proprietary vendor extensions. |
|
| |
| RFC 2154 | OSPF with Digital Signatures |
| |
| Authors: | S. Murphy, M. Badger, B. Wellington. |
| Date: | June 1997 |
| Formats: | txt pdf |
| Status: | EXPERIMENTAL |
|
This memo describes the extensions to OSPF required to add digital signature authentication to Link State data, and to provide a certification mechanism for router data. Added LSA processing and key management is detailed. A method for migration from, or co- existence with, standard OSPF V2 is described. |
|
| |
| RFC 2155 | Definitions of Managed Objects for APPN using SMIv2 |
| |
| Authors: | B. Clouston, B. Moore. |
| Date: | June 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2455 |
| Status: | PROPOSED STANDARD |
|
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 objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Networking) capabilities. This memo identifies managed objects for the APPN protocol. [STANDARDS- TRACK] |
|
| |
| RFC 2156 | MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME |
| |
|
|
This document relates primarily to the ITU-T 1988 and 1992 X.400 Series Recommendations / ISO IEC 10021 International Standard. This ISO/ITU-T standard is referred to in this document as "X.400", which is a convenient shorthand. [STANDARDS-TRACK] |
|
| |
| RFC 2157 | Mapping between X.400 and RFC-822/MIME Message Bodies |
| |
| Authors: | H. Alvestrand. |
| Date: | January 1998 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
This document defines how to map body parts of X.400 messages into MIME entities and vice versa, including the handling of multipart messages and forwarded messages. [STANDARDS-TRACK] |
|
| |
| RFC 2158 | X.400 Image Body Parts |
| |
| Authors: | H. Alvestrand. |
| Date: | January 1998 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
This document contains the body parts defined in RFC 1495 for carrying image formats that were originally defined in MIME through an X.400 system. [STANDARDS-TRACK] |
|
| |
| RFC 2159 | A MIME Body Part for FAX |
| |
| Authors: | H. Alvestrand. |
| Date: | January 1998 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
This document contains the definitions, originally contained in RFC 1494, on how to carry CCITT G3Fax in MIME, and how to translate it to its X.400 representation. [STANDARDS-TRACK] |
|
| |
| RFC 2160 | Carrying PostScript in X.400 and MIME |
| |
| Authors: | H. Alvestrand. |
| Date: | January 1998 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
This document describes methods for carrying PostScript information in the two standard mail systems MIME and X.400, and the conversion between them. [STANDARDS-TRACK] |
|
| |
| RFC 2161 | A MIME Body Part for ODA |
| |
| Authors: | H. Alvestrand. |
| Date: | January 1998 |
| Formats: | txt pdf |
| Status: | EXPERIMENTAL |
|
This document contains the definitions, originally contained in RFC 1495 and RFC 1341, on how to carry ODA in MIME, and how to translate it to its X.400 representation. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2162 | MaXIM-11 - Mapping between X.400 / Internet mail and Mail-11 mail |
| |
| Authors: | C. Allocchio. |
| Date: | January 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1405 |
| Status: | EXPERIMENTAL |
|
This document describes a set of mappings which will enable inter working between systems operating the ISO/IEC 10021 - CCITT (now ITU)X.400 Recommendations on Message Handling Systems, and systems running the Mail-11 (also known as DECnet mail or VMSmail) protocol.The specifications are valid both within DECnet Phase IV andDECnet/OSI addressing and routing scheme.
The complete scenario of X.400 / MIME / Mail-11 is also considered, in order to cover the possible complex cases arising in multiple gateway translations.
This document covers mainly the X.400 O/R address to/from Mail-11 address mapping and the RFC822 to/from Mail-11 ones; other mappings are based on MIXER specifications. Bodypart mappings are not specified in this document: MIXER and MIME-MHS specifications can be applied to map bodyparts between X.400, MIME and Mail-11, too. In fact MIME encoding can be used without modifications within Mail-11 text bodyparts.
This document obsoletes RFC 1405, which was a combined effort ofTERENA Working Group on Messaging, and the IETF X.400 Ops WorkingGroup. This update was prepared by IETF MIXER working group. |
|
| |
| RFC 2163 | Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM) |
| |
| Authors: | C. Allocchio. |
| Date: | January 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1664 |
| Updated by: | RFC 3597 |
| Status: | PROPOSED STANDARD |
|
This memo is the complete technical specification to store in theInternet Domain Name System (DNS) the mapping information (MCGAM) needed by MIXER conformant e-mail gateways and other tools to mapRFC822 domain names into X.400 O/R names and vice versa. Mapping information can be managed in a distributed rather than a centralised way. Organizations can publish their MIXER mapping or preferred gateway routing information using just local resources (their localDNS server), avoiding the need for a strong coordination with any centralised organization. MIXER conformant gateways and tools located on Internet hosts can retrieve the mapping information querying theDNS instead of having fixed tables which need to be centrally updated and distributed.
This memo obsoletes RFC1664. It includes the changes introduced byMIXER specification with respect to RFC1327: the new 'gate1' (O/R addresses to domain) table is fully supported. Full backward compatibility with RFC1664 specification is mantained, too.
RFC1664 was a joint effort of IETF X400 operation working group(x400ops) and TERENA (formely named "RARE") Mail and Messaging working group (WG-MSG). This update was performed by the IETF MIXER working group. |
|
| |
| RFC 2164 | Use of an X.500/LDAP directory to support MIXER address mapping |
| |
| Authors: | S. Kille. |
| Date: | January 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1838 |
| Status: | PROPOSED STANDARD |
|
This specification defines how to represent and maintain these mappings (MIXER Conformant Global Address Mappings of MCGAMs) in an X.500 or LDAP directory. [STANDARDS-TRACK] |
|
| |
| RFC 2165 | Service Location Protocol |
| |
| Authors: | J. Veizades, E. Guttman, C. Perkins, S. Kaplan. |
| Date: | June 1997 |
| Formats: | txt pdf |
| Updated by: | RFC 2608, RFC 2609 |
| Status: | PROPOSED STANDARD |
|
The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet no longer need so much 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 2166 | APPN Implementer's Workshop Closed Pages Document DLSw v2.0 Enhancements |
| |
| Authors: | D. Bryant, P. Brittain. |
| Date: | June 1997 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
This document specifies
- a set of extensions to RFC 1795 designed to improve the scalability of DLSw- clarifications to RFC 1795 in the light of the implementation experience to-date.
It is assumed that the reader is familiar with DLSw and RFC 1795. No effort has been made to explain these existing protocols or associated terminology.
This document was developed in the DLSw Related Interest Group (RIG) of the APPN Implementers Workshop (AIW). If you would like to participate in future DLSw discussions, please subscribe to the DLSwRIG mailing lists by sending a mail to majordomo@raleigh.ibm.com specifying 'subscribe aiw-dlsw' as the body of the message. |
|
| |
| RFC 2167 | Referral Whois (RWhois) Protocol V1.5 |
| |
| Authors: | S. Williamson, M. Kosters, D. Blacka, J. Singh, K. Zeilstra. |
| Date: | June 1997 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1714 |
| Status: | INFORMATIONAL |
|
This memo describes Version 1.5 of the client/server interaction ofRWhois. RWhois provides a distributed system for the discovery, retrieval, and maintenance of directory information. This system is primarily hierarchical by design. It allows for the deterministic routing of a query based on hierarchical tags, referring the user closer to the maintainer of the information. While RWhois can be considered a generic directory services protocol, it distinguishes itself from other protocols by providing an integrated, hierarchical architecture and query routing mechanism. |
|
| |
| RFC 2168 | Resolution of Uniform Resource Identifiers using the Domain Name System |
| |
|
|
The requirements document for URN resolution systems defines the concept of a "resolver discovery service". This document describes the first, experimental, RDS. It is implemented by a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2169 | A Trivial Convention for using HTTP in URN Resolution |
| |
| Authors: | R. Daniel. |
| Date: | June 1997 |
| Formats: | txt pdf |
| Status: | EXPERIMENTAL |
|
This document specifies the "THTTP" resolution protocol - a trivial convention for encoding resolution service requests and responses as HTTP 1.0 or 1.1 requests and responses. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. |
|
| |
| RFC 2170 | Application REQuested IP over ATM (AREQUIPA) |
| |
| Authors: | W. Almesberger, J. Le Boudec, P. Oechslin. |
| Date: | July 1997 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
This document specifies a method for allowing ATM-attached hosts that have direct ATM connectivity to set up end-to-end IP over ATM connections within the reachable ATM cloud, on request from applications, and for the exclusive use by the requesting applications. This allows the requesting applications to benefit in a straightforward way from ATM's inherent ability to guarantee the quality of service (QoS).
Given a mapping from service classes, as defined by INTSERV[6], toATM traffic descriptors, Arequipa can be used to implement integrated services over ATM link layers. Usage of Arequipa to provide integrated services even if ATM is only available for intermediate links is not discussed in this document but should be straight- forward.
The major advantage of using an approach like Arequipa is that it needs to be implemented only on the hosts using it. It requires no extra service (eg. NHRP or RSVP) to be deployed on the switches or routers of the ATM cloud.
We discuss the implementation of Arequipa for hosts running IPv4 andIPv6. As an illustration, we also discuss how World-Wide-Web applications can use Arequipa to deliver documents with a guaranteed quality of service.
In particular we show how
- Arequipa can be implemented in IPv4 by slightly modifying the- Arequipa can be implemented in IPv6[3] by the appropriate use of flow labels and the extension of the neighbour cache,- Arequipa can be used in the Web by adding extra information in the headers of HTTP requests and responses.
Finally, we address safety and security implications. |
|
| |
| RFC 2171 | MAPOS - Multiple Access Protocol over SONET/SDH Version 1 |
| |
| Authors: | K. Murakami, M. Maruyama. |
| Date: | June 1997 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
This document describes the protocol MAPOS, Multiple Access Protocol over SONET/SDH, for transmitting network-protocol datagrams overSONET/SDH. It focuses on the core protocol -- other documents listed in the bibliography may be referenced in conjunction with this document to provide support and services for protocols at higher layers. |
|
| |
| RFC 2172 | MAPOS Version 1 Assigned Numbers |
| |
| Authors: | M. Maruyama, K. Murakami. |
| Date: | June 1997 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
This document describes the protocol parameters used in the MultipleAccess Over SONET/SDH (MAPOS) version 1. MAPOS is a link layer protocol and provides multiple access capability over SONET/SDH links. |
|
| |
| RFC 2173 | A MAPOS version 1 Extension - Node Switch Protocol |
| |
| Authors: | K. Murakami, M. Maruyama. |
| Date: | June 1997 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
This document describes a MAPOS extension, Node Switch Protocol, for automatic node address assignment. MAPOS is a multiple access protocol for transmission of network-protocol datagrams, encapsulated in High-Level Data Link Control (HDLC) frames, over SONET/SDH. NSP automates the HDLC address configuration of each node. Using NSP, a node retrieves its HDLC address from the switch to which it is connected. |
|
| |
| RFC 2174 | A MAPOS version 1 Extension - Switch-Switch Protocol |
| |
| Authors: | K. Murakami, M. Maruyama. |
| Date: | June 1997 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
This document describes a MAPOS version 1 extension, SSP (SwitchSwitch Protocol). MAPOS is a multiple access protocol for transmission of network-protocol packets, encapsulated in High-LevelData Link Control (HDLC) frames, over SONET/SDH. In MAPOS network, aSONET switch provides the multiple access capability to end nodes.SSP is a protocol of Distance Vector family and provides unicast and broadcast/multicast routing for multiple SONET switch environment. |
|
| |
| RFC 2175 | MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing |
| |
| Authors: | K. Murakami, M. Maruyama. |
| Date: | June 1997 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
This document describes the protocol MAPOS 16, Multiple AccessProtocol over SONET/SDH with 16 Bit Addressing, for transmitting network-protocol datagrams over SONET/SDH. The primary difference with MAPOS version 1 is that it has 16 bit address field that offers significant wide address space. It first describes the major differences between MAPOS and MAPOS 16 briefly. Then, it explains the header format and its 16 bit address format. |
|
| |
| RFC 2176 | IPv4 over MAPOS Version 1 |
| |
| Authors: | K. Murakami, M. Maruyama. |
| Date: | June 1997 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
This document describes a protocol for transmission of the InternetProtocol Version 4 (IPv4) over Multiple Access Over SONET/SDH (MAPOS) version 1. MAPOS is a link layer protocol and provides multiple access capability over SONET/SDH links. IP runs on top of MAPOS. This document explains IP datagram encapsulation in HDLC frame of MAPOS, and the Address Resolution Protocol (ARP). |
|
| |
| RFC 2177 | IMAP4 IDLE command |
| |
| Authors: | B. Leiba. |
| Date: | June 1997 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
This document specifies the syntax of an IDLE command, which will allow a client to tell the server that it's ready to accept such real-time updates. [STANDARDS-TRACK] |
|
| |
| RFC 2178 |
