Network Protocol Bibliographies
- Protocol article references
There are approximately 200 complete or partial items listed in this
listing. 80% of these links lead to the complete work and about 20% lead to
identifying why you can locate the reference at your library or by using the Search
Engines to hunt them down. Unfortunately some of the more commercial web sites use
the partial chapters as bait to lure you into buying the hard copy of the text - rather
then putting the whole thing online and letting the consumer decide whether he/she prefers
the free online version or if they wish to purchase a hard copy.
Another problem with maintaining this listing is that web sites live and die faster then
fruit flies - so it is possible that links will be up one day and down the next.
SEARCHING THIS LIST - use your browsers built in
find feature
Iin order to best search this list for topics of your particular interest, use the built
in feature of YOUR web browser to search the page for keywords. On the IE
Explorer the FIND feature is located in the EDIT options at the top of your browser.
On the Netscape browser you will find the FIND option also in the EDIT options at
the top of your web browser.
Good luck... good hunting... and hopefully good reading !
Network Bibliography : Network Protocols
Steven Low, Nicholas F. Maxemchuk and Sanjoy Paul, "Anonymous Credit Cards," in
submitted to 1994 IEEE Symposium on Research in Security and Privacy, (Oakland,
California), 1994.
Abstract: This paper describes a novel technique for generating an anonymous
credit card which combines the privacy of cash transactions with the security,
record-keeping and charging mechanisms of credit cards. Using this scheme, and individual
can make purchases without revealing his identity while a shop can sell items to an
unknown individual without the fear of being cheated.
Keywords: electronic cash; anonymous credit cards; mercantile protocols
Steven Low, Nicholas F. Maxemchuk and Sanjoy Paul, "Collusion in a Multi-party
Communications Protocol for Anonymous Credit Cards," submitted to IEEE/ACM
Transactions on Networking, 1994.
Abstract: We proposed in [8] a novel scheme to implement an anonymous credit
card that protects privacy while providing the security, record- keeping, and charging
mechanism of conventional credit cards. The key idea is to use cryptographic techniques to
allow two parties to commuincate without knowing each other. In this paper we present a
formal method to study collusion in the multi-party communication protocol in [8].
Application of the method to our protocol leads to a simplified implementation of
anonymous credit cards that is equally secure.
Keywords: electronic cash; anonymous credit cards; mercantile protocols
Alec F. Yasinsac and William A. Wulf, "Evaluating cryptographic
protocols," Department of Computer Science, University of Virginia,
Charlottesville, Virginia, no. CS-93-66, Dec. 1993.
Abstract: Cryptographic protocol (CP) analysis is a topic of intense research.
Meadows describes four approaches to CP verification under investigation in (Meadows 1992)
and several authors have categorized protocols based on types of errors they are subject
to (Bird 1992, Syverson 1993). This paper addresses the weakness injected into protocols
when information is passed in the clear or encrypted only under the private key of a
public/private key pair. We also propose a method for logically analyzing protocols based
on action list analysis of valid and compromised protocol runs interleaved with action
lists of intruders conducting known attacks.
Keywords: cryptography; protocols; protocol verification
Dominique de Waleffe and Jean-Jacques Quisquater, "Better login protocols for
computer networks," in Computer Security and Industrial Cryptography, Preneel,
Bart and Govaerts, Ren\'e and Vandewalle, Joos, ed., Berlin, pp. 50--70, May 1991.
Abstract: Authenticating computer users is a fairly old problem. Password based
solutions were acceptable until the growth of computer networks based on insecure
communications. Today many systems still use fixed passwords as a means of authentication.
We show in this paper how an old scheme by Lamport can be used to provide more security.
Relying on that scheme and zero-knowledge techniques, we show extensions providing much
more general access control mechanisms. Those extensions can be exploited in several ways:
to authenticate users in computer networks, to provide users with access tickets or
provide servers with proofs of usage. We also show how, in a single transaction, a user
can prove this authenticity as well as prove his possession of a ticket. Finally, we
explain how smart cards make those protocols very practical.
Keywords: security; authentication; access control; login; smart card
Johan van Tilburg, "Secret-key exchange with authentication," in Computer
Security and Industrial Cryptography, Preneel, Bart and Govaerts, Ren\'e and
Vandewalle, Joos, ed., Berlin, pp. 71--86, May 1991.
Abstract: This paper provides an outline for the second lecture on
authentication protocols and deals with the secret-key exchange protocols. The object is
to encourage the interested reader to obtain and study the original papers, and papers
related to this subject.
Keywords: security; authentication; encryption; secret key; public-key;
Diffie-Hellman; ElGamal; zero-knowledge
Bart De Decker, "Unix Security and Kerberos," in Computer Security and
Industrial Cryptography, Preneel, Bart and Govaerts, Ren\'e and Vandewalle, Joos, ed.,
Berlin, pp. 257--274, May 1991.
Abstract: This paper discusses some security issues related to the UNIX
operating system, which is today the de facto standard Operating System. The
authentication mechanism has been focused on, both in a central system and in a networked
environment. It is shown that networking makes UNIX vulnerable if no special measures are
taken. One of these could be the introduction of the Kerberos authentication system which
is also becoming a ``standard'' in open network environments. The Kerberos protocols are
described, and their merits and limitations in a possibly hostile environment are
discussed.
Keywords: security; Unix; operating systems; Kerberos; authentication; login
B. Abarbanel and S. Venkatachalam, "BGP-4
support for Traffic Engineering," Internet Engineering Task Force, Jun. 2000.
Abstract: Currently, constraint routing (CR) and traffic engineering (TE) models
do not take into consideration the big picture view of IP traffic traversing multiple
autonomous systems (AS). Most of the traffic and constraint routing is based on IGP
protocols such as OSPF/ISIS, etc. The resulting view of the Internet is limited to one
autonomous system and areas or systems within it. Hence, the routing/forwarding functions
do not select the optimum path for packets that need to traverse several autonomous
systems. The proposal in this draft is that the BGP protocol can be utilized to choose the
best BGP routes based on traffic engineered (TE) constraint weights. This information can
be propagated between all BGP peers and calculated by the BGP AS border routers before it
is deployed to their forwarding tables.
J. Abela, "UTF-9,
a transformation format of UCS," Internet Engineering Task Force, Dec. 1997.
Abstract: ISO/IEC 10646 defines a multi-octet character set called the Universal
Character Set (UCS) which encompasses most of the world's writing systems. Multi-octet
characters, however, are not compatible with many current applications and protocols, and
this has led to the development of a few so-called UCS transformation formats (UTF), each
with different characteristics. UTF-9, the object of this memo, has the characteristic of
preserving the full ISO-Latin1 range, providing compatibility with file systems, parsers
and other software that rely on ISO-Latin1 values. ISO-Latin1 is almost as widespread as
ASCII in many countries, especially in most of western Europe, and is the default
character set for HTML. A compatible encoding seems desirable, where possible.
B. Aboba, "IPSEC Remote
Access Protocol Evaluation Criteria," Internet Engineering Task Force, Jul. 2000.
Abstract: This document describes criteria for evaluation of IPSEC Remote Access
(IPSRA) protocols. In particular, this document focuses on criteria relevant to voluntary
tunneling.
B. Aboba, "Extension
for PPP Authentication," Internet Engineering Task Force, Nov. 1997.
Abstract: This document defines the ''PPP Authentication Operation'' for LDAP.
This operation provides for PPP authentication in an LDAP association and is defined in
terms of an LDAP extended operation. It is expected that this extended operation will be
useful in inte- grating authentication protocols such as RADIUS and TACACS+ with LDAP-
based directory services. Consolidation of information stores is desirable since it
results in lessened administrative workload and a consistent view of user information
throughout the enterprise.
B. Aboba, "PPP EAP GSS
Authentication Protocol," Internet Engineering Task Force, Jul. 2000.
Abstract: The Extensible Authentication Protocol (EAP) provides a standard
mechanism for support of additional authentication methods within layer 2 protocols,
including PPP and IEEE 802. Through the use of EAP, support for a number of authentication
schemes may be added, including public key, smart cards, Kerberos, One Time Passwords, and
others.
C. Adams and J. Gilchrist, "The CAST-256
Encryption Algorithm," Internet Engineering Task Force, Feb. 1999.
Abstract: 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).
C. Adams, "Alternative
Certificate Formats for PKIX-CMP," Internet Engineering Task Force, Jul. 2000.
Abstract: The PKIX Certificate Management Protocols (PKIX-CMP) specification
[1], while primarily focused on X.509v3 public-key certificates, allows the messages it
defines to be used for the management of alternative certificate formats as well. This
document specifies precisely how such formats may be incorporated into PKIX-CMP and
provides the relevant syntax for some important certificate types.
C. Adams and R. Zuccherato, "Data Certification
Server Protocols," Internet Engineering Task Force, Jun. 1998.
Abstract: This document describes a general data certification service and the
protocols to be used when communicating with it. The Data Certification Server is a
Trusted Third Party (TTP) that can be used as one component in building reliable
non-repudiation services (see [ISONR]). Useful Data Certification Server responsibilities
in a PKI are to validate signatures and to provide up-to-date information regarding the
status of public key certificates. We give examples of how to use the Data Certification
Server to extend the lifetime of a signature beyond key expiry or revocation and to query
the Data Certification Server regarding the status of a public key certificate. The key
words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT',
'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described
in RFC 2119 [RFC2119].
C. Adams and R. Zuccherato, "Notary Protocols,"
Internet Engineering Task Force, Feb. 1998.
Abstract: This document describes a general notary service and the protocols to
be used when communicating with it. The Notary Authority is a Trusted Third Party (TTP)
that can be used as one component in building reliable non-repudiation services (see
[ISONR]). Useful Notary Authority responsibilities in a PKI are to validate signatures and
to provide up- to-date information regarding the status of certificates. We give examples
of how to use the notary to extend the lifetime of a signature beyond key expiry or
revocation and to query the notary regarding the status of a certificate.
C. Adams, D. Pinkas, P. Cain and R. Zuccherato, "Time Stamp
Protocols," Internet Engineering Task Force, Jun. 1998.
Abstract: This document describes the format of the data returned by a Time
Stamp Authority and the protocols to be used when communicating with it. The time stamping
service can be used as a Trusted Third Party (TTP) as one component in building reliable
non-repudiation services (see [ISONR]). In order to reduce the amount of trust required of
a TSA we introduce (in Appendix C) the optional Temporal Data Authority (TDA) whose
function is to provide further corroborating evidence of the time contained in the token.
We also give an example of how to place a signature at a particular point in time, from
which the appropriate certificate status information (e.g. CRLs) may be checked.
C. Perkins and H. AFIFI, "Internet General
Packet Radio Service (IGPRS); Service description," Internet Engineering Task
Force, Jul. 2000.
Abstract: We propose an architecture (IGPRS) for the integration of the IPv6
protocol in the GPRS infrastructure. The data and signalling protocol suite will be based
on mobile IPv6 protocol (instead of the GTP protocol). This new infrastructure will take
advantage of the available internet protocols for routing and security. Since it is
targetted to co-exist with the GPRS, it is a partial translation of MAP specifications to
Internet protocols. This document uses some of the GPRS Service document and some of its
terminology.
S. Ago, S. Moeenuddin and S. Hadvani, "NEC contribution
on pre-Spirits ICW implementations," Internet Engineering Task Force, Feb. 2000.
Abstract: This document provides overview of a pre-SPIRITS Internet Call Waiting
(ICW) implementation developed by NEC. The document describes the ICW service, the
architecture, interface, and the protocols used in the ICW implementation. As such, this
document contributes to the future SPIRITS architecture and protocol RFCs.
C. Akinlar, D. Braun and S. Mukherjee, "Multi-Router
Zeroconf Network Requirements," Internet Engineering Task Force, Aug. 2000.
Abstract: Zero Configuration (Zeroconf) Networks are a particular class of
TCP/IP networks that may be established in the home, in small offices or even for a
variety of adhoc purposes. Zeroconf networks do not have and should not be expected to
have user configurable network infrastructure such as DHCP, DNS and other administered
network services. This is because typical zeroconf network users neither have the skill
nor the desire to configure, administer or manage a network [1]. The IETF Zeroconf
Requirements draft [1] presents the zeroconf protocol requirements for 4 areas: IP host
configuration, domain name to IP address resolution, IP multicast address allocation, and
service discovery. This draft builds on [1] and lists the zeroconf protocol requirements
for IP router configuration and dynamic routing protocol in multi-router zeroconf
networks. The IETF Zeroconf Requirements draft [1] presents the zeroconf protocol
requirements for 4 areas: IP host configuration, domain name to IP address resolution, IP
multicast address allocation, and service discovery. The most complex network topology
addressed by the Zeroconf Requirements document [1] is a multi-segment zeroconf network
connected by a single router. This drafts builds on that draft and lists the zeroconf
protocol requirements for IP router configuration and dynamic routing protocols in
multi-router zeroconf networks.
S. Ostermann and M. Allman, "FTP Extensions
for Variable Protocol Specification," Internet Engineering Task Force, Aug. 1997.
Abstract: The specification for the File Transfer Protocol assumes that the
underlying network protocols use a 32-bit network address and a 16-bit transport address
(specifically IP version 4 and TCP). With the deployment of version 6 of the Internet
Protocol, network addresses will no longer be 32-bits. This paper specifies extensions to
FTP that will allow the protocol to work over a variety of network and transport
protocols.
H. Alvestrand, "IETF
Policy on Character Sets and Languages," Internet Engineering Task Force, Oct.
1997.
Abstract: The Internet is international. With the international Internet follows
an absolute requirement to interchange data in a multiplicity of languages, which in turn
utilize a bewildering number of characters. This document is (INTENDED TO BE) the current
policies being applied by the Internet Engineering Steering Group towards the
standardization efforts in the Internet Engineering Task Force in order to help Internet
protocols fulfil these requirements. The document is very much based upon the
recommendations of the IAB Character Set Workshop of February 29-March 1, 1996, which is
documented in RFC 2130 [WR]. This document attempts to be concise, explicit and clear;
people wanting more background are encouraged to read RFC 2130. The document uses the
terms 'MUST', 'SHOULD' and 'MAY', and their negatives, in the way described in [RFC 2119].
In this case, 'the specification' as used by RFC 2119 refers to the processing of
protocols being submitted to the IETF standards process.
C. Weider, T. Howes, C. Apple and M. Wahl, "A Minimum
LDAPv3 White Pages Schema," Internet Engineering Task Force, Dec. 1997.
Abstract: Many different white pages schema proposals have been published for
use in LDAPv3 as well as other directory service protocols. While these proposals define
schema elements that are indeed useful in the deployment of LDAPv3-based directory
services, there are a few problems common to the set of such proposals currently available
to implementors: inconsistent semantic and syntactic definitions of similar attributes
across schema, little or no semantic extensibility of attribute definitions without
changing source code for deployed implementations, lack of standard object class
definitions for containing white pages meta schema elements, and lack of an attribute
grouping method. This document defines an object class for holding IWPS attributes as
mapped into existing and relatively few newly defined extensible attribute types.
G. Armitage, "Security
issues for ION protocols," Internet Engineering Task Force, Oct. 1997.
Abstract: This document aims to assist people attempting to understand the
security limitations of existing ION working group protocols RFC 2022 (MARS), and RFC xxxx
(NHRP). As RFC 2022 and RFC xxxx share their basic control message protocol(s), this
document also identifies common areas amenable to improvement using additional security
TLVs.
T. Arnold and J. Eaton, "Simple Commerce
Messaging Protocol (SCMP)Version 1 Message Specification," Internet Engineering
Task Force, Jun. 2000.
Abstract: The Simple Commerce Messaging Protocol (SCMP) is a general-purpose
electronic commerce message protocol for secure, real-time communication of a set of data
from a sending agent's application to a receiving agent's server. Additionally the
response by the receiving agent's server to the sending agent is the reply from the
request represented by the set of data in the message's payload. The intent of this
protocol is to define a method where trading partners can perform on-line business
requests in an environment where the sending partner is fully authenticated, and the
message cannot be repudiated. The taxonomy of the SCMP message payload is not in the scope
of this document. The SCMP protocol does not specify payload definitions or how trading
partners are expected to process the payload, beyond basic server-level functions related
to processing SCMP headers. This intent is to permit trading partners the flexibility to
implement either a standard commerce message format as in ANSI-X12 Electronic Data
Interchange (EDI) or some other non-standard payload format. This document does give an
example implementation of a payload format based on [XML]. The only requirement on the
message payload is that it be prepared as specified in [MIME]. In this manner, SCMP
fundamentally differs from many emerging commerce message protocols. Beyond specifying the
method for encryption, authentication and handling, these other protocols specify the
contents of the message and details how a server is to process and respond to a given
message payload.
A. Arsenault and S. Farrell, "Securely
Available Credentials - Requirements," Internet Engineering Task Force, Sep.
2000.
Abstract: This document describes requirements to be placed on Securely
Available Credentials (sacred) protocols. This is the initial draft of the sacred
requirements specification and is therefore highly likely to change substantially.
Discussion of this draft is taking place on the sacred list (see
http://www.imc.org/ietf-sacred for subscription information).
S. Ayandeh and Y. Fan, "MPLS Routing
Dynamics," Internet Engineering Task Force, Mar. 1998.
Abstract: This Internet draft outlines how transients in protocols such as OSPF
[7] (intra-domain routing) and MPLS LDP [2] can lead to periods of time with loops and
other undesirable routing phenomenon. It defines a set of metrics to quantify this dynamic
behavior. Quantification of these metrics, using a simulation model, for various local vs.
egress label allocation schemes is used as the basis of a comparative analysis. This
includes quantifying any incremental impact that MPLS may have once it is introduced into
an autonomous IP routing area. The resulting insights would help develop a better
understanding of routing dynamics. This includes identifying key nodal and network
variables which impact routing dynamics hence guiding MPLS feature selection and IP
network design.
M. Bakke and J. Muchow, "Definitions of
Managed Objects for SCSI over TCP," Internet Engineering Task Force, Aug. 2000.
Abstract: 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 a client using the SCS over TCP (aka iSCSI) protocol.
S. Bakker, "AAA
Considerations for Middleware," Internet Engineering Task Force, Jun. 1999.
Abstract: The IETF AAA Working Group is currently looking at defining the
requirements for Authentication, Authorization and Accounting. Various documents have
already been written that outline AAA requirements for various services and protocols.
This document falls into that category, as it outlines some ideas for middleware that have
specific AAA requirements.
T. Nishida and A. Bakre, "IP Multicast over
ATM Networks with Cut-through Forwarding for Inter LIS Traffic," Internet
Engineering Task Force, Dec. 1997.
Abstract: This document proposes a scheme for IP multicasting in ATM networks,
which can achieve cut-through forwarding for inter LIS multicast traffic using ATM
protocols.
O. Aboul-Magd and others, "Signaling
Requirements at the Optical UNI," Internet Engineering Task Force, Jul. 2000.
Abstract: This draft considers the optical network service model referred to as
the 'domain services' model [1]. Under this model, the optical network provides a set of
well-defined services to clients (IP and others). The signaling and routing interface
between the client and optical networks is referred to as the User-Network Interface
(UNI). This draft describes the services provided over the UNI, and the requirements on
any signaling protocol used to invoke the services. This draft reflects ongoing work at
the Optical Interworking Forum (OIF) and the Optical Domain Service Interconnect (ODSI)
coalition on the optical UNI [2]. The relevance of this draft to the IETF is two-fold.
First, for the signaling portion of the optical UNI, extensions of two MPLS signaling
protocols are presently under consideration in the OIF: RSVP with TE extensions and LDP.
The objective of this draft is to guide the adaptation of these protocols for UNI
signaling. Second, to harmonize the signaling of UNI originated lightpath requests and
peer model lightpath establishment mechanisms [1], alignment between OIF, ODSI and IETF
lightpath parameters and signaling functionality is desirable. This draft aims to serve
this purpose. The content of this draft is expected to evolve as work progresses on the
optical UNI.
H. Balakrishnan and S. Seshan, "The Congestion
Manager," Internet Engineering Task Force, Mar. 2000.
Abstract: This document describes the Congestion Manager (CM), an end-system
module that (i) enables an ensemble of multiple concurrent flows from a sender destined to
the same receiver and sharing the same congestion properties to perform proper congestion
avoidance and control, and (ii) allows applications to easily adapt to network congestion.
This CM framework integrates congestion management across all applications and transport
protocols. The CM maintains congestion parameters (available aggregate and per-flow
bandwidth, per-receiver round-trip times, etc.) and exports an API that enables
applications to learn about network characteristics, pass information to the CM, share
congestion information with each other, and schedule data transmissions. This document
focuses on applications and transport protocols with their own independent per-byte or
per-packet sequence number information, and does not require modifications to the receiver
protocol stack. The receiving application must provide feedback to the sending application
about received packets and losses, and the latter uses the CM API to update CM state. This
document does not address networks with reservations or service discrimination.
B. Baldwin, A. Wilson, S. Nishimura and M. Yurovitsky, "BSAFE CRYPTOGRAPHIC
SECURITY COMPONENTS," Internet Engineering Task Force, May 1999.
Abstract: This Internet-Draft describes protocols, procedures, and conventions
to be employed by peers implementing a generic cryptographic application program
interface. Version 4.0 of this API was implemented inside RSA Data Security, Inc.'s BSAFE
product. The API provides a model for implementing symmetric ciphers, message digests,
message authentication, random number generation, public-key algorithms, digital
signatures, and secret sharing. The API is documented here for the benefit of others who
might also adopt and use the API, thus providing increased portability of security
applications.
A. Banerjea, M. Faloutsos and R. Pankaj, "Designing QoSMIC:
A Quality of Service sensitive Multicast Internet protoCol,"  Internet Engineering Task
Force, May 1998.
Abstract: We present, QoSMIC, a multicast protocol for the Internet that
supports QoS-sensitive routing, and minimizes the importance of a priori configuration
decisions (such as core selection). The protocol is resource-efficient, robust, flexible,
and scalable. In addition, our protocol is provably loop-free. Our protocol starts with a
resources-saving tree (Shared Tree) and individual receivers switch to a QoS-competitive
tree (Source-Based Tree) when necessary. In both trees, the new destination is able to
choose the most promising among several paths. An innovation is that we use dynamic
routing information without relying on a link state exchange protocol to provide it. Our
protocol limits the effect of pre- configuration decisions drastically, by separating the
management from the data transfer functions; administrative routers are not necessarily
part of the tree. This separation increases the robustness, and flexibility of the
protocol. Furthermore, QoSMIC is able to adapt dynamically to the conditions of the
network. The QoSMIC protocol introduces several new ideas that make it more flexible than
other protocols proposed to date. In fact, many of the other protocols, (such as YAM,
PIM-SM, BGMP, CBT) can be seen as special cases of QoSMIC. The goal of this document is to
present the motivation behind, and the design of QoSMIC, and to provide both analytical
and experimental results to support our claims. NOTE: The text version of the draft is
missing several figures, that facilitate the understanding of the work. For this, the
authors suggest the postscript version.
D. Basak, D. Awduche, J. Drake and Y. Rekhter, "Multi-protocol
Lambda Switching: Issues in Combining MPLS Traffic Engineering Control With Optical
Cross-connects," Internet Engineering Task Force, Feb. 2000.
Abstract: This document describes the domain specific enhancements required to
adapt MPLS traffic engineering control plane constructs to control optical cross-connects
in emerging automatically switched optical transport networks. These enhancements are
within the framework of Multiprotocol LAMBDA switching proposed in [1]. Specifically, this
memo investigates the behavior of the MPLS based control plane technique for OXCs, and
identifies required enhancements to both OXCs and to existing MPLS traffic engineering
control plane objects (routing and signaling protocols) to support the application to
OXCs.
J. Beck, "ResCap
Requirements," Internet Engineering Task Force, Jun. 1999.
Abstract: A variety of resource identifiers have been widely deployed on the
Internet as a means of identifying various resources, services, and destinations. However,
a means of attaching a set of attributes or characteristics to a given resource identifier
and subsequently assessing those attributes or characteristics has not been specified and
deployed. A particularly important resolution service of this general type is one which,
when given a mail address identifying a particular mail recipient, will return a series of
attributes describing the capabilities of that recipient. This differs from a directory
service in that no searching or other advanced query operations are involved. Two tasks
are envisioned. The first task will be to define a general resolution protocol that will
translate resource identifiers to a list of attributes. The second task will be to define
an administrative model and update protocol that can be used to set up and maintain the
information the resolution protocol accesses. This document defines the requirements for
these two protocols.
K. McCloghrie, P. Langille, A. Rijsinghani, A. Smith and L. Bell, "Definitions of
Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN
Extensions," Internet Engineering Task Force, Mar. 1998.
Abstract: 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 MAC bridges based on the IEEE 802.1D-1998 MAC Bridges and
IEEE 802.1Q-1998 Virtual LAN (VLAN) standards for bridging between Local Area Network
(LAN) segments. 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 several MIB modules in a manner that is compliant to the
SNMP SMI [3].
B. Bell, "IPDC Device
Management Protocol," Internet Engineering Task Force, Aug. 1998.
Abstract: The protocol described in this document is a member of the IP Device
Control (IPDC) family of protocols. The IPDC protocols are proposed as a protocol suite,
components of which can be used individually or together to perform connection control,
media control, and signaling transport for environments where the service control logic is
separated from the network access server. Please see the references section for other IPDC
documents. The protocol specification presented here is intended for use between a media
gateway controller and a media gateway. The media gateway may be capable of acting as a
voice over IP gateway, voice over ATM gateway, dialup modem media gateway, circuit switch,
or cross- connect. Using the IP Device Signaling Transport protocol presented here, the
media gateway can receive a signaling from a circuit switched network and deliver the
signaling to a media gateway controller on an intervening IP network. The media gateway
controller can also send signaling to a media gateway for delivery on a circuit switched
network.
S. Bellovin and R. Moskowitz, "Client
Certificate and Key Retrieval for IKE," Internet Engineering Task Force, Feb.
2000.
Abstract: (Insert justification, possibly copied wholesale from section 1.1 and
maybe 2.1/2.2 of draft-kelly-ipsra-userauth-00.txt) We consider inadvisable to change IKE
[RFC2409] to meet these needs. IKE is a complex protocol; adding more features to it is a
bad idea. Instead, we propose a layered approach: use standard IKE, with certificates, but
provide a simple mechanism to provide clients with keys and certificates. A number of
objections have been raised to using certificates. The most important is that we lack a
public key infrastructure (PKI). We do not agree that this is an obstacle. Our proposal
provides a simple mechanism for certificate generation and retrieval, while still relying
on legacy authentication infrastructures. Furthermore, we provide for an easy migration
path to certificate use once organizational PKIs are deployed. Our purpose at this point
is not to present a firm protocol. Rather, we sketch several ideas for what such a
protocol could look like. Final details can be determined if and when the working group
opts for this path. In the interests of simplicity, we have chosen to reuse standard
protocols and components. In particular, we use HTTP [RFC2616] for transport, HTML
[RFC1866] as a data representation and TLS [RFC2246] for confidentiality. However, we do
not mandate (or even necessarily encourage) use of a actual Web browser for certificate
retrieval. As an alternative, we present a transient shared secret generation mechanism
for IKE.
L. Berger and J. Jeffords, "MPLS/IP
Header Compression over PPP," Internet Engineering Task Force, Mar. 2000.
Abstract: This document describes an option for negotiating the use of MPLS and
IP header compression over the Point-to-Point Protocol [STD51]. It defines extensions to
the PPP Control Protocol for MPLS [LABELS]. It is based on, and borrows heavily from, IP
Header Compression over PPP [RFC2509]. MPLS/IP header compression is defined in [CMPLS]
and may be applied to MPLS datagrams transporting IPv4 and IPv6 datagrams in combination
with TCP, UDP and RTP transport protocols
L. Berger and T. O'Malley, "RSVP Extensions
for IPSEC Data Flows," Internet Engineering Task Force, Aug. 1997.
Abstract: This document presents extensions to Version 1 of RSVP. These
extensions permit support of individual data flows using RFC 1826 IP Authentication Header
(AH) or RFC 1827 IP Encapsulating Security Payload (ESP). RSVP Version 1 as currently
specified can support the IPSEC protocols, but only on a per address, per protocol basis
not on a per flow basis. The presented extensions can be used with both IPv4 and IPv6.
Y. Bernet, D. Durham and F. Reichmeyer, "Requirements of
Diff-serv Boundary Routers," Internet Engineering Task Force, Nov. 1998.
Abstract: This draft discusses requirements of routers that serve as
ingress/egress points to/from differentiated services (diff-serv) networks. We discuss the
traffic conditioning components required and associated configuration mechanisms and
protocols. We also discuss admission control to diff-serv networks in support of signaled
QoS.
G. Bernstein and V. Sharma, "Some
Comments on GMPLS and Optical Technologies," Internet Engineering Task Force,
Nov. 2000.
Abstract: GMPLS [2] is being considered as an extension to the MPLS framework to
include optical, non-packet switched technologies. This draft reviews the motivation for
doing so from an end-userĘs perspective and points out some key requirements/impacts that
this will have on the extensions to the routing and label distribution/signaling
protocols.
B. Beser, "Codec
Capabilities Attribute for SDP," Internet Engineering Task Force, Mar. 2000.
Abstract: The need for assured communication arisen protocols like RSVP [2] and
SBM [3] which are linked to access technologies to guarantee the delay and drop
probabilities of a given IP flow. One of the side-effects of the assurance is that when
the bandwidth of the IP flow goes outside the contracted region then the IP flow will be
disturbed and the communication will be effected. This document discusses the effects of
assured communication to SDP protocol, identifies the weaknesses and proposes a new
attribute to rectify these weaknesses.
S. Bhattacharyya and others, "A Framework for
Source-Specific IP Multicast Deployment," Internet Engineering Task Force, Jul.
2000.
Abstract: This document provides an overview of the Source-Specific Multicast
(SSM) service model which supports source-based multicast trees across multiple domains in
the Internet. SSM realizes components of the EXPRESS [HOLB99] multicast service model in
which there is a single source for every multicast channel, and channel membership is
based on the unique combination of multicast group address (G) as well as the source's
unicast address (S). End-hosts use version 3 of the IGMP protocol (IGMPv3) to register
their interest in a particular source-group (S,G) pair. The PIM-SM protocol is then used
to construct the multicast forwarding tree rooted at the source S. This document is
intended as a starting point for implementing and deploying SSM services. It provides a
brief architectural overview of SSM described in more detail in [HOLBOO] and describes
associated deployment challenges. It summarizes changes to protocols and applications both
at end-hosts and routers, with pointers to more detailed documents, wherever appropriate.
Issues of interoperability with the current multicast architecture are also discussed.
A. Bierman, "Remote
Monitoring MIB Extensions for Differentiated Services Enabled Networks," Internet
Engineering Task Force, Jun. 1999.
Abstract: This memo defines an experimental 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 monitoring Differentiated
Services Codepoint usage in IP packets, utilizing the monitoring framework defined in the
RMON-2 MIB [RFC2021].
K. McCloghrie and A. Bierman, "Entity MIB
Extesions for Persistent Component Identification," Internet Engineering Task
Force, Aug. 1997.
Abstract: This memo defines an experimental 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 physical topology
identification and discovery.
A. Bierman, "Application
Performance Measurement Capabilities MIB," Internet Engineering Task Force, Mar.
2000.
Abstract: 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 classifying and characterizing the application
performance measurement (APM) capabilities of various standard and proprietary APM
techniques.
A. Bierman, "Remote
Monitoring MIB Extensions for Virtual Data Sources," Internet Engineering Task
Force, Jul. 2000.
Abstract: 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 defining virtual data monitoring sources for use with
existing RMON MIBs.
M. Blaze, J. Feigenbaum, J. Ioannidis and A. Keromytis, "The
KeyNote Trust-Management System," Internet Engineering Task Force, Apr. 1999.
Abstract: this memo describes version 2 of the KeyNote trust-management system.
It specifies the syntax and semantics of KeyNote `assertions,' describes `action
attribute' processing, and outlines the application architecture into which a KeyNote
implementation can be fit. The KeyNote architecture and language are useful as building
blocks for the trust management aspects of a variety of Internet protocols and services.
M. Borella, D. Grabelsky, I. Sidhu and B. Petry, "Distributed
Network Address Translation," Internet Engineering Task Force, Oct. 1998.
Abstract: NAT (Network Address Translation) has been proposed to extend the
lifetime of IPv4 by allowing one or more subnets to exist behind a single IP address. It
is desirable to support dozens, if not hundreds, of nodes on a NAT subnet. As it is
currently defined, NAT may not gracefully scale beyond networks containing a few dozen
nodes. In particular, the computational burden placed on the NAT router may be
significant, especially if the router is shared by several NAT-enabled subnets.
Additionally, NAT requires that support for many protocols be specifically programmed into
the translation mechanism. In this document, we introduce DNAT (Distributed Network
Address Translation), an alternative to NAT. In particular, DNAT will eliminate all
address and port translation at the router, providing an application independent mechanism
for sharing an IP address amongst many hosts while providing end-to-end connectivity.
C. Bormann, "Network News
Distribution Protocol: Architecture and Design Guidelines," Internet Engineering
Task Force, Mar. 1998.
Abstract: This document describes an architecture and a set of protocols for
distributing Netnews [RFC0977, RFC1036] via IP multicast enabled networks. The
architecture is designed to be useful in the global Internet. In particular, it allows
multiple news servers to cooperate on multicasting each new article only once. To
facilitate scalability to tens of thousands of news servers, it also provides for
receive-only multicast participants (that continue to send articles via conventional
NNTP). This document is a submission to the IETF MNNP working group. Comments are
solicited and should be addressed to the working groups' mailing list at
ietf-mnnp@va.pubnix.com and/or the author.}
C. Bormann, J. Ott and N. Seifert, "MTP/SO:
Self-Organizing Multicast," Internet Engineering Task Force, Jul. 1999.
Abstract: MTP/SO is a reliable multicast protocol based on the earlier protocols
MTP (RFC1301) and MTP-2, simplifying the protocol considerably while adding
self-organization of the members of the group into a hierarchy of local regions, local
retransmissions, local NAK damping, and both global and local forward error correction.
MTP/SO retains the coordinated many-to-many multicast model of MTP-2 while improving
scalability.
J. Bouwen, B. Van Doorselaer and M. Dekeyser, "Issues for
Megaco - Sigtran Interworking in ISDN Access Gateways," Internet Engineering Task
Force, Jul. 2000.
Abstract: This document introduces the concept of an ISDN access gateway in the
context of Megaco/H.248 and Sigtran protocols. For these ISDN access gateways, the ISDN B
channels may be controlled by the Media Gateway Controller using megaco/H.248 while the
User-to-Network signaling running over the D channels may be relayed to the Media Gateway
Controller using either megaco/H.248 or the Sigtran protocols. The main issues involved
are: * Megaco/H.248 and Sigtran protocols may interwork in different ways in ISDN access
gateways, leaving room for non - interoperable solutions; * Megaco needs additional
packages in order to support ISDN terminations in the ISDN access gateway; * A data
service may be offered to ISDN users via the ISDN D- channel, introducing the need to
introduce a NAS package for the D-channel. This document addresses these issues, proposes
and explains different solutions and suggests best practice guideline for megaco / sigtran
interworking in ISDN access gateways.
S. Bradner, "OSI connectionless
transport services on top of UDP Applicability Statement for Historic Status,"
Internet Engineering Task Force, Jan. 1999.
Abstract: RFC 1240, 'OSI connectionless transport services on top of UDP', was
published as a Proposed Standard in June 1991 but at this time there do not seem to be any
implementations which follow RFC 1240. In addition there is a growing concern over using
UDP-based transport protocols in environments where congestion is a possibility.
A. Farrel, P. Brittain and P. Matthews, "Fault
Tolerance for LDP and CR-LDP," Internet Engineering Task Force, Jul. 2000.
Abstract: MPLS systems will be used in core networks where system downtime must
be kept to an absolute minimum. Many MPLS LSRs may, therefore, exploit fault tolerant (FT)
hardware or software to provide high availability of the core networks. The details of how
FT is achieved for the various components of an FT LSR, including LDP, CR-LDP, the
switching hardware and TCP, are implementation specific. This document identifies issues
in the CR-LDP specification [2] and the LDP specification [4] that make it difficult to
implement an FT LSR using the current LDP and CR-LDP protocols, and proposes enhancements
to the LDP specification to ease such FT LSR implementations. The extensions described
here are equally applicable to CR-LDP.
N. Brown and C. Kindel, "Distributed
Component Object Model Protocol -- DCOM/1.0," Internet Engineering Task Force,
Mar. 1998.
Abstract: The Distributed Component Object Model protocol is an
application-level protocol for object-oriented remote procedure calls useful for
distributed, component-based systems of all types. It is a generic protocol layered on the
distributed computing environment (DCE) RPC specification and facilitates the construction
of task-specific communication protocols through features such as: a platform neutral
argument/parameter marshaling format (NDR), the ability for objects to support multiple
interfaces with a safe, interface- level versioning scheme suited to independent evolution
by multiple parties, the ability to make authenticated connections and to choose levels of
channel security, and a transport-neutral data representation for references (including
by-value) to objects.
A. Brusilovsky, E. Gausmann, V. Gurbani and A. Jain, "A Proposal for
Internet Call Waiting Service using SIP An Implementation Report," Internet
Engineering Task Force, Jan. 1999.
Abstract: The purpose of this Internet Draft is to start discussion on the
issues involved in Internet Call Waiting Service (ICW), as part of interconnecting IP and
Global Switched Telephone Network (GSTN) with the intent of providing ICW service that is
much needed by numerous dial-up Internet users. Interworking of the IP network and GSTN,
based on open well-defined protocols, will promote interoperability of both the networks
and systems built by different vendors. This Internet Draft is submitted with the goal of
becoming an informational RFC. The rest of this document is as follows: Section 2 briefly
describes the services offered to the end Subscriber. It is the support of these services
that necessitates the proposed internetworking project. Section 3 describes the scope of
the proposed project by introducing its overall architecture, identifying the interfaces
to be standardized, describing experience with SIP for ICW. Sections 4, 5, and 6
respectively address security considerations, supply references, and provide the authors
address, as required by [1]. Section 7 acknowledges individuals providing assistance in
the creation of this document. Section 8 is the Appendix, which contains IN Tutorial and
Figure A.
A. Brusilovsky, V. Gurbani, A. Jain and D. Varney, "Need for PSTN
Internet Notification (PIN) ServiceA Proposal for a new Working Groups," Internet
Engineering Task Force, Feb. 1999.
Abstract: The purpose of this Internet Draft is to start discussion on the
issues involved in PSTN Internet Notification (PIN), as part of interconnecting IP and
Public Switched Telephone Network (PSTN) with the intent of converging existing and
creating new hybrid PSTN and IP services. PSTN Events Notification, based on open
well-defined protocols, will promote interoperability of both the networks and systems
built by different vendors. This Internet Draft is submitted with the goal of becoming an
informational RFC. The rest of this document is as follows: Section 2 briefly describes
the PIN services. Section 3 describes the scope of the proposed project by introducing its
overall architecture and identifying the interfaces to be standardized. Sections 4, 5, and
6 respectively address security considerations, supply references, and provide the authors
address, as required by [1]. Section 7 acknowledges individuals providing assistance in
the creation of this document.
A. Brusilovsky, J. Buller, L. Conroy, V. Gurbani and L. Slutsman, "PSTN
Internet Notification (PIN) Architecture, Services and Protocols (A Provisional Framework),"
Internet Engineering Task Force, Jun. 1999.
Abstract: The purpose of this Internet Draft is to continue discussion on the
issues involved in PSTN Internet Notification (PIN), as part of interconnecting IP and
Public Switched Telephone Network (PSTN) with the intent of converging existing and
creating new hybrid PSTN and IP services. PSTN initiated Service Requests, based on open
well-defined protocols, will promote interoperability of both the networks and systems
built by different vendors. This Internet Draft is submitted with the goal of becoming an
Informational RFC.
b. Buffam, B. Thompson and T. Koren, "IP/UDP/RTP
Header Compression over AAL2," Internet Engineering Task Force, Jul. 2000.
Abstract: This document describes a method to carry compressed and uncompressed
traffic over AAL2. This proposal uses AAL2 frame mode SSCS to carry uncompressed protocols
directly. The proposal also includes a new SSCS for carriage of compressed protocols over
AAL2 frame mode to improve the bandwidth efficiency of RTP streams over an ATM network
using compression and multiplexing. This proposal advocates the use of compressed RTP and
multiplexing over ATM Adaptation Layer Type 2 (AAL2) frame mode. RTP traffic is first
compressed, the resulting CRTP stream is then processed by the AAL2 CRTP Service Specific
Convergence Sub-layer (AAL2 CRTP SSCS), to be multiplexed onto an AAL2 CPS-PDU frame mode
stream. The resulting multiplexed stream is carried end-to-end through an ATM network and
then mapped in reverse back into CRTP at the far end to be presented to the upper layer
IP/UDP/RTP protocol stack.
H. Basilier, P. Calhoun, M. Holdrege, T. Johansson and J. Kempf, "AAA
Requirements for IP Telephony/Multimedia," Internet Engineering Task Force, Jul.
2000.
Abstract: The AAA Working Group has been defining requirements for Network
Access in an Inter-Domain (roaming) network, both Mobile IP and NASREQ. Some of these
requirements were input from work done in the 3rd Generation wireless SDOs. These same
SDO's have a need to tie their IP Intelligent Servers (e.g. Softswitches, Call Agents, SIP
Servers, etc.) to their AAA infrastructure. This specification defines some requirements
for both the AAA and IP Telephony protocols (SIP, MEGACO, etc.) This first Internet Draft
is intended to simulate discussions within the SIP Working Group, in order to come up with
a set of requirements that could then be used to begin protocol design.
M. Calsyn, L. Dusseault and G. Mohr, "RVP: A Presence
Notification Protocol," Internet Engineering Task Force, Mar. 1998.
Abstract: A new kind of application is emerging on the Internet, driven by the
desire of individuals to know instantly whether another individual is online, to be
notified when another individual arrives online, and to send messages in \021real
time\022. These are all special cases of the more general problem of Internet-wide
notification. This protocol for facilitating rendezvous between users, known herein as
RVP, is designed to enable such notifications and messages across a loosely coupled
(federated) constellation of servers. RVP is designed to address the need for notification
in a secure, reliable and scaleable fashion. RVP encompasses the client-server and
server-server interactions. The authors recognize that there is significant overlap with
between RVP and HTTP, though there are also significant differences. We expect RVP to
evolve and either converge or diverge with HTTP and/or other existing protocols. The
protocol described in this document represents a very viable starting point for a
discussion of a standardized solution to the problem. Comments on this draft are solicited
and should be sent to the authors or the RVP discussion list. To join the RVP discussion
list, send email with the body 'subscribe' to rvp- request@iastate.edu
G. Camarillo and A. Roach, "Best
Current Practice for ISUP to SIP mapping," Internet Engineering Task Force, Mar.
2000.
Abstract: This document describes a way to perform the mapping between two
signalling protocols: SIP and ISUP.
K. Carlberg and I. Brown, "Framework
for Supporting IEPS in IP Telephony," Internet Engineering Task Force, Nov. 2000.
Abstract: This document presents a framework for supporting authorized
emergency-related communication within the context of IP telephony. We present a series of
objectives that reflect a general view of how authorized emergency service, in line with
International Emergency Preparedness Scheme (IEPS), should be realized within today's IP
architecture and service models. From these objectives, we present a corresponding set of
functional requirements, which provide a more specific set of recommendations regarding
existing IETF protocols. Finally, we present two scenarios that act as guiding models for
the objectives and functions listed in this document. These, models, coupled with an
example of an existing service in the PSTN, contribute to a constrained solution space.
A. Casati and C. Perkins, "Generic Tunneling
Protocol (GTP)," Internet Engineering Task Force, Mar. 2000.
Abstract: Some discussion has been lately going on on the standardization of GRE
within the IETF. GRE has an Impact on standard track protocols such as Mobile IP. A
Generic Tunneling Protocol (GTP) sharing the same format and byte order of the 3GPP GTP
protocol ( 3G TS 29.060) benefits from the commonality of the encapsulation format used in
IP mobility support protocols in different families of 3G standards.
D. Chadwick, "Internet
X.509 Public Key Infrastructure Operational Protocols - LDAPv3," Internet
Engineering Task Force, Jun. 1999.
Abstract: This document describes the features of the Lightweight Directory
Access Protocol v3 that are needed in order to support a public key infrastructure based
on X.509 certificates and CRLs.
S. Chisholm, "Alarm
MIB," Internet Engineering Task Force, Oct. 2000.
Abstract: 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 management objects used for maintaining a list of alarms currently active on a
network element.
S. Christey, "The Infinite Monkey
Protocol Suite (IMPS)," Internet Engineering Task Force, Mar. 2000.
Abstract: This draft describes a protocol suite which supports an infinite
number of monkeys that sit at an infinite number of typewriters in order to determine when
they have either produced the entire works of William Shakespeare or a good television
show. The suite includes communications and control protocols for monkeys and the
organizations that interact with them.
P. Cordell, "Conversational
Multimedia URLs," Internet Engineering Task Force, Dec. 1997.
Abstract: The evolving technologies for real-time conversation over the Internet
require URLs to provide user contact information. As there are many protocols (including
some that are not Internet based) that can be used for inter-user conversation, this
document describes a two stage transaction process for obtaining a URL that can be used to
initiate conversation. The first stage involves retrieving a list of protocol specific
URLs in a MIME encoded file. The MIME type enables an appropriate application to be
launched which will analyse the presented URLs and select the most appropriate one. The
second stage involves interpreting the protocol specific URL and initiating the
conversation. The protocol specific URLs are encoded in a URL form so that they can be
embedded directly into HTML pages. This allows the first stage to be omitted. The document
describes the format of the MIME encoded list of URLs, and the format of a number of
protocol specific URLs.
D. Cromwell and M. Durling, "Requirements
For Control Of A Media Services Function," Internet Engineering Task Force, Nov.
1998.
Abstract: This document describes the functional requirements for protocol used
by a call processing agent in a packet network to control an media services function
located in the same packet network or at the inter- face of the packet network and the
traditional telephone network. The primary focus of the protocol is on audio, however the
protocol could be extended in the future to support other media streams such as video. The
protocol provides the standard audio operations of play audio, collect DTMF, and record
speech. It supports direct references to simple audio as well as indirect references to
simple and complex audio. It provides multi-language audio variables, interruptibility of
audio, digit buffer control, special key sequences, and support for reprompting during
data collection. The approach used in specifying protocol functionality was to look at
several existing protocols currently in use in the telephone network, taking the best
concepts from each and attempting to avoid any limi- tations. The following protocols were
examined: ITU CS1-R [2], Nor- tel Extended CS1-R [3], Bellcore GR-1129 [4], and Bellcore
SR-3511 [5]. The protocol described in this document provides at a minimum a superset of
the functionality of these protocols.
J. Crowcroft, H. Fuchs, T. Turletti, A. Ghosh, Z. Wang, L. Vicisano and C. Diot, "RMFP: A Reliable
Multicast Framing Protocol," Internet Engineering Task Force, Mar. 1998.
Abstract: There has been considerable interest in reliable multicast, and a
number of reliable multicast transport applications and systems have been built in the
past years, e.g. [PGM], [RMDP], [RMTP], [SRM]. A survey of most of current reliable
multicast protocols is available in [Diot97].
J. Crowcroft, "RTCP
location reports," Internet Engineering Task Force, Feb. 1999.
Abstract: This note is a proposal to add lat/long data to RTCP reports to enable
transport protocols, and applications to carry out a number of useful tasks.
C. Sapuntzakis and D. Cheriton, "TCP RDMA option,"
Internet Engineering Task Force, Feb. 2000.
Abstract: The TCP option introduced in this draft reduces the overhead of
receiving data with TCP-based protocols such as NFS and HTTP. It enables the construction
of a simple hardware accelerator that copies data directly from the incoming packet into
application buffers, avoiding expensive copies in the protocol stack. Even without
hardware acceleration, the option enables the protocol stack to decrease the number of
copies it must do.
J. Cucchiara, J. Luciani and H. Sjostrand, "Definitions
of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol
(LDP)," Internet Engineering Task Force, Aug. 1998.
Abstract: This memo defines an experimental 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 Multiprotocol Label
Switching, Label Distribution Protocol (LDP) as defined in [17]. This memo does not
specify a standard for the Internet community.
L. Daigle and R. Hedberg, "Technical
Infrastructure for Swedish Directory Access Gateways (TISDAG)," Internet
Engineering Task Force, Jun. 2000.
Abstract: The strength of the TISDAG project's DAG proposal is that it defines
the necessary technical infrastructure to provide a single-access-point service for
information on Swedish Internet users. The resulting service will provide uniform access
for all information - the same level of access to information (7x24 service), and the same
information made available, irrespective of the service provider responsible for
maintaining that information, their directory service protocols, or the end- user's client
access protocol.
M. Daniele, "IANA Address
MIB," Internet Engineering Task Force, Sep. 1998.
Abstract: This document contains an initial version of a MIB module for commonly
used network addressing information. It defines a registry for identifiers that identify
protocols and a set of textual conventions for representing addresses. This document also
establishes IANA as the maintainer of this registry.
M. Day and D. Gilletti, "Content
Distribution Network Peering Scenarios," Internet Engineering Task Force, Nov.
2000.
Abstract: This document sets forth several logical and detailed scenarios to be
considered when evaluating systems and protocols for CDN peering.
M. Day, "''HTTP
Envy'' and Presence Information Protocols," Internet Engineering Task Force, Mar.
1998.
Abstract: There are a variety of proposals [Calsyn, Mohr] for building a
presence information protocol as a variant or version of HTTP. This document summarizes
why I believe that is not a good idea.
T. Hasting, F. Wright, H. Lewis, S. Isaacson, R. deBry, C. Kugler and S. Gebert, "The Use of
Post: A Response to draft-cohen-http-postal-00.txt," Internet Engineering Task
Force, Feb. 1998.
Abstract: A recent Internet Draft [1] argues that the common use of POST to
proide a uniform method of passing blocks of data to an application, is being misused in
the definition of new application protocols, such as the Internet Printing Protocol. Cohen
et. al. argue that a new PUSH method be defined for this purpose. This Internet Draft
argues that the existing POST method proides all of the required functionality for back
end applications, such as Print, without sacrificing the leels of security that customers
expect. More importantly, from the customer\022s point of iew, it does this without any
impact to existing, installed network components.
N. Demizu, H. Esaki, K. Nagami and P. Doolan, "Virtual
Connection Identifier," Internet Engineering Task Force, Oct. 1997.
Abstract: Several label switching schemes have been proposed to fuse and
integrate the cost-performance and QoS assurance of Layer 2 devices and the flexibility
and functionality of Layer 3 protocols. Some of these proposals assume that Label
Switching Routers (LSRs) are placed in a homogeneous LSR cloud in a campus area network or
a backbone network, and they are connected directly to each other. However, this
assumption sometimes does not hold true in the real situation. For example, some campuses
will be connected via ATM SVC service, and LSR networks will be constructed
hierarchically. To deal with Virtual Connections (VCs) in these environments, this
document proposes to identify a VC with a VCID instead of a label.
N. Demizu and H. Izumiyama, "Dynamic Tunnel
Configuration Protocol," Internet Engineering Task Force, Dec. 1997.
Abstract: As the Internet grows, the importance of Uni-Directional Links such as
satellite links has been increasing. However, most of existing routing protocols assume
that datalinks are bi-directional. To incorporate UDLs into the Internet, an IP tunneling
approach has been proposed, where tunnels are set up as a virtual back-channel of a UDL to
carry routing information between Feeders and Receivers. Dynamic Tunnel Configuration
Protocol (DTCP) supports to setup tunnels dynamically between Feeders and Receivers in
such environments.
S. Dharanikota and S. Venkatachalam, "OSPF,
IS-IS, RSVP, CR-LDP Extensions to Support inter-Area Traffic Engineering Using MPLS TE,"
Internet Engineering Task Force, Nov. 2000.
Abstract: In this draft, we propose the extensions required to the routing
protocols, signaling protocols, and the MIB to support the idea of inter-area LSPs. A
companion document [INTER_AREA_FWK] provides the architectural requirements for such a
concept. This document also provides the signaling extensions to support the crankback as
defined in the architecture document [INTER_AREA_FWK].
R. Dietz, "Remote Monitoring
MIB Extensions or Application Performance Metrics," Internet Engineering Task
Force, Jul. 1999.
Abstract: This memo defines an experimental portion of the Management Informa-
tion Base (MIB) for use with network management protocols in the Internet community. In
particular, it describes managed objects used for monitoring selectable performance
metrics and statistics derived from the monitoring of network packets.
R. Dietz, "Transport
Performance Metrics MIB," Internet Engineering Task Force, Mar. 2000.
Abstract: This memo defines an experimental portion of the Management Informa-
tion Base (MIB) for use with network management protocols in the Internet community. In
particular, it describes managed objects used for monitoring selectable performance
metrics and statistics derived from the monitoring of network packets and transport
protocol states.
B. Dolnik, "Definitions of
Managed Objects for the Universal Serial Bus (USB) Interface," Internet
Engineering Task Force, Aug. 2000.
Abstract: 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 Universal Serial Bus (USB) interfaces.
A. Doria, T. Worster and K. Sundell, "Applicability
of GSMP as an IETF Protocol," Internet Engineering Task Force, Oct. 1998.
Abstract: This memo discusses the applicability of the General Switch Management
Protocol, GSMP, to network control protocols such as Multiprotocol Label Switching (MPLS).
It discusses the need for this protocol to be standardized and discusses areas where
development is still necessary. Finally, it recommends that the IETF establish a working
group with the objective of furthering the protocol and working toward making it a
standard. A PDF version of this draft can be found at: http://www.
apocalypse.org/~avri/draft-doria-gsmp-applicability-00.pdf
M. Duerst and M. Davis, "Character
Normalization in ITEF Protocols," Internet Engineering Task Force, Sep. 2000.
Abstract: The Universal Character Set (UCS) [ISO10646, Unicode] covers a very
wide repertoire of characters. The IETF, in [RFC 2277], requires that future IETF
protocols support UTF-8 [RFC 2279], an ASCII-compatible encoding of UCS. The wide range of
characters included in the UCS has lead to some cases of duplicate encodings. This
document proposes that in IETF protocols, the class of duplicates called canonical
equivalents be dealt with by using Early Uniform Normalization according to Unicode
Normalization Form C, Canonical Composition (NFC) [UTR15]. This document describes both
Early Uniform Normalization and Normalization Form C.
A. Dugan, "IPDC
Connection Control Protocol," Internet Engineering Task Force, Aug. 1998.
Abstract: The protocol described in this document is a member of the IP Device
Control (IPDC) family of protocols. The IPDC protocols are proposed as a protocol suite,
components of which can be used individually or together to perform connection control,
media control, and signaling transport for environments where the service control logic is
separated from the network access server. Please see the references section for other IPDC
documents. The protocol specification presented here is intended for use between a media
gateway controller and a media gateway. The media gateway may be capable of acting as a
voice over IP gateway, voice over ATM gateway, dialup modem media gateway, circuit switch,
or cross- connect. Using the IP Connection Control protocol presented here, the media
gateway controller can setup, modify and teardown connections within or between media
gateways.
A. Durand, "MIME
TYPE definition for IP in IP tunnels," Internet Engineering Task Force, Jul.
2000.
Abstract: IP in IP tunnels are very common in the Internet. They are often used
to deploy new technologies such as multicast or IPv6 when the underlying infrastructure is
not ready to natively support those new protocols. Virtual Private Network are also often
build using IP in IP tunnels. This document describe a MIME type that provide
configuration information about IP in IP tunnels.
W. Weiss, D. Durham and A. Westerinen, "Network Information
Model Requirements," Internet Engineering Task Force, Jul. 2000.
Abstract: As networking technology has evolved, a diverse set of technologies
has been deployed to manage the resulting products. These very from Web based products,
standard management protocols, and text scripts. The underlying systems to be manipulated
are represented in varying ways including implicitly in the programmatics, with
proprietary data descriptions, or with standardized descriptions using a range of
technologies including MIBs, PIBs, or LDAP schemas. The result is that a single
application such as DHCP or Differentiated Services may be represented in many different
inconsistent fashions. Even the existing standard descriptive technologies have not been
focussed on re-use across domains and commonality. The situation would be significantly
improved if there were to be a common representation of data (an 'information model') from
which technology-specific data models can be derived to suit application- specific
configuration and management needs. This would allow the industry to build common
descriptions, resulting in consistency across the paradigms, and better interoperability.
Such an 'information model' would also assist other IETF working groups by reducing the
work needed to determine how to represent those parts of their technology that are already
in the common model.
L. Dusseault and M. Calsyn, "Presence
Information Protocol Requirements," Internet Engineering Task Force, Feb. 1998.
Abstract: Online users have demonstrated a desire to know instantly whether
another individual is online, to be notified when another individual arrives online, and
to send instant messages. These applications currently use independent, non-standard and
usually non-interoperable protocols. The goal is to define a standard protocol so that
independently written client and server implementations can participate in a global
network of ''online'' users. This draft outlines requirements for a Presence Information
Protocol to support these applications. Distribution of this document is unlimited. Please
send comments to the RVP discussion list at rvp@iastate.edu, which may be joined by
sending a message with subject ''subscribe'' to rvp- request@iastate.edu. Archives of past
messages are available. Send the single word \021help\022 to rvp-request@iastate.edu for
more information
R. Earhart, "Application Core
Protocol," Internet Engineering Task Force, Mar. 1999.
Abstract: This document specifies a textual protocol intended as a framework for
applications-layer protocols. While complete, it does not do anything in and of itself;
it's meant to be extensible to particular applications.
R. Earhart, "Access Protocol,"
Internet Engineering Task Force, Jan. 1998.
Abstract: The Access Protocol defines a standard extensible framework upon which
application-specific protocols may be layered, providing a piece of infrastructure for a
common class of internet protocols.
R. Earhart, "A POP3 URL
Interface," Internet Engineering Task Force, Jan. 1998.
Abstract: It is occasionally useful to be able to reference a generic server to
be used for message submission. URLs provide a good mechanism for refering to arbitrary
network resources. The POP3 URL scheme allows a URL to specify a POP3 [POP3] server,
allowing other protocols to use a general ''URL to be used for mail access'' in place of
an explicit reference to POP3.
R. Earhart, "An SMTP URL
Interface," Internet Engineering Task Force, Dec. 1997.
Abstract: It is occasionally useful to be able to reference a generic server to
be used for message submission. URLs provide a good mechanism for refering to arbitrary
network resources. The SMTP URL scheme allows a URL to specify an SMTP server, thus
allowing other protocols to use a general ''URL to be used for message delivery'' in place
of an explicit reference to SMTP.
D. Eastlake, "ISO 7812/7816
Numbers and the Domain Name System (DNS)," Internet Engineering Task Force, Jul.
2000.
Abstract: There are a variety of servers, web pages, and the like, which holders
of ISO 7812 financial transaction identification card (i.e., credit/debit card) numbers
and ISO 7816 smart card or related numbers may need to locate on the Internet. For
example, some systems assume a smart card holder can contact the issuer of a smart card
application for maintenance and update functions and the payment protocols may assume that
a card holder can locate the appropriate certification authority to obtain a card holder
certificate. This document specifies a method using the DNS as an important element in
locating card related facilities on the Internet by mapping ISO 7812 and ISO 7816 number
systems into domain names within in the card.reg.int domain.
Donald E. Eastlake, "Universal
Payment Preamble," Internet Engineering Task Force, Oct. 1996.
Abstract: The Internet is becoming an increasingly commercial arena in which
payments are rendered for goods, information, and services. To support such commerce,
various incompatible Internet payment protocols have been proposed or adopted by a variety
of organizations. There appears to be little prospect of merger of all or abandonment of
most of these protocols. A header syntax, the Universal Payment Preamble (UPP), is
presented for parties to negotiate payment alternatives at any point in shopping, until a
final hand-off to a particular chosen payment system. The chosen payment system, not UPP,
is responsible for the security of any actual transmission of funds.
Keywords: payment protocol; electronic commerce
R. Ekstein, Y. T'Joens, B. Sales and O. Paridaens, "AAA Protocols
: Comparison between RADIUS, DIAMETER and COPS.," Internet Engineering Task
Force, Apr. 2000.
Abstract: The purpose of this draft is to provide an extensive comparison
between the RADIUS, DIAMETER and COPS protocols as these are positioned as generic
Authentication, Authorization and Accounting (AAA) protocols. The protocols will further
be verified on their compliance to the NAS requirements described in [TBA] and roaming
requirements described in RFC 2477.
R. Ekstein, Y. T'Joens, B. Sales and O. Paridaens, "AAA
Protocols : Comparison between RADIUS, DIAMETER and COPS.," Internet Engineering
Task Force, Jan. 2000.
Abstract: The purpose of this draft is to provide an extensive comparison
between the RADIUS, DIAMETER and COPS protocols as these are positioned as generic
Authentication, Authorization and Accounting (AAA) protocols. The protocols will further
be verified on their compliance to the NAS requirements described in [TBA] and roaming
requirements described in RFC 2477.
I. Elliott, "IPDC Media
Control Protocol," Internet Engineering Task Force, Aug. 1998.
Abstract: The protocol described in this document is a member of the IP Device
Control (IPDC) family of protocols. The IPDC protocols are proposed as a protocol suite,
components of which can be used individually or together to perform connection control,
media control, and signaling transport for environments where the service control logic is
separated from the network access server. Please see the references section for other IPDC
documents. The protocol specification presented here is intended for use between a media
gateway controller and a media gateway. The media gateway may be capable of acting as a
voice over IP gateway, voice over ATM gateway, dialup modem media gateway, circuit switch,
or cross-connect. Using the IP Media Control protocol presented here, the media gateway
controller can send messages to the media gateway to cause events such as tones to be
generated or detected within a media stream.
G. Vaudreuil and G. Parsons, "Voice Profile
for Internet Mail - version 2," Internet Engineering Task Force, Nov. 1999.
Abstract: Voice messaging evolved as telephone answering service into a full
send, receive, and forward messaging paradigm with unique message features, semantics and
usage patterns. Voice messaging was introduced on special purpose computers that interface
to a telephone switch and provide call answering and voice messaging services.
Traditionally, messages sent from one voice messaging system to another were transported
using analog networking protocols based on DTMF signaling and analog voice playback. As
the demand for networking increases, there was a need for a standard high-quality digital
protocol to connect these machines. VPIM has successfully demonstrated its usefulness as
this new standard. VPIM is widely implemented and is seeing deployment in early adopter
customer networks. This document clarifies ambiguities found in the earlier specification
and is consistent with implementation practice. The profile is referred to as VPIM (Voice
Profile for Internet Mail) in this document. This second revision of the version 2 of
obsoletes RFC 2421 which less precisely describes version 2 of the profile.
S. Casner, C. Bormann and M. Engan, "IP Header
Compression over PPP," Internet Engineering Task Force, Dec. 1997.
Abstract: This document describes an option for negotiating the use of header
compression on IP datagrams transmitted over the Point-to- Point Protocol [RFC1661]. It
defines extensions to the PPP Control Protocols for IPv4 and IPv6 [RFC1332, RFC2023].
Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP, UDP
and RTP transport protocols as specified in [IPHC] and [CRTP]. [Note to IANA, to be
removed before publication: The PPP protocol type assignments suggested in this document
were selected from those unassigned in
http://ftp.isi.edu/in-notes/iana/assignments/ppp-numbers on December 7, 1997. These
selections were presented to the PPPEXT working group at IETF in Washington, DC on
December 9, 1997 and were approved as being in the appropriate ranges for this protocol.]
D. Farinacci, L. Wei and J. Meylor, "Use of
Anycast Clusters for Inter-Domain Multicast Routing," Internet Engineering Task
Force, Mar. 1998.
Abstract: Anycast Clusters is a proposal to connect multiple ISP sparse-mode PIM
domains together. The environment we anticipate is multiple interconnection points among a
set of ISPs when they are unable to colocate their respective RPs at the same dense-mode
interconnect point. This is an alternative to the Multi-Level RP design and requires less
new code in routers. This proposal is being submitted as a method for the initial phase of
Inter-Domain Multicast deployment and is upward compatible with the IDMR protocols being
proposed for subsequent phases.
D. Farinacci, P. Lothberg, Y. Rekhter, H. Kilmer and J. Hall, "Multicast Source
Discovery Protocol (MSDP)," Internet Engineering Task Force, Jun. 1998.
Abstract: This proposal describes a mechanism to connect multiple PIM-SM domains
together. Each PIM-SM domain uses it's own independent RP(s) and do not have to depend on
RPs in other domains. This proposal is being submitted as a method for the initial phase
of Inter-Domain Multicast deployment in the Internet and may be upward compatible with the
IDMR protocols being proposed for subsequent phases.
A. Farrel and P. Brittain, "Fault Tolerance
for LDP and CR-LDP," Internet Engineering Task Force, Feb. 2000.
Abstract: MPLS systems will be used in core networks where system downtime must
be kept to an absolute minimum. Many MPLS LSRs may, therefore, exploit Fault Tolerant (FT)
hardware or software to provide high-availability of the core networks. The details of how
FT is achieved for the various components of an FT LSR, including LDP, CR-LDP, the
switching hardware and TCP, are implementation specific. This document identifies issues
in the CR-LDP specification [2] and the LDP specification [4] that make it difficult to
implement an FT LSR using the current LDP and CR-LDP protocols, and proposes enhancements
to the LDP specification to ease such FT LSR implementations. The extensions described
here are equally applicable to CR-LDP.
G. Fiaschi, F. Poggi and G. Rolandelli, "A
proposal to provide QoS capability for PPP," Internet Engineering Task Force,
Jul. 2000.
Abstract: Quality of Service in the IP protocol has been proposed in some
service definitions (Int-Serv and Diff-Serv) and in a variety of schemes and supporting
protocols (RSVP). These schemes assume, of course, that all the protocols supporting IP
links in turn provide a well-defined degree of QoS the IP schemes can rely upon. One of
the most common link protocols is PPP. The PPP protocol provides a standard method for
transporting multi-protocol datagrams over point-to-point links. It was designed to be
used in serial point-to-point links. These ones can be for example PSTN circuits,
characterized by a fixed bandwidth and fixed delay. Hence, there was no need to specify
QoS mechanisms for PPP: the IP layer (or more generally the network layer) did not take
into account the data-link layer to calculate the available resources.
R. Finlayson, "The Multicast
Attribute Framing Protocol," Internet Engineering Task Force, Jan. 1998.
Abstract: The Internet has recently seen the emergence of applications that
involve the ongoing transmission, or ''pushing'', of structured data from a server to one
or more client nodes. Most current applications send this data using unicast
communications - usually over TCP connections. However, similar applications can also be
implemented using multicast-based protocols. Multicast not only improves the scalability
of this particular class of application, but also makes possible an additional class of
application in which the participants can act as peers - sending data as well as
receiving. This Internet Draft describes the ''Multicast Attribute Framing Protocol''
(MAFP) - a generic, attribute-based data representation, intended for a wide variety of
multicast-based applications. It is currently being used to implement the ''multikit''
generic multicast session browser (http://www.lvn.com/multikit). This draft describes an
early version of MAFP that is likely to undergo changes in the future. However, it is
being described now, in the hope that it will promote open discussion of this and similar
protocols - ideally leading to the adoption of an open, interoperable standard for this
class of application.
E. Fleischman, "Advanced Streaming
Format (ASF) Specification," Internet Engineering Task Force, Feb. 1998.
Abstract: The Advanced Streaming Format (ASF) is an extensible file format
designed to store synchronized multimedia data. It supports data delivery over a wide
variety of networks and protocols while still proving suitable for local playback. ASF
supports advanced multimedia capabilities including extensible media types, component
download, scaleable media types, author-specified stream prioritization, multiple language
support, and extensive bibliographic capabilities, including document and content
management.
S. Floyd, "Congestion
Control Principles," Internet Engineering Task Force, Jun. 2000.
Abstract: The goal of this document is to explain the need for congestion
control in the Internet, and to discuss what constitutes correct congestion control. One
specific goal is to illustrate the dangers of neglecting to apply proper congestion
control. A second goal is to discuss the role of the IETF in standardizing new congestion
control protocols. This document draws heavily from earlier RFCs, in some cases
reproducing entire sections of the text of earlier documents [RFC2309, RFC2357]. We have
also borrowed heavily from earlier publications addressing the need for end-to-end
congestion control [FF99].
B. Foster, "MGCP CAS
Packages," Internet Engineering Task Force, Oct. 2000.
Abstract: This document contains a collection of media gateway CAS packages for
R1 CAS, North American CAS, CAS PBX interconnect as well as basic FXO support. Included
are six packages. The 'MS' package covers MF single stage dialing trunks. This includes
wink start and immediate start PBX DID/DOD trunks as well as basic R1 and Feature Group D
(FGD) Terminating protocol [3]. The 'DT' package covers immediate start and basic DTMF and
dial-pulse trunks and the 'BL' package covers the interface to a basic PBX (digital or FXS
interface). In addition to the Terminating protocol, there are three other FGD protocols
described in [3]. These include EAIN and EANA which is covered by the enclosed 'MD'
package and the Operator Service Signaling protocol which is handled by the 'MO' package.
Support for basic FXO interconnect is provided by 'DO' package.
J. Postel and N. Freed, "IANA Charset
Registration Procedures," Internet Engineering Task Force, Sep. 1997.
Abstract: MIME [RFC-2045, RFC-2046, RFC-2047, RFC-2184] and various other modern
Internet protocols are capable of using many different charsets. This in turn means that
the ability to label different charsets is essential. This registration procedure exists
solely to associate a specific name or names with a given charset and to give an
indication of whether or not a given charset can be used in MIME text objects. In
particular, the general applicability and appropriateness of a given registered charset is
a protocol issue, not a registration issue, and is not dealt with by this registration
procedure.
N. Freed and J. Postel, "IANA Charset
Registration Procedures," Internet Engineering Task Force, Jul. 2000.
Abstract: MIME [RFC-2045, RFC-2046, RFC-2047, RFC-2184] and various other
Internet protocols are capable of using many different charsets. This in turn means that
the ability to label different charsets is essential.
W. Fritsch and H. Seifert, "Dynamical
routing (unicast and multicast) for the Ipv6 protocol," Internet Engineering Task
Force, Nov. 1997.
Abstract: Future communication networks will be based more and more on a
dynamically changing network topology. Therefore it is advantageous, to have routing
mechanisms, which will dynamically adapt their routing decisions to these topology
changes. This document describes a set of network protocols, which realize such a
dynamical routing of unicast and multicast packets within communication networks based on
IPv6. All used routing algorithms will be immediately executed at the occurrence of any
topology changes and will therefore have already complete routing information at the
receipt of data packets. For the unicasting the Shortest Path First (SPF) routing
algorithm has be chosen. This algorithm calculates the shortest, and therefore the optimal
routing paths within the routing area, by which it is sufficient for a router, to compute
a single routing tree for the whole area. For the multicasting the Minimum Spanning Tree
(MST) routing algorithm has been chosen. This distributed algorithm prevents the
occurrence of endless routing loops, offers for distributed Address Groups nearly optimal
results in saving network bandwidth, and needs also only a single routing tree for the
whole area. This version 02 of the draft mainly corrects some minor errors of version 01.
R. Gellens, "POP URL Scheme,"
Internet Engineering Task Force, Mar. 1998.
Abstract: [POP3] is a widely-deployed mail access protocol. Many programs access
POP3 message stores, and thus need POP3 configuration information. Since there are
multiple configuration elements which are required in order to access a mailbox, a single
string representation is convenient. A POP3 mailbox (like an [IMAP4] mailbox) is a network
resource, and URLs are a widely-supported generalized representation of network resources.
A means of specifying a POP3 mailbox as a URL will likely be useful in many programs and
protocols. [ACAP] is one case where a string encapsulation of elements required to access
network services is needed. For example, an [IMAP4] message store is usually specified in
ACAP datasets as an [IMAP-URL].
J. Gettys and H. Nielsen, "The WebMUX Protocol,"
Internet Engineering Task Force, Aug. 1998.
Abstract: This document defines the experimental multiplexing protocol referred
to as 'WebMUX'. WebMUX is a session management protocol separating the underlying
transport from the upper level application protocols. It provides a lightweight
communication channel to the application layer by multiplexing data streams on top of a
reliable stream oriented transport. By supporting coexistence of multiple application
level protocols (e.g. HTTP and HTTP/NG), WebMUX should ease transitions to future Web
protocols, and communications of client applets using private protocols with servers over
the same TCP connection as the HTTP conversation. WebMUX is intended for, but by no means
restricted to, transport of Web related protocols; the name has been chosen to reduce
confusion with other existing multiplexing protocols. This document is part of a suite of
documents describing the HTTP-NG design and prototype implementation: * HTTP-NG Short- and
Longterm Goals, ID * HTTP-NG Architectural Model, ID * HTTP-NG Wire Protocol, ID * The
Classic Web Interfaces in HTTP-NG, ID * Description of the HTTP-NG Testbed, ID
N. Ghani, Z. Zhang, L. Zhang and J. Fu, "COPS Usage for
ODSI," Internet Engineering Task Force, Jul. 2000.
Abstract: ODSI is a framework of protocols designed to allow internetworking
devices to dynamically request bandwidth from optical networks. Within this framework, a
protocol is required for policy provisioning inside the optical domain. This documents
defines the application of the IETF Common Open Policy Service (COPS) protocol for this
purpose and details its interworking with the ODSI framework.
S. Giacalone, "Scored
Fair Metric Calculation," Internet Engineering Task Force, Aug. 2000.
Abstract: This memo defines a modular metric calculation system termed Scored
Fair Metric Calculation (SFMC). SFMC can be integrated with Link State and Distance Vector
routing protocols and their extensions [1,4,5,6,7], enabling them to find network paths
that support the highest possible number of best metrics across a network. SFMC makes it
possible to support and mix large sets of heterogeneous network features and capabilities.
SFMC solves many of the issues inherent in routing protocols that attempt to use complex
sets of metrics by decoupling raw metric data from the input side of routing protocols.
Unlike the past, SFMC regards all metrics all the time, while treating all metrics equally
(by default). Additionally, the SFMC architecture provides a simple and flexible interface
for extensive manipulation of path selection. Please send comments to
ospf@discuss.microsoft.com.}
B. Chen, H. Frystyk, L. Girod and J. Mallery, "WIRE - W3
Identifier Resolution Extensions," Internet Engineering Task Force, Mar. 1998.
Abstract: WIRE extends HTTP with a new type of redirect response that permits a
resolver to explicitly delegate a resolution to other resolvers and protocols. WIRE is an
effort to make delegation more explicit, redirection more flexible, and resolution
processes more efficient through the use of hints. This document defines WIRE and
describes the expected behaviors of resolvers and clients using WIRE. WIRE is an extension
of the HyperText Transfer Protocol (HTTP), and is intended to be compatible with HTTP/1.0
and above [4][5]. WIRE encourages use of long-lived URIs and at the same time supports
protocol evolution without having to change currently deployed URIs or URI schemes. The
extension is based on a simple URI resolution model that allows an application to
dynamically request metadata describing where and how to access a resource. The model can
use any generic metadata description language (e.g. RDF) and as the metadata itself is
interpreted as a first class resource, metadata resources are no different than any other
resource on the Web.
G. Mansfield, K. Ohta and T. Ika, "A Directory for
organizations and services from DNS and WHOIS.," Internet Engineering Task Force,
Nov. 1997.
Abstract: An Internet Directory is a necessity. The lack of an Internet
Directory is posing serious problems. There are several Directory Protocols ready for
deployment in the Internet. But, among other factors, content generation for the directory
has been a major stumbling block. A simple and straight-forward method of generating
contents for a directory of organizations and their network services using information
| 
