Bookmark and Share

pozycje od 1 do 25 z 97,  strona 1 z 4
 1  2  3  4  > 
  • RFC4298 - RTP Payload Format for BroadVoice Speech Codecs This document describes the RTP payload format for the BroadVoice(R) narrowband and wideband speech codecs. The narrowband codec, called BroadVoice16, or BV16, has been selected by CableLabs as a mandatory codec in PacketCable 1.5 and has a CableLabs specification. The document also provides specifications for the use of BroadVoice with MIME and the Session Description Protocol (SDP). [STANDARDS TRACK]
  • RFC4297 - Remote Direct Memory Access (RDMA) over IP Problem Statement Overhead due to the movement of user data in the end-system network I/O processing path at high speeds is significant, and has limited the use of Internet protocols in interconnection networks, and the Internet itself -- especially where high bandwidth, low latency, and/or low overhead are required by the hosted application.
    This document examines this overhead, and addresses an architectural, IP-based "copy avoidance" solution for its elimination, by enabling Remote Direct Memory Access (RDMA). This memo provides information for the Internet community.
  • RFC4296 - The Architecture of Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) on Internet Protocols This document defines an abstract architecture for Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) protocols to run on Internet Protocol-suite transports. This architecture does not necessarily reflect the proper way to implement such protocols, but is, rather, a descriptive tool for defining and understanding the protocols. DDP allows the efficient placement of data into buffers designated by Upper Layer Protocols (e.g., RDMA). RDMA provides the semantics to enable Remote Direct Memory Access between peers in a way consistent with application requirements. This memo provides information for the Internet community.
  • RFC4295 - Mobile IPv6 Management Information Base This memo defines a portion of the Management Information Base (MIB), the Mobile-IPv6 MIB, for use with network management protocols in the Internet community. In particular, the Mobile-IPv6 MIB will be used to monitor and control the mobile node, home agent, and correspondent node functions of a Mobile IPv6 (MIPv6) entity. [STANDARDS TRACK]
  • RFC4294 - IPv6 Node Requirements This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This memo provides information for the Internet community.
  • RFC4293 - Management Information Base for the Internet Protocol (IP) This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Internet Protocol (IP) in an IP version independent manner. This memo obsoletes RFCs 2011, 2465, and 2466. [STANDARDS TRACK]
  • RFC4292 - IP Forwarding Table MIB This document 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 related to the forwarding of Internet Protocol (IP) packets in an IP version-independent manner. This document obsoletes RFC 2096. [STANDARDS TRACK]
  • RFC4291 - IP Version 6 Addressing Architecture This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.
    This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS TRACK]
  • RFC4290 - Suggested Practices for Registration of Internationalized Domain Names (IDN) This document explores the issues in the registration of internationalized domain names (IDNs). The basic IDN definition allows a very large number of possible characters in domain names, and this richness may lead to serious user confusion about similar-looking names. To avoid this confusion, the IDN registration process must impose rules that disallow some otherwise-valid name combinations. This document suggests a set of mechanisms that registries might use to define and implement such rules for a broad range of languages, including adaptation of methods developed for Chinese, Japanese, and Korean domain names. This memo provides information for the Internet community.
  • RFC4289 - Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures This document specifies IANA registration procedures for MIME external body access types and content-transfer-encodings. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
  • RFC4288 - Media Type Specifications and Registration Procedures This document defines procedures for the specification and registration of media types for use in MIME and other Internet protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
  • RFC4287 - The Atom Syndication Format This document specifies Atom, an XML-based Web content and metadata syndication format. [STANDARDS TRACK]
  • RFC4286 - Multicast Router Discovery The concept of Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping requires the ability to identify the location of multicast routers. Since snooping is not standardized, there are many mechanisms in use to identify the multicast routers. However, this can lead to interoperability issues between multicast routers and snooping switches from different vendors.
    This document introduces a general mechanism that allows for the discovery of multicast routers. This new mechanism, Multicast Router Discovery (MRD), introduces a standardized means of identifying multicast routers without a dependency on particular multicast routing protocols. [STANDARDS TRACK]
  • RFC4285 - Authentication Protocol for Mobile IPv6 IPsec is specified as the means of securing signaling messages between the Mobile Node and Home Agent for Mobile IPv6 (MIPv6). MIPv6 signaling messages that are secured include the Binding Updates and Acknowledgement messages used for managing the bindings between a Mobile Node and its Home Agent. This document proposes an alternate method for securing MIPv6 signaling messages between Mobile Nodes and Home Agents. The alternate method defined here consists of a MIPv6-specific mobility message authentication option that can be added to MIPv6 signaling messages. This memo provides information for the Internet community.
  • RFC4284 - Identity Selection Hints for the Extensible Authentication Protocol (EAP) The Extensible Authentication Protocol (EAP) is defined in RFC 3748. This document defines a mechanism that allows an access network to provide identity selection hints to an EAP peer -- the end of the link that responds to the authenticator. The purpose is to assist the EAP peer in selecting an appropriate Network Access Identifier (NAI). This is useful in situations where the peer does not receive a lower-layer indication of what network it is connecting to, or when there is no direct roaming relationship between the access network and the peer's home network. In the latter case, authentication is typically accomplished via a mediating network such as a roaming consortium or broker.
    The mechanism defined in this document is limited in its scalability. It is intended for access networks that have a small to moderate number of direct roaming partners. This memo provides information for the Internet community.
  • RFC4283 - Mobile Node Identifier Option for Mobile IPv6 (MIPv6) Mobile IPv6 (MIPv6) defines a new Mobility header that is used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of bindings. Mobile IPv6 nodes need the capability to identify themselves using an identity other than the default home IP address. Some examples of identifiers include Network Access Identifier (NAI), Fully Qualified Domain Name (FQDN), International Mobile Station Identifier (IMSI), and Mobile Subscriber Number (MSISDN). This document defines a new mobility option that can be used by Mobile IPv6 entities to identify themselves in messages containing a mobility header. [STANDARDS TRACK]
  • RFC4282 - The Network Access Identifier In order to provide roaming services, it is necessary to have a standardized method for identifying users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during network authentication. "Roaming" may be loosely defined as the ability to use any one of multiple Internet Service Providers (ISPs), while maintaining a formal, \%customer-vendor relationship with only one. Examples of where roaming capabilities might be required include ISP "confederations" and \%ISP-provided corporate network access support. This document is a revised version of RFC 2486, which originally defined NAIs. Enhancements include international character set and privacy support, as well as a number of corrections to the original RFC. [STANDARDS TRACK]
  • RFC4281 - The Codecs Parameter for "Bucket" Media Types Several MIME type/subtype combinations exist that can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it would be helpful to know from the Content-Type alone if the content can be rendered.
    This document adds a new parameter, "codecs", to various type/subtype combinations to allow for unambiguous specification of the codecs indicated by the media formats contained within. By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action (such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.) [STANDARDS TRACK]
  • RFC4280 - Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers This document defines new options to discover the Broadcast and Multicast Service (BCMCS) controller in an IP network. BCMCS is being developed for Third generation (3G) cellular telephone networks. Users of the service interact with a controller in the network via the Mobile Node (MN) to derive information required to receive Broadcast and Multicast Service. Dynamic Host Configuration Protocol can be used to configure the MN to access a particular controller. This document defines the related options and option codes. [STANDARDS TRACK]
  • RFC4279 - Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) This document specifies three sets of new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys (PSKs). These pre-shared keys are symmetric keys, shared in advance among the communicating parties. The first set of ciphersuites uses only symmetric key operations for authentication. The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key, and the third set combines public key authentication of the server with pre-shared key authentication of the client. [STANDARDS TRACK]
  • RFC4278 - Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification The IETF Standards Process requires that all normative references for a document be at the same or higher level of standardization. RFC 2026 section 9.1 allows the IESG to grant a variance to the standard practices of the IETF. This document explains why the IESG is considering doing so for the revised version of the BGP-4 specification, which refers normatively to RFC 2385, "Protection of BGP Sessions via the TCP MD5 Signature Option". RFC 2385 will remain at the Proposed Standard level. This memo provides information for the Internet community.
  • RFC4277 - Experience with the BGP-4 Protocol The purpose of this memo is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4).
    This report satisfies the requirement for "the second report", as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1773 and describes additional knowledge and understanding gained in the time between when the protocol was made a Draft Standard and when it was submitted for Standard. This memo provides information for the Internet community.
  • RFC4276 - BGP-4 Implementation Report This document reports the results of the BGP-4 implementation survey. The survey had 259 questions about implementations' support of BGP-4 as specified in RFC 4271. After a brief summary of the results, each response is listed. This document contains responses from the four implementers that completed the survey (Alcatel, Cisco, Laurel, and NextHop) and brief information from three that did not (Avici, Data Connection Ltd., and Nokia).
    The editors did not use exterior means to verify the accuracy of the information submitted by the respondents. The respondents are experts with the products they reported on. This memo provides information for the Internet community.
  • RFC4275 - BGP-4 MIB Implementation Survey This document provides a survey of implementations of BGP-4 that support RFC 1657 MIB agents according to the BGP-4 v1 MIB specification. This memo provides information for the Internet community.
  • RFC4274 - BGP-4 Protocol Analysis The purpose of this report is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4).
    This report satisfies the requirement for "the second report", as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1774 and summarizes the key features of BGP-4, as well as analyzes the protocol with respect to scaling and performance. This memo provides information for the Internet community.
pozycje od 1 do 25 z 97,  strona 1 z 4
 1  2  3  4  >