| |
| RFC 3401 | Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS |
| |
|
|
This document specifies the exact documents that make up the completeDynamic Delegation Discovery System (DDDS). DDDS is an abstract algorithm for applying dynamically retrieved string transformation rules to an application-unique string.
This document along with RFC 3402, RFC 3403 and RFC 3404 obsolete RFC2168 and RFC 2915, as well as updates RFC 2276. |
|
| |
| RFC 3402 | Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm |
| |
|
|
This document describes the Dynamic Delegation Discovery System(DDDS) algorithm for applying dynamically retrieved string transformation rules to an application-unique string. Well-formed transformation rules will reflect the delegation of management of information associated with the string. This document is also part of a series that is completely specified in "Dynamic DelegationDiscovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401).It is very important to note that it is impossible to read and understand any document in this series without reading the others. |
|
| |
| RFC 3403 | Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database |
| |
|
|
This document describes a Dynamic Delegation Discovery System (DDDS)Database using the Domain Name System (DNS) as a distributed database of Rules. The Keys are domain-names and the Rules are encoded using the Naming Authority Pointer (NAPTR) Resource Record (RR).
Since this document obsoletes RFC 2915, it is the official specification for the NAPTR DNS Resource Record. It is also part of a series that is completely specified in "Dynamic DelegationDiscovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401).It is very important to note that it is impossible to read and understand any document in this series without reading the others. |
|
| |
| RFC 3404 | Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) |
| |
|
|
This document describes a specification for taking Uniform ResourceIdentifiers (URI) and locating an authoritative server for information about that URI. The method used to locate that authoritative server is the Dynamic Delegation Discovery System.
This document is part of a series that is specified in "DynamicDelegation Discovery System (DDDS) Part One: The Comprehensive DDDS"(RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. |
|
| |
| RFC 3405 | Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures |
| |
|
|
This document is fifth in a series that is completely specified in"Dynamic Delegation Discovery System (DDDS) Part One: TheComprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. |
|
| |
| RFC 3406 | Uniform Resource Names (URN) Namespace Definition Mechanisms |
| |
| Authors: | L. Daigle, D. van Gulik, R. Iannella, P. Faltstrom. |
| Date: | October 2002 |
| Formats: | txt html json |
| Obsoletes: | RFC 2611 |
| Obsoleted by: | RFC 8141 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3406 |
|
This document lays out general definitions of and mechanisms for establishing Uniform Resource Names (URN) "namespaces". The URN WG has defined a syntax for URNs in RFC 2141, as well as some proposed mechanisms for their resolution and use in Internet applications inRFC 3401 and RFC 3405. The whole rests on the concept of individual"namespaces" within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed in RFC 2288. |
|
| |
| RFC 3407 | Session Description Protocol (SDP) Simple Capability Declaration |
| |
| Authors: | F. Andreasen. |
| Date: | October 2002 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3407 |
|
This document defines a set of Session Description Protocol (SDP) attributes that enables SDP to provide a minimal and backwards compatible capability declaration mechanism. Such capability declarations can be used as input to a subsequent session negotiation, which is done by means outside the scope of this document. This provides a simple and limited solution to the general capability negotiation problem being addressed by the next generation of SDP, also known as SDPng. |
|
| |
| RFC 3408 | Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust Header Compression (ROHC) Profile |
| |
| Authors: | Z. Liu, K. Le. |
| Date: | December 2002 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3408 |
|
This document defines an additional mode of the link-layer assistedRObust Header Compression (ROHC) profile, also known as the zero-byte profile, beyond the two defined in RFC 3242. Zero-byte header compression exists in order to prevent the single-octet ROHC header from pushing a packet voice stream into the next higher fixed packet size for the radio. It is usable in certain widely deployed older air interfaces. This document adds the zero-byte operation for ROHCBidirectional Reliable mode (R-mode) to the ones specified forUnidirectional (U-mode) and Bidirectional Optimistic (O-mode) modes of header compression in RFC 3242. |
|
| |
| RFC 3409 | Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression |
| |
| Authors: | K. Svanbro. |
| Date: | December 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3409 |
|
This document describes lower layer guidelines for robust header compression (ROHC) and the requirements ROHC puts on lower layers.The purpose of this document is to support the incorporation of robust header compression algorithms, as specified in the ROHC working group, into different systems such as those specified byThird Generation Partnership Project (3GPP), 3GPP Project 2 (3GPP2),European Technical Standards Institute (ETSI), etc. This document covers only lower layer guidelines for compression of RTP/UDP/IP andUDP/IP headers as specified in [RFC3095]. Both general guidelines and guidelines specific for cellular systems are discussed in this document. |
|
| |
| RFC 3410 | Introduction and Applicability Statements for Internet-Standard Management Framework |
| |
| Authors: | J. Case, R. Mundy, D. Partain, B. Stewart. |
| Date: | December 2002 |
| Formats: | txt json html |
| Obsoletes: | RFC 2570 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3410 |
|
The purpose of this document is to provide an overview of the third version of the Internet-Standard Management Framework, termed theSNMP version 3 Framework (SNMPv3). This Framework is derived from and builds upon both the original Internet-Standard ManagementFramework (SNMPv1) and the second Internet-Standard ManagementFramework (SNMPv2).
The architecture is designed to be modular to allow the evolution of the Framework over time.
The document explains why using SNMPv3 instead of SNMPv1 or SNMPv2 is strongly recommended. The document also recommends that RFCs 1157,1441, 1901, 1909 and 1910 be retired by moving them to Historic status. This document obsoletes RFC 2570. |
|
| |
| RFC 3411 | An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks |
| |
|
|
This document describes an architecture for describing Simple NetworkManagement Protocol (SNMP) Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are anSNMP engine containing a Message Processing Subsystem, a SecuritySubsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. This document obsoletes RFC 2571. |
|
| |
| RFC 3412 | Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) |
| |
|
|
This document describes the Message Processing and Dispatching forSimple Network Management Protocol (SNMP) messages within the SNMP architecture. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP MessageProcessing Models, and for dispatching PDUs to SNMP applications.This document also describes one Message Processing Model - theSNMPv3 Message Processing Model. This document obsoletes RFC 2572. |
|
| |
| RFC 3413 | Simple Network Management Protocol (SNMP) Applications |
| |
|
|
This document describes five types of Simple Network ManagementProtocol (SNMP) applications which make use of an SNMP engine as described in STD 62, RFC 3411. The types of application described are Command Generators, Command Responders, Notification Originators,Notification Receivers, and Proxy Forwarders.
This document also defines Management Information Base (MIB) modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. This document obsoletes RFC2573. |
|
| |
| RFC 3414 | User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) |
| |
|
|
This document describes the User-based Security Model (USM) forSimple Network Management Protocol (SNMP) version 3 for use in theSNMP architecture. It defines the Elements of Procedure for providing SNMP message level security. This document also includes aManagement Information Base (MIB) for remotely monitoring/managing the configuration parameters for this Security Model. This document obsoletes RFC 2574. |
|
| |
| RFC 3415 | View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) |
| |
|
|
This document describes the View-based Access Control Model (VACM) for use in the Simple Network Management Protocol (SNMP) architecture. It defines the Elements of Procedure for controlling access to management information. This document also includes aManagement Information Base (MIB) for remotely managing the configuration parameters for the View-based Access Control Model.This document obsoletes RFC 2575. |
|
| |
| RFC 3416 | Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP) |
| |
|
|
This document defines version 2 of the protocol operations for theSimple Network Management Protocol (SNMP). It defines the syntax and elements of procedure for sending, receiving, and processing SNMPPDUs. This document obsoletes RFC 1905. |
|
| |
| RFC 3417 | Transport Mappings for the Simple Network Management Protocol (SNMP) |
| |
|
|
This document defines the transport of Simple Network ManagementProtocol (SNMP) messages over various protocols. This document obsoletes RFC 1906. |
|
| |
| RFC 3418 | Management Information Base (MIB) for the Simple Network Management Protocol (SNMP) |
| |
|
|
This document defines managed objects which describe the behavior of a Simple Network Management Protocol (SNMP) entity. This document obsoletes RFC 1907, Management Information Base for Version 2 of theSimple Network Management Protocol (SNMPv2). |
|
| |
| RFC 3419 | Textual Conventions for Transport Addresses |
| |
| Authors: | M. Daniele, J. Schoenwaelder. |
| Date: | December 2002 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3419 |
|
This document introduces a Management Information Base (MIB) module that defines textual conventions to represent commonly used transport-layer addressing information. The definitions are compatible with the concept of TAddress/TDomain pairs introduced by the Structure of Management Information version 2 (SMIv2) and support the Internet transport protocols over IPv4 and IPv6. |
|
| |
| RFC 3420 | Internet Media Type message/sipfrag |
| |
| Authors: | R. Sparks. |
| Date: | November 2002 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3420 |
|
This document registers the message/sipfrag Multipurpose InternetMail Extensions (MIME) media type. This type is similar to message/sip, but allows certain subsets of well formed SessionInitiation Protocol (SIP) messages to be represented instead of requiring a complete SIP message. In addition to end-to-end security uses, message/sipfrag is used with the REFER method to convey information about the status of a referenced request. |
|
| |
| RFC 3421 | Select and Sort Extensions for the Service Location Protocol (SLP) |
| |
| Authors: | W. Zhao, H. Schulzrinne, E. Guttman, C. Bisdikian, W. Jerome. |
| Date: | November 2002 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3421 |
|
This document defines two extensions (Select and Sort) for theService Location Protocol (SLP). These extensions allow a User Agent(UA) to request that the Uniform Resource Locator (URL) entries in aService Reply (SrvRply) be limited to the specified number, or be sorted according to the specified sort key list. Using these two extensions together can facilitate discovering the best match, such as finding a service that has the maximum speed or the minimum load. |
|
| |
| RFC 3422 | Forwarding Media Access Control (MAC) Frames over Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy (MAPOS) |
| |
| Authors: | O. Okamoto, M. Maruyama, T. Sajima. |
| Date: | November 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3422 |
|
This memo describes a method for forwarding media access control(MAC) frames over Multiple Access Protocol over Synchronous OpticalNetwork/Synchronous Digital Hierarchy (MAPOS), thus providing a way to unify MAPOS network environment and MAC-based Local Area Network(LAN) environment. |
|
| |
| RFC 3423 | XACCT's Common Reliable Accounting for Network Element (CRANE) Protocol Specification Version 1.0 |
| |
| Authors: | K. Zhang, E. Elkin. |
| Date: | November 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3423 |
|
This document defines the Common Reliable Accounting for NetworkElement (CRANE) protocol that enables efficient and reliable delivery of any data, mainly accounting data from Network Elements to any systems, such as mediation systems and Business Support Systems(BSS)/ Operations Support Systems (OSS). The protocol is developed to address the critical needs for exporting high volume of accounting data from NE's with efficient use of network, storage, and processing resources.
This document specifies the architecture of the protocol and the message format, which MUST be supported by all CRANE protocol implementations. |
|
| |
| RFC 3424 | IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation |
| |
| Authors: | L. Daigle, Ed., IAB. |
| Date: | November 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3424 |
|
As a result of the nature of Network Address Translation (NAT)Middleboxes, communicating endpoints that are separated by one or more NATs do not know how to refer to themselves using addresses that are valid in the addressing realms of their (current and future) peers. Various proposals have been made for "UNilateral Self-AddressFixing (UNSAF)" processes. These are processes whereby some originating endpoint attempts to determine or fix the address (and port) by which it is known to another endpoint - e.g. to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections.
This document outlines the reasons for which these proposals can be considered at best as short term fixes to specific problems and the specific issues to be carefully evaluated before creating an UNSAF proposal. |
|
| |
| RFC 3425 | Obsoleting IQUERY |
| |
|
|
The IQUERY method of performing inverse DNS lookups, specified in RFC1035, has not been generally implemented and has usually been operationally disabled where it has been implemented. Both reflect a general view in the community that the concept was unwise and that the widely-used alternate approach of using pointer (PTR) queries and reverse-mapping records is preferable. Consequently, this document deprecates the IQUERY operation, declaring it entirely obsolete.This document updates RFC 1035. |
|
| |
| RFC 3426 | General Architectural and Policy Considerations |
| |
| Authors: | S. Floyd. |
| Date: | November 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3426 |
|
This document suggests general architectural and policy questions that the IETF community has to address when working on new standards and protocols. We note that this document contains questions to be addressed, as opposed to guidelines or architectural principles to be followed. |
|
| |
| RFC 3427 | Change Process for the Session Initiation Protocol (SIP) |
| |
|
|
This memo documents a process intended to apply architectural discipline to the future development of the Session InitiationProtocol (SIP). There have been concerns with regards to new SIP proposals. Specifically, that the addition of new SIP features can be damaging towards security and/or greatly increase the complexity of the protocol. The Transport Area directors, along with the SIP and Session Initiation Proposal Investigation (SIPPING) working group chairs, have provided suggestions for SIP modifications and extensions. |
|
| |
| RFC 3428 | Session Initiation Protocol (SIP) Extension for Instant Messaging |
| |
| Authors: | B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle. |
| Date: | December 2002 |
| Formats: | txt json html |
| Updated by: | RFC 8591 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3428 |
|
Instant Messaging (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation.
This document proposes the MESSAGE method, an extension to theSession Initiation Protocol (SIP) that allows the transfer of InstantMessages. Since the MESSAGE request is an extension to SIP, it inherits all the request routing and security features of that protocol. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request. |
|
| |
| RFC 3429 | Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions |
| |
| Authors: | H. Ohta. |
| Date: | November 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3429 |
|
This document describes the assignment of one of the reserved label values defined in RFC 3032 (MPLS label stack encoding) to the'Operation and Maintenance (OAM) Alert Label' that is used by user- plane Multiprotocol Label Switching Architecture (MPLS) OAM functions for identification of MPLS OAM packets. |
|
| |
| RFC 3430 | Simple Network Management Protocol Over Transmission Control Protocol Transport Mapping |
| |
| Authors: | J. Schoenwaelder. |
| Date: | December 2002 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3430 |
|
This memo defines a transport mapping for using the Simple NetworkManagement Protocol (SNMP) over TCP. The transport mapping can be used with any version of SNMP. This document extends the transport mappings defined in STD 62, RFC 3417. |
|
| |
| RFC 3431 | Sieve Extension: Relational Tests |
| |
|
|
This document describes the RELATIONAL extension to the Sieve mail filtering language defined in RFC 3028. This extension extends existing conditional tests in Sieve to allow relational operators.In addition to testing their content, it also allows for testing of the number of entities in header and envelope fields. |
|
| |
| RFC 3432 | Network performance measurement with periodic streams |
| |
| Authors: | V. Raisanen, G. Grotefeld, A. Morton. |
| Date: | November 2002 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3432 |
|
This memo describes a periodic sampling method and relevant metrics for assessing the performance of IP networks. First, the memo motivates periodic sampling and addresses the question of its value as an alternative to the Poisson sampling described in RFC 2330. The benefits include applicability to active and passive measurements, simulation of constant bit rate (CBR) traffic (typical of multimedia communication, or nearly CBR, as found with voice activity detection), and several instances in which analysis can be simplified. The sampling method avoids predictability by mandating random start times and finite length tests. Following descriptions of the sampling method and sample metric parameters, measurement methods and errors are discussed. Finally, we give additional information on periodic measurements, including security considerations. |
|
| |
| RFC 3433 | Entity Sensor Management Information Base |
| |
| Authors: | A. Bierman, D. Romascanu, K.C. Norseth. |
| Date: | December 2002 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3433 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for extending the EntityMIB (RFC 2737) to provide generalized access to information related to physical sensors, which are often found in networking equipment(such as chassis temperature, fan RPM, power supply voltage). |
|
| |
| RFC 3434 | Remote Monitoring MIB Extensions for High Capacity Alarms |
| |
| Authors: | A. Bierman, K. McCloghrie. |
| Date: | December 2002 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3434 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for extending the alarm thresholding capabilities found in the Remote Monitoring (RMON) MIB(RFC 2819), to provide similar threshold monitoring of objects based on the Counter64 data type. |
|
| |
| RFC 3435 | Media Gateway Control Protocol (MGCP) Version 1.0 |
| |
|
|
This document describes an application programming interface and a corresponding protocol (MGCP) which is used between elements of a decomposed multimedia gateway. The decomposed multimedia gateway consists of a Call Agent, which contains the call control"intelligence", and a media gateway which contains the media functions, e.g., conversion from TDM voice to Voice over IP.
Media gateways contain endpoints on which the Call Agent can create, modify and delete connections in order to establish and control media sessions with other multimedia endpoints. Also, the Call Agent can instruct the endpoints to detect certain events and generate signals.The endpoints automatically communicate changes in service state to the Call Agent. Furthermore, the Call Agent can audit endpoints as well as the connections on endpoints.
The basic and general MGCP protocol is defined in this document, however most media gateways will need to implement one or more MGCP packages, which define extensions to the protocol suitable for use with specific types of media gateways. Such packages are defined in separate documents. |
|
| |
| RFC 3436 | Transport Layer Security over Stream Control Transmission Protocol |
| |
| Authors: | A. Jungmaier, E. Rescorla, M. Tuexen. |
| Date: | December 2002 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3436 |
|
This document describes the usage of the Transport Layer Security(TLS) protocol, as defined in RFC 2246, over the Stream ControlTransmission Protocol (SCTP), as defined in RFC 2960 and RFC 3309.
The user of TLS can take advantage of the features provided by SCTP, namely the support of multiple streams to avoid head of line blocking and the support of multi-homing to provide network level fault tolerance.
Additionally, discussions of extensions of SCTP are also supported, meaning especially the support of dynamic reconfiguration of IP- addresses. |
|
| |
| RFC 3437 | Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation |
| |
| Authors: | W. Palter, W. Townsley. |
| Date: | December 2002 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3437 |
|
This document defines extensions to the Layer Two Tunneling Protocol(L2TP) for enhanced support of link-specific Point to Point Protocol(PPP) options. PPP endpoints typically have direct access to the common physical media connecting them and thus have detailed knowledge about the media that is in use. When the L2TP is used, the two PPP peers are no longer directly connected over the same physical media. Instead, L2TP inserts a virtual connection over some or all of the PPP connection by tunneling PPP frames over a packet switched network such as IP. Under some conditions, an L2TP endpoint may need to negotiate PPP Link Control Protocol (LCP) options at a location which may not have access to all of the media information necessary for proper participation in the LCP negotiation. This document provides a mechanism for communicating desired LCP options betweenL2TP endpoints in advance of PPP LCP negotiation at the far end of anL2TP tunnel, as well as a mechanism for communicating the negotiatedLCP options back to where the native PPP link resides. |
|
| |
| RFC 3438 | Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update |
| |
|
|
This document describes updates to the Internet Assigned NumbersAuthority (IANA) considerations for the Layer Two Tunneling Protocol(L2TP). |
|
| |
| RFC 3439 | Some Internet Architectural Guidelines and Philosophy |
| |
|
|
This document extends RFC 1958 by outlining some of the philosophical guidelines to which architects and designers of Internet backbone networks should adhere. We describe the Simplicity Principle, which states that complexity is the primary mechanism that impedes efficient scaling, and discuss its implications on the architecture, design and engineering issues found in large scale Internet backbones. |
|
| |
| RFC 3440 | Definitions of Extension Managed Objects for Asymmetric Digital Subscriber Lines |
| |
| Authors: | F. Ly, G. Bathrick. |
| Date: | December 2002 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3440 |
|
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 additional managed objects used for managing Asymmetric Digital Subscriber Line (ADSL) interfaces not covered by the ADSL Line MIB (RFC 2662). |
|
| |
| RFC 3441 | Asynchronous Transfer Mode (ATM) Package for the Media Gateway Control Protocol (MGCP) |
| |
| Authors: | R. Kumar. |
| Date: | January 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3441 |
|
This document describes an Asynchronous Transfer Mode (ATM) package for the Media Gateway Control Protocol (MGCP). This package includes new Local Connection Options, ATM-specific events and signals, andATM connection parameters. Also included is a description of codec and profile negotiation. It extends the MGCP that is currently being deployed in a number of products. Implementers should be aware of developments in the IETF Megaco Working Group and ITU SG16, which are currently working on a potential successor to this protocol. |
|
| |
| RFC 3442 | The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4 |
| |
| Authors: | T. Lemon, S. Cheshire, B. Volz. |
| Date: | December 2002 |
| Formats: | txt json html |
| Updates: | RFC 2132 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3442 |
|
This document defines a new Dynamic Host Configuration Protocol(DHCP) option which is passed from the DHCP Server to the DHCP Client to configure a list of static routes in the client. The network destinations in these routes are classless - each routing table entry includes a subnet mask. |
|
| |
| RFC 3443 | Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks |
| |
|
|
This document describes Time To Live (TTL) processing in hierarchicalMulti-Protocol Label Switching (MPLS) networks and is motivated by the need to formalize a TTL-transparent mode of operation for an MPLS label-switched path. It updates RFC 3032, "MPLS Label StackEncoding". TTL processing in both Pipe and Uniform Model hierarchical tunnels are specified with examples for both "push" and"pop" cases. The document also complements RFC 3270, "MPLS Support of Differentiated Services" and ties together the terminology introduced in that document with TTL processing in hierarchical MPLS networks. |
|
| |
| RFC 3444 | On the Difference between Information Models and Data Models |
| |
| Authors: | A. Pras, J. Schoenwaelder. |
| Date: | January 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3444 |
|
There has been ongoing confusion about the differences betweenInformation Models and Data Models for defining managed objects in network management. This document explains the differences between these terms by analyzing how existing network management model specifications (from the IETF and other bodies such as theInternational Telecommunication Union (ITU) or the DistributedManagement Task Force (DMTF)) fit into the universe of InformationModels and Data Models.
This memo documents the main results of the 8th workshop of theNetwork Management Research Group (NMRG) of the Internet ResearchTask Force (IRTF) hosted by the University of Texas at Austin. |
|
| |
| RFC 3445 | Limiting the Scope of the KEY Resource Record (RR) |
| |
|
|
This document limits the Domain Name System (DNS) KEY Resource Record(RR) to only keys used by the Domain Name System Security Extensions(DNSSEC). The original KEY RR used sub-typing to store both DNSSEC keys and arbitrary application keys. Storing both DNSSEC and application keys with the same record type is a mistake. This document removes application keys from the KEY record by redefining the Protocol Octet field in the KEY RR Data. As a result of removing application keys, all but one of the flags in the KEY record become unnecessary and are redefined. Three existing application key sub- types are changed to reserved, but the format of the KEY record is not changed. This document updates RFC 2535. |
|
| |
| RFC 3446 | Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP) |
| |
| Authors: | D. Kim, D. Meyer, H. Kilmer, D. Farinacci. |
| Date: | January 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3446 |
|
This document describes a mechanism to allow for an arbitrary number of Rendevous Points (RPs) per group in a single shared-tree ProtocolIndependent Multicast-Sparse Mode (PIM-SM) domain. |
|
| |
| RFC 3447 | Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 |
| |
|
|
This memo represents a republication of PKCS #1 v2.1 from RSALaboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document is taken directly from the PKCS #1 v2.1 document, with certain corrections made during the publication process. |
|
| |
| RFC 3448 | TCP Friendly Rate Control (TFRC): Protocol Specification |
| |
| Authors: | M. Handley, S. Floyd, J. Padhye, J. Widmer. |
| Date: | January 2003 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5348 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3448 |
|
This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best- effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance. |
|
| |
| RFC 3449 | TCP Performance Implications of Network Path Asymmetry |
| |
| Authors: | H. Balakrishnan, V. Padmanabhan, G. Fairhurst, M. Sooriyabandara. |
| Date: | December 2002 |
| Formats: | txt html json |
| Also: | BCP 0069 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3449 |
|
This document describes TCP performance problems that arise because of asymmetric effects. These problems arise in several access networks, including bandwidth-asymmetric networks and packet radio subnetworks, for different underlying reasons. However, the end result on TCP performance is the same in both cases: performance often degrades significantly because of imperfection and variability in the ACK feedback from the receiver to the sender.
The document details several mitigations to these effects, which have either been proposed or evaluated in the literature, or are currently deployed in networks. These solutions use a combination of local link-layer techniques, subnetwork, and end-to-end mechanisms, consisting of: (i) techniques to manage the channel used for the upstream bottleneck link carrying the ACKs, typically using header compression or reducing the frequency of TCP ACKs, (ii) techniques to handle this reduced ACK frequency to retain the TCP sender's acknowledgment-triggered self-clocking and (iii) techniques to schedule the data and ACK packets in the reverse direction to improve performance in the presence of two-way traffic. Each technique is described, together with known issues, and recommendations for use.A summary of the recommendations is provided at the end of the document. |
|
| |
| RFC 3450 | Asynchronous Layered Coding (ALC) Protocol Instantiation |
| |
| Authors: | M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, J. Crowcroft. |
| Date: | December 2002 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5775 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3450 |
|
This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol.Asynchronous Layered Coding combines the Layered Coding Transport(LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. |
|
| |
| RFC 3451 | Layered Coding Transport (LCT) Building Block |
| |
| Authors: | M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, M. Handley, J. Crowcroft. |
| Date: | December 2002 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5651 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3451 |
|
Layered Coding Transport (LCT) provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols using IP multicast, but also provides support to protocols that use unicast. LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content. |
|
| |
| RFC 3452 | Forward Error Correction (FEC) Building Block |
| |
| Authors: | M. Luby, L. Vicisano, J. Gemmell, L. Rizzo, M. Handley, J. Crowcroft. |
| Date: | December 2002 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5052, RFC 5445 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3452 |
|
This document generally describes how to use Forward Error Correction(FEC) codes to efficiently provide and/or augment reliability for data transport. The primary focus of this document is the application of FEC codes to one-to-many reliable data transport usingIP multicast. This document describes what information is needed to identify a specific FEC code, what information needs to be communicated out-of-band to use the FEC code, and what information is needed in data packets to identify the encoding symbols they carry.The procedures for specifying FEC codes and registering them with theInternet Assigned Numbers Authority (IANA) are also described. This document should be read in conjunction with and uses the terminology of the companion document titled, "The Use of Forward ErrorCorrection (FEC) in Reliable Multicast". |
|
| |
| RFC 3453 | The Use of Forward Error Correction (FEC) in Reliable Multicast |
| |
| Authors: | M. Luby, L. Vicisano, J. Gemmell, L. Rizzo, M. Handley, J. Crowcroft. |
| Date: | December 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3453 |
|
This memo describes the use of Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for one-to-many reliable data transport using IP multicast. One of the key properties of FEC codes in this context is the ability to use the same packets containing FEC data to simultaneously repair different packet loss patterns at multiple receivers. Different classes of FEC codes and some of their basic properties are described and terminology relevant to implementing FEC in a reliable multicast protocol is introduced. Examples are provided of possible abstract formats for packets carrying FEC. |
|
| |
| RFC 3454 | Preparation of Internationalized Strings ("stringprep") |
| |
| Authors: | P. Hoffman, M. Blanchet. |
| Date: | December 2002 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7564 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3454 |
|
This document describes a framework for preparing Unicode text strings in order to increase the likelihood that string input and string comparison work in ways that make sense for typical users throughout the world. The stringprep protocol is useful for protocol identifier values, company and personal names, internationalized domain names, and other text strings.
This document does not specify how protocols should prepare text strings. Protocols must create profiles of stringprep in order to fully specify the processing options. |
|
| |
| RFC 3455 | Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP) |
| |
| Authors: | M. Garcia-Martin, E. Henrikson, D. Mills. |
| Date: | January 2003 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7315 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3455 |
|
This document describes a set of private Session Initiation Protocol(SIP) headers (P-headers) used by the 3rd-Generation PartnershipProject (3GPP), along with their applicability, which is limited to particular environments. The P-headers are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses. |
|
| |
| RFC 3456 | Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode |
| |
| Authors: | B. Patel, B. Aboba, S. Kelly, V. Gupta. |
| Date: | January 2003 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3456 |
|
This memo explores the requirements for host configuration in IPsec tunnel mode, and describes how the Dynamic Host ConfigurationProtocol (DHCPv4) may be leveraged for configuration. In many remote access scenarios, a mechanism for making the remote host appear to be present on the local corporate network is quite useful. This may be accomplished by assigning the host a "virtual" address from the corporate network, and then tunneling traffic via IPsec from the host's ISP-assigned address to the corporate security gateway. InIPv4, DHCP provides for such remote host configuration. |
|
| |
| RFC 3457 | Requirements for IPsec Remote Access Scenarios |
| |
| Authors: | S. Kelly, S. Ramamoorthi. |
| Date: | January 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3457 |
|
IPsec offers much promise as a secure remote access mechanism.However, there are a number of differing remote access scenarios, each having some shared and some unique requirements. A thorough understanding of these requirements is necessary in order to effectively evaluate the suitability of a specific set of mechanisms for any particular remote access scenario. This document enumerates the requirements for a number of common remote access scenarios. |
|
| |
| RFC 3458 | Message Context for Internet Mail |
| |
| Authors: | E. Burger, E. Candell, C. Eliot, G. Klyne. |
| Date: | January 2003 |
| Formats: | txt html json |
| Updated by: | RFC 3938 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3458 |
|
This memo describes a new RFC 2822 message header, "Message-Context".This header provides information about the context and presentation characteristics of a message.
A receiving user agent (UA) may use this information as a hint to optimally present the message. |
|
| |
| RFC 3459 | Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter |
| |
|
|
This document describes the use of a mechanism for identifying body parts that a sender deems critical in a multi-part Internet mail message. The mechanism described is a parameter to Content-Disposition, as described by RFC 3204.
By knowing what parts of a message the sender deems critical, a content gateway can intelligently handle multi-part messages when providing gateway services to systems of lesser capability. Critical content can help a content gateway to decide what parts to forward.It can indicate how hard a gateway should try to deliver a body part.It can help the gateway to pick body parts that are safe to silently delete when a system of lesser capability receives a message. In addition, critical content can help the gateway chose the notification strategy for the receiving system. Likewise, if the sender expects the destination to do some processing on a body part, critical content allows the sender to mark body parts that the receiver must process. |
|
| |
| RFC 3460 | Policy Core Information Model (PCIM) Extensions |
| |
|
|
This document specifies a number of changes to the Policy CoreInformation Model (PCIM, RFC 3060). Two types of changes are included. First, several completely new elements are introduced, for example, classes for header filtering, that extend PCIM into areas that it did not previously cover. Second, there are cases where elements of PCIM (for example, policy rule priorities) are deprecated, and replacement elements are defined (in this case, priorities tied to associations that refer to policy rules). Both types of changes are done in such a way that, to the extent possible, interoperability with implementations of the original PCIM model is preserved. This document updates RFC 3060. |
|
| |
| RFC 3461 | Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) |
| |
|
|
This memo defines an extension to the Simple Mail Transfer Protocol(SMTP) service, which allows an SMTP client to specify (a) thatDelivery Status Notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. |
|
| |
| RFC 3462 | The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages |
| |
|
|
The Multipart/Report Multipurpose Internet Mail Extensions (MIME) content-type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content- type is used to for all kinds of reports.
This document is part of a four document set describing the delivery status report service. This collection includes the Simple MailTransfer Protocol (SMTP) extensions to request delivery status reports, a MIME content for the reporting of delivery reports, an enumeration of extended status codes, and a multipart container for the delivery report, the original message, and a human-friendly summary of the failure. |
|
| |
| RFC 3463 | Enhanced Mail System Status Codes |
| |
|
|
This document defines a set of extended status codes for use within the mail system for delivery status reports, tracking, and improved diagnostics. In combination with other information provided in theDelivery Status Notification (DSN) delivery report, these codes facilitate media and language independent rendering of message delivery status. |
|
| |
| RFC 3464 | An Extensible Message Format for Delivery Status Notifications |
| |
|
|
This memo defines a Multipurpose Internet Mail Extensions (MIME) content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. This content-type is intended as a machine-processable replacement for the various types of delivery status notifications currently used in Internet electronic mail.
Because many messages are sent between the Internet and other messaging systems (such as X.400 or the so-called "Local Area Network(LAN)-based" systems), the Delivery Status Notification (DSN) protocol is designed to be useful in a multi-protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses and error codes, in addition to those normally used in Internet mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet mail. |
|
| |
| RFC 3465 | TCP Congestion Control with Appropriate Byte Counting (ABC) |
| |
| Authors: | M. Allman. |
| Date: | February 2003 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3465 |
|
This document proposes a small modification to the way TCP increases its congestion window. Rather than the traditional method of increasing the congestion window by a constant amount for each arriving acknowledgment, the document suggests basing the increase on the number of previously unacknowledged bytes each ACK covers. This change improves the performance of TCP, as well as closes a security hole TCP receivers can use to induce the sender into increasing the sending rate too rapidly. |
|
| |
| RFC 3466 | A Model for Content Internetworking (CDI) |
| |
| Authors: | M. Day, B. Cain, G. Tomlinson, P. Rzewski. |
| Date: | February 2003 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7336 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3466 |
|
Content (distribution) internetworking (CDI) is the technology for interconnecting content networks, sometimes previously called"content peering" or "CDN peering". A common vocabulary helps the process of discussing such interconnection and interoperation. This document introduces content networks and content internetworking, and defines elements for such a common vocabulary. |
|
| |
| RFC 3467 | Role of the Domain Name System (DNS) |
| |
| Authors: | J. Klensin. |
| Date: | February 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3467 |
|
This document reviews the original function and purpose of the domain name system (DNS). It contrasts that history with some of the purposes for which the DNS has recently been applied and some of the newer demands being placed upon it or suggested for it. A framework for an alternative to placing these additional stresses on the DNS is then outlined. This document and that framework are not a proposed solution, only a strong suggestion that the time has come to begin thinking more broadly about the problems we are encountering and possible approaches to solving them. |
|
| |
| RFC 3468 | The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols |
| |
|
|
This document documents the consensus reached by the MultiprotocolLabel Switching (MPLS) Working Group within the IETF to focus its efforts on "Resource Reservation Protocol (RSVP)-TE: Extensions toRSVP for Label-Switched Paths (LSP) Tunnels" (RFC 3209) as the MPLS signalling protocol for traffic engineering applications and to undertake no new efforts relating to "Constraint-Based LSP Setup using Label Distribution Protocol (LDP)" (RFC 3212). The recommendations of section 6 have been accepted by the IESG. |
|
| |
| RFC 3469 | Framework for Multi-Protocol Label Switching (MPLS)-based Recovery |
| |
| Authors: | V. Sharma, Ed., F. Hellstrand, Ed.. |
| Date: | February 2003 |
| Formats: | txt html json |
| Updated by: | RFC 5462 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3469 |
|
Multi-protocol label switching (MPLS) integrates the label swapping forwarding paradigm with network layer routing. To deliver reliable service, MPLS requires a set of procedures to provide protection of the traffic carried on different paths. This requires that the label switching routers (LSRs) support fault detection, fault notification, and fault recovery mechanisms, and that MPLS signaling support the configuration of recovery. With these objectives in mind, this document specifies a framework for MPLS based recovery. Restart issues are not included in this framework. |
|
| |
| RFC 3470 | Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols |
| |
|
|
The Extensible Markup Language (XML) is a framework for structuring data. While it evolved from Standard Generalized Markup Language(SGML) -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely-used mechanism for representing structured data.
There are a wide variety of Internet protocols being developed; many have need for a representation for structured data relevant to their application. There has been much interest in the use of XML as a representation method. This document describes basic XML concepts, analyzes various alternatives in the use of XML, and provides guidelines for the use of XML within IETF standards-track protocols. |
|
| |
| RFC 3471 | Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description |
| |
|
|
This document describes extensions to Multi-Protocol Label Switching(MPLS) signaling required to support Generalized MPLS. GeneralizedMPLS extends the MPLS control plane to encompass time-division (e.g.,Synchronous Optical Network and Synchronous Digital Hierarchy,SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms, and technology specific details are specified in separate documents. |
|
| |
| RFC 3472 | Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions |
| |
|
|
This document describes extensions to Multi-Protocol Label Switching(MPLS) Constraint-based Routed Label Distribution Protocol (CR-LDP) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g.,Synchronous Optical Network and Synchronous Digital Hierarchy,SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a CR-LDP specific description of the extensions. A generic functional description can be found in separate documents. |
|
| |
| RFC 3473 | Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions |
| |
| Authors: | L. Berger, Ed.. |
| Date: | January 2003 |
| Formats: | txt json html |
| Updated by: | RFC 4003, RFC 4201, RFC 4420, RFC 4783, RFC 4874, RFC 4873, RFC 4974, RFC 5063, RFC 5151, RFC 5420, RFC 6002, RFC 6003, RFC 6780, RFC 8359 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3473 |
|
This document describes extensions to Multi-Protocol Label Switching(MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g.,Synchronous Optical Network and Synchronous Digital Hierarchy,SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents. |
|
| |
| RFC 3474 | Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically Switched Optical Network (ASON) |
| |
| Authors: | Z. Lin, D. Pendarakis. |
| Date: | March 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3474 |
|
The Generalized MultiProtocol Label Switching (GMPLS) suite of protocol specifications has been defined to provide support for different technologies as well as different applications. These include support for requesting TDM connections based on SynchronousOptical NETwork/Synchronous Digital Hierarchy (SONET/SDH) as well asOptical Transport Networks (OTNs).
This document concentrates on the signaling aspects of the GMPLS suite of protocols, specifically GMPLS signaling using ResourceReservation Protocol - Traffic Engineering (RSVP-TE). It proposes additional extensions to these signaling protocols to support the capabilities of an ASON network.
This document proposes appropriate extensions towards the resolution of additional requirements identified and communicated by the ITU-TStudy Group 15 in support of ITU's ASON standardization effort. |
|
| |
| RFC 3475 | Documentation of IANA assignments for Constraint-Based LSP setup using LDP (CR-LDP) Extensions for Automatic Switched Optical Network (ASON) |
| |
|
|
Automatic Switched Optical Network (ASON) is an architecture, specified by ITU-T Study Group 15, for the introduction of a control plane for optical networks. The ASON architecture specifies a set of reference points that defines the relationship between the ASON architectural entities. Signaling over interfaces defined in those reference points can make use of protocols that are defined by theIETF in the context of Generalized Multi-Protocol Label Switching(GMPLS) work. This document describes Constraint-Based LSP setup using LDP (CR-LDP) extensions for signaling over the interfaces defined in the ASON reference points. The purpose of the document is to request that the IANA assigns code points necessary for the CR-LDP extensions. The protocol specifications for the use of the CR-LDP extensions are found in ITU-T documents. |
|
| |
| RFC 3476 | Documentation of IANA Assignments for Label Distribution Protocol (LDP), Resource ReSerVation Protocol (RSVP), and Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) Extensions for Optical UNI Signaling |
| |
|
|
The Optical Interworking Forum (OIF) has defined extensions to theLabel Distribution Protocol (LDP) and the Resource ReSerVationProtocol (RSVP) for optical User Network Interface (UNI) signaling.These extensions consist of a set of new data objects and error codes. This document describes these extensions. |
|
| |
| RFC 3477 | Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) |
| |
| Authors: | K. Kompella, Y. Rekhter. |
| Date: | January 2003 |
| Formats: | txt json html |
| Updated by: | RFC 6107 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3477 |
|
Current signalling used by Multi-Protocol Label Switching TrafficEngineering (MPLS TE) does not provide support for unnumbered links.This document defines procedures and extensions to ResourceReSerVation Protocol (RSVP) for Label Switched Path (LSP) Tunnels(RSVP-TE), one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. |
|
| |
| RFC 3478 | Graceful Restart Mechanism for Label Distribution Protocol |
| |
| Authors: | M. Leelanivas, Y. Rekhter, R. Aggarwal. |
| Date: | February 2003 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3478 |
|
This document describes a mechanism that helps to minimize the negative effects on MPLS traffic caused by Label Switching Router's(LSR's) control plane restart, specifically by the restart of itsLabel Distribution Protocol (LDP) component, on LSRs that are capable of preserving the MPLS forwarding component across the restart.
The mechanism described in this document is applicable to all LSRs, both those with the ability to preserve forwarding state during LDP restart and those without (although the latter needs to implement only a subset of the mechanism described in this document).Supporting (a subset of) the mechanism described here by the LSRs that can not preserve their MPLS forwarding state across the restart would not reduce the negative impact on MPLS traffic caused by their control plane restart, but it would minimize the impact if their neighbor(s) are capable of preserving the forwarding state across the restart of their control plane and implement the mechanism described here.
The mechanism makes minimalistic assumptions on what has to be preserved across restart - the mechanism assumes that only the actualMPLS forwarding state has to be preserved; the mechanism does not require any of the LDP-related states to be preserved across the restart.
The procedures described in this document apply to downstream unsolicited label distribution. Extending these procedures to downstream on demand label distribution is for further study. |
|
| |
| RFC 3479 | Fault Tolerance for the Label Distribution Protocol (LDP) |
| |
| Authors: | A. Farrel, Ed.. |
| Date: | February 2003 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3479 |
|
Multiprotocol Label Switching (MPLS) systems will be used in core networks where system downtime must be kept to an absolute minimum.Many MPLS Label Switching Routers (LSRs) may, therefore, exploitFault 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 FTLSR, including Label Distribution Protocol (LDP), the switching hardware and TCP, are implementation specific. This document identifies issues in the LDP specification in RFC 3036, "LDPSpecification", that make it difficult to implement an FT LSR using the current LDP protocols, and defines enhancements to the LDP specification to ease such FT LSR implementations.
The issues and extensions described here are equally applicable toRFC 3212, "Constraint-Based LSP Setup Using LDP" (CR-LDP). |
|
| |
| RFC 3480 | Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol) |
| |
| Authors: | K. Kompella, Y. Rekhter, A. Kullberg. |
| Date: | February 2003 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3480 |
|
Current signalling used by Multi-Protocol Label Switching TrafficEngineering (MPLS TE) does not provide support for unnumbered links.This document defines procedures and extensions to Constraint-RoutingLabel Distribution Protocol (CR-LDP), one of the MPLS TE signalling protocols that are needed in order to support unnumbered links. |
|
| |
| RFC 3481 | TCP over Second (2.5G) and Third (3G) Generation Wireless Networks |
| |
| Authors: | H. Inamura, Ed., G. Montenegro, Ed., R. Ludwig, A. Gurtov, F. Khafizov. |
| Date: | February 2003 |
| Formats: | txt html json |
| Also: | BCP 0071 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3481 |
|
This document describes a profile for optimizing TCP to adapt so that it handles paths including second (2.5G) and third (3G) generation wireless networks. It describes the relevant characteristics of 2.5G and 3G networks, and specific features of example deployments of such networks. It then recommends TCP algorithm choices for nodes known to be starting or ending on such paths, and it also discusses open issues. The configuration options recommended in this document are commonly found in modern TCP stacks, and are widely available standards-track mechanisms that the community considers safe for use on the general Internet. |
|
| |
| RFC 3482 | Number Portability in the Global Switched Telephone Network (GSTN): An Overview |
| |
| Authors: | M. Foster, T. McGarry, J. Yu. |
| Date: | February 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3482 |
|
This document provides an overview of E.164 telephone number portability (NP) in the Global Switched Telephone Network (GSTN).NP is a regulatory imperative seeking to liberalize local telephony service competition, by enabling end-users to retain telephone numbers while changing service providers. NP changes the fundamental nature of a dialed E.164 number from a hierarchical physical routing address to a virtual address, thereby requiring the transparent translation of the later to the former. In addition, there are various regulatory constraints that establish relevant parameters forNP implementation, most of which are not network technology specific.Consequently, the implementation of NP behavior consistent with applicable regulatory constraints, as well as the need for interoperation with the existing GSTN NP implementations, are relevant topics for numerous areas of IP telephony works-in-progress with the IETF. |
|
| |
| RFC 3483 | Framework for Policy Usage Feedback for Common Open Policy Service with Policy Provisioning (COPS-PR) |
| |
| Authors: | D. Rawlins, A. Kulkarni, M. Bokaemper, K. Chan. |
| Date: | March 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3483 |
|
Common Open Policy Services (COPS) Protocol (RFC 2748), defines the capability of reporting information to the Policy Decision Point(PDP). The types of report information are success, failure and accounting of an installed state. This document focuses on the COPSReport Type of Accounting and the necessary framework for the monitoring and reporting of usage feedback for an installed state. |
|
| |
| RFC 3484 | Default Address Selection for Internet Protocol version 6 (IPv6) |
| |
|
|
This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa.
All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification. |
|
| |
| RFC 3485 | The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp) |
| |
| Authors: | M. Garcia-Martin, C. Bormann, J. Ott, R. Price, A. B. Roach. |
| Date: | February 2003 |
| Formats: | txt html json |
| Updated by: | RFC 4896 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3485 |
|
The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol can be compressed by using Signaling Compression (SigComp). Similarly, theSession Description Protocol (SDP) is a text-based protocol intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This memo defines the SIP/SDP-specific static dictionary that SigComp may use in order to achieve higher efficiency. The dictionary is compression algorithm independent. |
|
| |
| RFC 3486 | Compressing the Session Initiation Protocol (SIP) |
| |
|
|
This document describes a mechanism to signal that compression is desired for one or more Session Initiation Protocol (SIP) messages.It also states when it is appropriate to send compressed SIP messages to a SIP entity. |
|
| |
| RFC 3487 | Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP) |
| |
| Authors: | H. Schulzrinne. |
| Date: | February 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3487 |
|
This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using the Session InitiationProtocol (SIP). |
|
| |
| RFC 3488 | Cisco Systems Router-port Group Management Protocol (RGMP) |
| |
| Authors: | I. Wu, T. Eckert. |
| Date: | February 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3488 |
|
This document describes the Router-port Group Management Protocol(RGMP). This protocol was developed by Cisco Systems and is used between multicast routers and switches to restrict multicast packet forwarding in switches to those routers where the packets may be needed.
RGMP is designed for backbone switched networks where multiple, high speed routers are interconnected. |
|
| |
| RFC 3489 | STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) |
| |
| Authors: | J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy. |
| Date: | March 2003 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5389 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3489 |
|
Simple Traversal of User Datagram Protocol (UDP) Through NetworkAddress Translators (NATs) (STUN) is a lightweight protocol that allows applications to discover the presence and types of NATs and firewalls between them and the public Internet. It also provides the ability for applications to determine the public Internet Protocol(IP) addresses allocated to them by the NAT. STUN works with many existing NATs, and does not require any special behavior from them.As a result, it allows a wide variety of applications to work through existing NAT infrastructure. |
|
| |
| RFC 3490 | Internationalizing Domain Names in Applications (IDNA) |
| |
|
|
Until now, there has been no standard method for domain names to use characters outside the ASCII repertoire. This document defines internationalized domain names (IDNs) and a mechanism calledInternationalizing Domain Names in Applications (IDNA) for handling them in a standard fashion. IDNs use characters drawn from a large repertoire (Unicode), but IDNA allows the non-ASCII characters to be represented using only the ASCII characters already allowed in so- called host names today. This backward-compatible representation is required in existing protocols like DNS, so that IDNs can be introduced with no changes to the existing infrastructure. IDNA is only meant for processing domain names, not free text. |
|
| |
| RFC 3491 | Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN) |
| |
| Authors: | P. Hoffman, M. Blanchet. |
| Date: | March 2003 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5891 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3491 |
|
This document describes how to prepare internationalized domain name(IDN) labels in order to increase the likelihood that name input and name comparison work in ways that make sense for typical users throughout the world. This profile of the stringprep protocol is used as part of a suite of on-the-wire protocols for internationalizing the Domain Name System (DNS). |
|
| |
| RFC 3492 | Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA) |
| |
|
|
Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications (IDNA).It uniquely and reversibly transforms a Unicode string into an ASCII string. ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens). This document defines a general algorithm calledBootstring that allows a string of basic code points to uniquely represent any string of code points drawn from a larger set.Punycode is an instance of Bootstring that uses particular parameter values specified by this document, appropriate for IDNA. |
|
| |
| RFC 3493 | Basic Socket Interface Extensions for IPv6 |
| |
| Authors: | R. Gilligan, S. Thomson, J. Bound, J. McCann, W. Stevens. |
| Date: | February 2003 |
| Formats: | txt json html |
| Obsoletes: | RFC 2553 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3493 |
|
The de facto standard Application Program Interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to supportIPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required byTCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document. |
|
| |
| RFC 3494 | Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status |
| |
|
|
This document recommends the retirement of version 2 of theLightweight Directory Access Protocol (LDAPv2) and other dependent specifications, and discusses the reasons for doing so. This document recommends RFC 1777, 1778, 1779, 1781, and 2559 (as well as documents they superseded) be moved to Historic status. |
|
| |
| RFC 3495 | Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration |
| |
| Authors: | B. Beser, P. Duffy, Ed.. |
| Date: | March 2003 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3495 |
|
This document defines a Dynamic Host Configuration Protocol (DHCP) option that will be used to configure various devices deployed withinCableLabs architectures. Specifically, the document describes DHCP option content that will be used to configure one class of CableLabs client device: a PacketCable Media Terminal Adapter (MTA). The option content defined within this document will be extended as future CableLabs client devices are developed. |
|
| |
| RFC 3496 | Protocol Extension for Support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering |
| |
| Authors: | A. G. Malis, T. Hsiao. |
| Date: | March 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3496 |
|
This document specifies a Resource ReSerVation Protocol-TrafficEngineering (RSVP-TE) signaling extension for support of AsynchronousTransfer Mode (ATM) Service Class-aware Multiprotocol Label Switching(MPLS) Traffic Engineering. |
|
| |
| RFC 3497 | RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video |
| |
| Authors: | L. Gharai, C. Perkins, G. Goncher, A. Mankin. |
| Date: | March 2003 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3497 |
|
This memo specifies an RTP payload format for encapsulating uncompressed High Definition Television (HDTV) as defined by theSociety of Motion Picture and Television Engineers (SMPTE) standard,SMPTE 292M. SMPTE is the main standardizing body in the motion imaging industry and the SMPTE 292M standard defines a bit-serial digital interface for local area HDTV transport. |
|
| |
| RFC 3498 | Definitions of Managed Objects for Synchronous Optical Network (SONET) Linear Automatic Protection Switching (APS) Architectures |
| |
| Authors: | J. Kuhfeld, J. Johnson, M. Thatcher. |
| Date: | March 2003 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3498 |
|
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 networks usingSynchronous Optical Network (SONET) linear Automatic ProtectionSwitching (APS) architectures. |
|
| |
| RFC 3499 | Request for Comments Summary RFC Numbers 3400-3499 |
| |
| Authors: | S. Ginoza. |
| Date: | December 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3499 |
|
|
|
