This document specifies the use of the KeyNote trust-management system as an authorization extension in the Transport Layer Security (TLS) Handshake Protocol, according to [AUTHZ]. Extensions carried in the client and server hello messages confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, KeyNote credentials are exchanged during the supplemental data handshake message.
The early MPLS documents defined the form of the MPLS Label Stack entry. This include a three bit field called the "EXP field". The exact use of this field was not defined by these documents, except to state that it was to be "reserved for experimental use". Although the intended use of the EXP field was as a "Class of Service" field, it was not named the "Class of Service" (CoS) field by these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today a number of standards documents define its usage as a CoS field. . To avoid misunderstanding about how this field may be used, this document changes the name of the field to the "CoS field". In doing so it also updates documents that define the current use of the EXP this field.
When IKEv2 is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads. The configuration payloads specified in RFC 4306 work well for IPv4, but make it difficult to use certain features of IPv6. This document describes the limitations of current IKEv2 configuration payloads for IPv6, and explores possible solutions that would allow IKEv2 to set up full- featured virtual IPv6 interfaces.
This document presents a summary of performance studies for PCN-based admission control and flow termination. The numerical results were obtained by simulation or mathematical analysis.
Routing Metrics used for Path Calculation in Low Power and Lossy Networks
This document specifies routing metrics used in path calculation for Routing Over Low power and Lossy networks (ROLL). Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired networks or even with similar ones such as mobile ad-hoc networks as indicated in several application-specific requirements documents. Since typical IGP routing metrics such as hop counts or link metrics are not sufficient for LLNs, this document specifies a new set of required link and node metrics suitable to LLNs.
ATN Topology Considerations for Aeronautical NEMO RO
The intention of this draft is to provide an overview of the topology of the Aeronautical Telecommunications Network to help with the analysis of the possible options of NEMO RO within this context. The intention is to allow taking the existing NEMO RO solution space analysis document and cross-check it with the aeronautical environment presented within this document.
Framework and Requirements for Virtual Private Multicast Service (VPMS)
This document provides a framework and service level requirements for Virtual Private Multicast Service (VPMS). VPMS is defined as a Layer 2 VPN service that provides point-to-multipoint connectivity for a variety of Layer 2 link layers across an IP or MPLS-enabled PSN. This document outlines architectural service models of VPMS and states generic and high level requirements. This is intended to aid in developing protocols and mechanisms to support VPMS.
Management Information Base for the SEcure Neighbor Discovery (SEND) protocol
Many Internet applications are used to access resources, such as server processes or pieces of information, which are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer filesharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications, which have to select one host out of several candidates for providing a desired resource. These recommendations shall be based on parameters that affect performance and efficiency of the data transmission between the hosts, e.g., the topological distance. The ultimate goal is to optimize performance (or Quality of Experience) in the application while minimizing resource consumption in the underlying network infrastructure. This document enumerates an initial set of requirements for ALTO and solicits feedback and discussion.
P2P Traffic Localization by Traceroute and 2-Means Classification
Most P2P system performance suffers from the mismatch between the randomly constructed overlays topology and the underlying physical network topology, causing a large burden in the ISP and a long RTT time. This document describes how DHT overlay peers can interact with the routers by traceroute to get the path information, and execute 2- Means Classification, thereafter peers leverage the DHT itself to build efficient "closer" cluster. This scheme only requires the infrastructure to enable traceroute queries.
This memo proposes a scheme that supports a fast handover effectively in Proxy Mobile IPv6 by optimizing the associated data and signaling flows during the handover. New signaling messages, Fast PBU and Reverse PBU, are defined and utilized to expedite the handover procedure.
The Session Traversal Utilities for NAT (STUN) protocol defines two STUN attributes -- FINGERPRINT and MESSAGE-INTEGRITY -- that may be included in STUN messages. This document provides test vectors for those two attributes.
Network Address Translation (NAT) Behavioral Requirements for DCCP
This document defines a set of requirements for DCCP-capable NATs that would allow certain applications, such as streaming applications to operate consistently. These requirements are very similar to the TCP requirements for NATs already published by this IETF working group. Developing NATs that meet this set of requirements will greatly increase the likelihood that applications using DCCP will function properly.
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 and its Generalized MPLS (GMPLS) extensions.
A framework for the exchange of capabilities in HELD is described. Capabilities for enabling device-based measurements and device-based location generation are described.
Dynamic Host Configuration Protocol Option for Geodetic Location Information
This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for the coordinate-based geographic location of the client. The Location Configuration Information (LCI) includes latitude, longitude, and altitude, with an indication of uncertainty for each. Separate parameters indicate the reference datum for each of these values.
A Conference List Information Event Package for the Session Initiation Protocol (SIP)
This document describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications related to conference lists. A new conference list event package is specified. This event package allows a user to subscribe to a single event (the conference-list) and receive notifications that contain the list of conferences to which the user belongs and the status of each conference. The notifications sent from the conference server can contain either the entire list of the user's conferences or a partial list with the updates since the previous notification.
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.
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.
Media Gateway Control Protocol Voiceband Data Package and General Purpose Media Descriptor Parameter Package
This document defines Media Gateway Control Protocol (MGCP) packages that enable a Call Agent to authorize and monitor the transition of a connection to and from voiceband data (VBD) with or without redundancy and FEC (forward error correction). Although the focus is on VBD, the General-Purpose Media Descriptor Parameter package can be used to authorize other modes of operation, not relevant to VBD, for a particular codec. In addition to the definition of these new packages, this document describes the use of the Media Format Parameter package and Fax package with VBD, redundancy and FEC.
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.
Proxy Mobile IPv6 is a network-based mobility management protocol. The mobility entities involved in the Proxy Mobile IPv6 protocol, the Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA), setup tunnels dynamically to manage mobility for a mobile node within the Proxy Mobile IPv6 domain. This document describes a heartbeat mechanism between the MAG and the LMA to detect failures quickly and take appropriate action.
The MVPN (Multicast Virtual Private Network) architecture is divided into a number of functional "layers". At each layer, multiple options are allowed. It is necessary to allow multiple options at each layer because "one size doesn't fit all." However, it is not expected that any particular implementation will support all the possible combinations of options. To ensure multi-vendor interoperability, it is useful to specify "profiles", where each profile is a particular combination of options. The number of specified profiles will be much less than the total number of possible combination, and a given implementation can be characterized by saying which profiles it supports. This document describes two profiles that use a PIM control plane.
To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented. This memo replaces RFC 2606.
The application/opensearchdescription+xml media type
This memo defines the application/opensearchdescription+xml media type for OpenSearch descriptions. Atom and XHTML elements are examples where this media type is used.
This document describes IPv6 link models and their applicability in a fixed broadband network architecture. This document also specifies the addressing and operation of IPv6 in broadband networks. The scope of this specification is limited to the operation of IPv6 in a broadband architecture. This includes the IPv6 link model, address configuration, router and neighbor discovery in broadband architecture.
Pointers for Peer-to-Peer Overlay Networks,Nodes,or Resources
Discovering overlay networks and the resources found within in them presents a number of bootstrapping problems. While those hard problems are under discussion, this draft proposes a small set of mechanisms which are intended to be generically useful for providing pointers to peer-to-peer overlay networks in web pages, email messages, and other textual media. While the mechanisms described below each meet similar needs, they are not mutually exclusive; it is expected that each will find some useful deployment during the early days of peer-to-peer overlay deployment.
This document describes IPv6 link models and their applicability in a fixed broadband network architecture. This document also specifies the addressing and operation of IPv6 in broadband networks. The scope of this specification is limited to the operation of IPv6 in a broadband architecture. This includes the IPv6 link model, address configuration, router and neighbor discovery in broadband architecture.
This document defines a new service registration 'shelter', and describes how to find, what instances of shelter service are closest to the user's location.
The Remote Authentication Dial In User Server (RADIUS) Protocol has traditionally used the User Datagram Protocol (UDP) as it's underlying transport layer. This document defines RADIUS over the Transport Control Protocol (TCP).
This document specifies the requirements for a MPLS Transport Profile (MPLS-TP). This document is a product of a joint ITU-IETF effort to include a MPLS Transport Profile within the IETF MPLS architecture to support the capabilities and functionalities of a packet transport network as defined by ITU-T. This work is based on two sources of requirements, MPLS architecture as defined by IETF and packet transport networks as defined by ITU-T.
Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths
Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of P2MP TE LSPs. This document describes extensions to the PCE Communication Protocol PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs.
Lossless Compression for IP Flow Information Export (IPFIX)
In this document, we discuss the benefits and possible realizations of IPFIX traffic compression. Experiments with real measurement data show that a significant compression gain can be achieved by applying the DEFLATE compression method to IPFIX data sets. Compression of IPFIX traffic can be based on underlying transport protocols, such as IPComp and TLS/DTLS, or realized as an extension of the IPFIX protocol.
MVPN: Optimized use of PIM,Wild Card Selectors,Bidirectional Tunnels
Specifications for a number of important topics were arbitrarily omitted from the initial MVPN specifications, so that those specifications could be "frozen" and advanced. The current document provides some of the missing specifications. The topics covered are: (a) using Wild Card selectors to bind multicast data streams to tunnels, (b) using Multipoint-to-Multipoint Label Switched Paths as tunnels, (c) binding bidirectional customer multicast data streams to specific tunnels, and (d) running PIM (i.e., sending and receiving multicast control traffic) over a set of tunnels that are created only if needed to carry multicast data traffic.
This draft is aimed at describing the ANCP protocol extensions required to support the NAS initiated ANCP Multicast Control use case described in ANCP framework draft. It proposes the definition of new ANCP message types, along with well known TLVs.
A wavelength switched optical network (WSON) requires that certain key information elements are made available to facilitate path computation and the establishment of label switching paths (LSPs). The information model described in "Routing and Wavelength Assignment Information for Wavelength Switched Optical Networks" shows what information is required at specific points in the WSON. The information may be used in Generalized Multiprotocol Label Switching (GMPLS) signaling protocols, and may be distributed by GMSPL routing protocols. Other distribution mechanisms (for example, XML-based protocols) may also be used. This document provides efficient, protocol-agnostic encodings for the information elements necessary to operate a WSON. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses.
Updates to Referred-By in the Session Initiation Protocol (SIP).
SIP has a mechanism for conveying the asserted identity of the originator of a request by means of the P-Asserted-Identity header field. When exploding a SIP MESSAGE request to a pre-defined group URI and when exploding a SIP INVITE request to an ad-hoc group or to a pre-defined group URI, the Referred-By header field in the resulting exploded requests is set to the P-Asserted-Identity header field or to the From header field. The Referred-By header is only included if the P-Asserted-Identity header field or From header field needs to carry another value, e.g. the URI of a pre-defined group, or a conference focus URI. Since the P-Asserted-Identity header field may carry up to two values, the Referred-By definition needs to be extended to allow up to two values as well.
Urban WSNs Routing Requirements in Low Power and Lossy Networks
The application-specific routing requirements for Urban Low Power and Lossy Networks (U-LLNs) are presented in this document. In the near future, sensing and actuating nodes will be placed outdoors in urban environments so as to improve the people's living conditions as well as to monitor compliance with increasingly strict environmental laws. These field nodes are expected to measure and report a wide gamut of data, such as required in smart metering, waste disposal, meteorological, pollution and allergy reporting applications. The majority of these nodes is expected to communicate wirelessly which - given the limited radio range and the large number of nodes - requires the use of suitable routing protocols. The design of such protocols will be mainly impacted by the limited resources of the nodes (memory, processing power, battery, etc.) and the particularities of the outdoors urban application scenarios. As such, for a wireless ROLL solution to be useful, the protocol(s) ought to be energy-efficient, scalable, and autonomous. This documents aims to specify a set of requirements reflecting these and further U-LLNs tailored characteristics.
Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies
This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address a security vulnerability identified in SIP proxy behavior. This vulnerability enables an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic. This document strengthens loop-detection requirements on SIP proxies when they fork requests (that is, forward a request to more than one destination). It also corrects and clarifies the description of the loop-detection algorithm such proxies are required to implement. Additionally, this document defines a Max-Breadth mechanism for limiting the number of concurrent branches pursued for any given request.
he document describes several use cases of peering of non-VoIP services between two or more Service Providers. These Service Providers create a peering relationship between themselves thus enabling their users to collaborate with users on the other Service Provider network. The target of the document is to drive requirements for peering between domains that provide the non-VoIP based collaboration services and presence and Instant Messaging (IM) in particular.
RFC 4364 and RFC 4659 define an approach to building provider- provisioned Layer 3 VPNs for IPv4 and IPv6. It may be desirable to use RSVP to perform admission control on the links between CE and PE routers. This document specifies procedures by which RSVP messages travelling from CE to CE across an L3VPN may be appropriately handled by PE routers so that admission control can be performed on PE-CE links. Optionally, admission control across the provider's backbone may also be supported.
Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with NAT traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution. This document obsoletes RFC 3489.
DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email to permit verification of the source and contents of messages. This document specifies an adjunct mechanism to aid in assessing messages that do not contain a DKIM signature for the domain used in the author's address. It defines a record that can advertise whether they sign their outgoing mail, and how other hosts can access those records.
Simple procedures for Detecting Network Attachment in IPv6
Detecting Network Attachment allows hosts to assess if its existing addressing or routing configuration is valid for a newly connected network. This document provides simple procedures for detecting network attachment in IPv6 hosts, and procedures for routers to support such services.
Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication
This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document replaces RFC 3567. This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms.
AAA and Admission Control Framework for Multicasting
IP multicast-based services, such as TV broadcasting or videoconferencing raise the issue of making sure that potential customers are fully entitled to access the corresponding contents. There is indeed a need for service and content providers to identify users (if not authenticate, especially within the context of enforcing electronic payment schemes) and to retrieve statistical information for accounting purposes, as far as content and network usage are concerned. This memo describes the framework for specifying the Authorization, Authentication and Accounting (AAA) capabilities that could be activated within the context of the deployment and the operation of IP multicast-based services. This framework addresses the requirements presented in "Requirements for Accounting, Authentication and Authorization in Well Managed IP Multicasting Services" [I-D.mboned-maccnt-req]. The memo provides a basic AAA enabled model as well as an extended fully enabled model with resource and admission control coordination.
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.
Signaling layer protocols in the NSIS working group may rely on GIST to handle authorization. Still, the signaling layer protocol itself may require separate authorization to be performed when a node receives a request for a certain kind of service or resources. This draft presents a generic model and object formats for session authorization within the NSIS Signaling Layer Protocols. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to coordinate actions between the signaling and transport planes.
The Session Initial Protocol (SIP) defined in RFC 3261 and a large number of extensions forms a considerable body of work, which through sheer size has a number of errors that require correction. This document explains the process for managing essential corrections to SIP.
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 new IPv6 extension headers.
This document defines basic terminology for describing different types of carrier-grade Network Address Translation (NAT) behavior when handling Unicast UDP, TCP and ICMP. Developing carrier-grade NATs that meet this set of requirements increase transparency of data between carrier networks.
Application of Event Package Bodies to Subscriptions to Lists of Resources in the Session Initiation Protocol (SIP)
This document specifies a mechanism by which subscriptions to the state of request-contained ("ad-hoc") lists of resources can have event-package-defined bodies applied to each of the contained resources.
DHCP Based Configuration of Mobile Node from Home Network
This document describes the mechanism for providing the host configuration parameters needed for network service from home network based on DHCPINFORM. DHCPINFORM message has been widely used by client to obtain other configuration information and could be sent to local broadcast address or server unicast address. Mobile IP specification could support DHCPINFORM broadcast or unicast message straightfully without any revision.
This specification clarifies the Diameter realm based request routing. We focus on the case where a Network Access Identifier in the User-Name AVP is used to populate the Destination-Realm AVP and the Network Access Identifier contains more than one realm. This particular case is possible when the Network Access Identifier decoration is used to force a routing of request messages through a predefined list of realms. However, this functionality is not unambiguously specified in the Diameter Base Protocol specification.
Moving the Session Initiation Protocol (SIP) Towards Draft Standard
This document is intended to stimulate discussion and progress towards advancing SIP to Draft Standard. It points to some of the issues the working group will need to work through and proposes an approach for creating an interoperability statement.
This document discusses how RFC 2026, the current description of the IETF standards process, operates in practice. Its main purpose is to document, for information only, how actual practice interprets the formal rules.
This document describes, how a LoST client can ask LoST server for the list of sub services that it supports, and to incorporate additional information about the service provider in response.
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.
A Packet Partition Scheduling Mechanism for Bandwidth Aggregation through Multiple Network Interfaces
This draft considers a packet partition scheduling mechanism for effective bandwidth aggregation over end-to-end multi-path through multiple network interfaces.
Benoit Claise, Paul Aitken, Andrew Johnson, Gerhard Muenz
Working Group:
IP Flow Information Export (ipfix)
This document specifies an improvement to the use of SCTP as specified in the IPFIX specifications in order to be able to deduce the Data Record loss per Template Record in case of partially-reliable SCTP export. This specification offers several extra advantages: immediate export of the Template Withdrawal Message, immediate reuse of Template ID within a stream, and the Collecting Process's job is easier.
This document specifies an improvement to the use of SCTP as specified in the IPFIX specifications in order to be able to deduce the Data Record loss per Template Record in case of partially-reliable SCTP export. This specification offers several extra advantages: immediate export of the Template Withdrawal Message, immediate reuse of Template ID within a stream, and the Collecting Process's job is easier.
This document describes a method for increasing the space available for TCP options. Two new TCP options (LO and SLO) are detailed which reduce the limitations imposed by the TCP header's Data Offset field. The LO option provides this extension after connection establishment, and the SLO option aids in transmission of lengthy connection initialization and configuration options.
Extensible Messaging and Presence Protocol (XMPP): Core
This document defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a technology for streaming Extensible Markup Language (XML) elements for the purpose of exchanging structured information in close to real time between any two or more network-aware entities. XMPP provides a generalized, extensible framework for incrementally exchanging XML data, upon which a variety of applications can be built. The framework includes methods for stream setup and teardown, channel encryption, authentication of a client to a server and of one server to another server, and primitives for push-style messages, publication of network availability information ("presence"), and request-response interactions. This document also specifies the format for XMPP addresses, which are fully internationalizable. This document obsoletes RFC 3920.
This document describes a new option for DHCPv6 [RFC3315] that provides a mechanism for specifying a list of service identifer which this connection support or don't support.
This document analysis the use of hashes in SeND, possible threats and the impact of recent attacks on hash functions used by SeND. Current SeND specification [rfc3971] uses SHA-1 [sha-1] hash algorithm and PKIX certificates [rfc3280] and does not provide support for the hash algorithm agility. Based on previous analysis, this document suggests multiple hash support that should be included in the SeND update specification.
Payloads carried over a Softwire mesh service as defined by BGP Encapsulation Subsequent Address Family Identifier (SAFI) information exchange often carry a number of identifiable, distinct flows. It can in some circumstances be desirable to distribute these flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Currently, the payload of a packet entering the Softwire can only be interpreted by the ingress and egress routers. Thus the load balancing decision of a core router is only based on the encapsulating header, presenting much less entropy than available in the payload or the encapsulated header since the Softwire encapsulation acts in a tunneling fashion. This document describes a method for achieving comparable load balancing efficiency in a network carrying Softwire mesh service over Layer Two Tunneling Protocol - Version 3 (L2TPv3) over IP or Generic Routing Encapsulation (GRE) encapsulation to what would be achieved without such encapsulation.
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been extended with a Leasequery capability that allows a client to request information about DHCPv4 bindings. That mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. This document expands on the Leasequery protocol, adding new query types and allowing for bulk transfer of DHCPv4 binding data via TCP.
This document discusses the communication protocol between mobile access point and terminal. With the evolution of mobile communication, there are various kind of wireless communication technologies such as WCDMA, LTE, WLAN, WiMAX, and TDS-CDMA et al. Each of these wireless communication technology has independent connection, mobility and configuration management. This document would like to cover all these functions into a common ground especially in the environment of multiple connections.
6lowpan applications sometimes need to include application-specific information in layer 2 packets that are intended to be processed as 6lowpan packets. This document specifies a way to include this information in a 6lowpan packet in such a way that it can be ignored by implementations that don't care for it. $Id: draft-bormann-6lowpan-ext-hdr.xml,v 1.5 2008/07/02 06:23:58 cabo Exp $
Definitions of Textual Conventions for Path Computation Element
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines Textual Conventions to represent commonly used Path Computation Element (PCE) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in PCE related MIB modules to avoid duplicating conventions.
Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification
This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851.
Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)
This document describes how to use Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS). The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the ANSI X9.62 standard, developed by the ANSI X9F1 working group, the IEEE 1363 standard, and the SEC 1 standard.
RSVP Extensions for Path-Triggered RSVP Receiver Proxy
RSVP signaling can be used to make end-to-end resource reservations in an IP network in order to guarantee the QoS required by certain flows. With conventional RSVP, both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are many use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable. Where the receiver is not RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy thereby performing RSVP signaling on behalf of the receiver. This allows resource reservations to be established on the segment of the end-to-end path from the sender to the RSVP Receiver Proxy. However, as discussed in the companion document presenting RSVP Proxy approaches, RSVP extensions are needed to facilitate operations with an RSVP Receiver Proxy whose signaling is triggered by receipt of RSVP Path messages from the sender. This document specifies these extensions.
This memo describes an RTP payload format for the ISO/IEC International Standard 15444-1 | ITU-T Rec. T.800, otherwise better known as: JPEG 2000. JPEG 2000 features are considered in the design of this payload format. JPEG 2000 is a truly scalable compression technolog
