|
Internet Drafts - IDs for Sep/2009
Index - Month Index of IDs
All IDs - sorted by date)
30/09/2009
| |
|
| |
| | RTP Payload format for GSM-HR |
| |
| | draft-ietf-avt-rtp-gsm-hr-02.txt |
| | Date: |
30/09/2009 |
| | Authors: |
Xiaodong Duan, Shuaiyu Wang, Magnus Westerlund, Karl Hellwig, Ingemar Johansson |
| | Working Group: |
Audio/Video Transport (avt) |
| | Formats: |
txt xml |
|
This document specifies the payload format for packetization of the GSM Half-Rate speech codec data into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per payload and packet loss robustness methods using redundancy. |
| | BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs |
| |
|
This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in [MVPN]. |
| | Re-ECN: Adding Accountability for Causing Congestion to TCP/IP |
| |
|
This document introduces a new protocol for explicit congestion notification (ECN), termed re-ECN, which can be deployed incrementally around unmodified routers. The protocol works by arranging an extended ECN field in each packet so that, as it crosses any interface in an internetwork, it will carry a truthful prediction of congestion on the remainder of its path. The purpose of this document is to specify the re-ECN protocol at the IP layer and to give guidelines on any consequent changes required to transport protocols. It includes the changes required to TCP both as an example and as a specification. It briefly gives examples of mechanisms that can use the protocol to ensure data sources respond correctly to congestion,and these are described more fully in a companion document [I-D.briscoe-tsvwg-re-ecn-tcp-motivation]. Authors' Statement: Status (to be removed by the RFC Editor) Although the re-ECN protocol is intended to make a simple but far- reaching change to the Internet architecture, the most immediate priority for the authors is to delay any move of the ECN nonce to Proposed Standard status. The argument for this position is developed in Appendix E. Changes from previous drafts (to be removed by the RFC Editor) Full diffs from all previous verisons (created using the rfcdiff tool) are available at From -07 to -08 (current version): Minor changes and consistency checks. References updated. From -06 to -07: Major changes made following splitting this protocol document from the related motivations document [I-D.briscoe-tsvwg-re-ecn-tcp-motivation]. Significant re-ordering of remaining text. New terminology introduced for clarity. Minor editorial changes throughout. |
| | Rbridges: TRILL Header Options |
| |
|
The TRILL base protocol specification, draft-ietf-trill-rbridge- protocol-13.txt, specifies minimal hooks for options. This draft specifies the format for options and an initial set of options. |
| | Virtual Enterprise Traversal (VET) |
| |
|
Enterprise networks connect routers over various link types, and may also connect to provider networks and/or the global Internet. Enterprise network nodes require a means to automatically provision IP addresses/prefixes and support internetworking operation in a wide variety of use cases including Small Office, Home Office (SOHO) networks, Mobile Ad hoc Networks (MANETs), ISP networks, multi- organizational corporate networks and the interdomain core of the global Internet itself. This document specifies a Virtual Enterprise Traversal (VET) abstraction for autoconfiguration and operation of nodes in enterprise networks. VET can also be considered as version 2 of the Intra-Site Automatic Tunnel Addressing Protocol (i.e., "ISATAPv2"). |
| | Reclassification of COPS-PR and SPPI to Historic |
| |
|
This memo reclassifies RFC 3084, COPS Usage for Policy Provisioning, and RFC 3159, Structure of Policy Provisioning Information, to Historic status. This memo obsoletes RFC 3084, RFC 3159, RFC 3317, RFC 3318, and RFC 3571. |
| | MOBIKE eXtension (MOBIKE-X) for Transport Mobility and Multihomed IKE_SA |
| |
|
This draft provides a description of MOBIKE mobility and multihoming extension (MOBIKE-X). The extension is elaborated from the MOBIKE [RFC4555] protocol as well as mobility and multihoming requirements described in [I-D.mglt-ipsec-mm-requirements]. Extension concerns the Security Association facilities in a multihoming and mobile environment. More specifically this draft considers the use of multiple interfaces and the transport mode of IPsec. One of the goal of this draft was to make this extension compatible with MOBIKE [RFC4555]. We especially point out the differences from MOBIKE [RFC4555], as well as how its interacts with MOBIKE. |
| | Support for multiple clock rates in an RTP session |
| |
|
The usage of multiple clock rates in an RTP session is currently underspecified. This document lists multiple ways to fix this problem and is meant as a support for discussion. |
| | A Framework for Session Initiation Protocol User Agent Profile Delivery |
| |
|
This document specifies a framework to enable configuration of Session Initiation Protocol (SIP) User Agents in SIP deployments. The framework provides a means to deliver profile data that User Agents need to be functional, automatically and with minimal or no User and Administrative intervention. The framework describes how SIP User Agents can discover sources, request profiles and receive notifications related to profile modifications. As part of this framework, a new SIP event package is defined for notification of profile changes. The framework provides minimal data retrieval options to ensure interoperability. The framework does not include specification of the profile data within its scope. |
29/09/2009
| |
|
| |
| | SCTP based TML (Transport Mapping Layer) for ForCES protocol |
| |
|
This document defines the SCTP based TML (Transport Mapping Layer) for the ForCES protocol. It explains the rationale for choosing the SCTP (Stream Control Transmission Protocol) [RFC4960] and also describes how this TML addresses all the requirements described in [RFC3654] and the ForCES protocol [FE-PROTO] draft. |
| | Locator/ID Separation Protocol (LISP) |
| |
| | draft-ietf-lisp-05.txt |
| | Date: |
29/09/2009 |
| | Authors: |
Dino Farinacci, Vince Fuller, Dave Meyer, Darrel Lewis |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
| | Formats: |
txt |
|
This draft describes a simple, incremental, network-based protocol to implement separation of Internet addresses into Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). This mechanism requires no changes to host stacks and no major changes to existing database infrastructures. The proposed protocol can be implemented in a relatively small number of routers. This proposal was stimulated by the problem statement effort at the Amsterdam IAB Routing and Addressing Workshop (RAWS), which took place in October 2006. |
| | LISP for Multicast Environments |
| |
| | draft-ietf-lisp-multicast-02.txt |
| | Date: |
29/09/2009 |
| | Authors: |
Dino Farinacci, Dave Meyer, John Zwiebel, Stig Venaas |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
| | Formats: |
txt |
|
This draft describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the LISP architecture. |
| | Content-Type Processing Model |
| |
|
Many web servers supply incorrect Content-Type headers with their HTTP responses. In order to be compatible with these servers, user agents consider the content of HTTP responses as well as the Content- Type header when determining the effective media type of the response. This document describes an algorithm for determining the effective media type of HTTP responses that balances security and compatibility considerations. |
| | The HTTP Origin Header |
| |
|
This document defines the HTTP Origin header. The Origin header is added by the user agent to describe the security contexts that caused the user agent to initiate an HTTP request. HTTP servers can use the Origin header to mitigate against Cross-Site Request Forgery (CSRF) vulnerabilities. |
| | IANA Registry Update for the SEED Cipher Algorithm Support in the Multimedia Internet KEYing (MIKEY) |
| |
|
This document updates IANA registries to support the SEED block cipher algorithm for the Secure Real-time Transport Protocol (SRTP) and the secure Real-time Transport Control Protocol (SRTCP) in Multimedia Internet KEYing (MIKEY). |
| | Guidelines for Authors and Reviewers of MIB Documents |
| |
|
This memo provides guidelines for authors and reviewers of IETF standards-track specifications containing MIB modules. Applicable portions may be used as a basis for reviews of other MIB documents. This document obsoletes RFC 4181, incorporating its update published in RFC 4841. Comments and discussion are invited on the opsawg@ietf.org mailing list. |
| | Security Requirements for UDT |
| |
| | draft-d-sec-udt-00.txt |
| | Date: |
29/09/2009 |
| | Authors: |
Danilo Valeros Bernardo, Doan Hoang |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
UDT does not have its specific security mechanism. It depends on the application to provide authentication and lower layer to provide security mechanisms[GG07]. However, UDT implementations should check each arrived packets are from the expected source, since UDP is connectionless. This document proposes evaluation of security requirements for UDT, or UDP based Data Transfer considered as an alternative data transfer protocol for the situation when TCP does not work well.The objective is to achieve a wide class of security methods used on existing mature protocols such as UDP and TCP. |
| | Comments on the IDNA2008 documents set |
| |
|
The IDNA2008 document set is now under IETF/LC. The memo publishes the position of the non-WG iucg@ietf.org (Internet User Contributing Group) mailing list that its facilitator can neither present nor discuss during that Last Call. |
| | MPLS TP Ring Fault Detection and Localization |
| |
|
This document describes fault detection and localization mechanism for MPLS TP ring network using dedicated control node and bidirectional periodical status OAM message. The mechanism takes advantage of ring topology and greatly reduces OAM sessions and messages among nodes in the ring. |
28/09/2009
| |
|
| |
| | Node behavior upon originating and receiving Resource ReserVation Protocol (RSVP) Path Error message |
| |
|
The aim of this document is to describe a common practice with regard to the behavior of a node sending a Resource ReserVation Protocol (RSVP) Traffic Engineering (TE) Path Error message and to the behavior of a node receiving an RSVP Path Error message for a preempted Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Path (TE LSP). This document does not define any new protocol extensions. |
| | P2PSIP Security Overview and Risk Analysis |
| |
|
This document provides a security overview and analysis for the Peer- to-Peer Session Initiation Protocol (P2PSIP) overlay network. It discusses security threats for the P2PSIP architecture and its components. It compares security difference between client/server (C/S) and P2P implementations of SIP, and then partitions the P2PSIP architecture into layers and analyzes the security issues in each layer and the security relationship among the layers. |
| | Case sensitive IDNA |
| |
|
This memo documents an IDNA proposition (AKA IDNAPLUS), which supports upper and lowercases and new possibilities for the Internet name space. |
27/09/2009
| |
|
| |
| | NAT Behavior Discovery Using STUN |
| |
|
This specification defines an experimental usage of the Session Traversal Utilities for NAT (STUN) Protocol that discovers the presence and current behaviour of NATs and firewalls between the STUN client and the STUN server. |
| | Right-to-left scripts for IDNA |
| |
| | draft-ietf-idnabis-bidi-06.txt |
| | Date: |
27/09/2009 |
| | Authors: |
Harald Alvestrand, Cary Karp |
| | Working Group: |
Internationalized Domain Names in Applications, Revised (idnabis) |
| | Formats: |
txt xml |
|
The use of right-to-left scripts in internationalized domain names has presented several challenges. This memo proposes a new BIDI rule for IDNA labels, based on the encountered problems with some scripts, and some shortcomings in the 2003 IDNA BIDI criterion. |
| | Extensions to the Path Computation Element communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering |
| |
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers through a process called inter-layer traffic engineering. PCE is a candidate solution for such requirements. The PCE communication Protocol (PCEP) is designed as a communication protocol between Path Computation Clients (PCCs) and PCEs. This document presents PCEP extensions for inter-layer traffic engineering. |
26/09/2009
| |
|
| |
| | Comcast's Protocol-Agnostic Congestion Management System |
| |
|
This document describes the congestion management system of Comcast Cable, a large cable broadband Internet Service Provider (ISP) in the U.S. Comcast completed deployment of this congestion management system on December 31, 2008. |
25/09/2009
| |
|
| |
| | The Optimized Link State Routing Protocol version 2 |
| |
| | draft-ietf-manet-olsrv2-10.txt |
| | Date: |
25/09/2009 |
| | Authors: |
Thomas Clausen, Christopher Dearlove, Philippe Jacquet |
| | Working Group: |
Mobile Ad-hoc Networks (manet) |
| | Formats: |
txt |
|
This document describes version 2 of the Optimized Link State Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). |
| | Media Resource Brokering |
| |
|
The MediaCtrl work group in the IETF is currently proposing an architecture for controlling media services. The Session Initiation Protocol (SIP) will be used as the signalling protocol which provides many inherent capabilities for message routing. In addition to such signalling properties, a need exists for intelligent, application level media service selection based on non-static signalling properties. This is especially true when considered in conjunction with deployment architectures that include 1:M and M:M combinations of Application Servers and Media Servers. |
| | Redundancy and Load Balancing Framework for Stateful Network Address Translators (NAT) |
| |
|
This document defines a framework for ensuring redundancy and/or load balancing for stateful Network Address Translators (NAT), including NAT44, NAT46 and NAT64. |
| | Baseline Encoding and Transport of Pre-Congestion Information |
| |
|
The objective of the pre-congestion notification (PCN) architecture is to protect the QoS of inelastic flows within a Diffserv domain. It achieves this by marking packets belonging to PCN-flows when the rate of traffic exceeds certain configured thresholds on links in the domain. These marks can then be evaluated to determine how close the domain is to being congested. This document specifies how such marks are encoded into the IP header by redefining the Explicit Congestion Notification (ECN) codepoints within such domains. The baseline encoding described here provides only two PCN encoding states: not- marked and PCN-marked. Future extensions to this encoding may be needed in order to provide more than one level of marking severity. |
24/09/2009
| |
|
| |
| | "Uncoordinated Protocol Development Considered Harmful" |
| |
|
This document identifies problems that may result from the absence of formal coordination and joint development on protocols of mutual interest between standards development organizations. Some of these problems may cause significant harm to the Internet. The document suggests that a robust procedure is required prevent this from occurring in the future. The IAB has selected a number of case studies, such as T-MPLS, as recent examples to describe hazard to the Internet architecture as a result of uncoordinated adaptation of a protocol. This experience has resulted in a considerable improvement in the relationship between the IETF and the ITU-T. In particular, this was achieved via the establishment of the "Joint working team on MPLS-TP" . In addition, the leadership of the two organisations agreed to improve inter-organizational working practices so as to avoid conflict in the future between ITU-T Recommendations and IETF RFCs. Whilst we use ITU-T - IETF interactions in these case studies, the scope of the document extends to all SDO that have an overlapping protocol interest with the IETF. |
| | PathErr Message Triggered MPLS and GMPLS LSP Reroute |
| |
|
This document describes how Resource ReserVation Protocol (RSVP) PathErr Messages may be used to trigger rerouting of Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) point-to-point Traffic Engineering (TE) Label Switched Paths (LSPs) without first removing LSP state or resources. Such LSP rerouting may be desirable in a number of cases including, for example, soft-preemption and graceful shutdown. This document describes the usage of existing Standards Track mechanisms to support LSP rerouting. In this case, it relies on mechanisms already defined as part of RSVP-TE and simply describes a sequence of actions to be executed. While existing protocol definition can be used to support reroute applications, this document also defines a new reroute-specific error code to allow for the future definition of reroute application-specific error values. |
| | XML Media Types |
| |
|
This document standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while deprecating text/xml and text/ xml-external-parsed-entity. This document also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME entities. XML MIME entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains. Major differences from [RFC3023] are deprecation of text/xml and text/xml-external-parsed-entity, the addition of XPointer and XML Base as fragment identifiers and base URIs, respectively, mention of the XPointer Registry, and updating of many references. |
| | Shim6 Implementation Report : LinShim6 |
| |
|
LinShim6 is an implementation of the Shim6 and REAP protocols, on the Linux platform. This draft provides a description of the architecture and describes the current state of our implementation. The level of support of each protocol feature is detailed. Protocol conformance is evaluated against the main drafts. |
| | An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition |
| |
|
Global IPv6 deployment was slower than originally expected in the last ten years. As IPv4 address exhaustion gets closer, the IPv4/IPv6 transition issues become more critical and complicated. Host-based transition mechanisms are not able to meet the requirements while most end users are not sufficiently expert to configure or maintain these transition mechanisms. Carrier Grade NAT with integrated transition mechanisms can simplify the operation of end users during the IPv4/IPv6 migration or coexistence period. This document proposes an incremental Carrier-Grade NAT (CGN) approach for IPv6 transition. It can provide IPv6 access services for IPv6-enabled end hosts and IPv4 access services for IPv4 end hosts while remaining most of legacy IPv4 ISP networks unchanged. It is suitable for the initial stage of IPv4/IPv6 migration. Unlike CGN alone, it also supports and encourages transition towards dual-stack or IPv6-only ISP networks. |
| | ECMQV_ECQV Cipher Suites for Transport Layer Security (TLS) |
| |
|
This document specifies a set of cipher suites for the Transport Layer Security (TLS) protocol that use Elliptic Curve Qu-Vanstone (ECQV) certificates to authenticate an Elliptic Curve Menezes-Qu- Vanstone (ECMQV) exchange. These cipher suites provide forward secrecy. |
| | IPsec mobility and multihoming requirements : Problem statement |
| |
|
Currently IPsec mobility is the purpose of MOBIKE [RFC4555] which is the IKEv2 multihoming and mobility extension. More specifically, MOBIKE mobility support provides the ability to change the outer IP address of a tunnel mode Security Association. On the other hand MOBIKE multihoming support provides the ability of a peer to inform its correspondent that alternate IP addresses may be used if the current IP address does not work any more. This draft presents requirements to extend mobility and multihoming facilities. This includes the use of simultaneous IP addresses as well as other IPsec mode like transport mode. |
23/09/2009
| |
|
| |
| | Handling of Unknown DNS Resource Record (RR) Types |
| |
|
Extending the Domain Name System (DNS) with new Resource Record (RR) types should not requires changes to name server software. This document specifies how new RR types are transparently handled by DNS software. |
| | Proposal to use an inner MPLS label to identify the remote ASBR VA |
| |
|
The draft "MPLS Tunnels for Virtual Aggregation" [I-D.ietf-grow-va-mpls] specifies how MPLS is used as the tunneling protocol for Virtual Aggregation (VA). The -00 version of that draft specifies only one level of labels, with the result that one Label Switched Path (LSP) for every remote ASBR must be established. For large ISPs, this can amount to a large number of LSPs. This draft proposes adding the option of using an inner label to identify the remote ASBR. Either an outer label or an IP tunnel is used to reach the local ASBR. When MPLS is used as the tunneling protocol, this reduces the number of LSPs to the number of local border routers (ASBR). |
| | Peer-to-peer (P2P) Architectures |
| |
|
In this document we provide a survey of P2P (Peer-to-Peer) systems. The survey includes a definition and several taxonomies of P2P systems. This survey also includes a description of which types of applications can be built with P2P technologies and examples of P2P applications that are currently in use on the Internet. Finally, we discuss architectural tradeoffs and provide guidelines for deciding whether or not a P2P architecture would be suitable to meet the requirements of a given application. |
| | The Network Trouble Ticket Data Model |
| |
| | draft-dzis-nwg-nttdm-01.txt |
| | Date: |
23/09/2009 |
| | Authors: |
Dimitris Zisiadis, Spyros Kopsidas, Matina Tsavli, Leandros Tassiulas, Chrysostomos Tziouvaras, Guillaume Cessieux, Xavier Jeannin |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
Handling multiple sets of network trouble tickets (TTs) originating from different participants inter-connected network environments poses a series of challenges for the involved institutions, Grid is a good example of such multi-domain project. Each of the participants follows different procedures for handling trouble in its domain, according to the local technical and linguistic profile. The TT systems of the participants collect, represent and disseminate TT information in different formats. As a result, management of the daily workload by a central Network Operations Centre (NOC) is a challenge on its own. Normalization of TTs to a common format for presentation and storing at the central NOC is mandatory. In the present document we provide a model for automating the collection and normalization of the TT received by multiple networks forming the Grid. Each of the participants is using its home TT system within its domain for handling trouble incidents, whereas the central NOC is gathering the tickets in the normalized format for repository and handling. XML is used as the common representation language. The model was defined and used as part of the networking support activity of the EGEE project (Enabling Grids for E-sciencE). |
| | AFS Callback Extensions draft-benjamin-extendedcallbackinfo-00 |
| |
|
AFS cache-control strategy is callback (invalidate) based. The AFS callback design allows a client to know when an object it has cached is no longer consistent, but the callback notification message itself provides no specific information about the triggering event. This is a protocol inefficiency, as in several scenarios it results in unnecessary round-trips to file servers to verify file status information, file access information, or to fetch file data which has not changed. We propose an extension of the callback mechanism to provide information about the event(s) triggering a callback, in the payload of the callback notification message itself. The proposed mechanism eliminates most or all unnecessary round-trips imposed by the current callback mechanism, and simultaneously allows AFS implementations to (efficiently) provide correct semantics in several scenarios involving multiple writers (ie, where AFS currently provides incorrect semantics).Editorial Note To provide feedback on this Internet-Draft, join the afs3-standardisation mailing list (afs3-standardization@openafs.org). |
| | The use of SVEC (Synchronization VECtor) list for Synchronized dependent path computations |
| |
|
A Path Computation Element (PCE) performing dependent path computations, for instance calculating a diverse working and protected path not sharing common network points, would need to synchronize the computations in order to increase the probability of meeting the working and protected path diversity (or disjointness) objective and network resource optimization objective. When a PCE computes multiple sets of dependent path computation requests concurrently, it is required to use Synchronization VECtor (SVEC) list for association among the sets of dependent path computation requests. SVEC is also applicable to end-to-end diverse path computation across multiple domains. This document describes the usage of SVECs in the SVEC list and diverse path computation guideline, for the synchronized computation of dependent paths. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on March 23, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. |
| | PCEP Requirements for WSON Routing and Wavelength Assignment |
| |
|
This memo provides application-specific requirements for the Path Computation Element communication Protocol (PCEP) for the support of Wavelength Switched Optical Networks (WSON). Lightpath provisioning in WSONs requires a routing and wavelength assignment (RWA) process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical light path computation. Requirements for Optical impairments will be addressed in a separate document. |
| | Trust Anchor Management Requirements |
| |
|
A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor. This document describes some of the problems associated with the lack of a standard trust anchor management mechanism and defines requirements for data formats and push-based protocols designed to address these problems. |
22/09/2009
| |
|
| |
| | RSVP-TE Signaling Extension For Management Plane To Control Plane LSP Handover In A GMPLS Enabled Transport Network. |
| |
|
We would like to dedicate this work to our friend and colleague Dino Bramanti, who passed away at the early age of 38. Dino has been involved in this work since its beginning. In a transport network scenario, where Data Plane connections controlled either by GMPLS Control Plane (Soft Permanent Connections - SPC) or by Management System (Permanent Connections - PC) may independently coexist, the ability of transforming an existing PC into a SPC and vice versa - without actually affecting Data Plane traffic being carried over it - is a requirement. This memo describes an extension to GMPLS RSVP-TE signaling that enables the transfer of connection ownership between the Management and the Control Planes. Such a transfer is referred to as a Handover. This document defines all Handover related procedures. This includes the handling of failure conditions and subsequent reversion to original state. A basic premise of the extension is that the handover procedures must never impact an already established Data plane. |
| | Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server |
| |
| | draft-ietf-dime-pmip6-04.txt |
| | Date: |
22/09/2009 |
| | Authors: |
Jouni Korhonen, Julien Bournelle, Kuntal Chowdhury, Ahmad Muhanna, Ulrike Meyer |
| | Working Group: |
Diameter Maintenance and Extensions (dime) |
| | Formats: |
txt xml |
|
This specification defines Authentication, Authorization, and Accounting interactions between Proxy Mobile IPv6 entities (both Mobile Access Gateway and Local Mobility Anchor) and an Authentication, Authorization, and Accounting server within a Proxy Mobile IPv6 Domain. These Authentication, Authorization, and Accounting interactions are primarily used to download and update mobile node specific policy profile information between Proxy Mobile IPv6 entities and a remote policy store. |
| | Cryptographic Algorithm Identifier Allocation for DNSSEC |
| |
|
This document specifies how DNSSEC cryptographic algorithm identifiers in the IANA registries are allocated. It changes the rule from "standard required" to "RFC required". It does not change the list of algorithms that are recommended or required for DNSSEC implementations. |
| | PIM Group-to-RP Mapping |
| |
|
Each PIM-SM router in a PIM Domain which supports ASM maintains Group-to-RP mappings which are used to identify a RP for a specific multicast group. PIM-SM has defined an algorithm to choose a RP from the Group-to-RP mappings learned using various mechanisms. This algorithm does not allow administrator to override a specific Group- to-RP mapping with the static Group-to-RP mapping which an administrator would want to use. This algorithm also does not consider the PIM mode and the mechanism through which a Group-to-RP mapping was learned. The intention of this document is to suggest a standard algorithm to deterministically choose between several group-to-rp mappings for a specific group. This document first explains the requirements to extend the Group-to-RP mapping algorithm and then proposes the new algorithm. |
21/09/2009
| |
|
| |
| | RTP Payload Format for H.264 Video |
| |
|
This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec, excluding the Scalable Video Coding (SVC) extension and the Multivew Video Coding extension, for which the RTP payload formats are defined elsewhere. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bit-rate conversational usage, to Internet video streaming with interleaved transmission, to high bit-rate video-on-demand. This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized in section 18. Issues on backward compatibility to RFC 3984 are discussed in section 17. |
| | Virtual Subnet Selection Options for DHCPv4 and DHCPv6 |
| |
| | draft-ietf-dhc-vpn-option-11.txt |
| | Date: |
21/09/2009 |
| | Authors: |
Kim Kinnear, Richard Johnson, Mark Stapp, Jay Kumarasamy |
| | Working Group: |
Dynamic Host Configuration (dhc) |
| | Formats: |
txt |
|
This memo defines a Virtual Subnet Selection (VSS) option for DHCPv4 and DHCPv6, and a DHCPv4 relay-agent-information sub-option. These are intended for use by DHCP clients, relay agents, and proxy clients in situations where VSS information needs to be passed to the DHCP server for proper address or prefix allocation to take place. For the DHCPv4 option and relay-agent-information sub-option, this memo documents existing usage as per RFC 3942 [RFC3942]. |
| | IPv6 Traffic Engineering in IS-IS |
| |
|
This document specifies a method for exchanging IPv6 Traffic Engineering information using the IS-IS routing protocol. The described method uses three new TLVs, together with two new sub-TLVs of the Extended IS Reachability TLV. The information distributed allows a CSPF algorithm to calculate traffic engineered routes using IPv6 addresses. |
| | Transient Binding for Proxy Mobile IPv6 |
| |
|
This document specifies a mechanism which enhances Proxy Mobile IPv6 protocol signaling to support the creation of a transient binding cache entry which is used to optimize the performance of dual radio handover, as well as single radio handover. This mechanism is applicable to the mobile node's inter-MAG handover while using a single interface or different interfaces. The handover problem space using the Proxy Mobile IPv6 base protocol is analyzed and the use of transient binding cache entries at the local mobility anchor is described. The specified extension to the Proxy Mobile IPv6 protocol ensures optimized forwarding of downlink as well as uplink packets between mobile nodes and the network infrastructure and avoids superfluous packet forwarding delay or even packet loss. |
| | IPv4 Address Blocks Reserved for Documentation |
| |
|
Three IPv4 unicast address blocks are reserved for use in examples in specifications and other documents. This document describes the use of these blocks. |
| | Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control |
| |
| | draft-zhang-ccamp-gmpls-evolving-g709-03.txt |
| | Date: |
21/09/2009 |
| | Authors: |
Fatai Zhang, Guoying Zhang, Sergio Belotti, Daniele Ceccarelli, Yi Lin, Yunbin Xu, Pietro Grandi, Diego Caviglia |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
Recent progress in ITU-T Recommendation G.709 standardization has introduced new ODU containers (ODU0, ODU4, ODU2e, ODU3e1, ODU3e2 and ODUflex) and enhanced Optical Transport Networking (OTN) flexibility. Expires January 2010 [page 1] draft-zhang-ccamp-gmpls-evolving-g709-03.txt July 2009 Several recent documents have proposed ways to modify GMPLS signaling protocols to support these new OTN features. It is important that a single solution is developed for use in GMPLS signaling and routing protocols. This solution must support ODUk multiplexing capabilities, address all of the new features, be acceptable to all equipment vendors, and be extensible considering continued OTN evolution. This document describes the extensions to the Generalized Multi- Protocol Label Switching (GMPLS) signaling to control the evolutive Optical Transport Networks (OTN) addressing ODUk multiplexing and new features including ODU0, ODU4, ODU2e, ODU3e1, ODU3e2 and ODUflex. |
| | Database of Long-Lived Cryptographic Keys |
| |
|
This document specifies the information contained in a database of long-lived cryptographic keys used by many different security protocols. The database design supports both manual and automated key management. In many instances, the security protocols do not directly use the long-lived key, but rather a key derivation function is used to derive a short-lived key from a long-lived key. |
| | MRB-Media Server Interaction Mechanisms |
| |
|
The MediaCtrl work group in the IETF is currently working on an architecture for controlling media services. As part of the MediaCtrl architecture the Media Resource Broker (MRB) was identified as the component needed for intelligent, application level media service selection based on non-static signaling properties. This document defines the mechanisms needed by the media servers to publish their capabilities and the mechanisms needed by the MRB to monitor the status of the media servers. |
20/09/2009
| |
|
| |
| | A Security Framework for Routing over Low Power and Lossy Networks |
| |
|
This document presents a security framework for routing over low power and lossy networks. The development of the framework builds upon previous work on routing security and adapts the security assessments to the issues and constraints specific to low power and lossy networks. A systematic approach is used in defining and assessing the security threats and identifying applicable countermeasures. These assessments provide the basis of the security recommendations for incorporation into low power, lossy network routing protocols. |
| | Link Relations for Addressing |
| |
|
This specification defines link relations for a number of common styles of resource addressing (for example, linking to the latest vs a specific version of a resource). |
19/09/2009
| |
|
| |
| | NAT State Synchronization Using SCSP |
| |
|
To support NAT redundancy in hot standby mode [NAT-STANDBY] among a group of NAT devices, the dynamic NAT entries created at the primary NAT device should be synchronized consistently to the backup NAT device. This document describes a method of using the Server Cache Synchronization Protocol (SCSP) for NAT state synchronization and specifies the corresponding NAT specific components for this method. |
18/09/2009
| |
|
| |
| | An Inband Data Communication Network For the MPLS Transport Profile |
| |
|
The Generic Associated Channel (G-ACh) has been defined as a generalization of the pseudowire (PW) associated control channel to enable the realization of a control/communication channel associated with Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs), MPLS PWs, MPLS LSP segments, and MPLS sections between adjacent MPLS-capable devices. The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS architecture that identifies elements of the MPLS toolkit that may be combined to build a carrier grade packet transport network based on MPLS packet switching technology. This document describes how the G-ACh may be used to provide the infrastructure that forms part of the Management Communication Network (MCN) and a Signaling Communication Network (SCN). Collectively, the MCN and SCN may be referred to as the Data Communication Network (DCN). This document explains how MCN and SCN messages are encapsulated, carried on the G-ACh, and demultiplexed |
| | DHCPv6 and CGA Interaction: Problem Statement |
| |
|
This document describes potential issues in the interaction between DHCPv6 and Cryptographically Generated Addresses (CGAs). Firstly, the scenario of using CGAs in DHCPv6 environments is discussed. Some operations are clarified for the interaction of DHCPv6 servers and CGA-associated hosts. We then also discuss how CGAs and DHCPv6 may have mutual benefits for each other, including using CGAs in DHCPv6 operations to enhance its security features and using DHCPv6 to provide the CGA generation function. |
| | Re-ECN: A Framework for adding Congestion Accountability to TCP/IP |
| |
|
This document describes the framework to support a new protocol for explicit congestion notification (ECN), termed re-ECN, which can be deployed incrementally around unmodified routers. Re-ECN allows accurate congestion monitoring throughout the network thus enabling the upstream party at any trust boundary in the internetwork to be held responsible for the congestion they cause, or allow to be caused. So, networks can introduce straightforward accountability for congestion and policing mechanisms for incoming traffic from end- customers or from neighbouring network domains. As well as giving the motivation for re-ECN this document also gives examples of mechanisms that can use the protocol to ensure data sources respond correctly to congestion. And it describes example mechanisms that ensure the dominant selfish strategy of both network domains and end- points will be to use the protocol honestly. Authors' Statement: Status (to be removed by the RFC Editor) Although the re-ECN protocol is intended to make a simple but far- reaching change to the Internet architecture, the most immediate priority for the authors is to delay any move of the ECN nonce to Proposed Standard status. The argument for this position is developed in Appendix E. |
| | Security Issues and Solutions in Peer-to-peer Systems for Realtime Communications |
| |
|
Peer-to-peer networks have become popular for certain applications and deployments for a variety of reasons, including fault tolerance, economics, and legal issues. It has therefore become reasonable for resource consuming and typically centralized applications like Voice over IP (VoIP) and, in general, realtime communication to adapt and exploit the benefits of P2P. Such a migration needs to address a new set of P2P specific security problems. This document describes some of the known issues found in common P2P networks, analyzing the relevance of such issues and the applicability of existing solutions when using P2P architectures for realtime communication. This document is a product of the P2P Research Group. |
17/09/2009
| |
|
| |
| | Certified Electronic Mail |
| |
| | draft-gennai-smime-cnipa-pec-05.txt |
| | Date: |
17/09/2009 |
| | Authors: |
Francesco Gennai, Alba Shahin, Claudio Petrucci, Alessandro Vinciarelli |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
Since 1997, the Italian Laws have recognized electronic delivery systems as legally usable. In 2005 after two years of technical tests, the characteristics of an official electronic delivery service, named certified electronic mail (in Italian "Posta Elettronica Certificata") were defined, giving the system legal standing. Design of the entire system was carried out by the National Center for Informatics in the Public Administration of Italy (CNIPA), followed by efforts for the implementation and testing of the service. The CNIPA has given the Italian National Research Council (CNR), and in particular The Institute of Information Science and Technologies at the CNR (ISTI), the task of running tests on providers of the service to guarantee the correct implementation and interoperability. This document describes the certified email system adopted in Italy. It represents the system as it is at the moment of writing, following the technical regulations that were written based upon the Italian Law DPR. November 2, 2005. |
| | On the generation of TCP timestamps |
| |
|
This document describes an algorithm for selecting the timestamps (TS value) used for TCP connections that use the TCP timestamp option, such that the resulting timestamps are monotonically-increasing across connections that involve the same four-tuple {local IP address, local TCP port, remote IP address, remote TCP port}. The properties of the algorithm are such that it reduces the possibility of an attacker of guessing the exact value. Additionally, it describes an algorithm for processing incoming SYN segments that allows higher connection-establishment rates between any two TCP endpoints when a TCP timestamps option is present in the incoming SYN segment. |
| | Behavior Negotiation in Link Management Protocol |
| |
|
The Link Management Protocol (LMP) is used to coordinate the properties, use, and faults of data links in Generalized Multiprotocol Label Switching (GMPLS) networks. Various proposals have been advanced to provide extensions to the base LMP specification. This document provides a generic procedure for LMP implementations that do not recognize or do not support any one of these extensions. |
| | A la carte: Announcing the supported transport protocols via DNS |
| |
|
While TCP has enjoyed many enhancements over the decades, it is useful to allow applications to use transports beyond just UDP and TCP and to use TCP in new ways. It is inefficient to naively probe the server using the new protocol. This document proposes a new DNS resource record which provides an efficient way to query which protocols are supported by a server. |
16/09/2009
| |
|
| |
| | IANA Registration of Enumservices: Guide,Template and IANA Considerations |
| |
|
This document specifies a revision of the IANA Registration Guidelines for Enumservices, describes corresponding registration procedures, and provides a guideline for creating Enumservice Specifications. |
| | DVB-IPTV Application-Layer Hybrid FEC Protection |
| |
|
The Annex E of the DVB-IPTV technical specification defines an optional Application-layer Forward Error Correction (AL-FEC) protocol to protect the streaming media carried over RTP transport. The DVB- IPTV AL-FEC protocol uses two layers for FEC protection. The first (base) layer is based on the 1-D interleaved parity code. The second (enhancement) layer is based on the Raptor code. By offering a layered approach, the DVB-IPTV AL-FEC protocol offers a good protection against both bursty and random packet losses at a cost of decent complexity. This document describes how one can implement the DVB-IPTV AL-FEC protocol by using the 1-D interleaved parity code and Raptor code that have already been specified in separate documents. |
| | Generation of ICMPv6 Echo Replies for Teredo Clients |
| |
|
Teredo uses return routing to discover the closest Teredo relay corresponding to any given peer. Discovery is achieved by sending an ICMPv6 Echo Request and waiting for the appropriate relay to forward the ICMPv6 Echo Reply back. Unanswered ICMPv6 Echo Requests make Teredo clients assume that the peer is unreachable. This document identifies two scenarios where a stateful middlebox can detect the lack of ICMPv6 Echo Reply and craft one for the Teredo client in order to avoid possibly erroneous peer unreachability assumptions. |
| | Home Automation Routing Requirements in Low Power and Lossy Networks |
| |
|
This document presents home control and automation application specific requirements for Routing Over Low power and Lossy networks (ROLL). In the near future many homes will contain high numbers of wireless devices for a wide set of purposes. Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure) and advanced controllers (RF-based AV remote control, Central server for light and heat control). Because such devices only cover a limited radio range, routing is often required. The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home control and automation environment. |
15/09/2009
| |
|
| |
| | Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks |
| |
|
MPLS-TE Graceful Shutdown is a method for explicitly notifying the nodes in a Traffic Engineering (TE) enabled network that the TE capability on a link or on an entire Label Switching Router (LSR) is going to be disabled. MPLS-TE graceful shutdown mechanisms are tailored toward addressing planned outage in the network. This document provides requirements and protocol mechanisms to reduce/eliminate traffic disruption in the event of a planned shutdown of a network resource. These operations are equally applicable to both MPLS-TE and its Generalized MPLS (GMPLS) extensions. |
| | 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 the IKEv2 exchanges that follow the IKE_SA_INIT exchange. |
| | Recommendations for the Remediation of Bots in ISP Networks |
| |
|
This document contains recommendations on how Internet Service Providers can manage the effects of computers used by their subscribers, which have been infected with malicious bots, via various remediation techniques. Internet users with infected computers are exposed to risks such as loss of personal data, as well as increased susceptibility to online fraud and/or phishing. Such computers can also become an inadvertent participant in or component of an online crime network, spam network, and/or phishing network, as well as be used as a part of a distributed denial of service attack. Mitigating the effects of and remediating the installations of malicious bots will make it more difficult for botnets to operate and could reduce the level of online crime on the Internet in general and/or on a particular Internet Service Provider's network. |
| | Flow State Aware signalling standardisation,and a proposal for alerting nodes or end-systems on data related to a flow |
| |
|
This document describes the motivation for Flow State Aware signalling and proposes a method of enabling Flow State Aware signalling packets to be identified. |
| | IPsec High Availability Problem Statement |
| |
|
This document describes a requirement from IKE and IPsec to allow for more scalable and available deployments for VPNs. It defines |
| | Transport Layer Security (TLS) Cached Information Extension |
| |
|
This document defines a Transport Layer Security (TLS) extension for cached information. This extension allows the TLS client to inform a server of cached information from previous TLS sessions, allowing the server to omit sending cached static information to the client during the TLS handshake protocol exchange. |
14/09/2009
| |
|
| |
| | Document: draft-ietf-ccamp-gmpls-g-694-lambda-labels-04.txt |
| |
|
Technology in the optical domain is constantly evolving and as a consequence new equipment providing lambda switching capability has been developed and is currently being deployed. However, RFC 3471 has defined that a wavelength label (section 3.2.1.1) "only has significance between two neighbors" and global wavelength continuity is not considered. In order to achieve interoperability in a network composed of next generation lambda switch-capable equipment, this document defines a standard lambda label format, being compliant with ITU-T G.694. Moreover some consideration on how to ensure lambda continuity with RSVP-TE is provided. This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the label format when Lambda Switching is requested in an all optical network. |
| | Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI) |
| |
|
This document creates a Dynamic Host Configuration Protocol (DHCP) Option for transmitting a client's geolocation Uniform Resource Identifier (URI) of a client, which can be dereferenced in a separate transaction by the client or an entity the client sends this URI to. |
| | Proxy Mobile IPv6 Management Information Base |
| |
| | draft-ietf-netlmm-pmipv6-mib-01.txt |
| | Date: |
14/09/2009 |
| | Authors: |
Glenn Mansfield, Kazuhide Koide, Sri Gundavelli, Ryuji Wakikawa |
| | Working Group: |
Network-based Localized Mobility Management (netlmm) |
| | Formats: |
txt |
|
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. |
| | Real-time Transport Control Protocol Extension Report for Run Length Encoding of Discarded Packets |
| |
|
The Real-time Transport Control Protocol (RTCP) is used in conjunction with the Real-time Transport Protocol (RTP) in to provide a variety of short-term and long-term reception statistics. The available reporting may include aggregate information across longer periods of time as well as individual packet reporting. This document specifies a per-packet report metric capturing individual packets discarded from the jitter buffer after successful reception. |
| | Generic UDP Tunnelling (GUT) |
| |
|
Deploying new transport protocols on the Internet is a well-known problem, as NATs and firewall drop packets with new protocol types. Tunnelling over UDP is one way to make IP packets hide the actual payload and enable end-to-end delivery. This draft proposes a simple UDP tunnelling encapsulation and end-host operation to enable new IP payloads, e.g., new transport protocols, to be deployed on the Internet. |
| | Building Automation Routing Requirements in Low Power and Lossy Networks |
| |
|
The Routing Over Low power and Lossy network (ROLL) Working Group has been chartered to work on routing solutions for Low Power and Lossy networks (LLN) in various markets: Industrial, Commercial (Building), Home and Urban networks. Pursuant to this effort, this document defines the IPv6 routing requirements for building automation. |
| | A Profile for X.509 PKIX Resource Certificates |
| |
|
This document defines a standard profile for X.509 certificates for the purposes of supporting validation of assertions of "right-of-use" of an Internet Number Resource (IP Addresses and Autonomous System Numbers). This profile is used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of- use" of the IP addresses and AS numbers that are described in the issued certificate. |
| | A Profile for Trust Anchor Material for the Resource Certificate PKI |
| |
| | draft-ietf-sidr-ta-02.txt |
| | Date: |
14/09/2009 |
| | Authors: |
George Michaelson, Stephen Kent, Geoff Huston |
| | Working Group: |
Secure Inter-Domain Routing (sidr) |
| | Formats: |
txt |
|
This document defines a standard profile for the publication of Trust Anchor material for the Resource Certificate Public Key Infrastructure. |
| | Improving TCP's Robustness to Blind In-Window Attacks |
| |
| | draft-ietf-tcpm-tcpsecure-12.txt |
| | Date: |
14/09/2009 |
| | Authors: |
Anantha Ramaiah, Randall Stewart, Mitesh Dalal |
| | Working Group: |
TCP Maintenance and Minor Extensions (tcpm) |
| | Formats: |
txt |
|
TCP has historically been considered protected against spoofed off- path packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32 bit sequence number(s). A combination of increasing window sizes and applications using longer term connections (e.g. H-323 or Border Gateway Protocol [RFC4271]) have left modern TCP implementations more vulnerable to these types of spoofed packet injection attacks. Many of these long term TCP applications tend to have predictable IP addresses and ports which makes it far easier for the 4-tuple (4-tuple is the same as the socket pair mentioned in [RFC0793]) to be guessed. Having guessed the 4-tuple correctly, an attacker can inject a TCP segment with the RST bit set, the SYN bit set or data into a TCP connection by systematically guessing the sequence number of the spoofed segment to be in the current receive window. This can cause the connection to abort or cause data corruption. This document specifies small modifications to the way TCP handles inbound segments that can reduce the chances of a successful attack. |
13/09/2009
| |
|
| |
| | Multiprotocol Label Switching Transport Profile Ring Protection |
| |
|
according to MPLS-TP Requirement draft, there are two requirements : requirement 56.B Recovery techniques used for P2P and P2MP should be identical to simplify implementation and operation.another require as section 2.5.6.1 describles: within the context of recovery in MPLS-TP networks,the optimization criteria considered in ring topologies are as follows: 1 minimize the number of OAM entities that are needed to trigger the recovery operation; 2 Minimize the number of elements of recovery in the ring; 3 Minimize the number of labels required for the protection paths across the ring; 4 minimize the amount of control and management plane transactions during a maintenance operation. this decument will describle and provide two types of ring protection solutions. both solutions can satisfy these requirements of recovery in mpls-tp ring network. |
| | A Framework for Session Initiation Protocol (SIP) Session Policies |
| |
|
Proxy servers play a central role as an intermediary in the Session Initiation Protocol (SIP) as they define and impact policies on call routing, rendezvous, and other call features. This document specifies a framework for SIP session policies that provides a standard mechanism by which a proxy can define or influence policies on sessions, such as the codecs or media types to be used. It defines a model, an overall architecture and new protocol mechanisms for session policies. |
12/09/2009
| |
|
| |
| | IPv4 Support for Proxy Mobile IPv6 |
| |
|
This document specifies extensions to Proxy Mobile IPv6 protocol for adding IPv4 protocol support. The scope of IPv4 protocol support is two-fold: 1) enable IPv4 home address mobility support to the mobile node. 2) allowing the mobility entities in the Proxy Mobile IPv6 domain to exchange signaling messages over an IPv4 transport network. |
| | 4over6 Transit Solution using IP Encapsulation and MP-BGP Extensions |
| |
|
The emerging and growing deployment of IPv6 networks will introduce cases where connectivity with IPv4 networks crossing IPv6 transit backbones is desired. This document describes a mechanism for automatic discovery and creation of IPv4 over IPv6 tunnels via extensions to multi- protocol BGP. It is targeted at connecting islands of IPv4 networks across an IPv6-only backbone without the need for a manually configured overlay of tunnels. The mechanisms described in this document have been implemented, tested and deployed on the large research IPv6 network in China. |
| | Correct transaction handling for 200 responses to Session Initiation Protocol INVITE requests |
| |
|
This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address an error in the specified handling of success (200 class) responses to INVITE requests. Elements following RFC 3261 exactly will misidentify retransmissions of the request as a new, unassociated, request. The correction involves modifying the INVITE transaction state machines. The correction also changes the way responses that cannot be matched to an existing transaction are handled to address a security risk. |
11/09/2009
| |
|
| |
| | Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) |
| |
| | draft-ietf-webdav-bind-26.txt |
| | Date: |
11/09/2009 |
| | Authors: |
Geoffrey Clemm, Jason Crawford, Julian Reschke, Jim Whitehead |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt xml |
|
This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource. Servers are required to ensure the integrity of any bindings that they allow to be created. |
| | Conversion of MIB to XSD for NETCONF |
| |
|
NETCONF needs a data model for its process of standardization. This documentation defines a standard expression of SMI MIBs in XSD for NETCONF to ensure uniformity, general interoperability and reusability of existing MIBs. In addition, we define a XML schema to give a restriction and validation to translated XSD files. |
| | Correct transaction handling for 200 responses to Session Initiation Protocol INVITE requests |
| |
|
This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address an error in the specified handling of success (200 class) responses to INVITE requests. Elements following RFC 3261 exactly will misidentify retransmissions of the request as a new, unassociated, request. The correction involves modifying the INVITE transaction state machines. The correction also changes the way responses that cannot be matched to an existing transaction are handled to address a security risk. |
| | Chinese Common Name to Uniform Resource Identifier(URI) Dynamic Delegation Discovery System(DDDS) Application(CCN) |
| |
|
This document discusses the use of the Domain Name System(DNS) for storage of Chinese Common Name to URI mapping. More specifically, how DNS can be used for identifying URIs or services associated with the Chinese Common Names. The method used to discover the mapping is the Dynamic Delegation Discovery System, which can be found in a series of documents specified in RFC 3401. Understanding of RFC 3401 is necessary for understanding this document. |
| | Chopan - Compressed HTTP Over PANs |
| |
|
This document describes a method for compressing HTTP messages into a binary format to be transmitted using UDP over 6LoWPAN wireless networks. |
| | Integrity Data Exchanges in IKEv2 |
| |
|
IKEv2 supports mutual authentication of the peers but does not support platform integrity validation of the peers nor does it support the exchange of data related to the platform integrity validation. This extension allows platform integrity validation data to be exchanged from one peer (initiator) to another (respondent), allowing the other peer to either use the data for statistical analysis, pass it along to a validation entity for validation or pass it along to a Fraud Information Gathering System for fraud detection or analysis. |
| | NACK-Oriented Reliable Multicast Transport Protocol |
| |
|
This document describes the messages and procedures of the Negative- ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) Protocol. This protocol can provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal a priori coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based repair and other IETF Reliable Multicast Transport (RMT) building blocks in its design. This document obsoletes RFC 3940. |
| | Use of DNS SRV and NAPTR Records for SPEERMINT |
| |
|
The objective of this document is to specify the Best Current Practice (BCP) adopted by a SSP or other organization providing multimedia communication services such as Voice over Internet Protocol(VoIP) in order to locate another SSP to peer with in the context of Session PEERing for Multimedia INTerconnect. This document attempts to fill the gaps in information from RFC 3261, RFC 3263, and other documents, in order to more assist SSPs in more easily performing SIP peering. [EDITORIAL NOTE: XREF ERROR GENERATED IN ABSTRACT, XREFS REMOVED] |
10/09/2009
| |
|
| |
| | Basic Socket Interface Extensions for Host Identity Protocol (HIP) |
| |
|
This document defines extensions to the current sockets API for the Host Identity Protocol (HIP). The extensions focus on the use of public-key based identifiers discovered via DNS resolution, but define also interfaces for manual bindings between HITs and locators. With the extensions, the application can also support more relaxed security models where the communication can be non-HIP based, according to local policies. The extensions in this document are experimental and provide basic tools for further experimentation with policies. |
| | The Unicode code points and IDNA |
| |
|
This document specifies rules for deciding whether a code point, considered in isolation or in context, is a candidate for inclusion in an Internationalized Domain Name. It is part of the specification of IDNA2008. |
| | Generic Notification Message for Mobile IPv4 |
| |
|
This document specifies protocol enhancements that allow Mobile IPv4 entities to send and receive explicit notification messages using a new Mobile IPv4 message type designed for this purpose. |
| | A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Sub-Types |
| |
|
The caller preferences specification for the Session Initiation Protocol (SIP) allows a caller to express preferences that the call be routed to a User Agent (UA) with particular capabilities. Similarly, a specification exists to allow a UA to indicate its capabilities in a registration. Amongst those capabilities are the type of media streams the agent supports, described as top-level MIME types. The 'application' MIME type is used to describe a broad range of stream types, and provides insufficient granularity as a capability. This specification allows a UA to indicate which application sub-types the agent supports. |
| | Single PCN Threshold Marking by using PCN baseline encoding for both admission and termination controls |
| |
|
Pre-congestion notification (PCN) gives early warning of congestion by metering and marking packets in order to protect the quality of service of inelastic flows. PCN traffic load is divide into three pre-congestion states by two rates that [I-D.ietf.pcn.architecture] defines per link: PCN-admissible- and PCN-supportable-rates. PCN admission control and flow termination mechanisms operate in accordance with these three states. [I-D.ietf.pcn.baseline.encoding] defines two PCN encoding states. This document proposes an algorithm for marking and metering by using PCN baseline encoding for both flow admission and flow termination. The ratio of marked packets determines the three link states: no packets marked, some packets marked, and all packets marked. To achieve this marking behaviour, we use two token buckets. One is not used for marking but for a marking switch; the other is used for marking. The token bucket for marking has two thresholds. One is TBthreshold.threshold, already defined in [I-D.ietf-pcn-marking-behaviour], and the other is a new threshold, which is set to be the number of bits of a metered-packet smaller than the token bucket size. Therefore, the new threshold is larger than TBthreshold.threshold. If the amount of tokens is less than TBthreshold.threshold, all the packets are marked as defined in [I-D.ietf-pcn-marking-behaviour]. If the amount of tokens is less than the new threshold and greater than TBthreshold.threshold, one- Nth packets are marked. We evaluated the performance of admission control and flow termination using a simulation. For admission control, the results show that the performance of the algorithm was almost the same as, but slightly inferior to, that of CL [draft-briscoe-tsvwg-cl-phb-03]. For flow termination, the performance of the algorithm was almost the same as CL when the load was 1.2 times the supportable rate, but it was superior to CL when the load was high (two times the supportable rate). Furthermore, in the algorithm, over termination percentages of all the bottleneck links are almost the same in the case of multi-bottleneck. In CL, the over termination percentages of all the bottleneck links are different and those at upstream bottleneck links are higher than those at downstream bottleneck links because of accumulation of marked packets. |
09/09/2009
| |
|
| |
| | IEEE 802.21 Basic Schema |
| |
|
This document describes an RDF (Resource Description Framework) schema defined in IEEE 802.21 as the basic schema for Media- Independent Information Service. This document serves as the Specification required by the IANA to maintain a global registry for storing the RDF schema. |
| | The Camellia-CMAC-96 and Camellia-CMAC-PRF-128 Algorithms and Its Use with IPsec |
| |
|
This memo specifies two new algorithms. One is the usage of Cipher- based Message Authentication Code (CMAC) with Camellia block cipher on the authentication mechanism of the IPsec Encapsulating Security Payload and Authentication Header protocols. This algorithm is called Camellia-CMAC-96. Latter is pseudo-random function based on CMAC with Camellia block cipher for Internet Key Exchange. This algorithm is called Camellia-CMAC-PRF-128. |
| | The Use of Galois/Counter Mode (GCM) Modes of Operation for Camellia and Its Use With IPsec |
| |
|
This document describes the use of the Camellia block ciper algorithm in Galois/Counter Mode (GCM) as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality and data origin authentication. |
| | ATN Topology Considerations for Aeronautical NEMO RO |
| |
|
The aviation industry is in the process of moving from legacy and ISO-based protocols to an IP-based environment. This task will require adoption, modification and/or creation of IETF related protocols. The intention of this draft is therefore to provide an overview of the operational environment and the topology of the Aeronautical Telecommunications Network to the IETF. |
| | The Camellia-XCBC-96 and Camellia-XCBC-PRF-128 Algorithms and Its Use with IPsec |
| |
|
This memo specifies two new algorithms. One is the usage of XCBC mode with Camellia block cipher on the authentication mechanism of the IPsec Encapsulating Security Payload and Authentication Header protocols. This algorithm is called Camellia-XCBC-96. Latter is pseudo-random function based on XCBC with Camellia block cipher for Internet Key Exchange. This algorithm is called Camellia-XCBC-PRF- 128. |
| | Solution Space for Aeronautical NEMO RO |
| |
|
Many potential solutions have been proposed for NEMO Route Optimization, although none has been adopted up to now. This draft aims on evaluating the different approaches for the aeronautical use case. At the end, a recommendation for the next steps is given. |
| | The Network Access Identifier |
| |
|
In order to provide roaming services, it is necessary to have a standardized method for identifying users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during network authentication. "Roaming" may be loosely defined as the ability to use any one of multiple Internet Service Providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of where roaming capabilities might be required include ISP "confederations" and ISP-provided corporate network access support. This document is a revised version of RFC 4282, which addresses issues with international character sets, as well as a number of other corrections to the previous RFC. |
| | "The OAM Acronym Soup" |
| |
| | draft-ietf-opsawg-mpls-tp-oam-def-00.txt |
| | Date: |
09/09/2009 |
| | Authors: |
Loa Andersson, Malcolm Betts, Huub Helvoort, Ronald Bonica, Dan Romascanu |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
| | Formats: |
txt |
|
At first glance the acronym "OAM" seems to be well known and well understood. Looking at it a bit more closely reveals a set of recurring problems that are revisited time and again. This document has one primary and a secondary goal. The primary goal is to find an understanding of OAM that is feasible for the MPLS Transport Profile (MPLS-TP)effort. The secondary goal is to make this understanding applicable in a wider scope. |
| | SIP End-to-End Performance Metrics |
| |
|
This document defines a set of metrics and their usage to evaluate the performance of end-to-end Session Initiation Protocol (SIP) based services in both production and testing environments. The purpose of this document is to combine a standard set of common metrics, allowing interoperable performance measurements, easing the comparison of industry implementations. |
08/09/2009
| |
|
| |
| | Displaying Downgraded Messages for Email Address Internationalization |
| |
|
This document describes a method for displaying downgraded messages which originally contained internationalized E-mail addresses or internationalized header fields. |
| | Multicast DNS |
| |
|
As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server, is becoming essential. Multicast DNS (mDNS) provides the ability to do DNS-like operations on the local link in the absence of any conventional unicast DNS server. In addition, mDNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of mDNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures. |
| | Definition of Master Key between PANA Client and Enforcement Point |
| |
|
This document defines a master key used between a client of the Protocol for carrying Authentication for Network Access (PANA) and an enforcement point, for bootstrapping lower-layer ciphering. The master key is derived from the Master Session Key of Extensible Authentication Protocol as a result of successful PANA authentication. The master key guarantees cryptographic independence among enforcement points across different types of lower-layers. |
| | RANGER Scenarios |
| |
|
Routing and Addressing in Next-Generation EnteRprises (RANGER) [I-D.templin-RANGER] provides an architectural framework for scalable routing and addressing. It provides for scalability, provider independence, mobility, multihoming and security for the next generation Internet. This document describes a series of use cases in order to showcase RANGER capabilities. It further shows how the RANGER architecture restores the network-within-network principles originally intended for the sustained growth of the Internet. |
| | Additional Private IPv4 Space Issues |
| |
|
When a private network or internetwork grows very large it is sometimes not possible to address it using private IPv4 address space. This document describes the problems faced by those networks, the available options and the issues involved in assigning a new block of private IPv4 address space. |
| | WG-IDNABIS/LC comments and responses |
| |
|
The IDNA is a key issue for the IUCG as a paradigm for the future of the Internet. There is therefore a need to make sure its description document set reflects a complete IETF and users consensus. To help this, this memo keeps track of the WG-IDNABIS/LC requested and received answers. The IAB Draft on IDN has been added because some remarks have been made which are important. The author is quoted if the comment is not from IUCG |
| | Reusing Transport Layer Connections in Session Initiation Protocol (SIP) |
| |
|
The current Session Initiation Protocol (SIP) specification dictates that a transport layer connection can carry SIP requests in only one direction i.e. from the client to the server. This presents scalability problems as twice the number of connections are needed for each pair of SIP entities that communicate with each other. The internet-draft [I-D.ietf-sip-connect-reuse] specifies a mechanism for reusing SIP over TLS connections. However, that document is predicated on secure TLS mutual authentication and specifically refrains connection reuse for transports such as SIP over TCP and SCTP. There are many situations, such as in Trust Domains [RFC3324], where TLS mutual authentication may not be required but where connection reuse is beneficial. This document specifies connection reuse for SIP over connection-oriented transports such as TCP and SCTP. It specifies the same mechanism for connection reuse as specified in [I-D.ietf-sip-connect-reuse], however, the solution is presented in the context of Trust Domains. |
| | Encrypted Key Package Content Type |
| |
|
This document defines the encrypted key package content type, which can be used to encrypt a content that includes a key package, such as a symmetric key package or an asymmetric key package. It is transport independent. The Cryptographic Message Syntax (CMS) can be used to digitally sign, digest, authenticate, or further encrypt this content type. It is designed to be used with the CMS Content Constraints extension, which does not constrain the EncryptedData, EnvelopedData, and AuthEnvelopedData. |
| | Algorithms for Encrypted Key Package Content Type |
| |
|
This document describes the conventions for using several cryptographic algorithms with the encrypted key package content type. Specifically, it includes conventions necessary to implement EnvelopedData, EncryptedData, and AuthEnvelopedData. |
| | Certificate Management Service for The Session Initiation Protocol (SIP) |
| |
|
This draft defines a Credential Service that allows Session Initiation Protocol (SIP) User Agents (UAs) to use a SIP event package to discover the certificates of other users. This mechanism allows user agents that want to contact a given Address-of-Record (AOR) to retrieve that AOR's certificate by subscribing to the Credential Service, which returns an authenticated response containing that certificate. The Credential Service also allows users to store and retrieve their own certificates and private keys. |
07/09/2009
| |
|
| |
| | ForCES Interoperability Draft |
| |
|
This document describes the details of the interoperability test of the Forward and Control Element Separation (ForCES) protocol that took place in the University of Patras in Rio, Greece, 15 and 16 July 2009. This informational draft provided necessary information, for all parties who wish to participate in the interoperability test. This update also includes the results of the test. |
| | Implementation Report for ForCES |
| |
|
Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES Network Element (ForCES NE). RFC3654 has defined the ForCES requirements, and RFC3746 has defined the ForCES framework. This document is an implementation report of the ForCES Protocol, Model and SCTP-TML, including the report on interoperability testing and the current state of ForCES implementations. |
| | ISP Shared Address |
| |
| | draft-shirasaki-isp-shared-addr-03.txt |
| | Date: |
07/09/2009 |
| | Authors: |
Yasuhiro Shirasaki, Shin Miyakawa, Akira Nakagawa, Jiro Yamaguchi, Hiroyuki Ashida |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document defines IPv4 ISP Shared Address to be jointly used among Internet Service Providers (ISPs). This space is intended to be used in NAT444 model which is used during the transition period to IPv6. |
| | NAT444 with ISP Shared Address |
| |
|
This document describes one of the network models that are designed for smooth transition to IPv6. It is called NAT444 model. NAT444 model is composed of IPv6, and IPv4 with Large Scale NAT (LSN). NAT444 is the only scheme not to require replacing Customer Premises Equipment (CPE) even if IPv4 address exhausted. But it must be noted that NAT444 has serious restrictions i.e. it limits the number of sessions per CPE so that rich applications such as AJAX and RSS feed cannot work well. Therefore, IPv6 which is free from such a difficulty has to be introduced into the network at the same time. In other words, NAT444 is just a tool to make IPv6 transition easy to be swallowed. It is designed for the days IPv4 and IPv6 co-existence. |
| | IANA Allocation Guidelines for the PPP Bandwidth Allocation Protocol (BAP) |
| |
|
This document specifies the IANA guidelines for allocating new values in the PPP Bandwidth Allocation and Bandwidth Allocation Control Protocols. |
| | Problems of impeding the use of internationalized email address |
| |
|
Many organizations have implemented and tested the internationalized email systems based on the key RFCs which have been published. This document points out some problems, which blocks the receiver to receive the internationalized email address and may impede the deployment and use of the internationalized email address. Knowing the problems will help the smooth deployment of Email Address Internationalization system. |
| | Keying Material Exporters for Transport Layer Security (TLS) |
| |
|
A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. |
05/09/2009
| |
|
| |
| | Clarifications and Implementation Notes for DNSSECbis |
| |
|
This document is a collection of technical clarifications to the DNSSECbis document set. It is meant to serve as a resource to implementors as well as a repository of DNSSECbis errata. |
| | LDP Typed Wildcard FEC |
| |
|
The LDP specification [RFC5036] for the Wildcard FEC element has several deficiencies. This document corrects those deficiencies. In addition, it specifies the Typed Wildcard FEC for the Prefix FEC Element Type defined in RFC5036. |
| | Proxy Mobile IPv6 Reliability Protocol |
| |
|
The Local Mobility Anchor (LMA) and Mobile Access Gateway (MAG) are the key entities to realize system function of Proxy Mobile IPv6 (PMIPv6). It is critical to provide LMA/MAG reliability in the event of a LMA/MAG becoming failed or overloaded. This document provides a mechanism of LMA/MAG failure detection and service switching for failed or overloaded entities. |
04/09/2009
| |
|
| |
| | IMAP Support for UTF-8 |
| |
|
This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support unencoded international characters in user names, mail addresses and message headers. |
| | The Mechanism of MPLS-TP OAM Communication Based on MPLS-TP Sign Label |
| |
|
This document extends the applicability of the Generic Associated channel Label (GAL), enabling the realization of the communication between a Maintenance End Point (MEP) and a Maintenance Intermediate Point (MIP) in the MPLS-TP OAM architecture. This mechanism can only be used in the point-to-point co-routed bidirectional path of MPLS- TP networks. By introducing the MPLS-TP Sign Label, it enables the peer MEP to obtain the path information along the MPLS Label Switched Paths (LSPs) or MPLS pseudowires (PWs). After that, it could number the MIPs along the path, and each MIP could record the pairing relationship of the forward and the backward directions of that transport path. |
| | Using OAuth for Recursive Delegation |
| |
|
This document describes a use case for delegating authorization by a Resource Owner to another user via a Client using the OAuth protocol. OAuth allows Clients to access server resources on behalf of another party (such as a different Client or an end-user). This document describes the use of OAuth for delegating one Client's authorization to another Client - a scenario, which is also known as four-legged authorization. |
03/09/2009
| |
|
| |
| | Heuristics for Detecting ESP-NULL packets |
| |
|
This document describes a heuristic approach for distinguishing ESP- NULL (Encapsulating Security Payload without encryption) packets from encrypted ESP packets. The reason for using heuristics instead of modifying ESP is to provide a solution that can be used now without updating all end nodes. With heuristic methods, only the intermediate devices wanting to find ESP-NULL packets need to be updated. |
| | Open Research Issues in Internet Congestion Control |
| |
|
This document describes some of the open problems in Internet congestion control that are known today. This includes several new challenges that are becoming important as the network grows, as well as some issues that have been known for many years. These challenges are generally considered to be open research topics that may require more study or application of innovative techniques before Internet- scale solutions can be confidently engineered and deployed. |
| | PMIPv6 with Bicasting for Soft Handover |
| |
|
This document proposes an enhanced handover scheme on the Proxy Mobile IPv6 (PMIPv6) with bicasting for IP handover (B-PMIPv6). In B- PMIPv6, a mobile node (MN) performs binding update to Local Mobility Anchor (LMA) in advance, and then the LMA begins the bicasting of data packets to the new Mobile Access Gateway (N-MAG) as well as the previous MAG (P-MAG). The B-PMIPv6 minimizes the possible packet losses and handover latency during handover. |
02/09/2009
| |
|
| |
| | Diameter Base Protocol |
| |
|
The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services used by all Diameter applications. The Diameter base protocol as defined in this document must be supported by all Diameter implementations. |
| | LMA Discovery for Proxy Mobile IPv6 |
| |
|
Large Proxy Mobile IPv6 deployments would benefit from a functionality, where a Mobile Access Gateway could dynamically discover a Local Mobility Anchor for a Mobile Node attaching to a Proxy Mobile IPv6 domain. The purpose of the dynamic discovery functionality is to reduce the amount of static configuration in the Mobile Access Gateway. This specification describes a number of possible dynamic Local Mobility Anchor discovery solutions. |
| | Comparison of OSPF-MDR and OSPF-MPR |
| |
|
This document presents a comparison of two proposed MANET extensions of OSPF: OSPF-MDR and OSPF-MPR. It includes a qualitative comparison, which discusses the different design choices and how they can affect performance and scalability, and a simulation comparison. |
| | Comparison of OSPF-MDR and OSPF-OR |
| |
|
This document presents a comparison of two proposed MANET extensions of OSPF: OSPF-MDR and OSPF-OR. It includes a simulation comparison and a qualitative comparison, which discusses the different design choices and how they can affect performance and scalability. |
| | Scaling Requirements for Presence in SIP/SIMPLE |
| |
|
The document lists requirements for optimizations of SIP/SIMPLE. These optimizations should reduce the load on the network and the presence servers due to inter-domain presence subscriptions. The need for the requirements is based on a separate document that provides scaling analysis for inter-domain presence over SIP/SIMPLE. |
01/09/2009
| |
|
| |
| | Certificate Exchange Messaging for EDIINT |
| |
|
The EDIINT AS1, AS2 and AS3 message formats do not currently contain any neutral provisions for transporting and exchanging trading partner profiles or digital certificates. EDIINT Certificate Exchange Messaging provides the format and means to effectively exchange certificates for use within trading partner relationships. The messaging consists of two types of messages, Request and Response, which allow trading partners to communicate certificates, their intended usage and their acceptance through XML. Certificates can be specified for use in digital signatures, data encryption or SSL/TLS over HTTP (HTTPS). |
| | Multiple Attachments for EDI-INT |
| |
|
The EDIINT AS1, AS2 and AS3 message were designed specifically for the transport of EDI documents. Since multiple interchanges could be placed within a single EDI document, there was not a need for sending multiple EDI documents in a single message. As adoption of EDI-INT grew, other uses developed aside from single EDI document transport. Some transactions required multiple attachments to be interpreted together and stored in a single message. This informational draft describes how multiple documents, including non-EDI payloads, can be attached and transmitted in a single EDI-INT transport message. The attachments are stored within the MIME Multipart/Related structure. A minimal list of content-types to be supported as attachments is provided. |
| | Mobility Anchor Point (MAP) Reliability Extension |
| |
|
This document introduces an extension to allow an adapted multiple binding in hierarchical mobile network. Mobile node registers its RCoA and LCoA in the home agent at same time to get two separate connections between the mobile node and the home agent, or between the mobile node and the correspondent node in Route Optimization scenario. These connections provide robust communication between the mobile node and correspondent nodes and mobile node can overcome the failure on MAP. |
|
