RFC Abstracts

RFC3482 - Number Portability in the Global Switched Telephone Network (GSTN): An Overview
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 for NP 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. This memo provides information for the Internet community.
RFC3481 - TCP over Second (2.5G) and Third (3G) Generation Wireless Networks
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. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC3480 - Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol)
Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links. This document defines procedures and extensions to Constraint-Routing Label Distribution Protocol (CR-LDP), one of the MPLS TE signalling protocols that are needed in order to support unnumbered links. [STANDARDS-TRACK]
RFC3479 - Fault Tolerance for the Label Distribution Protocol (LDP)
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, 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 Label Distribution Protocol (LDP), the switching hardware and TCP, are implementation specific. This document identifies issues in the LDP specification in RFC 3036, "LDP Specification", 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 to RFC 3212, "Constraint-Based LSP Setup Using LDP" (CR-LDP). [STANDARDS-TRACK]
RFC3478 - Graceful Restart Mechanism for Label Distribution Protocol
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 its Label 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 actual MPLS 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. [STANDARDS-TRACK]
RFC3477 - Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)
Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links. This document defines procedures and extensions to Resource ReSerVation 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. [STANDARDS-TRACK]
RFC3476 - 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 the Label Distribution Protocol (LDP) and the Resource ReSerVation Protocol (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. This memo provides information for the Internet community.
RFC3475 - 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 the IETF 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. This memo provides information for the Internet community.
RFC3474 - 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)
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 Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) as well as Optical Transport Networks (OTNs). This document concentrates on the signaling aspects of the GMPLS suite of protocols, specifically GMPLS signaling using Resource Reservation 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-T Study Group 15 in support of ITU's ASON standardization effort. This memo provides information for the Internet community.
RFC3473 - Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions
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. [STANDARDS-TRACK]
RFC3472 - 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. [STANDARDS-TRACK]
RFC3471 - 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. 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 functional description of the extensions. Protocol specific formats and mechanisms, and technology specific details are specified in separate documents. [STANDARDS-TRACK]
RFC3470 - 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. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC3469 - Framework for Multi-Protocol Label Switching (MPLS)-based Recovery
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. This memo provides information for the Internet community.
RFC3468 - The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols
This document documents the consensus reached by the Multiprotocol Label Switching (MPLS) Working Group within the IETF to focus its efforts on "Resource Reservation Protocol (RSVP)-TE: Extensions to RSVP 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. This memo provides information for the Internet community.
RFC3467 - Role of the Domain Name System (DNS)
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. This memo provides information for the Internet community.
RFC3466 - A Model for Content Internetworking (CDI)
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. This memo provides information for the Internet community.
RFC3465 - TCP Congestion Control with Appropriate Byte Counting (ABC)
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. This memo defines an Experimental Protocol for the Internet community.
RFC3464 - 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. [STANDARDS-TRACK]
RFC3463 - 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 the Delivery Status Notification (DSN) delivery report, these codes facilitate media and language independent rendering of message delivery status. [STANDARDS-TRACK]
RFC3462 - 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 Mail Transfer 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. [STANDARDS-TRACK]
RFC3461 - 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) that Delivery 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. [STANDARDS-TRACK]
RFC3460 - Policy Core Information Model (PCIM) Extensions
This document specifies a number of changes to the Policy Core Information 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. [STANDARDS-TRACK]
RFC3459 - 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. [STANDARDS-TRACK]
RFC3458 - Message Context for Internet Mail
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. [STANDARDS-TRACK]
RFC3457 - Requirements for IPsec Remote Access Scenarios
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. This memo provides information for the Internet community.
RFC3456 - Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode
This memo explores the requirements for host configuration in IPsec tunnel mode, and describes how the Dynamic Host Configuration Protocol (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. In IPv4, DHCP provides for such remote host configuration. [STANDARDS-TRACK]
RFC3455 - Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)
This document describes a set of private Session Initiation Protocol (SIP) headers (P-headers) used by the 3rd-Generation Partnership Project (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. This memo provides information for the Internet community.
RFC3454 - Preparation of Internationalized Strings ("stringprep")
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. [STANDARDS-TRACK]
RFC3453 - The Use of Forward Error Correction (FEC) in Reliable Multicast
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. This memo provides information for the Internet community.
RFC3452 - Forward Error Correction (FEC) Building Block
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 using IP 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 the Internet 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 Error Correction (FEC) in Reliable Multicast". This memo defines an Experimental Protocol for the Internet community.
RFC3451 - Layered Coding Transport (LCT) Building Block
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. This memo defines an Experimental Protocol for the Internet community.
RFC3450 - Asynchronous Layered Coding (ALC) Protocol Instantiation
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. This memo defines an Experimental Protocol for the Internet community.
RFC3449 - TCP Performance Implications of Network Path Asymmetry
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. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC3448 - TCP Friendly Rate Control (TFRC): Protocol Specification
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. [STANDARDS-TRACK]
RFC3447 - Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1
This memo represents a republication of PKCS #1 v2.1 from RSA Laboratories' 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. This memo provides information for the Internet community.
RFC3446 - Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)
This document describes a mechanism to allow for an arbitrary number of Rendevous Points (RPs) per group in a single shared-tree Protocol Independent Multicast-Sparse Mode (PIM-SM) domain. This memo provides information for the Internet community.
RFC3445 - 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. [STANDARDS-TRACK]
RFC3444 - On the Difference between Information Models and Data Models
There has been ongoing confusion about the differences between Information 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 the International Telecommunication Union (ITU) or the Distributed Management Task Force (DMTF)) fit into the universe of Information Models and Data Models. This memo documents the main results of the 8th workshop of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) hosted by the University of Texas at Austin. This memo provides information for the Internet community.
RFC3443 - Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks
This document describes Time To Live (TTL) processing in hierarchical Multi-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 Stack Encoding". 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. [STANDARDS-TRACK]
RFC3442 - The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4
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. [STANDARDS-TRACK]
RFC3441 - Asynchronous Transfer Mode (ATM) Package for the Media Gateway Control Protocol (MGCP)
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, and ATM 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. This memo provides information for the Internet community.
RFC3440 - Definitions of Extension Managed Objects for Asymmetric Digital Subscriber Lines
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). [STANDARDS-TRACK]
RFC3439 - 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. This memo provides information for the Internet community.
RFC3438 - Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update
This document describes updates to the Internet Assigned Numbers Authority (IANA) considerations for the Layer Two Tunneling Protocol (L2TP). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC3437 - Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation
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 between L2TP endpoints in advance of PPP LCP negotiation at the far end of an L2TP tunnel, as well as a mechanism for communicating the negotiated LCP options back to where the native PPP link resides. [STANDARDS-TRACK]
RFC3436 - Transport Layer Security over Stream Control Transmission Protocol
This document describes the usage of the Transport Layer Security (TLS) protocol, as defined in RFC 2246, over the Stream Control Transmission 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. [STANDARDS-TRACK]
RFC3435 - 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. This memo provides information for the Internet community.
RFC3434 - Remote Monitoring MIB Extensions for High Capacity Alarms
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. [STANDARDS-TRACK]
RFC3433 - Entity Sensor Management Information Base
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 Entity MIB (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). [STANDARDS-TRACK]