|
Internet Drafts - IDs for Jul/2009
Index - Month Index of IDs
All IDs - sorted by date)
31/07/2009
| |
|
| |
| | Access Node Control Protocol (ANCP) MIB module for Access Nodes |
| |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing access nodes that are using the Access Node Control Protocol (ANCP). |
| | Using Kerberos V5 over the Transport Layer Security (TLS) protocol |
| |
|
This document specify how the Kerberos V5 protocol can be transported over the Transport Layer Security (TLS) protocol, to provide additional security features. |
| | Selective transmission of RTP Session |
| |
|
Selective transmission is an effective technique implementation for media stream transport when network congestion occurs or dynamic transient burst stream transfers on a bandwidth constrained network. |
| | Consideration of Network Mobility in PMIPv6 |
| |
| | draft-zhang-netlmm-nemo-00.txt |
| | Date: |
31/07/2009 |
| | Authors: |
Zhi-wei Yan, Hong-Ke Zhang, Hua-chun Zhou, Jian-feng Guan, Si-Dong Zhang |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
The NetLMM WG is specifying Proxy Mobile IPv6 (PMIPv6) for network- based localized mobility management (NetLMM), taking basic support for registration, de-registration and handover of signal Mobile Node (MN) into account in the RFC 5213 [1]. When a whole network moves into the PMIPv6 domain through the Mobile Router (MR), the scheme should be considered to provide and maintain the connectivity for the Mobile Network Node (MNN) in the mobile network (NEMO). This document discusses the deployment consideration of NEMO support in PMIPv6 network and proposes the possible solution accordingly. |
30/07/2009
| |
|
| |
| | GSS-API Naming Extensions |
| |
|
The Generic Security Services API (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers. |
| | Initial and Pass Through Authentication Using Kerberos V5 and the GSS- API (IAKERB) |
| |
|
This document defines extensions to the Kerberos protocol and the GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to exchange messages with the KDC using the GSS-API acceptor as the proxy, by encapsulating the Kerberos messages inside GSS-API tokens. With these extensions a client can obtain Kerberos tickets for services where the KDC is not accessible to the client, but is accessible to the application server. |
| | The Remote Framebuffer Protocol |
| |
|
RFB ("remote framebuffer") is a simple protocol for remote access to graphical user interfaces which allows a client to view and control a window system on another computer. Because it works at the framebuffer level RFB is applicable to all windowing systems and applications. This document describes the protocol used to communicate between an RFB client and RFB server. RFB is the protocol used in VNC, Virtual Network Computing. |
| | Export of Structured Data in IPFIX |
| |
|
This document specifies an extension to IP Flow Information eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX information model specified in [RFC5102] to support hierarchical structured data and lists (sequences) of Information Elements in data records. This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Templates. |
| | Revised IAOC Membership |
| |
|
The original specification of the membership of the IAOC included the IETF and IAB Chairs as voting members. While probably desirable initially, this has turned out to have unfortunate side effects. This document discusses those side effects and replaces those specific individuals with liaisons from the IAB and IESG. |
29/07/2009
| |
|
| |
| | MPLS Traffic Engineering Soft Preemption |
| |
|
This document specifies Multiprotocol Label Switching (MPLS) Traffic Engineering Soft Preemption, a suite of protocol modifications extending the concept of preemption with the goal of reducing/ eliminating traffic disruption of preempted Traffic Engineering Label Switched Paths (TE LSPs). Initially MPLS RSVP-TE was defined supporting only immediate TE LSP displacement upon preemption. The utilization of a reroute request notification helps more gracefully mitigate the re-route process of preempted TE LSP. For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect under-provisioned until the TE LSP(s) can be re-routed. For this reason, the feature is primarily but not exclusively interesting in MPLS enabled IP networks with Differentiated Services and Traffic Engineering capabilities. |
| | Safe IKE Recovery |
| |
|
The Internet Key Exchange protocol version 2 (IKEv2) suffers from the limitation of not having a means to quickly recover from a stale state known as dangling Security Associations (SA's) where one side has SA's that the corresponding party does not have anymore. This Draft proposes to address the limitation by offering an immediate, DoS-free recovery mechanism for IKE that can be used in all failover or post-crash situations. |
| | On Secure Neighbor Discovery Proxying Using 'Symbiotic' Relationship |
| |
|
This document introduces a simple mechanism which enables a host using a cryptographically generated IPv6 address to delegate the task of secure neighbor discovery to another node, i.e., proxying, by means of establishing a 'symbiotic' relationship with that node. |
| | Address Selection Using Source Address Specific Routing Tables |
| |
|
RFC 3484 defines two algorithms for default source and destination address selection, but it has several shortcomings as specified in RFC 5220. RFC 5221 lists some requirements for any attempts to update the original RFC. This document specifies an alternate address selection algorithm to fulfill those requirements. |
| | A Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure |
| |
|
This document defines a profile for the algorithm and key size to be used for signatures applied to certificates, Certificate Revocation Lists, and signed objects in the context of the Resource Public Key Infrastructure. |
| | Fast Content Switching with RTSP 2.0 |
| |
|
RTSP defines the setup and control for on demand and live streaming media sessions, which are delivered via an external media transport protocol such as RTP/UDP. RTSP does not define a mechanism to change the content during an on-going streaming session. Such a mechanism improves the streaming experience when a user browses through multiple offerings on a single streaming site. This document describes several methods to improve content switching. The basic principle is to re-use already established transport sessions (e.g. RTP/UDP sessions) and negotiate new content to be delivered on the existing sessions. If additional transport sessions are necessary, those sessions are established separately. This principle of re-using the RTSP control and transport sessions decreases the content switch delay to a large extent and improves the end-user experience. The present document defines a mechanism for switching to new content, both when the client already has the content description available and when it does not. This document additionally considers switching of a single media stream in a session, when several alternative media components are available. For instance, the content may provide several alternate audio tracks in different languages to be played with a single video stream. The principle of Fast Content Switching and Start-up is also defined in 3GPP TS 26.234 [3GPP.26.234] for RTSP 1.0 [RFC2326]. |
| | Sieve Email Filtering: Include Extension |
| |
|
The Sieve Email Filtering "include" extension permits users to include one Sieve script inside another. This can make managing large scripts or multiple sets of scripts much easier, and allows a site and its users to build up libraries of scripts. Users are able to include their own personal scripts or site-wide scripts. Change History (to be removed prior to publication as an RFC) Changes from ietf-02 to ietf-03: a. Setting a variable then calling global on it is an error (something like 'use strict'). b. Specify that the 'global' keyword is only available when 'variables' has also been required. c. Uploading a script that includes a nonexistent script is not an error at upload time. Changes from ietf-01 to ietf-02: a. Require that script names must be constant strings, not subject to variable expansion. b. Try the phrase immediate script instead of current script. c. Clarify that "global 'varname'" and "global.varname" refer to the same variable. d. Drop the requirement the global keywords come after require and before anything else. Changes from ietf-00 to ietf-01: a. Replaced import/export with global. b. Added :once modifier to include. c. Added global namespace to see if it holds water. Changes from daboo-06 to ietf-00: a. None Changes from -05 to -06: a. Aaron Stone joins as author. b. Removed | characters from the script examples. c. Updated draft references to published RFCs. Changes from -04 to -05: a. Fixed examples. b. Relaxed requirement that imported/exported variables be set before being used. Changes from -03 to -04: a. Fixed missing 2119 definitions. b. Defined interaction with variables through use of import and export commands. Changes from -02 to -03: a. Refreshing expired draft (updated for nits). b. Syntax -> Usage. c. Updated to 3028bis reference. Changes from -01 to -02: a. Minor formatting changes only - refreshing expired draft. Changes from -00 to -01: a. Added IPR boiler plate. b. Re-ordered sections at start to conform to RFC style. c. Moved recursion comment into General Considerations section. d. Switched to using optional parameter to indicate personal vs global. e. Explicitly state that an error occurs when a missing script is included. |
28/07/2009
| |
|
| |
| | Problem Statement and Requirements for 6LoWPAN Routing |
| |
|
6LoWPANs are formed by devices that are compatible with the IEEE 802.15.4 standard. However, neither the IEEE 802.15.4 standard nor the 6LoWPAN format specification define how mesh topologies could be obtained and maintained. Thus, it should be considered how 6LoWPAN formation and multi-hop routing could be supported. This document provides the problem statement and design space for 6LoWPAN routing. It defines the routing requirements for 6LoWPAN networks, considering the low-power and other particular characteristics of the devices and links. The purpose of this document is not to recommend specific solutions, but to provide general, layer-agnostic guidelines about the design of 6LoWPAN routing, which can lead to further analysis and protocol design. This document is intended as input to groups working on routing protocols relevant to 6LoWPAN, such as the IETF ROLL WG. |
| | Terminology for Benchmarking IPsec Devices |
| |
|
This purpose of this document is to define terminology specific to measuring the performance of IPsec devices. It builds upon the tenets set forth in [RFC1242], [RFC2544], [RFC2285] and other IETF Benchmarking Methodology Working Group (BMWG) documents used for benchmarking routers and switches. This document seeks to extend these efforts specific to the IPsec paradigm. The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents. |
| | Methodology for Benchmarking IPsec Devices |
| |
|
The purpose of this draft is to describe methodology specific to the benchmarking of IPsec IP forwarding devices. It builds upon the tenets set forth in [RFC2544], [RFC2432] and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the IPsec paradigm. The BMWG produces two major classes of documents: Benchmarking |
| | draft-ietf-ccamp-gmpls-vcat-lcas-08.txt |
| |
|
This document describes requirements for, and use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in conjunction with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing mechanism and its companion Link Capacity Adjustment Scheme (LCAS) which can be used for hitless dynamic resizing of the inverse multiplex group. These techniques apply to Optical Transport Network (OTN), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals. |
| | Extension Mechanisms for DNS (EDNS0) |
| |
|
The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward compatible mechanisms for allowing the protocol to grow. This document updates the EDNS0 specification based on 10 years of operational experience. |
| | Revisions to the BGP 'Minimum Route Advertisement Interval' |
| |
|
This document revises the specification of the BGP MRAI timer, by deprecating the previously recommended values and by allowing for withdrawals to be exempted from the MRAI. |
| | Diversion Indication in SIP |
| |
|
This document proposes an extension to the Session Initiation Protocol (SIP). This extension provides the ability for the called SIP user agent to identify from whom the call was diverted and why the call was diverted. The extension defines a general header, Diversion, which conveys the diversion information from other SIP user agents and proxies to the called user agent. This extension allows enhanced support for various features, including Unified Messaging, Third-Party Voicemail, and Automatic Call Distribution (ACD). SIP user agents and SIP proxies which receive diversion information may use this as supplemental information for feature invocation decisions. |
| | GRE Key Extension for Mobile IPv4 |
| |
|
The GRE specification contains a Key field, which MAY contain a value that is used to identify a particular GRE data stream. This specification defines a new Mobile IP extension that is used to exchange the value to be used in the GRE Key field. This extension further allows the Mobility Agents to setup the necessary protocol interfaces prior to receiving the mobile's traffic. The new extension option allows a foreign agent to request GRE tunneling without disturbing the Home Agent behavior specified for Mobile Ipv4. GRE tunneling provides an advantage that allows operator's private home networks to be overlaid and allows the HA to provide overlapping home addresses to different subscribers. When the tuple < Care of Address, Home Address and Home Agent Address > is the same across multiple subscriber sessions, GRE tunneling will provide a means for the FA and HA to identify data streams for the individual sessions based on the GRE key. In the absence of this key identifier, the data streams cannot be distinguished from each other, a significant drawback when using IP-in-IP tunneling. |
| | Media Server Markup Language (MSML) |
| |
| | draft-saleem-msml-09.txt |
| | Date: |
28/07/2009 |
| | Authors: |
Adnan Saleem, Garland Sharratt |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
The Media Server Markup Language (MSML) is used to control and invoke many different types of services on IP Media Servers. The MSML control interface was initially driven by Radisys with subsequent significant contributions from Intel, Dialogic, and others in the industry. Clients can use it to define how multimedia sessions interact on a Media Server and to apply services to individuals or groups of users. MSML can be used, for example, to control Media Server conferencing features such as video layout and audio mixing, create sidebar conferences or personal mixes, and set the properties of media streams. As well, clients can use MSML to define media processing dialogs, which may be used as parts of application interactions with users or conferences. Transformation of media streams to and from users or conferences as well as IVR dialogs are examples of such interactions, which are specified using MSML. MSML clients may also invoke dialogs with individual users or with groups of conference participants using VoiceXML. |
| | Distributed DNS Implementation in IpV6 |
| |
|
This file is a proposal for P2P based Domain Name query stratagy in IpV6. The DNS servers construct n-tuple overlay virtual hierarchical overlay network. With cached addresses of DNS servers, the overload of traffic in tree structure can be avoided. This strategy may use for Domain Name query and reverse Domain Name query in IpV6 for a large number of domain names. |
| | Distributed Universal Resource Name Resolution based on Distributed DNS |
| |
|
This file is a proposal for Universal Resource Name resolution based on semantic P2P network-VIRGO. |
| | IPv6 Ephemeral Addresses |
| |
|
This document describes a new address type that is called "Ephemeral Addresses". Ephemeral Addresses are designed to be used as clients' source addresses of TCP / UDP sessions. An idea Ephemeral Addresses is simple enough. They are achieved by deriving existing "ephemeral ports" specifications. In other words, they are achieved by naturally upgrading their concept from the port space to the address space. Since Ephemeral Addresses functions are implemented only in the kernel side of the OS, we can use the Ephemeral Addresses functions in current exiting enormous client applications without modifying them. Ephemeral Addresses functions can contribute to various types of security enhancements that include privacy protections etc. |
| | Harmless IPv6 Address State Extension (Uncertain State) |
| |
|
This document describes a new IPv6 address state called "Uncertain" address state as an extension of IPv6 address state specification. "Uncertain" address state is designed to introduce two functionalities. One is to achieve "Temporary Address Reservation" function. The other is to avoid a DAD (Duplicate Address Detection) time consuming problem for dynamically created addresses. New "Uncertain" Address State is inserted between "Tentative" address state and "Valid" address state. After "Tentative" address state (DAD operation has finished) for a newly created address, its state will enter to "Uncertain" address state. While an address stay at "Uncertain" address state, the address is behaved as if it is temporary reserved by the node exclusively. (The other nodes can not obtain such a reserved address.) When it becomes really necessary for the node to utilize the temporary reserved address, its address state is changed into "Valid" address state without accompanying time consuming DAD operation. By these procedures, we can avoid the DAD problem. |
| | "Son of 1036": News Article Format and Transmission |
| |
|
By the early 1990s it had become clear that RFC 1036, the then specification for the Interchange of USENET Messages, was badly in need of repair. This "INTERNET DRAFT to be", though never formally published at that time, was widely circulated and became the de facto standard for implementors of News Servers and User Agents, rapidly acquiring the nickname "Son of 1036". Indeed, under that name, it could fairly be described as the best-known Internet Draft (n)ever published, and it formed the starting point for the recently adopted Proposed Standards for Netnews. It is being published now in order to provide the Historical Background out of which those standards have grown. Present-day implementors should be aware that it is NOT NOW APPROPRIATE for use in current implementations. |
| | DNSSEC OK buffer minimum size requirement and error handling |
| |
|
RFC3226 mandated support for EDNS0 in DNS entities claiming to support either DNS Security Extensions or IPv6 address records. This requirement was motivated because these new features increase the size of DNS messages. If EDNS0 is not supported fall back to TCP will happen, having a detrimental impact on query latency and DNS server load. |
| | Use of Wildcard in S-PMSI Auto-Discovery Routes |
| |
|
The current MVPN specifications do not define encoding and procedures for advertising in a single route binding of multiple multicast streams of a given MVPN customer to a single provider's tunnel. This document defines such encoding and procedures. These procedures allow in certain situations to reduce MVPN control plane load (note though that these procedures have no impact on the data plane load). The procedures specified in this document assume that BGP is used for transmission of MVPN customers' routing information within the service provider(s) infrastructure. |
| | Session Hijack in Neighbor Discovery |
| |
|
This memo is to point out a security issue in IPv6 Neighbor Discovery. |
| | GIST State Machine |
| |
|
This document describes the state machines for the General Internet Signaling Transport (GIST). The states of GIST nodes for a given flow and their transitions are presented in order to illustrate how GIST may be implemented. |
27/07/2009
| |
|
| |
| | The Diameter Capabilities Update Application |
| |
|
This document defines a new Diameter application and associated command codes. The Capabilities Update application is intended to allow the dynamic update of Diameter peer capabilities while the peer-to-peer connection is in the open state. |
| | Best Current Practice for Communications Services in support of Emergency Calling |
| |
|
The IETF and other standards organization have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks and services should use such standards to make emergency calls. |
| | Framework for Emergency Calling using Internet Multimedia |
| |
| | draft-ietf-ecrit-framework-10.txt |
| | Date: |
27/07/2009 |
| | Authors: |
Brian Rosen, Henning Schulzrinne, James Polk, Andrew Newton |
| | Working Group: |
Emergency Context Resolution with Internet Technologies (ecrit) |
| | Formats: |
txt xml |
|
The IETF has standardized various aspects of placing emergency calls. This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities. |
| | Timezone Information in HTTP |
| |
|
This document defines a HTTP header for clients to provide timezone information to web servers. An ABNF description of the corresponding header is provided.Discussion Discussion about this document takes place in http-wg mailing list (ietf-http-wg@w3.org). Please CC v13@v13.gr too. |
| | A Location Dereferencing Protocol Using HELD |
| |
|
This document describes how to use the Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) as a dereferencing protocol to resolve a reference to a Presence Information Data Format Location Object (PIDF-LO). The document assumes that a Location Recipient possesses a secure HELD URI that can be used in conjunction with the HELD protocol to request the location of the Target. |
| | Location Information Server (LIS) Discovery From Behind Residential Gateways |
| |
|
The residential gateway is a device that has become an integral part of home networking equipment. Discovering a Location Information Server (LIS) is a necessary part of acquiring location information for location-based services. However, discovering a LIS when a residential gateway is present poses a configuration challenge, requiring a method that is able to work around the obstacle presented by the gateway. This document describes a solution to this problem. The solution provides alternative domain names as input to the LIS discovery process based on the network addresses assigned to a Device. |
| | Extensible Authentication Protocol Method for Trusted Computing Groups (TCG) Trusted Platform Modules |
| |
| | draft-latze-emu-eap-tpm-01.txt |
| | Date: |
27/07/2009 |
| | Authors: |
Carolin Latze, Ulrich Ultes-Nitsche, Florian Baumgartner |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document describes an Extensible Authentication Protocol (EAP) [RFC3748] method for identity distribution, authentication and session key distribution using the Trusted Computing Group's (TCG) Trusted Platform Module (TPM). The TPM has been defined by the TCG in order to establish a root of trust and measurements in (consumer) computers. It provides several cryptographic functions and a secure storage for keys and hashes. There is also a TPM specification for mobile devices called Mobile Trusted Module (MTM), which can also be used for EAP-TPM. This new EAP method allows network authentication, which also supports user anonymity, the usage of different user identities for the authentication with different network operators, result indication, and a fast re-authentication. |
| | IPv4 and IPv6 Greynets |
| |
|
This note discusses a feature to support building Greynets for IPv4 and IPv6. |
| | A Distance Vector Protocol for Routing Over Low Power and Lossy Networks |
| |
|
This draft describes a distance vector protocol for routing over low power and lossy networks (LLN). |
| | MANET Cryptographical Signature TLV Definition |
| |
|
This document describes a general and flexible TLV (type-length-value structure) for representing cryptographic signatures as well as timestamps, using the generalized MANET packet/message format [RFC5444]. It defines two Message TLVs and two Packet TLVs, for affixing a cryptographic signature and a timestamp to a packet and message, respectively. |
| | IPv6 via IPv4 Service Provider Networks |
| |
|
This document specifies a protocol mechanism tailored to advance deployment of IPv6 to end users via a Service Provider's IPv4 network infrastructure. Key aspects include automatic IPv6 prefix delegation to sites, stateless operation, simple provisioning, and service which is equivalent to native IPv6 outside of the SP's IPv4 network infrastructure. |
| | The rsync URI Scheme |
| |
|
This document specifies the rsync Uniform Resource Identifier (URI) scheme. |
| | IKEv2 Redirect and Authentication Offload |
| |
|
IKEv2 supports multiple authentication mechanisms like public key signatures, shared secrets and EAP. EAP based authentication requires server to maintain information about the client until EAP completes. Public key based authentication mechanisms are highly computational intensive and demands server CPU resources. Redirect Mechanism for IKEv2 proposes a mechanism for IKEv2 that enables a VPN gateway to redirect the VPN client to another VPN gateway, for example, based on the load condition. Redirect mechanism can also be used to redirect a client to another router (trust anchor) to do mutual authentication on behalf of the server. This redirection happens during the IKE_SA_INIT and server does not maintain any information about the redirected client. After mutual authentication Trust anchor can redirect the client back to the server with an Access Token which can be used as a dynamic pre- shared key between the server and client for password based IKE_AUTH exchange. Mechanism described here allows servers to compute the same pre-shared key dynamically, without contacting trust anchors, based on the information provided by the client during IKE_AUTH exchange. Such a mechanism is useful especially for low power devices like handsets. For example, a mobile node can redirect such authentications to its home agent. This proposal explains a mechanism to offload such verifications to a set of less critical routers or to a service provider who offers trust as a service. |
| | Prefix Sub-delegation in a SOHO/SMB Environment |
| |
|
This memo considers the question of IPv6 prefix sub-delegation. |
| | The atypes media feature tag for Session Initiation Protocol (SIP) |
| |
|
This specification defines a new media feature tag called atypes. This new media feature tag indicates the IP address type capabilities of the UA (User Agent) and can aid the routing process and ease the invocation of required functions when heterogeneous (i.e. IPv4 and IPv6) parties are involved in a given SIP session. |
| | LMA Redirection Solution |
| |
|
In network-based mobility management domain, LMA is used to manage the mobility of IP node attached to MAG. LMA discovery and LMA redirection mechanism are used to improve the network flexibility. This document is used to introduce a recommended solution for this purpose. In this solution Redirect Agent function is adopted to accomplish the requirement. |
| | A New SIP Usage for RELOAD |
| |
|
This document points out the main drawbacks of the solution in "draft-ietf-p2psip-sip-01". And solve such problems by introducing a new way. |
| | Session Initiation Protocol (SIP) Event Package for OMA Content Push Delivery |
| |
|
This document specifies a new event package for OMA Push-based service over SIP. The purpose is to allow an OMA application or a UA to subscribe to updates to its own OMA application events containing either content or references to the content. This document further describes how content can be pushed out to an application by the use of OMA Push-based events. |
| | Multi-Screen Application for SVC Video |
| |
|
This memo proposes a supplement to existing draft, RTP payload Format for SVC Video. One new application, Multi-Screen is added. SVC is very suitable for Multi-Screen application, which has some different characteristics from the existing applications in the current draft. This proposal provides a paradigm and addresses potential issues and consideration. |
| | Global Navigation Satellite System (GNSS) Reference Information Protocol (GRIP) |
| |
|
This document describes a means of acquiring Global Navigation Satellite System (GNSS) assistance data using HTTP. Assistance data aids GNSS receivers in acquiring and measuring satellite signals, as well as being useful in calculating positions. The GNSS Reference Information Protocol (GRIP) provides a framework for discovering resources capable of providing any kind of location-based assistance data. |
| | Global Navigation Satellite System (GNSS) Reference Information Protocol (GRIP) - Global Positioning System (GPS) Assistance Data |
| |
|
This document defines assistance data formats for the Global Positioning System (GPS). These formats can be used with the Global Navigation Satellite System (GNSS) Reference Information Protocol (GRIP) by a GPS receiver to acquire assistance data. |
| | Inclusion of Manageability Sections in PCE Working Group Drafts |
| |
|
It has often been the case that manageability considerations have been retrofitted to protocols after they have been specified, standardized, implemented, or deployed. This is sub-optimal. Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements. This document specifies the recommendation for all new Internet-Drafts in the PCE Working Group to include a "Manageability Considerations" section, and gives guidance on what that section should contain. |
| | Conveying Vendor-Specific Constraints in the Path Computation Element Protocol |
| |
|
The Path Computation Element Protocol (PCEP) is used to convey path computation requests and responses between Path Computation Clients (PCCs) and Path Computation Elements (PCEs), and also between cooperating PCEs. In PCEP the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation. The mechanisms defined for indicating objective functions include the capability to convey vendor-specific objective functions. This document defines a facility to carry vendor-specific constraints in PCEP. |
| | Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV) |
| |
|
This document describes Connectivity Verification (CV) types using Bidirectional Forwarding Detection (BFD) with Virtual Circuit Connectivity Verification (VCCV). VCCV provides a control channel that is associated with a Pseudowire (PW), as well as the corresponding operations and management functions such as connectivity verification to be used over that control channel. |
| | SAVI Threat Scope |
| |
|
This memo discusses threats enabled by IP source address spoofing and discusses a number of techniques aimed at mitigating those threats. |
| | SIP-Specific Event Notification |
| |
|
This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. |
14/07/2009
| |
|
| |
| | The case against Hop-by-Hop options |
| |
|
The Hop-by-Hop option header is a type of IPv6 extension header that has been defined in the IPv6 protocol specification. The contents of this header need to be processed by every node along the path of an IPv6 datagram.This draft highlights the characteristics of this extension header which make it prone to Denial of Service attacks and proposes solutions to minimize such attacks. |
| | Multiple aggregated control URIs for RTSP |
| |
|
RTSP defines the setup and control for on demand and live streaming media sessions, which are delivered via an external media transport protocol such as RTP/UDP. RTSP does not define a mechanism to change the content during an on-going streaming session. Such a mechanism improves the streaming experience when a user browses through multiple offerings on a single streaming site. This document describes several methods to improve content switching. The basic principle is to re-use already established transport sessions (e.g. RTP/UDP sessions) and negotiate new content to be delivered on the existing sessions. If additional transport sessions are necessary, those sessions are established separately. This principle of re-using the RTSP control and transport sessions decreases the content switch delay to a large extent and improves the end-user experience. The present document defines a mechanism for switching to new content, both when the client already has the content description available and when it does not. This document additionally considers switching of a single media stream in a session, when several alternative media components are available. For instance, the content may provide several alternate audio tracks in different languages to be played with a single video stream. The principle of Fast Content Switching and Start-up is also defined in 3GPP TS 26.234 [3GPP.26.234] for RTSP 1.0 [RFC2326]. |
| | Line identification in IPv6 Router Solicitation messages |
| |
|
In ethernet and PON based aggregation networks, several subscriber premises may be connected to the same interface of an edge router. This document proposes a method for the edge router to identify the subscriber premises using the contents of the received router solicitation messages. |
| | MPLS-TP OAM based on Y.1731 |
| |
|
This document specifies how to leverage Y.1731 [2] Protocol Data Units (PDU) and procedures (state machines) to provide a set of Operation, Administration, and Maintenance (OAM) mechanisms that meets the MPLS Transport Profile (MPLS-TP) OAM requirements as defined in [6]. In particular, this document specifies the MPLS-TP technology specific encapsulation mechanisms to carry these OAM PDUs within MPLS-TP packets to provide MPLS-TP OAM capabilities in MPLS-TP networks. |
| | SIP extensions for media control |
| |
| | draft-siva-sip-media-01.txt |
| | Date: |
14/07/2009 |
| | Authors: |
Shanmugalingam Sivasothy, Gyu Myoung Lee, Noel Crespi |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This draft presents a requirement and proposes a solution to integration of Session Initiation Protocol (SIP), to the Real Time Streaming Protocol (RTSP and RTSP v2) [RFC 2326 and IDRTSP] especially in the context of converged media services or IPTV services. The document develops a rationale for using SIP with streaming media applications. One service on top of IPTV service is sketched out, which required SIP optimally. |
13/07/2009
| |
|
| |
| | IPv6 Node Requirements RFC 4294-bis |
| |
|
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. |
| | Why RTP Does Not Mandate a Single Security Mechanism |
| |
|
This memo discusses the problem of securing real-time multimedia sessions, and explains why the Real-time Transport Protocol (RTP) does not mandate a single media security mechanism. |
| | Secure Proxy ND Support for SEND |
| |
|
Secure Neighbor Discovery (SEND) specifies a method for securing Neighbor Discovery (ND) signaling against specific threats. As specified today, SEND assumes that the node advertising an address is the owner of the address and is in possession of the private key used to generate the digital signature on the message. This means that the Proxy ND signaling initiated by nodes that do not possess knowledge of the address owner's private key cannot be secured using SEND. This document extends the current SEND specification with support for Proxy ND, the Secure Proxy ND Support for SEND. |
| | DHCPv6 Relay Agent Assignment Notification (RAAN) Option |
| |
|
The DHCP Relay Agent Assignment Notification (RAAN) option is sent from a DHCP server to a DHCP relay agent to inform the relay agent of IPv6 addresses that have been assigned or IPv6 prefixes that have been delegated to DHCP clients. |
| | Diameter Applications Design Guidelines |
| |
|
The Diameter Base protocol provides updated rules on how to extend Diameter by modifying and/or deriving from existing applications or creating entirely new applications. This is a companion document to the Diameter Base protocol that further explains and clarifies these rules. It is meant as a guidelines document and therefore it does not add, remove or change existing rules. |
| | Updated IANA Considerations for Diameter Command Code Allocations |
| |
|
The Diameter Base specification, described in RFC 3588, provides a number of ways to extend Diameter, with new Diameter commands, i.e. messages used by Diameter applications, and applications as the most extensive enhancements. RFC 3588 illustrates the conditions that lead to the need to define a new Diameter application or a new command code. Depending on the scope of the Diameter extension IETF actions are necessary. Although defining new Diameter applications does not require IETF consensus, defining new Diameter commands requires IETF consensus per RFC 3588. This has lead to questionable design decisions by other Standards Development Organizations which chose to define new applications on existing commands rather than asking for assignment of new command codes for the pure purpose of avoiding bringing their specifications to the IETF. In some cases interoperability problems were causes as an effect of the poor design caused by overloading existing commands. This document aligns the extensibility rules of Diameter application with the Diameter commands offering ways to delegate work on Diameter to other SDOs to extend Diameter in a way that does not lead to poor design choices. |
| | Internationalized Delivery Status and Disposition Notifications |
| |
|
Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type. This document experimentally extends RFC 3461, RFC 3464, and RFC 3798. |
| | Location Hiding: Problem Statement and Requirements |
| |
| | draft-ietf-ecrit-location-hiding-req-02.txt |
| | Date: |
13/07/2009 |
| | Authors: |
Henning Schulzrinne, Laura Liess, Hannes Tschofenig, Barbara Stark, Andres Kuett |
| | Working Group: |
Emergency Context Resolution with Internet Technologies (ecrit) |
| | Formats: |
txt xml |
|
The emergency services architecture developed in the IETF Emergency Context Resolution with Internet Technology (ECRIT) working group describes an architecture where location information is provided by access networks to end points or VoIP service providers in order to determine the correct dial string and information to route the call to a Public Safety Answering Point (PSAP). For determining the PSAP Uniform Resource Identifier (URI) the usage of the Location-to- Service Translation (LoST) Protocol is envisioned. This document provides a problem statement and lists requirements for situations where the Internet Access Provider (IAP) and/or the Internet Service Provider (ISP) are only willing to disclose limited or no location information. |
| | Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information |
| |
| | draft-ietf-geopriv-policy-21.txt |
| | Date: |
13/07/2009 |
| | Authors: |
Henning Schulzrinne, Hannes Tschofenig, John Morris, Jorge Cuellar, James Polk |
| | Working Group: |
Geographic Location/Privacy (geopriv) |
| | Formats: |
txt xml |
|
This document defines an authorization policy language for controlling access to location information. It extends the Common Policy authorization framework to provide location-specific access control. More specifically, this document defines condition elements specific to location information in order to restrict access based on the current location of the Target. Furthermore, it offers location- specific transformation elements to reduce the granularity of the returned location information. |
| | GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements |
| |
|
This document provides a problem statement, lists requirements and captures design aspects for a Geopriv Layer 7 Location Configuration Protocol L7 (LCP). This protocol aims to allow an end host to obtain location information, by value or by reference, from a Location Information Server (LIS) that is located in the access network. The obtained location information can then be used for a variety of different protocols and purposes. For example, it can be used as input to the Location-to-Service Translation Protocol (LoST) or to convey location within SIP to other entities. |
| | MRT routing information export format |
| |
|
This document describes the MRT format for routing information export. This format was developed in concert with the Multi-threaded Routing Toolkit (MRT) from whence the format takes it name. The format can be used to export routing protocol messages, state changes, and routing information base contents. |
| | BGP Monitoring Protocol |
| |
| | draft-ietf-grow-bmp-02.txt |
| | Date: |
13/07/2009 |
| | Authors: |
John Scudder, Rex Fernando, Stephen Stuart |
| | Working Group: |
Global Routing Operations (grow) |
| | Formats: |
txt |
|
This document proposes a simple protocol, BMP, which can be used to monitor BGP sessions. BMP is intended to provide a more convenient interface for obtaining route views for research purpose than the screen-scraping approach in common use today. The design goals are to keep BMP simple, useful, easily implemented, and minimally service-affecting. BMP is not suitable for use as a routing protocol. |
| | Reporting IP Performance Metrics to Users |
| |
|
The aim of this document is to define a small set of metrics that are robust, easy to understand, orthogonal, relevant, and easy to compute. The IPPM WG has defined a large number of richly parameterized metrics because network measurement has many purposes. Often, the ultimate purpose is to report a concise set of metrics describing a network's state to an end user. It is for this purpose that the present set of metrics is defined. |
| | Multicast in VPLS |
| |
| | draft-ietf-l2vpn-vpls-mcast-05.txt |
| | Date: |
13/07/2009 |
| | Authors: |
Rahul Aggarwal, Yuji Kamite, Luyuan Fang, Yakhov Rekhter |
| | Working Group: |
Layer 2 Virtual Private Networks (l2vpn) |
| | Formats: |
txt |
|
This document describes a solution for overcoming a subset of the limitations of existing VPLS multicast solutions. It describes procedures for VPLS multicast that utilize multicast trees in the sevice provider (SP) network. One such multicast tree can be shared between multiple VPLS instances. Procedures by which a single multicast tree in the SP network can be used to carry traffic belonging only to a specified set of one or more IP multicast streams from one or more VPLSes are also described. |
| | Long-term Archive Protocol (LTAP) |
| |
| | draft-ietf-ltans-ltap-08.txt |
| | Date: |
13/07/2009 |
| | Authors: |
Aleksej Jerman-Blazic, Peter Sylvester, Carl Wallace |
| | Working Group: |
Long-Term Archive and Notary Services (ltans) |
| | Formats: |
xml txt |
|
This document describes a service operated as a trusted third party to securely archive electronic documents called a long-term archive service (LTA). We describe an architecture framework and a protocol allowing clients to interact with such a service. Bindings to concrete transport and security protocol layers are given. |
| | Simplified Multicast Forwarding |
| |
|
This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic IP multicast forwarding suitable for wireless mesh and mobile ad hoc network (MANET) use. SMF defines techniques for multicast duplicate packet detection (DPD) to be applied in the forwarding process and includes maintenance and checking operations for both IPv4 and IPv6 protocol use. SMF also specifies mechanisms for applying reduced relay sets to achieve more efficient multicast data distribution within a mesh topology versus simple flooding. The document describes interactions with other protocols and multiple deployment approaches. Distributed algorithms for selecting reduced relay sets and related discussion are provided in the Appendices. Basic issues relating to the operation of multicast MANET border routers are discussed but ongoing work remains in this area beyond the scope of this document. |
| | Home Agent Reliability Protocol |
| |
|
The home agent can be a single point of failure when Mobile IPv6 is operated in a system. It is critical to provide home agent reliability in the event of a home agent crashing or becoming unavailable. This would allow another home agent to take over and continue providing service to the mobile nodes. This document describes the problem scope briefly and provides a mechanism of home agent failure detection, home agent state transfer, and home agent switching for home agent redundancy and reliability. |
| | Locating IEEE 802.21 Mobility Servers using DNS |
| |
|
This document defines application service tags that allow service location without relying on rigid domain naming conventions, and DNS procedures for discovering servers which provide IEEE 802.21 [IEEE802.21] defined Mobility Services. Such Mobility Services are used to assist a Mobile Node (MN) supporting IEEE 802.21 [IEEE802.21], in handover preparation (network discovery) and handover decision (network selection). The services addressed by this document are the Media Independent Handover Services defined in [IEEE802.21]. |
| | Real Time Streaming Protocol 2.0 (RTSP) |
| |
| | draft-ietf-mmusic-rfc2326bis-22.txt |
| | Date: |
13/07/2009 |
| | Authors: |
Henning Schulzrinne, Anup Rao, Rob Lanphier, Magnus Westerlund, Martin Stiemerling |
| | Working Group: |
Multiparty Multimedia Session Control (mmusic) |
| | Formats: |
txt xml |
|
This memorandum defines RTSP version 2.0 which obsoletes RTSP version 1.0 which is defined in RFC 2326. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). |
| | A Network Address Translator (NAT) Traversal mechanism for media controlled by Real-Time Streaming Protocol (RTSP) |
| |
|
This document defines a solution for Network Address Translation (NAT) traversal for datagram based media streams setup and controlled with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signalling channel, defining the necessary extra RTSP extensions and procedures. |
| | NETCONF Configuration Protocol |
| |
| | draft-ietf-netconf-4741bis-01.txt |
| | Date: |
13/07/2009 |
| | Authors: |
Rob Enns, Martin Bjorklund, Juergen Schoenwaelder, Andy Bierman |
| | Working Group: |
Network Configuration (netconf) |
| | Formats: |
txt |
|
The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer. |
| | Cisco Systems' Simple Certificate Enrollment Protocol |
| |
|
This document specifies the Simple Certificate Enrollment Protocol, a PKI communication protocol which leverages existing technology by using PKCS#7 and PKCS#10 over HTTP. SCEP is the evolution of the enrollment protocol developed by VeriSign, Inc. for Cisco Systems, Inc. It now enjoys wide support in both client and CA implementations. |
| | Prepaid Extensions to Remote Authentication Dial-In User Service (RADIUS) |
| |
|
This document specifies an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol that enables service providers to charge for prepaid services. The supported charging models supported are volume-based, duration-based, and based on one-time events. |
| | Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling |
| |
|
Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM circuits have been around a long time; more recently, Ethernet VPNs, including Virtual Private LAN Service, have become popular. Traditional L2VPNs often required a separate Service Provider infrastructure for each type, and yet another for the Internet and IP VPNs. In addition, L2VPN provisioning was cumbersome. This document presents a new approach to the problem of offering L2VPN services where the L2VPN customer's experience is virtually identical to that offered by traditional Layer 2 VPNs, but such that a Service Provider can maintain a single network for L2VPNs, IP VPNs and the Internet, as well as a common provisioning methodology for all services. |
| | Robust Header Compression (ROHC) over 802 networks |
| |
|
Various proposals have been submitted to the ROHC working group for enabling the use of ROHC [RFC3095] header compression over Ethernet, 802.11 and other 802-based links. Previous proposals generally suffered from a lack of systems perspective on 802 networks. The present document attempts to supply some systems perspective and provides a rough outline for a solution. This is a submission to the IETF ROHC WG. Please direct discussion to its mailing list, rohc@ietf.org $Revision: 1.9 $ |
| | IPv6 over Low Power WPAN Security Analysis |
| |
|
This document discusses possible threats and security options for IPv6-over-IEEE802.15.4 networks. Its goal is to raise awareness about security issues in IPv6 lowPan networks. |
| | An uniform format for IPv6 extension headers |
| |
|
In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the transport layer header. There are a small number of such extension headers currently defined. This document defines a format for defining a new family of IPv6 extension headers. |
| | Real-time Inter-network Defense |
| |
|
Network security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Network providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms across for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. |
| | LDP Extensions for Source-initiated Point-to-Multipoint Pseudowire |
| |
|
This document provides a solution to extend Label Distribution Protocol (LDP) signaling in order to allow set up and maintenance of Point-to-Multipoint Pseudowire (P2MP PW). Such an extension of existing point to point Pseudowire is made necessary by new applications. The document deals with the source-initiated P2MP PW setup and maintenance. |
| | Diameter Base Protocol Interoperability Test Suite |
| |
|
This document describes a collection of test cases to be used for Diameter base protocol interoperability testing. |
| | Diameter Credit Control Interoperability Test Suite |
| |
|
This document describes a collection of test cases to be used for Diameter Credit Control application interoperability testing. |
| | Diameter Applications Interoperability Test Suite |
| |
|
This document describes a collection of test cases to be used for Diameter applications interoperability testing. |
| | Requirements,Terminology and Framework for Exigent Communications |
| |
|
Various agencies need to provide information to the restricted group of persons or even to the generic public before, during and after emergency situations. While many aspects of such systems are specific to national or local jurisdictions, emergencies span such boundaries and notifications need to reach visitors from other jurisdictions. This document summarizes requirements for protocols to allow alerts to be conveyed to IP-based end points. |
| | Session Initiation Protocol (SIP) Event Package for the Common Alerting Protocol (CAP) |
| |
|
The Common Alerting Protocol (CAP) is an XML document format for exchanging emergency alerts and public warnings. This document allows CAP documents to be distributed via the event notification mechanism available with the Session Initiation Protocol (SIP). |
| | GMPLS Signaling Extensions for Optical Impairment Aware Lightpath Setup |
| |
|
The problem of provisioning a lightpath in a transparent dense wavelength division multiplexing (DWDM) optical island requires the evaluation of of the optical impairments along the selected route. In this memo we propose a GMPLS signaling protocol (RSVP/RSVP-TE) extension to collect and provide the egress node the optical impairment parameters needed to validate a lightpath setup request feasibility. |
| | Real-time text interworking between PSTN and IP networks |
| |
| | draft-hellstrom-txtgwy-01.txt |
| | Date: |
13/07/2009 |
| | Authors: |
Gunnar Hellstrom, Barry Dingle, Arnoud Wijk, Guido Gybels |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt xml |
|
IP networks can support real-time text communication. SIP-based real- time text is called Text-over-IP or ToIP. PSTN networks support real-time text using textphones (or TTYs). When real-time text is supported by different networks, gateways are needed to provide interoperability. Real-time text capable gateways may also support real-time voice. This specification describes procedures for interworking between ToIP and PSTN textphones using a real-time text capable gateway (RTT gateway). It also describes ways to route calls to RTT gateways for several call scenarios. Procedures that support the phased introduction of RTT gateways and procedures that support the invocation of text channels at any time during the call are included. Interworking of PSTN textphones that do not support simultaneity of voice and text with IP User Agents that support simultaneous voice and text is also described. |
| | IGMP and MLD Hold and Release Extensions for Mobility |
| |
|
This document describes IGMP and MLD Hold and Release protocol extensions for hosts and routers. The interoperability with the standard IGMPv3/MLDv2 protocols and these previous versions is also taken into account. |
| | Mobile and Wireless Multicast Requirements on IGMP/MLD Protocols |
| |
|
This document presents the requirements for IGMP/MLD protocols to allow the deployment of mobile multicast service. It is intended to provide useful guideline when adapting current IGMP/MLD protocols to support terminal mobility. |
| | BGP based Virtual Private Multicast Service Auto-Discovery and Signaling |
| |
|
A Point-to-Multipoint (P2MP) Pseudowire (PW) is a mechanism that emulates the essential attributes of a unidirectional P2MP Telecommunications service such as P2MP ATM over a Packet Switched Network (PSN). One of the applicabilities of a P2MP PW is to deliver a Layer 2 multicast service, that carries multicast frames (encoded using Layer 2 or IP mechanisms) from a multicast source to one or more multicast receivers. [RFC4664] describes a number of different ways in which sets of PWs may be combined together into "Provider Provisioned Layer 2 VPNs" (L2 PPVPNs, or L2VPNs), resulting in a number of different kinds of L2VPN. P2MP PWs enable a L2VPN to provide a Virtual Private Multicast Service (VPMS), which may be in addition to the Virtual Private Wire Service (VPWS) offered by the L2VPN. A VPMS is a L2VPN service that provides point-to-multipoint connectivity traffic to customers. VPMS framework and requirements are described in [VPLS-REQ]. One of the VPMS requirements is auto-discovery. This document describes how procedures outlined in [VPLS-MCAST] can be used for auto-discovery (A-D) in VPMS using BGP. This document also describes BGP based procedures for P2MP PW signaling for VPMS that may be used when BGP is used for VPMS auto-discovery. |
| | Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP) |
| |
|
SCTP (Stream Control Transmission Protocol) is a transport protocol used to establish associations between two endpoints. This document describes how to express media transport over SCTP in SDP (Session Description Protocol). This document defines the 'SCTP' and 'SCTP/ DTLS' protocol identifiers for SDP. |
| | Diameter Application for Authentication and Authorization in Web Applications |
| |
|
This document specifies the Diameter Application for Authentication and Authorization in Web Applications (Diameter WebAuth). This Diameter application is intended to be used by Diameter clients to perform authentication and authorization operations with a Diameter server in web-based environments. It provides facilities to allow web sites to authenticate their web user clients using a number of (HTTP) authentication schemes. In addition, it supports user authorization using dedicated service identifiers. Diameter WebAuth may also be used by non web-based Diameter clients and servers that require a lightweight authentication and authorization Diameter application. |
| | Clarification of sender behaviour in persist condition. |
| |
|
This document attempts to clarify the notion of the Zero Window Probes (ZWP) described in RFC 1122 [RFC1122]. In particular, it clarifies the actions that can be taken on connections which are experiencing the ZWP condition. The motivation for this document stems from the belief that TCP implementations strictly adhering to the current RFC language have the potential to become vulnerable to Denial of Service (DoS) scenarios. |
| | Secure DHCPv6 Using CGAs |
| |
|
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCP servers to pass configuration parameters. It offers configuration flexibility. If not secured, DHCPv6 is vulnerable to various attacks, particularly fake attack. This document analyzes the security issues of DHCPv6 and specifies security mechanisms, mainly using CGAs. |
| | Updated Specification of the IPv4 ID Field |
| |
|
The IPv4 Identification (ID) field enables fragmentation and reassembly, and as currently specified is required to be unique within the maximum lifetime on all IP packets. If enforced, this uniqueness requirement would limit all connections to 6.4 Mbps. Because this is obviously not the case, it is clear that existing systems violate the current specification. This document updates the specification of the IP ID field to more closely reflect current practice and to more closely match IPv6, so that the field is defined only when a packet is actually fragmented and that fragmentation occurs only at originating hosts or their equivalent. When fragmentation occurs, this document recommends that the ID field be unique within the reordering context, rather than an arbitrary, unenforced upper bound on packet lifetime. |
| | Trustworthy Location Information |
| |
|
For some location-based applications, such as emergency calling or roadside assistance, it appears that the identity of the requestor is less important than accurate and trustworthy location information. To ensure adequate help location has to be left untouched by the end point or by entities in transit. This document lists different threats, an adversary model, outlines three frequentlly discussed solutions and discusses operational considerations. Finally, the document concludes with a suggestion on how to move forward. |
| | Border Router Discovery Protocol (BRDP) based Address Autoconfiguration |
| |
|
Mobile Ad hoc Networks (MANET) may be attached to a fixed infrastructure network, like the Internet. This document specifies a mechanism for Border Router discovery and utilization in such a subordinate, possibly multi-homed, MANET. It provides facilities for choosing preferred Border Router(s) and configuring IP address(es) needed for communication between MANET nodes and nodes on the Internet via the selected Border Router. Autonomous MANETs do not have Border Routers; a self-sufficient Address Autoconfiguration mechanism for Autonomous MANETs is defined as well. |
| | Alert-Info URNs for the Session Initiation Protocol (SIP) |
| |
|
The Session Initiation Protocol (SIP) supports the capability to provide a reference to the alternative ringback tone (RBT) for caller, or ring tone (RT) for callee using the Alert-Info header. However, the reference addresses only the network resources with specific rendering properties. There is currently no support for predefined standard identifiers for ringback tones or semantic indications without tied rendering. To overcome this limitations and support new applications a family of the URNs is defined in this specification. |
| | BU/BA Based Prefix Delegation Support for Mobile Networks |
| |
|
This document defines prefix delegation support for mobile networks. Mobile Router dynamically requests its Mobile Network Prefixes from its Home Agents using Binding Update both at the home link and at the visited links. Home agents get the prefixes delegated using DHCPv6 Prefix Delegation or by other means and reply to the Mobile Router with Binding Acknowledgement. |
| | Multicast Support Requirements for Proxy Mobile IPv6 |
| |
|
This document summarizes requirements for multicast listener support in Proxy Mobile IPv6 (PMIPv6) scenarios. In correspondance to PMIPv6, multicast mobility management requirements do not request any active participation of the mobile node. |
| | IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios |
| |
|
When IPv6 was designed, it was expected that the transition from IPv4 to IPv6 would occur more smoothly and expeditiously than experience has revealed. The growth of the IPv4 Internet and predicted depletion of the free pool of IPv4 address blocks on a foreseeable horizon has highlighted an urgent need to revisit IPv6 deployment models. This document provides an overview of deployment scenarios with the goal of helping to understand what types of additional tools the industry needs to assist in IPv4 and IPv6 co-existence and transition. This document was originally created as input to the Montreal co- existence interim meeting in October 2008, which led to the rechartering of the Behave and Softwire working groups to take on new IPv4 and IPv6 coexistence work. This document is published as a historical record of the thinking at the time. |
| | Scalable Multihoming across IPv6 Local-Address Routing Zones Global-Prefix/Local-Address Stateless Address Mapping (SAM) |
| |
|
The continuous growth of routing tables in the core of Internet is a challenge. It would become overwhelming if each multihomed customer site would need a provider independent prefix to take full advantage of its multihoming. IPv6 has the potential to solve this problem, but a complete specification is still missing. This draft proposes an approach for a solution. The Stateless Address Mapping (SAM) model, introduced for this, is applicable to a hierarchy of routing zones with multihoming permitted at each level, and with each zone using local addresses for its internal routing plan. End-to-end transparency of the Internet is maintains across these local-address zones, thanks to a systematic encapsulation of global-address packets into local-address packets. Local addresses are statelessly derived from prefixes found in global addresses, and from static parameters of traversed zones. Global prefixes delegated by a zone to its child interfaces can be obtained by autoconfiguration, thanks to to a bidirectional correspondence between SAM local addresses and SAM global prefixes. Deployment can be incremental. |
| | PMIPv6 Extensions for Multicast |
| |
|
This document describes Proxy Mobile IPv6 (PMIPv6) extensions to support IP multicast. The Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA) are the mobility entities defined in the PMIPv6 protocol. The proposed protocol extension provides; 1) a dedicated multicast tunnel (M-Tunnel) between LMA and MAG, and 2) local routing to deliver IP multicast packets for mobile nodes. This document defines the roles of LMA and MAG to support IP multicast for the mobile nodes. |
| | Considerations for IPv6 Address Selection Policy Changes |
| |
|
Where the source and/or destination node of an IPv6 communication is multi-addressed, a mechanism is required for the initiating node to select the most appropriate address pair for the communication. RFC 3484 (IPv6 Default Address Selection) [RFC3484] defines such a mechanism for nodes to perform source and destination address selection. While RFC3484 recognised the need for implementations to be able to change the policy table, it did not define how this could be achieved. Requirements have now emerged for administrators to be able to dynamically change the RFC 3484 policy tables from a central control point, and for nomadic hosts to be able to obtain the policy for the network that they are currently attached to without manual user intervention. This text discusses considerations for such policy changes, including examples of cases where a change of policy is required, and the likely frequency of such policy changes. This text also includes some discussion on the need to also update RFC 3484, where default policies are currently defined. |
| | A Uniform Resource Name (URN) for Early Warning Emergency Services and Location-to-Service Translation (LoST) Protocol Usage |
| |
|
The Common Alerting Protocol (CAP) is an XML document format for exchanging emergency alerts and public warnings. Different organizations issue alerts for specific geographic regions. The Location-to-Service Translation (LoST) protocol provides a way to discover servers that distribute these alerts for a geographical region. This document defines the Service Uniform Resource Names (URN)s for warnings in the same way as they have been defined with RFC 5031 for citizen-to-authority emergency services. Additionally, this document suggests to use LoST for the discovery of servers distributing alerts. |
| | Diameter Routing Problem Statement |
| |
|
This document describes use cases that suggest a requirement to be able to add constraints to the existing Diameter routing mechanisms so that subsequent messages in a session pass through specific proxies that were on the initial path that set up the session. Routing between these proxies may use the present Diameter rules. |
| | The Solution for Pmipv6 Multicast Service |
| |
|
To mobility scenario, multicast service is a valuable feature to those mobile customers. We need to consider how to integrate current multicast service in PMIPv6 domain. This draft will introduce this kind of solution about proxy mobile multicast. It explains the system solution and framework about how to provide the proxy mobile multicast system. |
| | Hierarchical OLSR |
| |
|
This document describes the Hierarchical Optimized Link State Routing (HOLSR) mechanism for heterogeneous mobile ad hoc networks. In this specification a heterogeneous mobile ad hoc network is defined as a network of mobile routers that are characterized by different communication capabilities, such as communication channels, processing powers or energy levels. The HOLSR mechanism is an extension to the OLSRv2 protocol. HOLSR takes advantage of the router's distinct communications capabilities to reduce the routing control overhead in large heterogeneous ad hoc networks, thus improving the performance of the routing mechanism. More precisely, HOLSR defines a hierarchy in the network and presents a routing scheme for this hierarchical structure with a better scalability. |
| | vCard XML Schema |
| |
|
This document defines the XML schema of the vCard data format. |
| | Explicit Notification Extension (ECN) Support for RTP Sessions |
| |
|
This document describes a design to support Explicit Congestion Notification (ECN) for the RTP layer. The design defines a means of end-to-end negotiated support of ECN using the Session Description Protocol (SDP) and a new RTCP Extended Report. |
| | draft-kumar-mpls-fec-to-nhlfe-mib-01 |
| |
|
This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for FEC-to-NHLFE for use in Multiprotocol Label Switching (MPLS)network. The MIB module defined in this document is used for configuring, and monitoring Forwarding Equivalence Class (FEC) to Next Hop Label Forwarding Entry (NHLFE) mappings and corresponding actions for use with Multiprotocol Label Switching (MPLS). |
| | MPLS-TP Fault OAM |
| |
| | draft-boutros-mpls-tp-fault-02.txt |
| | Date: |
13/07/2009 |
| | Authors: |
Sami Boutros, Siva Sivabalan, George Swallow, David Ward, Stewart Bryant |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This draft specifies a fault management indications for MPLS Transport Profile(MPLS-TP) Label Switched Paths (LSPs). The notification mechanism employs a generic method for a Maintenance End Point (MEP) or Maintenance Intermediate Point (MIP) to indicate a fault on an MPLS-TP LSP. A new MPLS Operation, Administration, and Maintenance (OAM) message is defined. |
| | Private Extension to the Session Initiation Protocol (SIP) for Debugging |
| |
|
Networks that use SIP to start and stop sessions between their users will frequently be upgraded with software and hardware changes. Users will similarly frequently change their client software and the way they use the network. In order to allow troubleshooting and regression testing, it is useful to provide debugging as part of the network fabric. This draft describes an event package that provides debugging configuration to SIP entities and a SIP private header that triggers logging of SIP signalling and identifies logs at mulitiple SIP entities as belonging to a single end-to-end session. |
| | Embedding Host Identity Tags Data in DNS |
| |
|
This document proposes conventions to access and manage Host Identity Tag (HIT) mappings using the Domain Name System (DNS) interface. |
| | PMIPv6 Localized Routing Problem Statement |
| |
|
Proxy Mobile IPv6 is the IETF standard for network-based localized mobility management. In Proxy Mobile IPv6, mobile nodes are topologically anchored at a Local Mobility Anchor, which forwards all data for registered mobile nodes. The set up and maintenance of localized routing, which allows forwarding of data packets between mobile nodes and correspondent nodes directly without involvement of the Local Mobility Anchor in forwarding, is not considered. This document describes the problem space of localized routing in Proxy Mobile IPv6. |
| | Issues with network based inter-technology handovers |
| |
|
Proxy Mobile IPv6 (PMIPv6) is a network based mobility management protocol that enables IP mobility for a host without requiring its participation in any mobility-related signaling. While the PMIPv6 protocol itself supports handover across interfaces and between access types, there are several issues with effectively performing inter-technology handovers with network based mobility protocols. This document aims to enumerate some known issues with such handovers. |
| | The atypes media feature tag for Session Initiation Protocol (SIP) |
| |
|
This specification defines a new media feature tag called atypes. This new media feature tag indicates the IP address type capabilities of the UA (User Agent) and can aid the routing process and ease the invocation of required functions when heterogeneous (i.e. IPv4 and IPv6) parties are involved in a given SIP session. |
| | MPLS-TP Control Plane Framework |
| |
|
The MPLS Transport Profile (MPLS-TP) supports both static provisioning of transport paths via an NMS/OSS, and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning, and covers control plane signaling, routing, addressing, traffic engineering, path computation, and recovery in the event of network failures. The document focuses on the control of Label Switched Paths (LSPs) as the Pseudowire (PW) control plane is not modified by MPLS-TP. MPLS-TP uses GMPLS as the control plane for MPLS-TP LSPs. Backwards compatibility to MPLS is required. Management plane functions such as manual configuration, the initiation of LSP setup are out of scope of this document. |
| | Analysis and scenarios of multiple interfaces in a host |
| |
|
This document includes an analysis of multiple interfaces in a host and a description of scenarios of multiple interfaces with the respect of the relationship between layer 2 connection and layer 3 connection. The current TCP/IP mechanism and networking methods are suitable for single network interface. When a host has multiple interfaces, the current TCP/IP mechanism and networking methods cannot directly be used for them. A network interface establishes layer 2 connection to layer 2 entity (e.g., WLAN Access Point) and it does not mean providing proper layer 3 connection. So every active network interfaces do not guarantee successful IP layer operations. In this document, we describe some problems for a host which has multiple interfaces as an aspect of host's operations and usage scenarios of multiple interfaces in a host. |
| | RTSP 2.0 Bitrate Notification |
| |
| | draft-hayano-rtsp-bitrate-02.txt |
| | Date: |
13/07/2009 |
| | Authors: |
Hiroyuki Hatano, Kunihiro Taniguchi, Akira Kobayashi, Martin Stiemerling |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
Typically, there is no use for providing bandwidth information from an RTSP 2.0 server to RTSP 2.0 clients. The bandwidth of the medias played out by the server is different from the available bandwidth in the network (which is also changing) and there is anyhow the need to perform congestion control during media playout. This is true for Internet deployments, or similar, but conveying information about bandwidth of the medias can be required in other deployments of RTSP 2.0. It might necessarily for RTSP 2.0 clients to obtain information about the by medias used bandwidth in networks that rely on bandwidth reservation initiated by the end host. An example is the Next Generation Network (NGN) standardized by ETSI TISPAN, where RTSP 2.0 clients must indicate the required bandwidth to the network. This memo discusses how to provide bandwidth information from RTSP 2.0 servers to clients and how to introduce it in RTSP 2.0. |
| | Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for Access Network Discovery and Selection Function(ANDSF) Discovery |
| |
|
This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options that contain a list IP addresses and a list of domain names that can be mapped to ANDSF (Access Network Discovery and Selection Function) entities in an IP network. ANDSF is being developed in 3GPP (Release-8) and provides inter-system mobility policies and access network specific information to the mobile nodes(MNs) [3GPPTS23.402]. |
| | MPLS-TP OAM Alarm Suppression Tools |
| |
|
The aim of this draft is to define an MPLS-TP OAM mechanism to meet the requirements for Alarm Suppression functionality as required in [3]. One packet format with two different function codes is here defined in order to distinguish among packets with Alarm Indication information and packets with Lock Indication Information. |
| | vCard Format Extension : To Represent the Social Network Information of an Individual |
| |
|
This document defines an extension to the vCard data format for representing and exchanging a variety of social network information. Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to vcarddav@ietf.org. |
| | Open Grid Protocol: Service Establishment |
| |
|
Service establishment in the Open Grid Protocol is the process of creating an application layer association between a client application and a remote service responsible for managing an end entity's identity. Before a service may be used, the requesting party must present credentials, handle any per-entity authentication- time maintenance requirements, and request capabilities the client intends to use. Peer hosts to be authenticated include end users and remote domain hosts. Multiple mechanisms are defined for authentication, but all authentication and service establishment requests follow the same pattern. |
| | Reed-Solomon Forward Error Correction (FEC) Schemes for FECFRAME |
| |
| | draft-roca-fecframe-rs-01.txt |
| | Date: |
13/07/2009 |
| | Authors: |
Vincent Roca, Mathieu Cunche, Jerome Lacan, Amine Bouabdallah, Kazuhisa Matsuzono |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document describes four fully-specified FEC schemes for Reed- Solomon codes that can be used to protect media streams along the lines defined by the FECFRAME framework. Reed-Solomon codes belong to the class of Maximum Distance Separable (MDS) codes which means they offer optimal protection against packet erasures. They are also systematic codes, which means that the source symbols are part of the encoding symbols. The price to pay is a limit on the maximum source block size, on the maximum number of encoding symbols, and a computational complexity higher than that of sparse parity check based FEC codes. However, this complexity remains compatible with software codecs. The first scheme is for Reed-Solomon codes over GF(2^^m), with m in {2..16}, a simple FEC encoding and arbitrary packet flows. The second scheme is for Reed-Solomon codes over GF(2^^8), the interleaved FEC encoding, and arbitrary packet flows. The third (resp. fourth) scheme is similar to the first (resp. second) scheme, with the exception that it is for a single sequenced flow. |
| | Qualifying the Harmfulness of Address Translation |
| |
|
Address translation is widely considered harmful because it conflicts with design principles highly regarded within the Internet engineering community. Still, address translation has become common practice despite technical problems because it constitutes an easy- to-deploy solution to a set of common operational needs. Since some of these needs will continue to exist in IP version 6, there is concern within the Internet engineering community about the potential proliferation of harmful technology from IP version 4 to IP version 6. This document investigates this concern. It compares feasible address translator designs with respect to the harmful impact they may have, explains why the problems of address translation, as used today, are to a significant extent entailed by the shortage of global addresses in IP version 4, and shows how the problems can be mitigated in IP version 6. |
| | draft-valin-celt-rtp-profile-02 RTP Payload Format for the CELT Codec |
| |
|
CELT is an open-source voice codec suitable for use in very low delay audio communication applications, including Voice over IP (VoIP). This document describes the payload format for CELT generated bit streams within an RTP packet. Also included here are the necessary details for the use of CELT with the Session Description Protocol (SDP). At the time of this writing, the CELT bit-stream has NOT been finalized yet, and compatibility is usually broken with every new release of the codec. |
| | Local Mobile Anchor Discovery Using DNS by Service Name |
| |
|
This draft defines a Domain Name System (DNS)-based scheme to enable dynamic discovery of a Local Mobility Anchor (LMA) in Proxy Mobile IPv6. DNS Service Resource Record option is used allowing a Mobile Access Gateway (MAG) to request the LMA's Fully Qualified Domain Name (FQDN) and possibly IP address via the DNS response. IPv4 case is also covered. |
| | Nominating Committee Process: Incumbent Review Model |
| |
|
The traditional IETF Nomcom model treats incumbents and new nominees (for the same and other positions) as equivalent. This has not proven realistic in practice and has had a number of undesirable side effects. This document reviews the issues and the specific changes to the model that take advantage of the differences between incumbents and new nominees. |
| | Realm-Based Redirection In Diameter |
| |
|
RFC 3588 allows a Diameter redirect agent to specify one or more individual hosts to which a Diameter message may be redirected by an upstream Diameter node. However, in some circumstances an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies the means by which this can be achieved. |
| | RPL: Routing Protocol for Low Power and Lossy Networks |
| |
|
This document specifies the Routing Protocol for Low Power and Lossy Networks (RPL), in accordance with the requirements described in [I-D.ietf-roll-building-routing-reqs], [I-D.ietf-roll-home-routing-reqs], [I-D.ietf-roll-indus-routing-reqs], and [RFC5548]. |
| | Security Extension for Unidirectional Lightweight Encapsulation Protocol |
| |
|
The Unidirectional Lightweight Encapsulation (ULE) protocol provides an efficient mechanism for transporting IP and other network layer protocol data over MPEG-2 networks. Such networks, widely used especially for providing digital TV services, often use broadcast wireless transmission media, and are hence vulnerable to various types of security attacks. This document describes a new mandatory ULE extension to protect ULE traffic using security features such as data confidentiality, data integrity, data origin authentication, and prevention against replay attacks. Additionally, destination addresses may be hidden from unauthorized receiver devices using the identity protection feature. The format of the security extension header as well as the processing at receivers and transmitters are described in detail. The extension aims to be lightweight and flexible such that it may be implemented in low-cost, resource-scarce transceivers, and different levels of security may be selected. The security extension may be easily adapted to the Generic Stream Encapsulation (GSE) protocol, which uses a similar extension header mechanism. |
| | A Childless Initiation of the IKE SA |
| |
|
This document describes an extension to the IKEv2 protocol that allows an IKE SA to be created and authenticated without generating a child SA. |
| | Enhancing Mobile IPv6 Route Optimization Mode with Secure Social Dimension |
| |
|
This memo describes an enhancement to Mobile IPv6 route optimization mode which is derived from introducing a social dimension within the home network. |
| | Constrained-Energy Lapped Transform (CELT) Codec |
| |
| | draft-valin-celt-codec-01.txt |
| | Date: |
13/07/2009 |
| | Authors: |
Jean-Marc Valin, Timothy Terriberry, Gregory Maxwell, Christopher Montgomery |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt xml |
|
CELT [celt-website] is an open-source voice codec suitable for use in very low delay Voice over IP (VoIP) type applications. This document describes the encoding and decoding process. |
| | 6LowApp: Problem Statement for 6LoWPAN and LLN Application Protocols |
| |
|
The 6LoWPAN and ROLL WGs are laying the groundwork to make the Wireless Embedded Internet a reality, but what application protocols will we use? Request-response protocols like HTTP are a poor fit to a communication model with battery-operated, mostly sleeping nodes. In addition, the usual data formats (both headers and body) are perceived to be too chatty for the 50-60 byte payloads possible in LoWPANs and to require too much code for the 8-bit and 16-bit processors dominating the Internet of Things. Still, it would be a mistake to start a new silo of application protocols that do not benefit from existing application area Internet experience. This document provides a problem statement for possible work on of application protocols in 6LoWPAN networks or, more generally, in low- power, lossy networks, as well as some considerations for required related work. |
| | Global HA to HA Protocol Specification |
| |
|
This document presents a revised version of the global HAHA protocol specification. This version clarified several issues that were vague in the original specification. All the protocol specifications for the global HAHA are now added on top of the Home Agent Reliability protocol. |
| | Achieving Addressing Functions in IPv6 without using NAT |
| |
|
Proposals have been made to include Network Address Translation (NAT) in IPv6. Network Address Translation substitutes a source address in the outbound Packet headers at the Internet Egress point for one present at the network edge. It then matches the responding packets by destination address, and restores the original headers. NAT itself is not a feature. It is a mechanism which provides features at an application cost. This document identifies features which are supplied by NAT in IPv4 and how these features may be provisioned in IPv6. Both NAT and application-friendly alternatives are presented. |
| | BGP based Multi-homing in Virtual Private LAN Service |
| |
|
Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private Network (VPN) that gives its customers the appearance that their sites are connected via a Local Area Network (LAN). It is often required for the Service Provider (SP) to give the customer redundant connectivity to some sites, often called "multi-homing". This memo shows how BGP-based multi-homing can be offered in the context of LDP and BGP VPLS solutions. |
| | Proxy Mobile IPv6 Localized Routing |
| |
|
The IETF specified Proxy Mobile IPv6 as protocol for network-based mobility management. In Proxy Mobile IPv6, mobile nodes are attached to the network through Mobility Access Gateways and registered with a Local Mobility Anchor. Traffic from and to the mobile node traverses the mobile node's Local Mobility Anchor, irrespective of the location of the mobile node's corresponding communication endpoint. This document specifies a protocol extension to Proxy Mobile IPv6 which allows the set up and maintenance of an optimized routing path between two communicating mobile nodes' Mobility Access Gateways without traversing the mobile nodes' Local Mobility Anchor(s). The protocol component of a rendezvous control point ensures stable maintenance of routing states during handover in scenarios with multiple mobility anchors, where states for the two communication endpoints are distributed between these anchors. |
| | GMPLS Synchronized Signaling for Optical Lightpath Setup |
| |
|
In Generalized Multi-Protocol Label Switching (GMPLS) several extension are proposed to cope with constrain provide Wavelength Switched Optical Networks (WSON). One of the technology constrain related to Dense Wavelength Division Multiplexing (DWDM) systems is the bi-directionality of the lightpath. This memo provides some consideration about how extending the signaling phase to cope with the bi-directional requirements. The procedure is independent from the wavelength continuity constrain in both direction. |
| | Session Peering Provisioning Protocol |
| |
| | draft-mule-drinks-proto-01.txt |
| | Date: |
13/07/2009 |
| | Authors: |
Jean-Francois Mule, Kenneth Cartwright, Debbie Guyton, Alexander Mayrhofer |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt xml |
|
This document defines a protocol for provisioning session establishment data into Session Data Registries or SIP Service Provider data stores. The provisioned data may then be used by various network elements for session peering. This document focuses on the Session Peering Provisioning Protocol used by clients to provision registries. The document provides a set of guiding principles for the design of this protocol like extensibility and independent transport definitions, a basic data model that meets some of the requirements discussed in DRINKS and an early XML Schema Document. |
| | Storing Host Locators in HIP Resource Record |
| |
|
There is a resource record (RR) in the Domain Name System (DNS) used for the Host Identity Protocol (HIP). This document proposes to store the host locators in the HIP resource records as well. |
| | Shim6 with IPv4 locators through 6to4 |
| |
|
A limitation of Shim6 is that it only works with IPv6. With 6to4, it is possible for hosts that only have IPv4 connectivity to still enjoy Shim6's multihoming benefits. |
| | Client Capabilities for OGPX |
| |
|
client side capabilities for OGPX. |
| | OGPX layering and architectural patterns |
| |
|
Architectural layering and patterns for OGPX. |
| | End to End NAT |
| |
|
According to the end to end argument, NAT function can completely and correctly be implemented only with the knowledge and help of end hosts. By making NAT visible to the end hosts of NAT clients and let the hosts help NAT gateways, NAT actually becomes correct, complete, and end to end transparent. End to end NAT is upper compatible to legacy NAT while enabling various transport protocols (ICMP, SCTP, IPSEC), DNS reverse look up, Multicast and Mobile IP. |
| | Routing algorithm based on the flow sensing parameter |
| |
|
The packet loss rate of each path between the source node and destination node can be obtained through two methods, one is direct measurement, another approach is proposed in this document calculating the packet loss rate based on the flow sensing parameter. The core idea of the calculating approach is the flow sensing parameter, which can be used to calculate the packet loss rate of each path between the source node and destination node and select the path whose packet loss rate is smallest to be the data transmission path. |
| | RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) |
| |
|
This document specifies real-time transport protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Three media type registrations are included for EVRC-NW RTP payload formats. In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as e-mail. |
| | Applicability Statement of NSIS Protocols in Mobile Environments |
| |
|
Mobility of an IP-based node affects routing paths, and as a result, can have a significant effect on the protocol operation and state management. This draft discusses the effects mobility can cause to the NSIS protocol suite, and how the protocols operate in different scenarios, with mobility management protocols. |
| | Requirements for Point-to-Multipoint Pseudowire |
| |
|
This document presents a set of requirements for providing an unidirectional Point-to-Multipoint PWE3 (Pseudowire Emulation Edge to Edge) emulation. The requirements identified in this document are related to architecture, signaling and maintenance aspects of a Point-to-Multipoint PW operation. They are proposed as guidelines for the standardization of such mechanisms. Among other potential applications Point-to-Multipoint PWs SHOULD be used to optimize the support of multicast services as defined in the Layer 2 Virtual Private Network working group. |
| | TLS encryption for RADIUS over TCP (RadSec) |
| |
|
This document specifies security on the transport layer (TLS) for the RADIUS protocol [RFC2865] when transmitted over TCP [I-D.dekok-radext-tcp-transport]. This enables dynamic trust relationships between RADIUS servers. |
| | NAI-based Dynamic Peer Discovery for RADIUS over TLS and DTLS |
| |
|
This document specifies a means to find authoritative AAA servers for a given NAI realm as defined in [RFC4282]. It can be used in conjunction with RADIUS over TLS and RADIUS over DTLS. |
| | The RObust Header Compression (ROHC) Framework |
| |
|
The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics. The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095. This specification obsoletes RFC 4995. It fixes one interoperability issue that was erroneously introduced in RFC 4995, and adds some minor clarifications. |
| | Models for Intra-Domain Presence and Instant Messaging (IM) Bridging |
| |
|
Presence and Instant Messaging (IM) bridging involves the sharing of presence information and exchange of IM across multiple systems within a single domain. As such, it is a close cousin to presence and IM federation, which involves the sharing of presence and IM across differing domains. Presence and IM bridging can be the result of a multi-vendor network, or a consequence of a large organization that requires partitioning. This document examines different use cases and models for intra-domain presence and IM bridging. It is meant to provide a framework for defining requirements and specifications for presence and IM bridging. |
| | Location Conveyance for the Session Initiation Protocol |
| |
|
This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The extension covers end-to-end conveyance as well as location-based routing, where SIP servers make routing decisions based on the location of the user agent client. |
| | SPEERMINT Security Threats and Suggested Countermeasures |
| |
|
This memo presents the different security threats related to SPEERMINT, classifying them into threats to the Lookup Function (LUF), Location Routing Function (LRF), to the Signaling Function (SF) and to the Media Function (MF). The different instances of the threats are briefly introduced inside the classification. Finally, the existing security solutions for SIP and RTP/RTCP are presented to describe the countermeasures currently available for such threats. Security requirements for SPEERMINT can be found in draft-ietf-speermint-requirements. The objective of this document is to identify and enumerate SPEERMINT-specific threat vectors and to give guidance for implementers on selecting appropriate countermeasures. |
| | TCP Options and MSS |
| |
|
This memo discusses what value to use with the TCP MSS option. |
| | Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples |
| |
| | draft-ietf-xcon-examples-01.txt |
| | Date: |
13/07/2009 |
| | Authors: |
Mary Barnes, Chris Boulton, Lorenzo Miniero, Roberta Presta, Simon Romano |
| | Working Group: |
Centralized Conferencing (xcon) |
| | Formats: |
txt |
|
This document provides detailed call flows for the scenarios documented in the Centralized Conferencing (XCON) Framework and the XCON Scenarios. The call flows document the use of the interface between a conference control client and a conference control server using the Centralized Conferencing Manipulation Protocol (CCMP). The objective is to provide a base reference for both protocol researchers and developers. |
12/07/2009
| |
|
| |
| | Multisession BGP |
| |
|
This specification augments "Multiprotocol Extensions for BGP-4" (MP- BGP) by proposing a mechanism to facilitate the use of multiple sessions between a given pair of BGP speakers. Each session is used to transport routes related by some session-based attribute such as AFI/SAFI. This provides an alternative to the MP-BGP approach of multiplexing all routes onto a single connection. Use of this approach is expected to provide finer-grained fault management and isolation as the BGP protocol is used to support more and more diverse services. |
| | Requirements for Multicast AAA coordinated between Content Provider(s) and Network Service Provider(s) |
| |
| | draft-ietf-mboned-maccnt-req-08.txt |
| | Date: |
12/07/2009 |
| | Authors: |
Tsunemasa Hayashi, Haixiang He, Hiroaki Satou, Hiroshi Ohta, Susheela Vaidya |
| | Working Group: |
MBONE Deployment (mboned) |
| | Formats: |
txt |
|
This memo presents requirements in the area of accounting and access control for IP multicasting. The scope of the requirements is limited to cases where Authentication, Accounting and Authorization (AAA) functions are coordinated between Content Provider(s) and Network Service Provider(s). In order to describe the new requirements of a multi-entity Content Deliver System(CDS) using multicast, the memo presents three basic business models: 1) the Content Provider and the Network Provider are the same entity, 2) the Content Provider(s) and the Network Provider(s) are separate entities and users are not directly billed, and 3) the Content Provider(s) and the Network Provider(s) are separate entities and users are billed based on content consumption or subscriptions. The requirements of these three models are listed and evaluated as to which aspects are already supported by existing technologies and which aspects are not. General requirements for accounting and admission control capabilities including quality-of-service (QoS) related issues are listed and the constituent logical functional components are presented. This memo assumes that the capabilities can be realized by integrating AAA functionalities with a multicast CDS system, with IGMP/MLD at the edge of the network. |
| | MPLS Upstream Label Assignment for RSVP-TE |
| |
|
This document describes procedures for distributing upstream-assigned labels for Resource Reservation Protocol - Traffic Engineering (RSVP- TE). It also describes how these procedures can be used for avoiding branch LSR traffic replication on a LAN for RSVP-TE point-to- multipoint (P2MP)LSPs. |
| | MPLS Upstream Label Assignment for LDP |
| |
|
This document describes procedures for distributing upstream-assigned labels for Label Distribution Protocol (LDP). It also describes how these procedures can be used for avoiding branch LSR traffic replication on a LAN for LDP point-to-multipoint (P2MP)LSPs. |
| | The "tdb" URI scheme: denoting described resources |
| |
|
This document defines a URI scheme, "tdb" ( standing for "Thing Described By"). It provides a semantic hook for allowing anyone at any time to mint a URI for anything that they can describe. Such URIs may include a timestamp to fix the description at a given date or time. This URI scheme may reduce the need to define define new URN namespaces merely for the purpose of creating stable identifiers. In addition, they provide a ready means for identifying "non-information resources" by semantic indirection -- a way of creating a URI for anything. Note This document is not a product of any working group. Many of the ideas here have been discussed since 2001. This document has been discussed on the mailing list . Previous versions have couched "tdb" as a URN namespace, and included a "duri" scheme for fixing date without indirection, which seems unnecessary. It was originally written as a thought experiment as a way of resolving the use/mention problem in semantic web applications, but may have other uses. |
| | Registration of the Real-time-text Media Feature Tag |
| |
|
This memo defines a new Media Feature Tag "real-time-text" for use in SIP registration and session establishment. This is used to indicate if a device capable of text communication has full real-time text capabilities or limitations in its capabilities requiring the users to apply some turn-taking habits. To the RFC editor Please replace y.y with the assigned ASN.1 identifier and XXXX with the RFC number of this specification. |
| | Text media handling in RTP based real-time conferences |
| |
|
This memo specifies methods for text media handling in multi-party calls, where the text is carried by the RTP protocol. Real-time text is carried in a time-sampled mode according to RFC 4103. Centralized multi-party handling of real-time text is achieved through a media control unit coordinating multiple RTP text streams into one RTP session, identifying each stream with its own SSRC. Identification for the streams are provided through the RTCP messages. This mechanism enables the receiving application to present the received real-time text medium in different ways according to user preferences. Some presentation related features are also described explaining suitable variations of transmission and presentation of text. Call control features are described for the SIP environment, while the transport mechanisms should be suitable for any IP based call control environment using RTP transport. An alternative method using a single RTP stream and source identification inline in the text stream is also described. |
| | Proxy Mobile IPv6 Management Information Base |
| |
|
This memo defines a portion of the Management Information Base (MIB), the Proxy Mobile-IPv6 MIB, for use with network management protocols in the Internet community. In particular, the Proxy Mobile-IPv6 MIB will be used to monitor and control the mobile access gateway (MAG) node and the local mobility anchor (LMA) functions of a Proxy Mobile IPv6 (PMIPv6) entity. |
| | Guidelines for Internationalized Email Deployment |
| |
|
Key RFCs for internationalized email address have been published, specifying the basic protocols for using it. This document provides some guidelines for implementing the email systems that support Email Address Internationalization (EAI). Its aim is to give some suggestions and help the engineers to implement these protocols. |
| | BRPC Extensions for Point-to-Multipoint Path Computation |
| |
|
The ability to compute constrained Traffic Engineering Label Switched Paths (TE LSPs) for point-to-multipoint (P2MP) LSPs in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains (where a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems) has been identified as a key requirement [PCEP-P2MP-REQ]. This document addresses this requirement by extending backward recursive path computation (BRPC) technique proposed for Point-to-Point (P2P) LSPs in [P2P-BRPC] for P2MP LSP path computation in a multiple domains network. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. |
| | ALTO Service Discovery |
| |
|
Application-Layer Traffic Optimization (ALTO) service aims to provide distributed applications with information to perform better-than- random initial peer selection when multiple peers in the network are available to provide a resource or service. In order to discover an Application-Layer Traffic Optimization (ALTO) Server, a set of mechanisms are required. These mechanisms enable applications to find an information source which provides them with information regarding the underlying network. This document discusses various scenarios of ALTO discovery and specifies the use of several available options such as DHCP or DNS. |
| | Routing Architecture for the Next Generation Internet (RANGI) |
| |
|
IRTF Routing Research Group (RRG) is exploring a new routing and addressing architecture to address the issues with the current Internet, e.g., mobility, multi-homing, traffic engineering, and especially the routing scalability. This document describes a new identifier (ID)/locator split based routing and addressing architecture, called Routing Architecture for the Next Generation Internet (RANGI), in an attempt to deal with the above problems. |
| | Transition Mechanisms for Routing Architecture for the Next Generation Internet (RANGI) |
| |
|
The Routing Architecture for the Next Generation Internet (RANGI) described in [RANGI] is a proposal for solving routing scalability, mobility, multihoming, traffic engineering and other issues facing the current Internet. This document describes some transition mechanisms for the RANGI. With these mechanisms, legacy IPv4 and IPv6 hosts can communicate with RANGI hosts, and vice versa. |
| | An Incremental Deployable Mapping Service for Scalable Routing Architecture |
| |
| | draft-chen-lisp-er-mo-01.txt |
| | Date: |
12/07/2009 |
| | Authors: |
Gang Chen, Hui Deng, Bo Zhou, Mingwei Xu, Dong Huo, Yu Cao |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document describes a mechanism of providing mapping service for LISP-like architecture. The mapping service comprises of EID Router (ER) mechanism and supplementary DHT Mapping Overlay (MO), in which ER mechanism is for reducing forwarding entries in routers while driving the packets to the destination through tunnels, and the DHT MO serves as a supplement that provides specific mappings to reduce the number of tunnels. The mechanism is flexibly deployable for ISPs since it costs little and is easy to progress. |
11/07/2009
| |
|
| |
| | Extensions to IS-IS for Layer-2 Systems |
| |
|
This document specifies the IS-IS extensions necessary to support multi-link IPv4 and IPv6 networks, as well as to provide true link state routing to any protocols running directly over layer 2. While supporting this concept involves several pieces, this document only describes extensions to IS-IS. We leave it to the systems using these IS-IS extensions to explain how the information carried in IS-IS is used. |
| | Support for Sieve in Internet Message Access Protocol (IMAP4) |
| |
|
Sieve defines an email filtering language that can, in principle, plug into any point in the processing of an email message. As defined in the base specification, it plugs into mail delivery. This document defines how Sieve can plug into points in the IMAP protocol where messages are created or changed, adding the option of user- defined or installation-defined filtering (or, with Sieve extensions, features such as notifications).Note This document defines extensions to IMAP and Sieve. For now, it is the work of the Lemonade Working Group (Enhancements to Internet email to support diverse service environments), but it will be moved to the Sieve working group at some point. 1. Discussion of this document should be taken to the Sieve mailing list at mailto:ietf-mta-filters@imc.org 2. Subscription requests can be sent to mailto:ietf-mta-filters-request@imc.org?body=subscribe (send an email message with the word "subscribe" in the body). 3. A WWW archive of back messages is available at http://www.ietf.org/mail-archive/web/sieve/index.html 4. Older messages, which were posted to the lemonade mailing list, are archived at http://www.ietf.org/mail-archive/web/lemonade/index.html |
| | Web Linking |
| |
|
This document specifies relation types for Web links, and defines a registry for them. It also defines how to send such links in HTTP headers with the Link header-field. |
| | Presentation of Text Conversation in realtime and en-bloc form |
| |
|
This specification defines methods for presentation of a text conversation with focus on the real-time features. The aim is to give the participants in a conversation a good opportunity to perceive the real-time flow of the conversation and also provide a display of the history of the conversation that makes it easy to read. Both two-party and multi-party situations are defined. |
| | A Quick Crash Detection Method for IKE |
| |
| | draft-nir-ike-qcd-05.txt |
| | Date: |
11/07/2009 |
| | Authors: |
Yoav Nir, Frederic Detienne, Pratima Sethi |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt xml |
|
This document describes an extension to the IKEv2 protocol that allows for faster detection of SA desynchronization using a saved token. When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the other peer to discover that the reboot has occurred, thus delaying recovery. In this text we propose an extension to the protocol, that allows for recovery immediately following the restart. |
| | Best Current Practices for SIP Interoperability |
| |
|
This document identifies several commonly found interoperability issues with SIP, and provides guidance to implementers for how to avoid them. This is an initial set of commonly found problems. |
| | Extensions to OSPF to Support Mobile Ad Hoc Networking |
| |
|
This document describes extensions to OSPF to support mobile ad hoc networks (MANETs). The extension, called OSPF-OR, includes a mechanism for link-local signaling, a OSPF-MANET interface, a simple technique to reduce the size of Hello packets by only transmitting incremental state changes, and a method for optimized flooding of routing updates. It also provides a means to reduce unnecessary adjacencies to support larger MANET networks. |
| | Securing RPSL Objects with RPKI Signatures |
| |
|
This document describes a method to allow parties to electronically sign RPSL-like objects and validate such electronic signatures. This allows relying parties to detect accidental or malicious modifications on such objects. It also allows parties who run Internet Routing Registries or similar databases, but do not yet have RPSS-like authentication of the maintainers of certain objects, to verify that the additions or modifications of such database objects are done by the legitimate holder(s) of the Internet resources mentioned in those objects. |
| | Design Considerations for Session Initiation Protocol (SIP) Overload Control |
| |
|
Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document discusses models and design considerations for a SIP overload control mechanism. |
10/07/2009
| |
|
| |
| | Guidelines for Internationalized Email Clients |
| |
|
This document provides some guidelines for email clients that support Email Address Internationalization (EAI) as outlined in RFC 4952. A number of interoperability cases between different versions of email components are reviewed. Recommendations are made to improve interoperability and usability and to minimize discrepancies between the display of composed and received email in different language environments. |
| | OSPFv3 as a PE-CE routing protocol |
| |
| | draft-ietf-l3vpn-ospfv3-pece-03.txt |
| | Date: |
10/07/2009 |
| | Authors: |
Padma Pillay-Esnault, Peter Moyer, Jeff Doyle, Emre Ertekin, Michael Lundberg |
| | Working Group: |
Layer 3 Virtual Private Networks (l3vpn) |
| | Formats: |
txt |
|
Many Service Providers (SPs) offer Virtual Private Network (VPN) services to their customers using a technique in which Customer Edge (CE) routers are routing peers of Provider Edge (PE) routers. The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLS IP VPN". Originally only IPv4 was supported and it was later extended to support IPv6 VPNs as well. Extensions were later added for the support of the Open Shortest Path First protocol version 2 (OSPFv2) as a PE-CE routing protocol for the IPv4 VPNs. This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functionality is identical to that of OSPFv2 except for the differences described in this document. |
| | SDP media capabilities Negotiation |
| |
|
Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. In this document, we extend the framework by defining media capabilities that can be used to negotiate media types and their associated parameters. This extension is designed to map easily to existing and future SDP media attributes, but not encodings or formatting. |
| | Device Capability Negotiation for Device-Based Location Determination and Location Measurements in HELD |
| |
|
A framework for the exchange of capabilities in HELD is described. Capabilities for enabling Device-based measurements and Device-based location generation are defined based on this framework. |
| | Chatrooms within a Centralized Conferencing (XCON) System |
| |
|
The document "A Framework for Centralized Conferencing" defines a centralized conference as both signaling and protocol agnostic. The primary examples within this framework focus on audio and video as the media types for the session. This document provides an overview of the mechanisms defined in the centralized conferencing framework that can be used to support multi-user chat. In addition, the document describes additional functionality and requirements necessary to provide feature rich functionality. |
| | Shelter Service And Classification |
| |
|
This document defines and registers a new service 'shelter', for the service URN to find, what instances of shelter service are closest to the user's location. The Location-to-Service Translation (LoST) protocol can provide these information for a geographical region. |
| | SACK-IMMEDIATELY extension for the Stream Control Transmission Protocol |
| |
|
This document defines a method for a sender of a DATA chunk to indicate that the corresponding SACK chunk should be sent back immediately. |
| | IP Flow Anonymisation Support |
| |
|
This document describes anonymisation techniques for IP flow data and the export of anonymised data using the IPFIX protocol. It provides a categorization of common anonymisation schemes and defines the parameters needed to describe them. It provides guidelines for the implementation of anonymised data export and storage over IPFIX, and describes an Options-based method for anonymization metadata export within the IPFIX protocol, providing the basis for the definition of information models for configuring anonymisation techniques within an IPFIX Metering or Exporting Process, and for reporting the technique in use to an IPFIX Collecting Process. |
| | BFD with Graceful Restart |
| |
|
This document proposes an extension for Bidirectional Forwarding Detection (BFD) to support Graceful restart, in complementing Graceful restart support of the underlying protocol.This shall work consistently irespective of the bfd mode or protocol or the type of restart.This document describes the challenges to bfd in surviving a graceful restart and a generic solution to succeed. |
| | draft-jml-ipsec-ikev1-security-context-01 |
| |
|
This document describes the need for and use of a security context within IPsec. It describes the extension to the Internet IP Security Domain of Interpretation (IPsec DOI) [RFC2407] for the Internet Security Association and Key Management Protocol (ISAKMP) [RFC2408]. This extension supports the negotiation of the security context for a particular IP Authentication Header (AH) [RFC4302] or IP Encapsulating Security Payload (ESP) [RFC4303] security association. |
| | Security Context Addendum to IPsec |
| |
|
This document describes the high-level requirements needed within IPsec to support Mandatory Access Control (MAC) on network communications. It describes the extensions to the Security Architecture for the Internet Protocol [RFC4301] and the Internet Key Exchange Protocol Version 2 [RFC4306]. It also describes the negotiation of the security context for a particular Authentication Header (AH) [RFC4302] and/or Encapsulating Security Payload (ESP) [RFC4303] security association. |
| | Guidelines and Protocol Extensions for Combining SIP Based Real-time Media Sessions With XMPP Based Instant Messaging and Presence Service. |
| |
|
This memo defines guidelines and protocol extensions for combining Session Initiation Protocol (SIP) based real-time media sessions with Extensible Messaging and Presence Protocol (XMPP) based instant messaging and presence services in a seamless manner. This is accomplished by integration and protocol extension support in the endpoints, without requiring any changes in the SIP or XMPP server infrastructure. It is even possible that SIP and XMPP services are offered by different service providers. |
| | Mechanism for Peer-to-Peer Group Management using Multiple Overlays |
| |
|
This document introduces a mechanism for managing peer groups in structured peer-to-peer (P2P) overlay networks. Group management enables efficient and secure interaction between the group members (peers), by controlling the scope of propagation for the group- specific P2P messaging and other communications. The mechanism for group management, introduced in this document, is based on a multiple-overlay scheme. Each group is a separate overlay network with its own address space, resources, and message routing information. A common overlay is used for sharing information about the group overlays (sub-overlays). |
| | RMD-QOSM - The Resource Management in Diffserv QOS Model |
| |
| | draft-ietf-nsis-rmd-15.txt |
| | Date: |
10/07/2009 |
| | Authors: |
Attila Bader, Lars Westberg, Georgios Karagiannis, Cornelia Kappler, Hannes Tschofenig, Thomas Phelan, Attila Takacs, Andras Csaszar |
| | Working Group: |
Next Steps in Signaling (nsis) |
| | Formats: |
txt |
|
This document describes an NSIS QoS Model for networks that use the Resource Management in Diffserv (RMD) concept. RMD is a technique for adding admission control and pre-emption function to Differentiated Services (Diffserv) networks. The RMD QoS Model allows devices external to the RMD network to signal reservation requests to edge nodes in the RMD network. The RMD Ingress edge nodes classify the incoming flows into traffic classes and signals resource requests for the corresponding traffic class along the data path to the Egress edge nodes for each flow. Egress nodes reconstitute the original requests and continue forwarding them along the data path towards the final destination. In addition, RMD defines notification functions to indicate overload situations within the domain to the edge nodes. |
| | IP Fast Reroute Using Not-via Addresses |
| |
|
This draft describes a mechanism that provides fast reroute in an IP network through encapsulation to "not-via" addresses. A single level of encapsulation is used. The mechanism protects unicast, multicast and LDP traffic against link, router and shared risk group failure, regardless of network topology and metrics. |
09/07/2009
| |
|
| |
| | Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) |
| |
|
The Access Node Control Protocol (ANCP) aims to communicate QoS- related, service-related and subscriber-related configurations and operations between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)). The main goal of this protocol is to allow the NAS to configure, manage and control access equipments including the ability for the access nodes to report information to the NAS. The present document investigates security threats that all ANCP nodes could encounter. This document develops a threat model for ANCP security aiming to decide which security functions are required. Based on this, security requirements regarding the Access Node Control Protocol are defined. |
| | Forward Error Correction (FEC) Framework |
| |
|
This document describes for a framework for using forward error correction (FEC) codes with applications in public and private IP networks to provide protection against packet loss. The framework supports applying Forward Error Correction to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. This framework can be used to define Content Delivery Protocols that provide Forward Error Correction for streaming media delivery or other packet flows. Content Delivery Protocols defined using this framework can support any FEC Scheme (and associated FEC codes) which is compliant with various requirements defined in this document. Thus, Content Delivery Protocols can be defined which are not specific to a particular FEC Scheme and FEC Schemes can be defined which are not specific to a particular Content Delivery Protocol. |
| | Considerations for Civic Addresses in PIDF-LO - Guidelines and IANA Registry Definition |
| |
|
This document provides a guideline for creating civic address consideration documents for individual countries, as required by RFC 4776. Furthermore, this document also creates an IANA Registry referring to such address consideration documents and registers such an address consideration for Austria. |
| | OCRA: OATH Challenge-Response Algorithms |
| |
|
This document describes the OATH algorithm for challenge-response authentication and signatures. This algorithm is based on the HOTP algorithm [RFC4226] that was introduced by OATH (initiative for Open AuTHentication) [OATH] and submitted as an individual draft to the IETF in 2006. |
| | Link Metrics for OLSRv2 |
| |
|
This document describes how link metrics may be added, in a relatively straightforward manner, to the specification of OLSRv2, in order to allow routing by other than minimum hop count routes. In addition to metric signaling and use, the most significant change is a separation of the routing and flooding functions of MPRs. |
| | RAN Synchronization Requirements |
| |
|
This Internet draft describes RAN synchronization requirements, mainly about synchronization description and requirements, also includes some applications and problem description. |
| | BGP Extended Community for QoS Marking |
| |
|
This document specifies a simple signalling mechanism for inter- domain QoS marking using several instances of a new BGP Extended Community. Class based packet marking and forwarding is currently performed independently within ASes. The new QoS marking community makes the targeted Per Hop Behaviour within the IP prefix advertising AS and the currently applied marking at the interconnection point known to all access and transit ASes. This enables individual (re-)marking and possibly forwarding treatment adaptation to the original QoS class setup of the respective originating AS. The extended community provides the means to signal QoS markings on different layers, which are linked together in QoS Class Sets. It provides inter-domain and cross-layer insight into the QoS class mapping of the source AS with minimal signalling traffic. |
| | Framework and Requirements for MPLS Over Composite Link |
| |
|
This document states a traffic distribution problem in today's IP/MPLS network when multiple links are configured between two routers. The document presents motivation, a framework and requirements. It defines a composite link as a group of parallel links that can be considered as a single traffic engineering link or as an IP link, and used for MPLS. The document primarily focuses on MPLS traffic controlled through control plane protocols, the advertisement of composite link parameter in routing protocols, and the use of composite links in the RSVP-TE and LDP signaling protocols. Interactions with the data and management plane are also addressed. Applicability can be between a single pair of MPLS- capable nodes, a sequence of MPLS-capable nodes, or a multi-layer network connecting MPLS-capable nodes. |
| | Using SCTP as a Transport Layer Protocol for HTTP |
| |
|
Hyper-Text Transfer Protocol (HTTP) [RFC2616] requires a reliable transport for end-to-end communication. While historically TCP has been used for this purpose, this document proposes an alternative -- the Stream Control Transmission Protocol (SCTP) [RFC4960]. Similar to TCP, SCTP offers a reliable end-to-end transport connection to applications. Additionally, SCTP offers innovative services unavailable in TCP. This draft (i) specifies HTTP over SCTP's multistreaming service, (ii) lists open issues warranting more discussion and/or investigation, and (iii) shares some lessons learned from implementing HTTP over SCTP. Finally, this document highlights SCTP services that better match HTTP's needs than TCP. |
| | An IPv4 - IPv6 multicast translator |
| |
|
This document describes an IPv4 - IPv6 translator device that embeds all IPv4 multicast group addresses into IPv6, and allows IPv6 hosts to receive from and send to any IPv4 multicast group. This mechanism can be also used to allow IPv4 hosts to receive from and send to a subset of the IPv6 multicast groups. |
| | Burst Loss Metrics for IPPM |
| |
|
The IPPM Working Group has developed a one way packet loss metric that measures the loss rate on a Poisson probe stream between two hosts. However, the burst properties of packet loss are required to understand the impact of packet loss on applications. This draft defines one-way burst packet loss metrics that express the frequency and duration of loss episode, i.e., maximal sets of consecutively lost probe packets. The draft also defines a probing methodology under which the burst loss metrics are to be measured. |
| | Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 |
| |
|
This document describes the usage of Advanced Encryption Standard Counter Mode (AES-CTR), with an explicit initialization vector, by IKEv2 for encrypting IKE-SA and Child-SA negotiations. |
| | Basic Security Requirements of Authentication Protocol on Ad hoc |
| |
| | draft-wang-tinyauth-00.txt |
| | Date: |
09/07/2009 |
| | Authors: |
Weihong Wang, Tieming Chen, Yubing Lin, Yiling Cui |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document specifies basic security standards for authentication protocol on Ad hoc. The security standards are based on the ECDH to discover a authentication protocol between two nodes, and on the TinyOS simulation platform and Mica nodes. This document also defines elements of procedure for authentication protocol, including System Initialization, Key extract and the identity authentication. With these standards, authentication between two nodes can be completed in a certain time and a certain circles. |
| | An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package |
| |
|
This document describes an "xcap-diff" SIP (Session Initiation Protocol) event package for the SIP Event Notification Framework, which clients can use to receive notifications of changes to Extensible Markup Language (XML) Configuration Access Protocol (XCAP) resources. The initial synchronization information exchange and document updates are based on the XCAP Diff format. |
08/07/2009
| |
|
| |
| | Raptor FEC Schemes for FECFRAME |
| |
|
This document describes Fully-Specified Forward Error Correction (FEC) Schemes for the Raptor code and its application to reliable delivery of media streams in the context of FEC Framework. The Raptor code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in one or more repair flows in addition to the source symbols that are sent to the receiver(s) within a source flow. The Raptor code offers a close to optimal protection against arbitrary packet losses at a low computational complexity. Two FEC Schemes are defined, one for protection of arbitrary packet flows and another for protection of a single flow that already contains a sequence number. Repair data may be sent over arbitrary datagram transport (e.g. UDP) or using RTP. An RTP Payload Type is defined for this latter case. |
| | Mobile IPv6 Location Privacy Solutions |
| |
|
Mobile IPv6 (RFC 3775) enables a mobile node to remain reachable while it roams on the Internet. However, the location and movement of the mobile node can be revealed by the IP addresses used in signaling or data packets. In this document, we consider the Mobile IPv6 location privacy problem described in RFC 4882, and propose efficient and secure techniques to protect location privacy of the mobile node. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. |
| | IPv4 Mobility Extension for Multicast and Broadcast Packets |
| |
| | draft-chakrabarti-mip4-mcbc-04.txt |
| | Date: |
08/07/2009 |
| | Authors: |
Ahmad Muhanna, Samita Chakrabarti, Gabriel Montenegro, Yingzhe Wu, Basavaraj Patil |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This specification defines a new Mobile IPv4 extension which is used to negotiate the Multicast-Broadcast Encapsulation Delivery style in the case of Mobile IPv4 Foreign Agent Care-of Address mode registration. This mechanism allows the mobile node to negotiate which type of traffic to be delivered encapsulated to the foreign agent while delivering other types of IP packets using direct delivery style. In particular, this mechanism gives the flexibility to eliminate tunnel overhead in the (typically) wireless medium between the mobile node and the foreign agent. In addition to the reduced overhead, the new mechanism makes many multicast and broadcast services available to the mobile node in a much more deterministic and efficient way. |
| | Common TCP Evaluation Suite |
| |
|
This document presents an evaluation test suite for the initial evaluation of proposed TCP modifications. The goal of the test suite is to allow researchers to quickly and easily evaluate their proposed TCP extensions in simulators and testbeds using a common set of well- defined, standard test cases, in order to compare and contrast proposals against standard TCP as well as other proposed modifications. This test suite is not intended to result in an exhaustive evaluation of a proposed TCP modification or new congestion control mechanism. Instead, the focus is on quickly and easily generating an initial evaluation report that allows the networking community to understand and discuss the behavioral aspects of a new proposal, in order to guide further experimentation that will be needed to fully investigate the specific aspects of a new proposal. |
| | Information Model for Impaired Optical Path Validation |
| |
|
This document provides an information model for the optical impairment characteristics of optical network elements for use in GMPLS/PCE control plane protocols and mechanisms. This information model supports Impairment Aware Routing and Wavelength Assignment (IA-RWA) in optical networks in which path computation and optical path validation are essential components. This is not a general network management information model. This model is based on ITU-T defined optical network element characteristics as given in ITU-T recommendation G.680 and related specifications. This model is intentionally compatible with a previous impairment free optical information model used in optical path computations and wavelength assignment. |
| | Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP) |
| |
|
SDP has been extended with a capability negotiation mechanism framework that allows the endpoints to negotiate transport protocols and attributes. This framework has been extended with a Media capabilities negotiation mechanism that allows endpoints to negotiate additional media-related capabilities. This negotiation is embedded into the widely-used SDP offer/answer procedures. This memo extends the SDP capability negotiation framework to allow endpoints to negotiate a number of miscellaneous SDP capabilities. In particular, this memo provides a mechanism to negotiate media titles ("i=" line for each media), connection data ("c=" line), and media bandwidth ("b=" line). |
| | Reverse Binding for Proxy Mobile IPv6 |
| |
|
This memo proposes a scheme that utilizes only pre-established bi- directional tunnels between LMA and MAGs to support a fast handover effectively in Proxy Mobile IPv6. To expedite the handover procedure, we define new signaling messages, Fast PBU/PBA and Reverse PBU/PBA, exchanged by LMA and MAGs. Because any signaling messages exchanged by two MAGs are neither created nor utilized and thus bi- directional tunnel between MAGs is not created, the proposed scheme puts less overload upon network than the existing fast handover scheme for PMIPv6. It can also tackle effectively with the so-called ping-pong movement of mobile nodes. |
| | Information Encoding for Impaired Optical Path Validation |
| |
|
This document provides an information encoding for the optical impairment characteristics of optical network elements for use in path computation and optical path impairment validation. This encoding is based on ITU-T defined optical network element characteristics as given in ITU-T recommendation G.680 and related specifications. This encoding is intentionally compatible with a previous impairment free optical information encoding used in optical path computations and wavelength assignment. |
| | Protocol Analysis and Comparison of PPlive,PPstream and UUSee by Internet Measurement |
| |
|
In this draft we introduce an Internet measurement work for pplive, ppstream and UUSee. First, we give a brief introduction about our motivation and target of this measurement. We then introduce the methodology, platform, data and modeling of our measurement. Finally we outline the p2p media streaming protocols by the measurement. Zhang Expires January 9,2010 [page 2] Internet-Draft Protocol Analysis and Comparison of PPlive, PPstream and UUSee by Internet Measurement July 2009 |
| | The OAuth Security Model for Delegated Authorization |
| |
|
This document describes the security model for the OAuth authorization system, which allows a party that holds some authorization to delegate a subset of that authorization to another party, without requiring either party to disclose its credentials to the other. In this document, we describe a set of design constraints, a high-level work flow for establishing authorizations subject to those constraints, and set of security requirements for protocols that implement this model. |
| | Multicast security algorithm based on agent node |
| |
|
Multicast security algorithm based on agent node can select the group node corresponding to the smallest path cost to be the agent node, and multicast in accordance with the optimal multicast routing. In addition, the multicast source node uses the key different from the group key to encrypt multicast data to meet the requirements of multicast security. The agent nodes can be different for different multicast sources, which can spread the burden of the agent node and avoid the excessive burden problem when the same node as the agent node of different sources. |
| | Document: draft-ietf-pce-gmpls-aps-req-01.txt |
| |
|
The initial effort of PCE WG is specifically focused on MPLS (Multi- protocol label switching). As a next step, this draft describes functional requirements for GMPLS (Generalized MPLS) application of PCE (Path computation element). |
07/07/2009
| |
|
| |
| | The DHCPv4 Relay Agent Identifier Suboption |
| |
|
This memo defines a new Relay Agent Identifier suboption for the Dynamic Host Configuration Protocol's (DHCP) Relay Agent Information option. The suboption carries a value that uniquely identifies the relay agent device. The value may be administratively-configured or may be generated by the relay agent. The suboption allows a DHCP relay agent to include the identifier in the DHCP messages it sends. |
| | Extensible Authentication Protocol (EAP) Early Authentication Problem Statement |
| |
|
Extensible Authentication Protocol early authentication may be defined as the use of EAP by a mobile device to establish authenticated keying material on a target attachment point prior to its arrival. This draft discusses the EAP early authentication problem in detail. |
| | IMAP4 Multimailbox SEARCH Extension |
| |
|
The IMAP4 specification allows the searching only of the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the round-trips and waiting for various searches to complete, and not requiring disruption of the currently selected mailbox. This also uses MAILBOX and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses. Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to morg@ietf.org. |
| | Secure SCTP |
| |
|
This document explains the reason for the integration of security functionality into SCTP, and gives a short description of S-SCTP and its services. S-SCTP is fully compatible with SCTP defined in RFC4960, it is designed to integrate cryptographic functions into SCTP. |
| | Reporting Metrics: Different Points of View |
| |
|
Consumers of IP network performance metrics have many different uses in mind. This memo categorizes the different audience points of view. It describes how the categories affect the selection of metric parameters and options when seeking info that serves their needs. The memo then proceeds to discuss "long-term" reporting considerations (e.g, days, weeks or months, as opposed to 10 seconds). |
| | Relay Chaining in DHCPv4 |
| |
|
DHCP Relay Agents eliminate the necessity of having a DHCP server on each physical network. In certain network configurations, a DHCP server may be multiple subnets away from the DHCP client and multiple Relay Agents may be configured to relay DHCP messages to and from DHCP client. Such configuration can be supported only when each Relay Agent adds certain Information to DHCP messages before relaying them. This additional information helps in relaying the DHCP reply back to the DHCP client through the same path. This mechanism is referred as Relay Chaining. |
| | Digital Signature Methods for Location Dependability |
| |
|
The dependability of location information is closely related to the degree of trust placed in the source of that information. This document describes techniques that can be used to mitigate the impact of falsifying location information. The application of digital signatures is described, relating these methods to the attacks that they address. |
| | Optimized MAC Address Operations in VPLS with Redundancy |
| |
|
The Virtual Private LAN Service (VPLS) using Label Distribution Protocol (LDP) signaling is described in RFC 4762. That document describes a mechanism called MAC Address Withdrawal to remove or unlearn MAC addresses which have been dynamically learned in a VPLS instance. Further work in progress defines an extension to MAC Address Withdrawal procedure which can greatly restrict the scope of MAC flushing. This document provides a flushing-free mechanism which removes the need for MAC address flushing in a VPLS instance. This mechanism is called MAC Address Switching. |
| | A SIP Event Package for Subscribing to Changes to an HTTP Resource |
| |
|
The Session Initiation Protocol (SIP) is increasingly being used in systems that are tightly coupled with Hypertext Transport Protocol (HTTP) servers for a variety of reasons. In many of these cases, applications can benefit from being able to discover, in near-real- time, when a specific HTTP resource is created, changed, or deleted. This document proposes a mechanism, based on the SIP events framework, for doing so. This document further proposes that the HTTP work necessary to make such a mechanism work be extensible to support protocols other than SIP for monitoring HTTP resources. |
| | Source Address Finding (SAF) for IPv6 Translation Mechanisms |
| |
|
There are various recent proposals that would result in IPv6 translation becoming permanent. RFC 3424 discusses UNilateral Self- Address Fixing (UNSAF) mechanisms which are required for applications to work with most translation schemes, points out a number of problems with them, and requires an exit strategy for any UNSAF mechanism. This document discusses an alternative to UNSAF mechanisms should IPv6 translation become permanent. |
| | RSVP-TE extensions to GMPLS Calls |
| |
|
Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extensions are used to support Calls. Although it is stated that these mechanisms are applicable to any environment (including multi-area), the "Call Path" is determined hop-by-hop by each "Call Manager" in sequence along the path of the Call. However, it is desirable to allow the Call-initiator to identify the Call Path explicitly in some cases (especially in the multi-domain case). This document describes RSVP-TE signaling extensions to allow the Call-initiator to identify the Call Path explicitly when transit nodes (besides the Call-initiator and Call-terminator) are involved in these Calls. |
| | NFS Server-side Copy |
| |
|
This document describes a set of NFS operations for offloading a file copy to a file server or between two file servers. |
| | Diameter Attribute-Value Pairs for Cryptographic Key Transport |
| |
|
Some AAA applications require the transport of cryptographic keying material; this document specifies a set of Attribute-Value Pairs (AVPs) providing native Diameter support of cryptographic key delivery. |
| | MPLS-TP BFD for Proactive CC-CV and RDI |
| |
|
Several documents on BFD based OAM for MPLS-TP has been put forward and the dependencies between those drafts are not yet fully sorted out; this document is one of these drafts. It is published in now to make ideas, motivations and approaches available. However we expect the final BFD based solution for MPLS-TP will be a cooperation of the parties between the existing drafts and that the BFD based OAM solution for MPLS-TP will merge into an agreed set of drafts approved by the MEAD team. This document specifies the BFD extension and behaviour to meet the requirements for MPLS-TP proactive Continuity Check and Connectivity Verification functionality and the RDI functionality as defined in [3]. |
| | IXFR-ONLY to Prevent IXFR Fallback to AXFR |
| |
|
Presents IXFR-ONLY, a way for a DNS slave to prevent a DNS master from falling back from IXFR to AXFR. |
| | URN Namespace for news-related resources |
| |
|
This document describes a URN (Uniform Resource Name) namespace for identifying news-related data items. A news-related data item is an information resource used for news exchange that is expressed as an instance complying with a specific data schema. This may be the schema of IPTC news standards specifications such as NewsML 1 and the G2-Standards or the specification of any other body. |
| | Use of the RSA-KEM Key Transport Algorithm in CMS |
| |
|
The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key. This document specifies the conventions for using the RSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax (CMS). The ASN.1 syntax is aligned with ANS X9.44 and ISO/IEC 18033-2. |
06/07/2009
| |
|
| |
| | AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) |
| |
|
This document defines how AES-GCM, AES-CCM, and other Authenticated Encryption with Associated Data (AEAD) algorithms, can be used to provide confidentiality and data authentication mechanisms in the SRTP protocol. |
| | GRE and IP-in-IP Tunnels for Virtual Aggregation |
| |
|
The document "FIB Suppression with Virtual Aggregation" [I-D.grow-va] describes how FIB size may be reduced. That draft refers generically to tunnels, and leaves it to other documents to define the tunnel establishment methods for specific tunnel types. This document provides those definitions for GRE and IP-in-IP tunnels. |
| | Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute |
| |
|
This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects used to support two fast reroute (FRR) methods for Multiprotocol Label Switching (MPLS) based traffic engineering (TE). The two methods are one-to-one backup method and facility backup method. |
| | A BEEP Binding for the HELD Protocol |
| |
|
A BEEP binding is described for HELD. This binding is more suitable than the basic HTTP binding in scenarios where multiple messages are sent between the same two parties. |
| | Providing Satellite Navigation Assistance Data using HELD |
| |
|
This document describes a method for providing Global Navigation Satellite System (GNSS) assistance data using the HTTP-Enabled Location Delivery (HELD) protocol. An assistance data request is included with the HELD location request and the Location Information Server (LIS) provides assistance data along with location information. |
| | SRTP Store-and-Forward Use Cases and Requirements |
| |
|
The Secure Real-time Transport Protocol (SRTP) was designed to allow simple and efficient protection of RTP. To provide this, encryption and authentication of media and control signaling are tightly coupled to the RTP session, and the information in the RTP header. Hence, in general, it is not possible to perform store-and-forward of protected media using SRTP. This document gives, based on a use case analysis, requirements that SRTP and new SRTP transforms need to satisfy in order to allow secure store-and-forward operation. A first outline on how to introduce the needed new functionality and transforms in SRTP is also presented. |
| | SEAL with Reliability Extensions (SEAL-RE) |
| |
|
The Subnetwork Encapsulation and Adaptation Layer (SEAL) includes two basic modes of operation known as "SEAL with Fragmentation Sensing (SEAL-FS)" and "SEAL with Traffic Engineering (SEAL-TE)". This document specifies an additional mode known as "SEAL with Reliability Extensions (SEAL-RE)". |
| | Arcband Shape Binary Encoding |
| |
|
This document describes a binary encoding format for an arcband, which is compatible with the binary encoding defined by 3GPP [3GPP23.032], and which is widely used in today's cellular networks. This encoding can additionally be used by a number of other protocols, which demand a bandwidth efficient encoding of location information, eg link layers like IEEE 802.11. |
| | On the association of GMPLS Recovery LSPs |
| |
|
End-to-End and Segment Recovery are defined for GMPLS (Generalized Multi-Protocol Label Switching) controlled label switched paths (LSPs) in RFC 4872 and RFC 4873 respectively. Both definitions use the ASSOCIATION object to associate recovery LSPs with the LSP they are protecting. This document provides additional narrative on how such associations are to be identified. This document does not define any new procedures or mechanisms and is strictly informative in nature. It may not be obvious to the informed reader why this document is necessary. |
| | Requirements for IP multicast performance monitoring |
| |
|
With increasing deployment of IP multicast in service provider (SP) network, SPs need a carrier-grade IP multicast performance monitoring solution. This document describes the requirements for such a system for a SP network. This system enables efficient performance monitoring in SPs' production network and provides diagnostic information in case of performance degradation or failure. |
| | Preserving the reachability of LISP ETRs in case of failures |
| |
|
Maintaining reachability of an EID prefix despite the failures of ETRs is a key concern in the LISP architecture. In this document, we first analyse this problem in comparison with traditional routing protocols. Then, we explain how Internet Service Providers could offer a service that preserves the reachability of the LISP ETRs of their customers in case of failures. |
| | Session Description Protocol (SDP) Connectivity Capability (CCAP) Attribute |
| |
|
This memo proposes a mechanism which allows to carry multiple IP addresses, of different address families (e.g., IPv4, IPv6), in the same SDP offer/answer. The proposed attribute solves the backward compatibility problem which plagued ANAT, due to its syntax. |
| | Connection Verification and Continuity Check for MPLS Transport Profile Label Switched Path |
| |
| | draft-boutros-mpls-tp-cv-cc-00.txt |
| | Date: |
06/07/2009 |
| | Authors: |
Sami Boutros, Siva Sivabalan, George Swallow, David Ward, Stewart Bryant |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
Connection Verification (CV) and Continuity Check (CC) are important Operations, Administration, and Management (OAM)functions of MPLS Transport Profile (MPLS-TP). This document specifies methods for CV and CC for MPLS-TP Label Switched Path (LSP) using Bidirectional Forwarding Detection (BFD). |
| | Connection verification for MPLS Transport Profile LSP |
| |
|
This document specifies method for verifying the connection of an MPLS Transport Profile(MPLS-TP) Label Switched Path (LSP) for management purpose. The proposed extension is based on MPLS Operation, Administration, and Maintenance (OAM). The goal is to verify that an MPLS-TP LSP is properly setup in both control and data planes, as well as to record the identities of all the LSRs along the path of MPLS-TP LSP. |
| | Host Identity Protocol (HIP) Multi-hop Routing Extension |
| |
|
This document specifies two extensions to HIP to implement multi-hop routing. The first extension allows a HIP packet to carry the list of hosts that forwarded it. The second extension allows implementing source routing in HIP. That is, a host sending a HIP packet can define a set of hosts that the HIP packet should traverse. |
| | Host-based Translation Problem Statement |
| |
|
When operators start to customize user terminals, host-based IPv6 translation will be feasible. Host-based translation should overcome single-point failure problems and support various connections between two IP families networks simultaneously. In addition, legacy IPv4 applications should not be modified. This document will discuss host-based translation applicable scenarios and corresponding issues. |
| | EDNS0 OWNER Option |
| |
|
The DNS-SD Sleep Proxy Service uses a message format identical to that used by standard DNS Update, with two additional pieces of information: the identity of the sleeping server to which the records belong, and the Wake-on-LAN Magic Packet bit pattern which should be used to wake the sleeping server. This document specifies the EDNS0 option used to carry that additional information. |
| | The Internet Assigned Number Authority (IANA) Application Configurations Access Protocol (ACAP) Vendor Subtrees Registry |
| |
|
The original ACAP specification included a vendor registry now used in other protocols. This document updates the description of this registry, removing the need for a direct normative reference to ACAP, and removing ambiguity. |
| | PET-based solution for IPv4/IPv6 coexistence |
| |
| | draft-cui-pet-00.txt |
| | Date: |
06/07/2009 |
| | Authors: |
Yong Cui, Mingwei Xu, Shengling Wang, Xing Li, Jianping Wu |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
IPv6 offers significant advantages over IPv4, however it will take long time to replace IPv4 with IPv6. Therefore, these two protocols are expected to coexist during the transition period. Currently, there are many transition devices deployed to solve transition problems. Most of them only use one technology (either translation or tunneling). However, any transition technology has limitation and application scope. In transition scenarios, besides IP version of source, middle and destination network, the network characteristic (a regular edge network or a backbone) has key impact on system performance of transition methods. Therefore, we need to decide which transition method should be used in some typical transition scenarios and how the transition and tunneling devices collaborate for solving transition problems. This draft introduces a smart toolbox named PET (shortfor Prefixing, encapsulation and translation) which includes all fundamental elements needed in all transition scenarios, such as the control and data plane operations of tunneling and translation. Based on PET, we propose a network side transition solution. In this framework, there deploys only one kind of transition device, i.e. PET. Through the collaboration of PETs, the transition problems can be solved. In this draft, we give the advantages and disadvantages of all transition methods PET may adopt according to IP version of source, middle and destination network, and the network characteristic. |
| | PET-based framework for IPv4/IPv6 coexistence |
| |
|
IPv6 offers significant advantages over IPv4, however it will take a long time to replace IPv4 with IPv6. Therefore, these two protocols are expected to coexist during the transition period. Currently, there are many transition technologies, such as translation and tunneling. In some typical transition scenarios, both tunneling and translation are needed. However, either translation or tunneling has limitation and application scope. In addition, besides IP version of source, middle and destination network, the network property (a regular edge network or a backbone) has key impact on system performance. Therefore, we need to decide which transition method should be used in some typical transition scenarios and how transition and tunneling collaborate for solving transition problems. This draft presents an IPv4-IPv6 transition framework, which is a network side transition solution. It introduces a toolbox named PET (short for Prefixing, encapsulation and translation) to solve IPv4- IPv6 transition. PET includes fundamental elements needed in transition scenarios, which provides the flexibility for network to decide the proper transition methods. In addition, this draft also addresses how to deploy PETs and analyze the advantages and disadvantages of all transition methods that PET may adopt. |
| | VA-Based Softwire |
| |
|
The increasing deployment of IPv6 networks in both customer networks and ISP networks leads to two common traversing transition scenarios: in the first scenario, an IPv6-only backbone network needs to provide IP connectivity between IPv4 networks, we call it IPv4-over-IPv6 scenario; In the second scenario, IPv6 networks need to be interconnected over an IPv4 transit network, we call it IPv6-over- IPv4 scenario. In both scenarios, the ISP operating the transit network of one address family must offer transit services for attached client networks of the other address family. The Softwire WG has defined softwire mesh mechanism [RFC5565] for the two traversing scenarios. Softwire mesh uses automatic softwire tunnels employing multi-protocol BGP extensions for distributing E-IP routes, where both BGP peers and tunnels between PEs forms a full-mesh architecture. Inspired by the Virtual Aggregation approach [I-D.ietf-grow-va] to IPv4 routing scalability, in this draft we proposed a scalable mechanism for distributing E-IP routes over the transit network. Our solution can significantly reduce the forwarding information base (FIB) size at Address Family Border Routers (AFBRs) as well as the total amount of routing updates, and offers the ISP an easy way to manage the transit service. |
| | VALARM Extensions for iCalendar |
| |
|
This document defines a set of extensions to the iCalendar VALARM component to enhance use of alarms and improve interoperability between clients and servers. |
| | ALTO-FCP: Application Layer Traffic Optimization Feedback-Based Client Protocol |
| |
| | draft-despotovic-alto-feedback-cp-00.txt |
| | Date: |
06/07/2009 |
| | Authors: |
Zoran Despotovic, Wolfgang Kellerer, Spiros Spirou, Dirk Staehle, Maria Rodriguez, Ioanna Papafili |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
In some networked applications, such as peer-to-peer file sharing, the same resource (e.g., a file or a server process) is available at several potential resource providers. Resource consumers typically try to select providers so that application performance is improved, establishing an overlay topology of direct logical links in the process. However, lack of reliable information about the underlying network can lead to poor choices and suboptimal application performance. In addition, resulting application traffic is largely oblivious to technical, economical, and political constraints at the network level, causing problems for network operators. This document describes a protocol that facilitates the exchange of information between an overlay and the underlying network. Such information can be used at each layer to make decisions that are not detrimental to the other layer or, ideally, are beneficial to both. |
| | Security Framework for MPLS-TP |
| |
|
[page 1] MPLS-TP Security framework July 2009 This document provides a security framework for Multiprotocol Label Switching Transport Profile (MPLS-TP). MPLS-TP Requirements and MPLS-TP Framework are defined in [MPLS-TP REQ] and [MPLS-TP FW]. Extended from MPLS technologies, MPLS-TP introduces new OAM capabilities, transport oriented path protection mechanism, and strong emphasis on static provisioning supported by network management systems. This document addresses the security aspects that are relevant in the context of MPLS-TP specifically. It describes the security requirements for MPLS-TP; potential securities threats and migration procedures for MPLS-TP networks and MPLS-TP inter-connection to MPLS, GMPLS networks. The general security analysis and guidelines for MPLS and GMPLS are addressed in [MPLS/GMPLS Security FW], will not be covered in this document. |
| | Shortest Path Bridging and Backbone Bridging with IS-IS |
| |
| | draft-fedyk-isis-spb-00.txt |
| | Date: |
06/07/2009 |
| | Authors: |
Don Fedyk, Peter Ashwood-Smith, Nigel Bragg, David Allan, Jérôme Chiabaut |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
Several techniques are being developed which use IS-IS to deliver link state based layer 2 forwarding. The superset of the extensions proposed to IS-IS to allow these capabilities is found in [IS-IS- L2]. One technique for layer 2 forwarding is being specified in the IEEE 802.1aq task group, under the over-arching title of "Shortest Path Bridging" (SPB). SPB however only requires a subset of the proposed IS-IS extensions in [IS-IS-L2]. For clarity this informational draft documents only the subset required by SPB. In addition a high level introduction, describing how these TLVs are used is provided for those who do not follow the IEEE work in detail. A reference is also given to the normative IEEE 802.1aq document The ordering of material in this document follows that of Clause 28 of IEEE 802.1aq, to aid cross-referencing. |
| | HTTP Extensions for Simultaneous Download from Multiple Mirrors |
| |
|
This document describes an extension to HTTP by which servers can automatically inform clients of mirrors of resources. Clients can then simultaneously request segments of the resource from different servers, enhancing both network and server utilisation, download speeds, and thus user experience. |
| | Suite VPN-D: Cryptographic Algorithm Suite with 112-bit Security for IPSEC |
| |
|
This document defines a suite of cryptographic algorithms that target a 112-bit security level. Additionally, this document defines the use of these algorithms for use in IPSEC. |
| | The isup-oli SIP URI Parameter |
| |
|
A SIP URI parameter "isup-oli" is being used for interworking the ISUP Originating Line Information parameter or equivalent PSTN signaling information with SIP. This parameter has been also been discussed in various documentation, but nowhere is it formally documented. This document formally documents the usage, syntax, and semantics of this parameter, providing a reference for discussion of this parameter. It does not seek to achieve standardization of this parameter. |
| | Signaling BFD configuration for a backup path in an FRR environment |
| |
|
Today there is no support in the RSVP protocol to dynamically signal the enabling and configuring of the BFD (Bi-directional Forwarding Detection) on a backup path. This document introduces a new RSVP object called "FRR backup BFD object". The procedures described in this document are only applicable to Fast Reroute LSPs [RFC4090]. |
| | DSA with SHA-2 for DNSSEC |
| |
|
This document describes how to specify DSA keys and signatures based on SHA-256 with a specific set of parameters in DNSSEC. The keys used are 2048 bits, and have an equivalent security level of 112 bits. |
| | Elliptic Curve DSA for DNSSEC |
| |
|
This document describes how to specify Elliptic Curve DSA keys and signatures in DNSSEC. It lists curves of different sizes, and uses the SHA-2 family of hashes for signatures. |
| | VALID |
| |
| | draft-hoyer-valid-00.txt |
| | Date: |
06/07/2009 |
| | Authors: |
Philip Hoyer, Tim Moses, Mingliang Pei, Salah Machani |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt xml |
|
This document describes a Web-service interface standard for an authentication-data validation service that supports risk-based, multi-factor authentication.This standard enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure. |
| | DNS Encoding of Domain Reputation and IP# Classification |
| |
|
This document defines the format of a new Resource Record (RR) for the Domain Naming System (DNS), (and reserves a corresponding DNS type mnemonic: DRIC and numerical code - to be done) This definition deals with associating a reputation measure to a domain, a host name, or a url before domain name resolution. It also deals with associating a classification of the result ip# after domain name resolution. The data shown in this document is fictitious and does not necessarily reflect the real Internet. |
| | A Next Generation Transport Services Architecture |
| |
|
While there is substantial community interest in next-generation multipath-capable Internet transports, evolutionary pressures have gradually eroded the simplicity of the Internet's original transport architecture to a point where it is no longer realistically applicable to new tranports. This document proposes a new architectural framework for next-generation multipath-capable transport protocols, focusing immediately on multipath TCP but taking care to allow for generalization to other multipath-capable transports. The architecture places emphasis on enabling new multipath features in a safe, TCP-friendly, and backward-compatible fashion, retaining full interoperability with both existing applications and existing network infrastructure, and enabling reuse of existing protocols as much as possible while providing incremental deployment paths to new, more powerful and/or more efficient protocols. The architecture re-establishes the long-lost principles of end-to-end reliability and fate sharing, in the presence of existing and future network middleboxes, and enables the deployment of transport-neutral end-to-end protection without interfering with these policy-enforcing or performance-enhancing middleboxes. This document describes architecture goals, a layering model supporting these goals, abstract properties of the interfaces between the architecture's new layers, general approaches to multipath congestion control and how they fit into the architecture, realistic protocol design and incremental deployment paths, and ways in which this document complements and relates to ongoing protocol design activities in the IETF. |
| | Simple Public Key Trust Alternatives |
| |
|
This document describes often used patterns for establishing technical trust for public key-based security architectures other than traditional PKIX-based public key infrastructure. The intent is that this document be useful as a reference for protocol specification authors who use technology like PKIX, PGP or S/MIME as part of their protocols. |
| | Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD) |
| |
|
This document specifies the HIP BONE instance specification for RELOAD. It provides the details needed to build a RELOAD-based overlay that uses HIP. |
| | Interaction of dynamic firewall control protocols and SIP |
| |
|
SIP-based multimedia applications dynamically negotiate parameters for the related media streams, such as UDP port numbers. Therefore, firewalls that want to inspect these streams have to interact with the session signaling. Several architectures and protocols have been developed for the dynamic control of firewalls on the media path, e. g., MIDCOM, SIMCO, and the NSIS NAT/FW NSLP. This document investigates problems with the interaction of standard SIP (as of RFC 3261) and these firewall control protocols, especially with respect to error handling. It will be pointed out how existing SIP extensions can be used for improving the interaction, and which additional mechanisms need to be specified. While the actual specification of such additional mechanisms is out of the scope of this document, it solicits feedback and discussion. |
| | MIF Security Analysis |
| |
|
MIF is working to describe the issues of attaching to multiple networks on hosts and document existing practice. The group is also expected to analyze the impacts and effectiveness of these existing mechanisms. A MIF node will have various security considerations that must be reviewed. This document provides security analysis for MIF. MIF security requirements are also presented. |
| | Proxy Mobile IPv6 Basic Multicast Support Solution |
| |
|
This document describes how multicast routing can be supported in Proxy Mobile IPv6 in a way similar to Mobile IPv6. The Mobile Access Gateway tunnels MLD messages from the mobile nodes to local mobility anchor. The Local Mobility Anchor joins the multicast group and starts forwarding the received multicast packets to the mobile access gateway. In case of a handover the tunnel end point changes but the operation remains anchored at the local mobility anchor. |
| | A SIP Flight Data Recorder Extension |
| |
|
A major responsibility of Session Initiation Protocol (SIP) servers is to provide application-layer routing. SIP routing can be quite complex and lead to similarly complicated paths that SIP requests traverse on the way to their actual destinations. It is therefore important to be in position to troubleshoot errors that occur along a SIP path, inside and outside troubleshooters' administrative domains. Particularly important for the troubleshooters is knowledge of where an error occurred in a SIP path. This document introduces a new header field called Debug. The purpose of the header field is to convey extra debugging information that can be used to locate errors in SIP implementations involved in processing of a SIP transaction. |
| | Hierarchical P2PSIP Overlay |
| |
|
This draft discusses the hierarchical overlay architecture in Peer- to-Peer (P2P) SIP system. The P2P SIP is defined as a distributed network and each peer is equal in it. But actually peers are different from each other on many aspects, e.g., physical performance, network performance or system performance (e.g., uptime). So node heterogeneity should been considered enough in P2P SIP system, which affects the scalability and service availability of P2P SIP overlays. This draft introduces the performance concerns of P2P SIP overlay without consideration of node heterogeneity at first. After that, an alternative architecture of hierarchical P2P SIP overlay is brought up. |
| | SMTP Service Extension for Message Recall |
| |
|
End users occasionally send email messages that they later want to recall, perhaps because they sent incorrect information, or had second thoughts about what they said in the message. Proprietary email systems often provide such a recall function. This document specifies a standard mechanism for providing it with Internet email. Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to morg@ietf.org. |
| | A Session Description Protocol (SDP) Attribute for Maximum Media Source Count Indication |
| |
|
The Real-Time Transport Protocol (RTP) is a multi-point protocol, supporting multiple simultaneous sending sources in an RTP session. However, many existing RTP endpoints cannot usefully receive more than one simultaneous source. This document provides a Session Description Protocol (SDP) attribute that allows endpoints to indicate the maximum number of sources they can usefully receive. |
| | Line identification in IPv6 Neighbour Solicitation messages |
| |
|
Duplicate address detection of link-local address in DSL access network is a mandatory part for IPv6 netwrok. In N:1 VLAN model, simple DAD does not work due to the user isolation. NAS should perform a DAD proxy function for the task. This documents proposes to include the line identification information in neighbour solicitation and neighbour advertisement messages to help DAD proxy to perform the function. |
| | Traffic localization for RELOAD |
| |
|
This document describes the traffic problems due to randomly distributed data storage in P2PSIP overlay, identifies the traffic localization requirements, and then proposes an overlay construction and data storage mechanism to implement traffic localization for REsource LOcation And Discovery (RELOAD). Specifically, it's proposed to add location indicator to the Peer node ID, for example, the beginning 5 bit hash ID stands for the peer location, and user data with the location indication shall be possible to be stored in local peer, thus to achieve traffic localization, reduce backbone network traffic, and improve the efficiency and QoS of the whole network. |
| | Source Address Validation via Shared Key |
| |
|
This document describes a mechanism to provide source address validation for IPv6 networks using a shared key (Skey) signature approach. The basic idea is that a device generates a signature using a shared key and its IP address and then the signature is sent to a validating device for source address validation. The proposed mechanism is intended to complement ingress filtering techniques with a finer granularity on the control of the source addresses used. |
| | Recommended Configuration and Use of DNS Redirect by Service Providers |
| |
|
The objective of this document is to describe the design of so-called DNS Redirect services deployed today by Internet Service Providers (ISPs), DNS Application Service Providers (ASPs), and other organizations providing so-called DNS Redirect services via their recursive DNS services, as well as to describe the recommended best current practices regarding such systems. |
| | Disaggregated Media in the Session Initiation Protocol (SIP) |
| |
|
Disaggregated media refers to the ability for a user to create a multimedia session combining different media streams, coming from different devices under his or her control, so that they are treated by the far end of the session as a single media session. This document lists several use cases that involve disaggregated media in SIP. Additionally, this document analyzes what types of disaggregated media can be implemented using existing protocol mechanisms, and the pros and cons of using each of those mechanisms. Finally, this document describes scenarios that are not covered by current mechanisms and proposes new IETF work to cover them. |
| | A Topology Plug-in for REsource LOcation And Discovery |
| |
|
REsource LOcation And Discovery (RELOAD) is a peer-to-peer signaling protocol that can be used to maintain an overlay network, and to store data in and retrieve data from the overlay. This document defines a new topology plug-in for RELOAD that is more appropriate for real world large scale overlays. This topology plug-in implements three important functionalities that allow RELOAD to operate under real world constraints. First, it includes a load balancing algorithm that specifies efficient allocation of load to different nodes in the network. Second, the document describes robust techniques for stabilization of fingers and successors and specifies self tuning mechanisms that allow dynamic and automatic adjustment of parameters needed for these advanced techniques in the topology plug-in. Finally, it specifies a locality aware finger selection algorithm that reduces average lookup latency. |
| | Architecture for Fast EAP Re-authentication based on a new EAP method (EAP-FRM) working on standalone mode |
| |
| | draft-marin-eap-frm-fastreauth-00.txt |
| | Date: |
06/07/2009 |
| | Authors: |
Rafael Lopez, Fernando Pereniguez-Garcia, Fernando Bernal-Hidalgo, Antonio Gomez-Skarmeta |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document describes an architecture aimed for reducing the latency of network access authentication based on the Extensible Authentication Protocol (EAP). The architecture is based on the design of a new EAP method for which a standalone authenticator is used, and does not require any change to the EAP specification or the specifications of existing EAP lower-layers. |
| | Recommendations for Implementing IPFIX over DTLS |
| |
|
This document discusses problems and solutions regarding the implementation of the IPFIX protocol over SCTP and DTLS. |
| | Problems and Possible Solutions for Advancing Metrics on the Standards Track |
| |
|
This memo identifies some issues with the process of progressing performance metric RFCs along the standards track. This memo takes the position that the metric definitions themselves should be the primary focus, rather than the implementations of metrics. This appears to allow some simplification of the task at hand and subsequently leads to solutions for the issues raised. |
| | Network File System (NFS) version 4 pNFS back end protocol extensions |
| |
|
This document describes an extension to the NFSv4.1 draft protocol to allow NFS clients to act as pNFS data servers towards other NFS clients. The intention is to reduce the load on the actual data servers by allowing some trusted clients to share the contents of their data caches with other clients.Keywords |
| | Network File System (NFS) version 4 pNFS back end protocol extensions |
| |
|
This document describes an extension to the NFSv4.1 draft protocol to allow NFS clients to act as pNFS data servers towards other NFS clients. The intention is to reduce the load on the actual data servers by allowing some trusted clients to share the contents of their data caches with other clients. |
| | Improving Remote Participation in IETF WG Meetings |
| |
|
This document discusses some steps for improving the ability of people to remotely participate in IETF meetings. This document makes some recommendations of "best practice", that if adopted, could improve the ability for people to participate in IETF meetings without needing to physically attend meetings. Improving the ability of participants to contribute and participate remotely would improve the overall effectiveness of the IETF and improve the quality of the work it produces. |
| | Analysis and Scenarios of generating the Multi-Path Routings |
| |
|
This document discusses the use of multiple interfaces of Mobile Ad hoc NETworks (MANETs) nodes and multiple path MANET routings protocols with respect to traditional, single network interface based ones. It then describes the design principles and methods of multiple path routing over MANET nodes with multiple interfaces. |
| | Geocoding and Reverse-geocoding Using Location-to-Service Translation |
| |
|
This document creates new service URNs for geocoding and reverse geocoding location formats to be used by location-to-service translation protocol (LoST) to convert location values into a format of choice. |
| | A Conversion of Location Related eXtensible Markup Language (XML) Elements to Type-Length-Value (TLV) Fields |
| |
|
This document specifies how to translate geolocation related eXtensible Markup Language (XML) elements to Type-Length-Value (TLV) fields, specifically where XML is not optimal or not appropriate to use for transporting geolocation related values. This document specifies a payload for binary protocols to use. This document makes no recommendations about which protocols should use this payload. |
| | Point-to-Multipoint Pseudo-Wire Encapsulation |
| |
|
A Point-to-Multipoint (P2MP) Pseudo Wire (PW) is a mechanism that emulates the essential attributes of a unidirectional P2MP Telecommunications service such as P2MP ATM over a Packet Switched Network (PSN). This document describes the encapsulation and data plane procedures for a P2MP PW. These procedures are meant to be independent of the control plane used to signal a P2MP PW. |
| | Session Recording for Conferences using SMIL |
| |
|
This document deals with session recording, specifically for what concerns recording of multimedia conferences, both centralized and distributed. Each involved media is recorded separately, and is then properly tagged. A SMIL [W3C.CR-SMIL3-20080115] metadata is used to put all the separate recordings together and handle their synchronization, as well as the possibly asynchronous opening and closure of media within the context of a conference. This SMIL metadata can subsequently be used by an interested user by means of a compliant player in order to passively receive a playout of the whole multimedia conference session. The motivation for this document comes from our experience with our conferencing framework, Meetecho, for which we implemented a recording functionality. |
| | RTP Payload Format and File Storage Format for SILK Speech and Audio Codec |
| |
|
This document defines the Real-time Transport Protocol (RTP) payload format and file storage format for packetization of SILK encoded speech and audio data that is essential to implement SILK in the most compatible way. Further, media type registrations are described for the RTP payload format and the file storage format. |
| | 1588v2 modules of time synchronization with frequency layer support |
| |
|
This I-D introduce a set of functional components of 1588v2 time/ phase synchronization system with frequency layer support and some optimized schemes for time synchronization devices based on PTP. |
| | IP/IPVPN services with IEEE 802.1aq SPBB networks |
| |
|
This document describes a compact method of using a IEEE 802.1aq Shortest Path Backbone Bridging SPBB network to natively enable and carry IP and IPVPN services for both unicast and multicast traffic on native Ethernet links. Further this documents the extensions to SPBB's control protocol, IS-IS, required to allow it to be a single mechanism for providing all these services types. On its own SPBB provides virtual Ethernet networks; utilizing IS-IS to create loop free Ethernet topologies that forward Ethernet traffic using a standard Ethernet header. This document shows how the same SPBB network can also be leveraged to provide IP based services. |
| | The Session Initiation Protocol (SIP) P-Private-Network-Indication Private-Header (P-Header) |
| |
|
This document specifies the SIP P-Private-Network-Indication P-header. The use of this private network indication extension is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport and usage of such information. A private network indication allows nodes in such a domain to treat private network traffic according to a different set of rules than the set applicable to public network traffic. The indication also distinguishes traffic from one private network from another private network. |
| | HIP and User Authentication |
| |
|
This document specifies how to use Extensible Authentication Protocol (EAP) in HIP to incorporate user authentication in the IPsec tunnel creation. This document describes two new parameters for transporting EAP messages inside HIP control packets. The main focus of this document is to describe how to use these parameters to combine needed EAP negotiation in order to authenticate the user. This document also describes how on-path middleboxes can take part in the negotiation as authenticators. |
| | SILK Speech Codec |
| |
| | draft-vos-silk-00.txt |
| | Date: |
06/07/2009 |
| | Authors: |
Koen Vos, Soeren Skak Jensen, Karsten Vandborg Soerensen |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document describes SILK, a speech codec for real-time, packet- based voice communications. Targeting a diverse range of operating environments, SILK provides scalability in several dimensions. Four different sampling frequencies are supported for encoding the audio input signal. Adaptation to network characteristics is provided through control of bitrate, packet rate, packet loss resilience and use of discontinuous transmission (DTX). And several different complexity levels let SILK take advantage of available processing power without relying on it. Each of these properties can be adjusted during operation of the codec on a frame-by-frame basis. |
| | Analysis of paths selection modes for Add-Paths |
| |
|
This document is aimed at discussing the various alternatives for the selection of the paths that are to be advertised with add-paths. The goal is to summarize the properties of those selection methods depending on which application they are used for. |
| | DHCP Option for Local Domain Name Discovery |
| |
|
This document defines the local domain name option for DHCPv4 and DHCPv6. This option is used by the Peer (DHCP client) to request local domain name described in [RFC5296] which is used to derive the local root key, e.g., DSRK defined in [RFC5295]. |
| | Trace Control Support for Proxy Mobile IPv6 |
| |
|
In some Proxy Mobile IPv6 (PMIPv6) [RFC5213] deployments, a mobility session needs to be traced by the back-end network manager for network diagnosis, troubleshooting, new service testing, etc. This document defines a Trace Session option for PMIPv6 protocol to control and manage (activation and de-activation) a trace session associated with a mobility session of the mobile node. This option is sent by the mobile access gateway in Proxy Binding Update message to request the local mobile anchor to activate the trace session. When the local mobile anchor successfully processes the Proxy Binding Update, it then activates the trace session and starts to record/report the traced mobility session based on the corresponding trace parameters. |
| | MIF Problem Requirements and Scenarios |
| |
|
This document provides the problem statement requirements and scenarios for MIF. These requirements and use case scenarios are intended to define an approach to solving common problems presented in MIF. These MIF requirements and scenarios are based around the common and prevalent problem of adaptation of a host to attach to multiple networks simultaneously. Such a host not only has to make decisions about selection of service parameters but also how to deal with issues relating to contradictory configuration objects. These MIF scenarios are intended to be part of a set of such scenarios that together define the purpose, scope and requirements for proposed and realized capabilities. |
| | Local domain name discovery |
| |
|
As described in [RFC5296], the local domain name can be learnt by the peer though the ERP exchange or via lower-layer announcement. However lower-layer announcement for local domain name is not specified. This document specifies one local domain name discovery mechanism based on DHCP extension. |
| | Introduction of MTN |
| |
|
This draft briefly introduces MTN, the Median Telecom Network built by China Telecom to support streaming and file download services with peer to peer technologies. |
| | Improved INSIGNIA Based on Network measurement |
| |
|
This document specifies an improved version of INSIGNIA[1][2], which is a framework supporting quality of service(QOS) in mobile ad hoc networks. INSIGNIA is an in-band signaling system, and 'in-band signaling' means the control information is carried along with data in IP packets. In this memo we introduce network measurement into INSIGNIA, and then this system can highly responsive to changes of performance on mobile ad hoc networks. |
| | SMTP Extension for Internationalized Email Address |
| |
|
This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Communication with systems that do not implement this specification is specified in another document. This document updates some syntaxes and rules defined in RFC 2821 and RFC 2822, and has some material updating RFC 4952. |
| | Multi-Class DSTE Support for the Path Computation Element Communication Protocol |
| |
|
Diffserv-Aware Traffic Engineering (DS-TE) can be used by Service Providers to perform fine grain bandwidth management of a subset, or sub-pool, of traffic flows. Typically in DS-TE a diffserv class will use a single Label Switch Path (LSP) that satisfies the bandwidth required. Where traffic with different diffserv characteristics must be mapped to a single LSP. Multi-Class DS-TE can be used to select an LSP that satisfy the bandwidth requirement of all classes required. This document specifies the PCEP extentions to support Multi-Class Type DS-TE where path computation is performed with the aid of a Path Computation Element (PCE). |
| | IVIT(IVI+Tunnel) |
| |
| | draft-xu-behave-ivit-00.txt |
| | Date: |
06/07/2009 |
| | Authors: |
Mingwei Xu, Chunmei Xia, Xing Li, Yong Cui, Jianping Wu |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document proposes a mechanism, IVIT (IVI+Tunnel), to support non-IVI IPv6 hosts to communicate with IPv4 hosts, and vice versa. IVIT combines IVI translation and Tunnel methods with the IVI translation at the core and the tunnel at the edge. In this document, IVIT provides two modes. One is the dual-stack host mode, which supports the communication between a dual-stack host in an IPv4 network and a non-IVI IPv6 host, especially the communication scenario between a dual-stack server in an IPv4 network and a non-IVI IPv6 host. The other is the CPE mode, which supports the communication between an IPv4-only host and a non-IVI IPv6 host, especially the bidirectional communication scenario between a private IPv4 network and a non-IVI IPv6 network. Combined with IVI, IVIT can support the communication between IPv4 networks and IPv6 networks statelessly at the core. |
| | The OAuth Protocol: Authentication |
| |
|
This document specifies the OAuth protocol authentication method. OAuth allows clients to access server resources on behalf of another party (such a different client or an end user). This document defines an HTTP authentication method which supports the ability to include two sets of cred | |