Current Internet-Drafts This summary sheet provides a short synopsis of each Internet-Draft available within the "internet-drafts" directory at the shadow sites directory. These drafts are listed alphabetically by working group acronym and start date. IP over IEEE 802.16 Networks (16ng) ----------------------------------- "Transmission of IP over Ethernet over IEEE 802.16 Networks", HongSeok Jeon, 18-Nov-08, This document describes the transmission of IPv4 over Ethernet as well as IPv6 over Ethernet in an access network deploying the IEEE 802.16 cellular radio transmission technology. The Ethernet on top of IEEE 802.16 is realized by bridging connections which the IEEE 802.16 provides between a base station and its associated subscriber stations. Due to the resource constraints of radio transmission systems and the limitations of the IEEE 802.16 MAC functionality for the realization of an Ethernet, the transmission of IP over Ethernet over IEEE 802.16 may considerably benefit by adding IP specific support functions in the Ethernet over IEEE 802.16 while maintaining full compatibility with standard IP over Ethernet behavior. "Transmission of IPv4 packets over IEEE 802.16's IP Convergence Sublayer", Syam Madanapalli, Soohong Daniel Park, Samita Chakrabarti, Gabriel Montenegro, 2-Nov-08, IEEE 802.16 is an air interface specification for wireless broadband access. IEEE 802.16 has specified multiple service specific convergence sublayers for transmitting upper layer protocols. The packet CS (Packet Convergence Sublayer) is used for the transport of all packet-based protocols such as Internet Protocol (IP), IEEE 802.3 (Ethernet) and IEEE 802.1Q (VLAN). The IP-specific part of the Packet CS enables the transport of IPv4 packets directly over the IEEE 802.16 MAC. This document specifies the frame format, the Maximum Transmission Unit (MTU) and address assignment procedures for transmitting IPv4 packets over the IP-specific part of the Packet Convergence Sublayer of IEEE 802.16. IPv6 over Low power WPAN (6lowpan) ---------------------------------- "Compression Format for IPv6 Datagrams in 6LoWPAN Networks", Jonathan Hui, Pascal Thubert, 17-Nov-08, This document specifies an IPv6 header compression format for IPv6 packet delivery in 6LoWPAN networks. The compression format relies on shared context to allow compression of arbitrary prefixes. This document specifies compression of multicast addresses and a framework for compressing next headers. This framework specifies UDP compression and is prepared for additional transports. "Design and Application Spaces for 6LoWPANs", Eunsook Kim, Nicolas Chevrollier, Dominik Kaspar, JP Vasseur, 3-Nov-08, This document investigates potential application scenarios and use cases for low-power wireless personal area networks (LoWPANs). "Neighbor Discovery for 6LoWPAN", Zach Shelby, Pascal Thubert, Jonathan Hui, Samita Chakrabarti, Erik Nordmark, 18-Nov-08, This document specifies Neighbor Discovery optimized for 6LoWPAN. The 6LoWPAN format allows IPv6 to be used over very low-power, low- bandwidth wireless networks often making use of extended multihop topologies. However, the use of standard IPv6 Neighbor Discovery over 6LoWPAN networks has several problems. Standard Neighbor Discovery was not designed for wireless links, the standard IPv6 link concept and heavy use of multicast makes it inefficient. This document spefies a new mechanism allowing efficient Duplicate Address Detection over entire 6LoWPAN networks. In addition it specifies prefix and context dissemination for use with router advertisements, allows for stateless address assignment, and the use of Neighbor Discovery Proxy. This document is an identical replacement of draft-shelby-6lowpan-nd-01. This document was now submitted as a 6lowpan working group document. "Problem Statement and Requirements for 6LoWPAN Routing", Eunsook Kim, Dominik Kaspar, Carles Gomez, Carsten Bormann, 18-Nov-08, This document provides the problem statement for 6LoWPAN routing. It also defines the requirements for 6LoWPAN routing considering IEEE 802.15.4 specificities and the low-power characteristics of the network and its devices. IPv6 Maintenance (6man) ----------------------- "Solution approaches for address-selection problems", Arifumi Matsumoto, Tomohiro Fujisaki, Ruri Hiromi, Ken-ichi Kanayama, 18-Jun-08, In response to address selection problem statement and requirement documents, this document describes approaches to solutions and evaluates proposed solution mechanisms in line with requirements. It also examines the applicability of each solution mechanism from the viewpoint of practical application. Matsumoto, et al. Expires August 2, 2008 [page 1] "IPv6 Node Requirements RFC 4294-bis", John Loughney, 3-Nov-08, This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. "Reserved IPv6 Interface Identifiers", Suresh Krishnan, 14-Jul-08, Interface Identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique within a subnet. Several RFCs have specified interface identifiers or identifier ranges that have a special meaning attached to them. An IPv6 node autoconfiguring an interface identifier in these ranges will encounter unexpected consequences. Since there is no centralized repository for such reserved identifiers, this document aims to create one. "IPv6 Subnet Model: the Relationship between Links and Subnet Prefixes", Hemant Singh, Wes Beebee, Erik Nordmark, 6-Oct-08, IPv6 specifies a model of a subnet that is different than the IPv4 subnet model. The subtlety of the differences has resulted in incorrect implementations that do not interoperate. This document spells out the most important difference; that an IPv6 address isn't automatically associated with an IPv6 on-link prefix. This document also invalidates (partially due to security concerns) a part of the definition of on-link from [RFC4861]. "Handling of overlapping IPv6 fragments", Suresh Krishnan, 4-Nov-08, The fragmentation and reassembly algorithm specified in the base IPv6 specification allows fragments to overlap. This document demonstrates the security issues with allowing overlapping fragments and updates the IPv6 specification to explicitly forbid overlapping fragments. ADSL MIB (adslmib) ------------------ "Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2)", Moti Morgenstern, Scott Baillie, Umberto Bonollo, 8-Jul-08, This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing parameters of the "Very High Speed Digital Subscriber Line 2 (VDSL2)" interface type, which are also applicable for managing ADSL, ADSL2, and ADSL2+ interfaces. "xDSL multi-pair bonding (G.Bond) MIB", Edward Beili, Moti Morgenstern, Narendranath Nair, 1-Sep-08, This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document proposes an extension to the Interfaces Group MIB with a set of common objects for managing multi-pair bonded Digital Subscriber Line (xDSL) interfaces, defined in ITU-T recommendations G.998.1, G.998.2 and G.998.3. The MIB modules specific to each bonding technology are defined in GBOND-ATM-MIB, GBOND-ETH-MIB and GBOND-TDIM-MIB respectively. Access Node Control Protocol (ancp) ----------------------------------- "Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks", Sven Ooghe, Norbert Voigt, Michel Platnic, Thomas Haag, Sanjay Wadhwa, 3-Nov-08, The purpose of this document is to define a framework for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform QoS-related, service-related and Subscriber-related operations. The Access Node Control Mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather using a direct device-device communication. This allows for performing access link related operations within those network elements, while avoiding impact on the existing OSS systems. "Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)", Hassnaa Moustafa, Hannes Tschofenig, Stefaan De Cnodder, 7-Oct-08, The Access Node Control Protocol (ANCP) aims to communicate QoS- related, service-related and subscriber-related configurations and operations between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)). The main goal of this protocol is to allow the NAS to configure, manage and control access equipments including the ability for the access nodes to report information to the NAS. The present document investigates security threats that all ANCP nodes could encounter. This document develops a threat model for ANCP security aiming to decide which security functions are required. Based on this, security requirements regarding the Access Node Control Protocol are defined. "Protocol for Access Node Control Mechanism in Broadband Networks", Sanjay Wadhwa, Jerome Moisand, Swami Subramanian, Thomas Haag, Norber Voigt, Roberta Maglione, 3-Nov-08, This document describes proposed extensions to the GSMPv3 protocol to allow its use in a broadband environment, as a control plane between Access Nodes (e.g. DSLAM) and Broadband Network Gateways (e.g. NAS). These proposed extensions are required to realize a protocol for "Access Node Control" mechanism as described in [ANCP-FRAMEWORK]. The resulting protocol with the proposed extensions to GSMPv3 [RFC3292] is referred to as "Access Node Control Protocol" (ANCP). This document currently focuses on specific use cases of access node control mechanism for topology discovery, line configuration, and OAM as described in ANCP framework document [ANCP-FRAMEWORK]. It is intended to be augmented by additional protocol specification for future use cases considered in scope by the ANCP charter. ANCP framework document [ANCP-FRAMEWORK] describes the ANCP use-cases in detail. Illustrative text for the use-cases is included here to help the protocol implementer understand the greater context of ANCP protocol interactions. "Access Node Control Protocol (ANCP) MIB module for Access Nodes", Stefaan De Cnodder, Moti Morgenstern, 24-Jun-08, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing access nodes that are using the Access Node Control Protocol (ANCP). Ad-Hoc Network Autoconfiguration (autoconf) ------------------------------------------- "Mobile Ad hoc Network Architecture", Ian Chakeres, Joseph Macker, Thomas Clausen, 7-Nov-07, This document discusses Mobile Ad hoc NETworks (MANETs). It presents the initial motivation for MANET and describes unaccustomed characteristics and challenges. It also defines a MANET, other MANET entities, and MANET architectural concepts. Audio/Video Transport (avt) --------------------------- "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback", Joerg Ott, 7-Jan-08, This document specifies an extension to the Real-time Transport Control Protocol (RTCP) to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism. Ott et al. Internet Draft - Expires July 2008 [page 1] RTCP with Unicast Feedback "RTP Payload Format for Adaptive TRansform Acoustic Coding (ATRAC) Family", Jun Matsumoto, Mitsuyuki Hatanaka, 24-Nov-08, This document describes an RTP payload format for efficient and flexible transporting of audio data encoded with the Adaptive TRansform Audio Coding (ATRAC) family of codecs. Recent enhancements to the ATRAC family of codecs support high quality audio coding with multiple channels. The RTP payload format as presented in this document also includes support for data fragmentation, elementary redundancy measures, and a variation on scalable streaming. "Associating Time-codes with RTP streams", David Singer, 3-Nov-08, This document describes a mechanism for associating time-codes, as defined by the Society of Motion Picture and Television Engineers (SMPTE), with media streams, in a way that is independent of the RTP payload format of the media stream itself. "RTP Payload Format for ITU-T Recommendation G.722.1", Patrick Luthi, Roni Even, 22-Aug-08, International Telecommunication Union (ITU-T) Recommendation G.722.1 is a wide-band audio codec. This document describes the payload format for including G.722.1 generated bit streams within an RTP packet. The document also describes the syntax and semantics of the SDP parameters needed to support G.722.1 audio codec. "RTP Payload Format for the Speex Codec", Greg Herlein, Jean-Marc Valin, Alfred Heggestad, Aymeric Moizard, 16-Feb-08, Speex is an open-source voice codec suitable for use in Voice over IP (VoIP) type applications. This document describes the payload format for Speex generated bit streams within an RTP packet. Also included here are the necessary details for the use of Speex with the Session Description Protocol (SDP).Editors Note All references to RFC XXXX are to be replaced by references to the RFC number of this memo, when published. "How to Write an RTP Payload Format", Magnus Westerlund, 11-Sep-08, This document contains information on how to best write an RTP payload format. Reading tips, design practices, and practical tips on how to quickly and with good results produce an RTP payload format specification. A template is also included with instructions that can be used when writing an RTP payload format. "Transmission Time offsets in RTP streams", David Singer, HariKishan Desineni, 11-Mar-08, This document describes a method to inform RTP clients when RTP packets are transmitted at a time other than their 'nominal' transmission time. It also provides a mechanism to provide improved inter-arrival jitter reports from the clients, that take into account the reported transmission times. "Multiplexing RTP Data and Control Packets on a Single Port", Colin Perkins, Magnus Westerlund, 6-Aug-07, This memo discusses issues that arise when multiplexing RTP data packets and RTP control protocol (RTCP) packets on a single UDP port. It updates RFC 3550 to describe when such multiplexing is, and is not, appropriate, and explains how the Session Description Protocol (SDP) can be used to signal multiplexed sessions. "RTP Payload Format for SVC Video", Stephan Wenger, Ye-Kui Wang, Thomas Schierl, Alex Eleftheriadis, 3-Nov-08, This memo describes an RTP payload format for Scalable Video Coding (SVC) as defined in_Annex G of ITU-T Recommendation H.264, which is technically identical to Amendment 3 of ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit in multiple RTP packets. Furthermore, it supports transmission of an SVC stream over a single as well as multiple RTP sessions. For single-session transmission the packetization modes of [I-D.ietf-avt-rtp- rfc3984bis] are used. For multi-session transmission four different modes are defined in this memo. The modes differ depending on whether the SVC data are allowed to be interleaved, i.e., to be transmitted in an order different than the intended decoding order, and they also differ in the mechanisms provided in order to recover the correct decoding order of the NAL units across the multiple RTP sessions. Specifically, decoding order recovery is performed using either timestamp alignment or Cross-Session Decoding Order Numbers (CS-DON), although in one of the modes both schemes are used in order to allow receivers to use their preferred method. The multi- session transmission modes use the packetization modes defined in [I-D.ietf-avt-rtp-rfc3984bis] as each individual session still uses a packetization mode defined in [I-D.ietf-avt-rtp-rfc3984bis]. The packetization modes defined in [I-D.ietf-avt-rtp-rfc3984bis] are slightly extended such that the three new NAL unit types defined in this memo can be included in the RTP packet streams. The payload format defines a new media subtype name "H264-SVC", but is still backwards compatible to [I-D.ietf-avt-rtp-rfc3984bis] since the base layer, when encapsulated in its own RTP stream, must use the H.264 media subtype name ("H264") and the packetization method specified in [I-D.ietf-avt-rtp-rfc3984bis]. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. Table of Contents Status of this Memo...............................................1 Copyright Notice..................................................1 Abstract..........................................................2 "RTP Payload Format for MIDI", John Lazzaro, John Wawrzynek, Intellectual Property, 6-Aug-08, This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content- delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. "RTP payload format for mU-law EMbedded Codec for Low-delay IP communication (UEMCLIP) speech codec", Yusuke Hiwasaki, Hitoshi Ohmuro, 25-Feb-08, This document describes the RTP payload format of a mU-law EMbedded Coder for Low-delay IP communication (UEMCLIP), an enhanced speech codec of ITU-T G.711. The bitstream has a scalable structure with an embedded u-law bitstream, also known as PCMU, thus providing a handy transcoding operation between narrowband and wideband speech. "Application Mechanism for maintaining alive the Network Address Translator (NAT) mappings associated to RTP flows.", Xavier Marjou, Aurelien Sollaud, 2-Oct-08, This document lists the different mechanisms that enable applications using Real-time Transport Protocol (RTP) to maintain their RTP Network Address Translator (NAT) mappings alive. It also makes a recommendation for a preferred mechanism. This document is not applicable to Interactive Connectivity Establishment (ICE) agents. "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)", David McGrew, Eric Rescorla, 29-Oct-08, This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for secure RTP (SRTP) and secure RTP Control Protocol (SRTCP) flows. DTLS keying happens on the media path, independent of any out-of-band signalling channel present. "Forward-shifted RTP Redundancy Payload Support", Qiaobing Xie, 7-Oct-08, This document defines a simple enhancement to RFC 2198 to support RTP sessions with forward-shifted redundant encodings, i.e., redundant data sent before the corresponding primary data. Forward-shifted redundancy can be used to conceal losses of a large number of consecutive media frames (e.g., consecutive loss of seconds or even tens of seconds of media). "The SEED Cipher Algorithm and Its Use with the Secure Real-time Transport Protocol (SRTP)", Intellectual Property, 17-Nov-08, This document describes the use of the SEED block cipher algorithm in the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for the Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). "Support for Reduced-Size RTCP, Opportunities and Consequences", Ingemar Johansson, Magnus Westerlund, 18-Nov-08, This memo discusses benefits and issues that arise when allowing RTCP packets to be transmitted with reduced size. The size can be reduced if the rules on how to create compound packets outlined in RFC3550 are removed or changed. Based on that analysis this memo defines certain changes to the rules to allow feedback messages to be sent as reduced-size RTCP packets under certain conditions when using the RTP AVPF profile (RFC 4585). This document updates [RFC3550], [RFC3711] and [RFC4585]. "G.729.1 RTP Payload Format update: DTX support", Aurelien Sollaud, 26-Sep-08, This document updates the Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union (ITU-T) Recommendation G.729.1 audio codec. It adds Discontinuous Transmission (DTX) support to the RFC 4749 specification, in a backward-compatible way. An updated media type registration is included for this payload format. "Guidelines for Extending the RTP Control Protocol (RTCP)", Joerg Ott, Colin Perkins, 7-Jul-08, The RTP Control Protocol (RTCP) is used along with the Real-time Transport Protocol (RTP) to provide a control channel between media senders and receivers. This allows constructing a feedback loop to enable application adaptivity and monitoring, among other uses. The basic reporting mechanisms offered by RTCP are generic, yet quite powerful and suffice to cover a range of uses. This document provides guidelines on extending RTCP if those basic mechanisms prove insufficient. "RTP Payload Format for Elementary Streams with MPEG Surround multi- channel audio", Frans Bont, Stefan Doehla, Malte Schmidt, Ralph Sperschneider, 20-Oct-08, This memo describes extensions for the RTP payload format defined in RFC3640 for the transport of MPEG Surround multi-channel audio. Additional Media Type parameters are defined to signal backwards compatible transmission inside an MPEG-4 audio elementary stream. In addition a layered transmission scheme without using the MPEG-4 systems framework is presented to transport an MPEG Surround elementary stream via RTP in parallel with an RTP stream containing the downmixed audio data. "RTP Payload format for G.719", Magnus Westerlund, Ingemar Johansson, 17-Nov-08, This document specifies the payload format for packetization of the G.719 full-band codec encoded audio signals into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple channels, multiple frames per payload, and interleaving. "Post-Repair Loss RLE Report Block Type for RTCP XR", Ali Begen, Dong Hsu, Michael Lague, 27-Oct-08, This document defines a new report block type within the framework of RTP Control Protocol (RTCP) Extended Reports (XR). One of the initial XR report block types is the Loss Run Length Encoding (RLE) Report Block. This report conveys the information regarding the individual Real-time Transport Protocol (RTP) packet receipt and loss events experienced during the RTCP interval preceding the transmission of the report. The new report, which is referred to as the Post-repair Loss RLE Report, carries the information regarding the remaining lost packets after all loss-repair methods are applied. By comparing the RTP packet receipts/losses before and after the loss repair is completed, one can determine the effectiveness of the loss- repair methods in an aggregated fashion. This document also defines the signaling of the Post-repair Loss RLE Report in the Session Description Protocol (SDP). "Why RTP Does Not Mandate a Single Security Mechanism", Colin Perkins, Magnus Westerlund, 4-Nov-08, This memo discusses the problem of securing real-time multimedia sessions, and explains why the Real-time Transport Protocol (RTP) does not mandate a single media security mechanism. "RTP Payload Format for H.264 Video", Ye-Kui Wang, Roni Even, Tom Kristensen, 3-Nov-08, 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 intends to obsolete RFC 3984. Changes from RFC 3984 are summarized in section 17. Issues on backward compatibility to RFC 3984 are discussed in section 16. "RTP payload format for G.718 speech/audio", Ari Lakaniemi, Ye-Kui Wang, 23-Oct-08, This document specifies the Real-Time Transport Protocol (RTP) payload format for the Embedded Variable Bit-Rate (EV-VBR) speech/audio codec, specified in ITU-T G.718. A media type registration for this RTP payload format is also included. "RTCP XR Report Block for Burst/Gap Loss metric Reporting", Geoff Hunt, Alan Clark, 27-Oct-08, This document defines an RTCP XR Report Block that allows the reporting of Burst and Gap Loss metrics for use in a range of RTP applications. "RTCP XR Report Block for Burst/Gap Discard metric Reporting", Geoff Hunt, Alan Clark, 27-Oct-08, This document defines an RTCP XR Report Block that allows the reporting of Burst and Gap Discard metrics for use in a range of RTP applications. "RTCP XR Report Block for Post-Repair Loss metric Reporting", Geoff Hunt, Alan Clark, 27-Oct-08, This document defines an RTCP XR Report Block that allows the reporting of a simple post-repair loss count metric for use in a range of RTP applications. It complements the pre-repair loss count metric "cumulative number of packets lost" provided by RFC3550. "RTCP XR Report Block for Packet Delay Variation Metric Reporting", Geoff Hunt, Alan Clark, 27-Oct-08, This document defines an RTCP XR Report Block that allows the reporting of Packet Delay Variation metrics for a range of RTP applications. "RTCP XR Report Block for Measurement Identity", Geoff Hunt, Alan Clark, 27-Oct-08, This document defines an RTCP XR Report Block carrying parameters which identify a measurement, to which one or more other RTCP XR Report Blocks may refer. "RTCP XR Report Block for Loss Concealment metric Reporting", Geoff Hunt, Alan Clark, 27-Oct-08, This document defines an RTCP XR Report Block that allows the reporting of Loss Concealment metrics primarily for audio applications of RTP. "RTCP XR Report Block for Jitter Buffer Metric Reporting", Geoff Hunt, Alan Clark, 27-Oct-08, This document defines an RTCP XR Report Block that allows the reporting of Jitter Buffer metrics for a range of RTP applications. "RTCP XR Report Block for Discard metric Reporting", Geoff Hunt, Alan Clark, 27-Oct-08, This document defines an RTCP XR Report Block that allows the reporting of a simple discard count metric for use in a range of RTP applications. "RTCP XR Report Block for Delay metric Reporting", Geoff Hunt, Alan Clark, 27-Oct-08, This document defines an RTCP XR Report Block that allows the reporting of Delay metrics for use in a range of RTP applications. "RTCP XR Report Block for Concealed Seconds metric Reporting", Geoff Hunt, Alan Clark, 27-Oct-08, This document defines an RTCP XR Report Block that allows the reporting of Concealed Seconds metrics primarily for audio applications of RTP. "RTCP XR Report Block for QoE Metrics Reporting", Alan Clark, Geoff Hunt, 27-Oct-08, This document defines an RTCP XR Report Block that allows the reporting of QoE metrics for use in voice, audio and video services. "RTCP XR Report Block for Signal Level Metrics Reporting", Alan Clark, Geoff Hunt, 27-Oct-08, This document defines an RTCP XR Report Block that allows the reporting of metrics related to signal levels for use in voice, audio and video services. Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", Jonathan Rosenberg, Rohan Mahy, Philip Matthews, 29-Oct-08, If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. The TURN protocol was designed to be used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal, though it can be also used without ICE. "Traversal Using Relays around NAT (TURN) Extension for IPv4/IPv6 Transition", Gonzalo Camarillo, Oscar Novo, 29-Oct-08, This document defines the REQUESTED-ADDRESS-TYPE attribute for Traversal Using Relays around NAT (TURN). The REQUESTED-ADDRESS-TYPE attribute allows a client to explicitly request the address type the TURN server will allocate (e.g., an IPv4-only node may request the TURN server to allocate an IPv6 address). Additionally, this document also defines a new error response code with the value 440 (Address Family not Supported). "NAT Behavioral Requirements for ICMP protocol", Pyda Srisuresh, Bryan Ford, Senthil Sivakumar, Saikat Guha, 22-Nov-08, This document specifies the behavioral properties required of the Network Address Translator (NAT) devices in conjunction with the Internet Control Message Protocol (ICMP). The objective of this memo is to make NAT devices more predictable and compatible with diverse application protocols that traverse the devices. Companion documents provide behavioral recommendations specific to TCP, UDP and other protocols. "NAT Behavior Discovery Using STUN", Derek MacDonald, Bruce Lowekamp, 3-Nov-08, This specification defines an experimental usage of the Simple Traversal Underneath Network Address Translators (NAT) (STUN) Protocol that discovers the presence and current behaviour of NATs and firewalls between the STUN client and the STUN server. "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", Jonathan Rosenberg, Rohan Mahy, 4-Nov-08, This specification defines an extension of Traversal Using Relays around NAT (TURN), a relay protocol for NAT traversal, to allows a TURN client to request TCP allocations, and defines new requests and indications for the TURN server to open and accept TCP connections with the client's peers. TURN and this extension both purposefully restrict the ways in which the relayed address can be used. In particular, it prevents users from running general purpose servers from ports obtained from the STUN server. "Test vectors for STUN", Remi Denis-Courmont, 18-Nov-08, The Session Traversal Utilities for NAT (STUN) protocol defines several STUN attributes. The content of some of these -- FINGERPRINT, MESSAGE-INTEGRITY and XOR-MAPPED-ADDRESS -- involve binary-logical operations (hashing, xor). This document provides test vectors for those attributes. "Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol", Remi Denis-Courmont, 27-Nov-08, This document defines a set of requirements for NATs handling the Datagram Congestion Control Protocol (DCCP). Those allow DCCP applications, such as streaming applications to operate consistently. These requirements are very similar to the TCP requirements for NATs already published by the IETF. Ensuring that NATs meet this set of requirements will greatly increase the likelihood that applications using DCCP will function properly. "Stream Control Transmission Protocol (SCTP) Network Address Translation", Randall Stewart, Michael Tuexen, Irene Ruengeler, 22-Oct-08, Stream Control Transmission Protocol [RFC4960] provides a reliable communications channel between two end-hosts in many ways similar to TCP [RFC0793]. With the widespread deployment of Network Address Translators (NAT), specialized code has been added to NAT for TCP that allows multiple hosts to reside behind a NAT and yet use only a single globally unique IPv4 address, even when two hosts (behind a NAT) choose the same port numbers for their connection. This additional code is sometimes classified as Network Address and Port Translation or NAPT. To date, specialized code for SCTP has NOT yet been added to most NATs so that only pure NAT is available. The end result of this is that only one SCTP capable host can be behind a NAT. This document describes an SCTP specific variant of NAT which provides similar features of NAPT in the single point and multi-point traversal scenario. Bidirectional Forwarding Detection (bfd) ---------------------------------------- "BFD Management Information Base", Thomas Nadeau, Zafar Ali, Nobo Akiya, 31-Oct-08, This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol. "BFD For MPLS LSPs", Rahul Aggarwal, Kireeti Kompella, Thomas Nadeau, George Swallow, 20-Jun-08, One desirable application of Bi-directional Forwarding Detection (BFD) is to detect a Multi Protocol Label Switched (MPLS) Label Switched Path (LSP) data plane failure. LSP-Ping is an existing mechanism for detecting MPLS data plane failures and for verifying the MPLS LSP data plane against the control plane. BFD can be used for the former, but not for the latter. However the control plane processing required for BFD control packets is relatively smaller than the processing required for LSP-Ping messages. A combination of LSP-Ping and BFD can be used to provide faster data plane failure detection and/or make it possible to provide such detection on a greater number of LSPs. This document describes the applicability of BFD in relation to LSP-Ping for this application. It also describes procedures for using BFD in this environment. "Bidirectional Forwarding Detection", Dave Katz, David Ward, 24-Mar-08, This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. Comments on this draft should be directed to rtg-bfd@ietf.org. "BFD for Multihop Paths", Dave Katz, David Ward, 16-Jan-08, This document describes the use of the Bidirectional Forwarding Detection protocol (BFD) over multihop paths, including unidirectional links. "BFD for IPv4 and IPv6 (Single Hop)", Dave Katz, David Ward, 24-Mar-08, This document describes the use of the Bidirectional Forwarding Detection protocol over IPv4 and IPv6 for single IP hops. Comments on this draft should be directed to rtg-bfd@ietf.org. "Generic Application of BFD", Dave Katz, David Ward, 16-Jan-08, This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol. Comments on this draft should be directed to rtg-bfd@ietf.org. Basic Level of Interoperability for SIP Services (bliss) -------------------------------------------------------- "Basic Level of Interoperability for Session Initiation Protocol (SIP) Services (BLISS) Problem Statement", Jonathan Rosenberg, 3-Nov-08, The Session Initiation Protocol (SIP) has been designed as a general purpose protocol for establishing and managing multimedia sessions. It provides many core functions and extensions in support of features such as transferring of calls, parking calls, and so on. However, interoperability of more advanced features between different vendors has been poor. This document describes the reason behind these interoperability problems, and presents a framework for addressing them. "An Analysis of Automatic Call Handling Implementation Issues in the Session Initiation Protocol (SIP)", John Elwell, 3-Nov-08, This discusses problems associated with automatic call handling (ACH) when using the Session Initiation Protocol (SIP). This work is being discussed on the bliss@ietf.org mailing list. "Call Completion for Session Initiation Protocol (SIP)", Dale Worley, Martin Huelsemann, Denis Alexeitsev, 20-Jun-08, The features "call completion on busy subscriber" and "call completion on no reply" allow the calling party of a failed call to be notified when the called party becomes available to receive a call. This document describes an architecture for implementing these features in the Session Initiation Protocol: "Call completion" implementations at the caller's and callee's endpoints cooperate to place the caller's request for call completion into a queue at the callee's endpoint, and, when a caller's request is ready to be serviced, re-attempt the original, failed call. "Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)", Alan Johnston, Mohsen Soroushnejad, Venkatesh Venkataramanan, 2-Nov-08, This document describes the requirements and implementation of a group telephony feature commonly known as Bridged Line Appearance (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line Appearance (SCA). When implemented using the Session Initiation Protocol (SIP), it is referred to as Shared Appearances (SA) of an Address of Record (AOR) since SIP does not have the concept of lines. This feature is commonly offered in IP Centrex services and IP-PBX offerings and is likely to be implemented on SIP IP telephones and SIP feature servers used in a business environment. This document lists requirements and compares implementation options for this feature. Extensions to the SIP dialog event package are proposed. Benchmarking Methodology (bmwg) ------------------------------- "Benchmarking Methodology for Link-State IGP Data Plane Route Convergence", Scott Poretsky, Brent Imhoff, Intellectual Property, 15-Oct-08, This document describes the methodology for benchmarking Interior Gateway Protocol (IGP) Route Convergence. The methodology is to be used for benchmarking IGP convergence time through externally observable (black box) data plane measurements. The methodology can be applied to any link-state IGP, such as ISIS and OSPF. Link-State IGP Data Plane Route Convergence "Terminology for Benchmarking Link-State IGP Data Plane Route Convergence", Scott Poretsky, Brent Imhoff, Intellectual Property, 15-Oct-08, This document describes the terminology for benchmarking Interior Gateway Protocol (IGP) Route Convergence. The terminology is to be used for benchmarking IGP convergence time through externally observable (black box) data plane measurements. The terminology can be applied to any link-state IGP, such as ISIS and OSPF. Link-State IGP Data Plane Route Convergence "Considerations for Benchmarking Link-State IGP Data Plane Route Convergence", Scott Poretsky, Intellectual Property, 15-Oct-08, This document discusses considerations for benchmarking Interior Gateway Protocol (IGP) Route Convergence for any link-state IGP, such as Intermediate System-Intermediate System (ISIS) and Open-Shorted Path first (OSPF). A companion methodology document is to be used for benchmarking IGP convergence time through externally observable (black box) data plane measurements. A companion "Benchmarking Terminology for Protection Performance", Scott Poretsky, 3-Nov-08, This document provides common terminology and metrics for benchmarking the performance of sub-IP layer protection mechanisms. The performance benchmarks are measured at the IP-Layer, avoiding dependence on specific sub-IP protection mechanisms. The benchmarks and terminology can be applied in methodology documents for different sub-IP layer protection mechanisms such as Automatic Protection Switching (APS), Virtual Router Redundancy Protocol (VRRP), Stateful High Availability (HA), and Multi-Protocol Label Switching Fast Reroute (MPLS-FRR). "Methodology for Benchmarking MPLS Protection Mechanisms", Rajiv Papneja, Samir Vapiwala, Jay Karthik, Scott Poretsky, Shankar Rao, Jean-Louis Roux, 3-Nov-08, Protection Mechanisms This draft describes the methodology for benchmarking MPLS Protection mechanisms for link and node protection as defined in [MPLS-FRR-EXT]. This document provides test methodologies and test bed setup for measuring failover times while considering all dependencies that might impact faster recovery of real-time services bound to MPLS based traffic engineered tunnels. The terms used in the procedures included in this document are defined in [TERM-ID]. "MPLS Forwarding Benchmarking Methodology", Aamer Akhter, Rajiv Asati, 3-Nov-08, This document describes a methodology specific to the benchmarking of MPLS forwarding devices, limited to various types of packet- forwarding and delay measurements. It builds upon the tenets set forth in RFC2544 [RFC2544], RFC1242 [RFC1242] and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the MPLS paradigm. Better-Than-Nothing Security (btns) ----------------------------------- "IPsec Channels: Connection Latching", Nicolas Williams, 3-Nov-08, This document specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create "channels" by latching "connections" (packet flows) to certain IPsec Security Association (SA) parameters for the lifetime of the connections. Connection latching is layered on top of IPsec and does not modify the underlying IPsec architecture. Connection latching can be used to protect applications against accidentally exposing live packet flows to unintended peers, whether as the result of a reconfiguration of IPsec or as the result of using weak peer identity to peer address associations. Weak association of peer ID and peer addresses is at the core of Better Than Nothing Security (BTNS), thus connection latching can add a significant measure of protection to BTNS IPsec nodes. Finally, the availability of IPsec channels will make it possible to use channel binding to IPsec channels. "An abstract interface between applications and IPsec", Michael Richardson, 2-Nov-08, This document explains in the abstract (no language bindings are provided) how an application may learn that IPsec has been applied to a conversation or specify that IPsec should be used. Though this is useful in general it is particularly useful for applications that wish to use BTNS (Better Than Nothing Security -- a mode of IPsec keying), either in conjunction with channel binding or otherwise. Calendaring and Scheduling Standards Simplification (calsify) ------------------------------------------------------------- "iCalendar Message-Based Interoperability Protocol (iMIP)", Alexey Melnikov, 9-Jun-08, This document, iCalendar Message-Based Interoperability Protocol (iMIP), specifies a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) to Internet email-based transports. Calendaring entries defined by the iCalendar Object Model (iCAL) are composed using constructs from RFC 2822, RFC 2045, RFC 2046, RFC 2047 and RFC 2049. This document is a product of Calendaring and Scheduling Standards Simplification (calsify) working group. More information about the IETF CALSIFY working group activities can be found on the IETF web site at . The issue tracker for the Calsify WG is located at: "iCalendar Transport-Independent Interoperability Protocol (iTIP)", Cyrus Daboo, 3-Nov-08, This document specifies a protocol using the iCalendar object specification to provide scheduling interoperability between different calendaring systems. This is done without reference to a specific transport protocol so as to allow multiple methods of communication between systems. Subsequent documents will define profiles of this protocol using specific interoperable methods of communications between systems. iTIP complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendaring systems. These scheduling methods permit two or more calendaring systems to perform transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel. "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", Bernard Desruisseaux, 31-Oct-08, This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to- dos, journal entries and free/busy information, independent of any particular calendar service or protocol.Editorial Note (To be removed by RFC Editor prior to publication) This document is a product of the Calendaring and Scheduling Standards Simplification (Calsify) working group of the Internet Engineering Task Force. Comments on this draft are welcomed, and should be addressed to the ietf-calsify@osafoundation.org [1] mailing list. Control And Provisioning of Wireless Access Points (capwap) ----------------------------------------------------------- "CAPWAP Protocol Specification", Michael Montemurro, Dorothy Stanley, Pat Calhoun, 1-Nov-08, This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol, meeting the objectives defined by the CAPWAP working group in RFC 4564. The CAPWAP protocol is designed to be flexible, allowing it to be used for a variety of wireless technologies. This document describes the base CAPWAP protocol, while separate binding extensions will enable its use with additional wireless technologies. "CAPWAP Protocol Binding for IEEE 802.11", Michael Montemurro, Dorothy Stanley, Pat Calhoun, 1-Nov-08, Wireless LAN product architectures have evolved from single autonomous access points to systems consisting of a centralized Access Controller (AC) and Wireless Termination Points (WTPs). The general goal of centralized control architectures is to move access control, including user authentication and authorization, mobility management and radio management from the single access point to a centralized controller. This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Binding Specification for use with the IEEE 802.11 Wireless Local Area Network protocol. "CAPWAP Threat Analysis for IEEE 802.11 Deployments", Scott Kelly, Charles Clancy, 10-Sep-08, Early Wireless Local Area Network (WLAN) deployments feature a "fat" Access Point (AP) which serves as a stand-alone interface between the wired and wireless network segments. However, this model raises scaling, mobility, and manageability issues, and the Control and Provisioning for Wireless Access Points (CAPWAP) protocol is meant to address these issues. CAPWAP effectively splits the fat AP functionality into two network elements, and the communication channel between these components may traverse potentially hostile hops. This document analyzes the security exposure resulting from the introduction of CAPWAP, and summarizes the associated security considerations for IEEE 802.11-based CAPWAP implementations and deployments. "CAPWAP Access Controller DHCP Option", Pat Calhoun, 14-Oct-08, The Control And Provisioning of Wireless Access Points Protocol allows a Wireless Termination Point to use DHCP to discover the Access Controllers it is to connect to. This document describes the DHCP options to be used by the CAPWAP protocol. "CAPWAP Protocol Base MIB", Yang Shi, David Perkins, Chris Elliott, Yong Zhang, 1-Nov-08, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol. "CAPWAP Protocol Binding MIB for IEEE 802.11", Yang Shi, David Perkins, Chris Elliott, Yong Zhang, 27-Oct-08, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol for IEEE 802.11 wireless binding. Common Control and Measurement Plane (ccamp) -------------------------------------------- "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", Kohei Shiomoto, Adrian Farrel, Richard Rabbat, Arthi Ayyangar, Zafar Ali, 17-Oct-08, Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links for carrying traffic in those networks or in other (client) networks. Protocol extensions already exist to facilitate the establishment of an LSP as a numbered traffic engineering (TE) link within the same instance of the routing as is used to advertise the links that it traverses creating a Forwarding Adjacency (FA). This document extends those mechanisms to support unnumbered FAs. This document also defines how to indicate that an LSP should be advertised as a link in another instance of the routing protocol (for instance in a client network) and which instance to use. Furthermore, mechanisms are defined to indicate when an LSP is to be used as a component link of a TE link bundle and to identify the bundle. "Ethernet Traffic Parameters", Dimitri Papadimitriou, Intellectual Property, 1-Nov-08, This document describes the Metro Ethernet Forum (MEF) - specific Ethernet Traffic Parameters as described in MEF10.1 when using Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. "OSPFv2 Routing Protocols Extensions for ASON Routing", Dimitri Papadimitriou, Intellectual Property, 29-Oct-08, The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON). The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies including optical networks such as time division multiplexing (TDM) networks including SONET/SDH and Optical Transport Networks (OTNs), and lambda switching optical networks. The requirements for GMPLS routing to satisfy the requirements of ASON routing, and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines to the OSPFv2 Link State Routing Protocol to meet the routing requirements for routing in an ASON. D.Papadimitriou et al. - Expires April 2009 [page 1] draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt October 2008 Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations current when those documents were written. Future extensions of revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. "Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks", Zafar Ali, JP Vasseur, Anca Zamfir, Jonathan Newton, 29-Oct-08, 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. Ali et al. Expires April 2009 [page 1] draft-ietf-ccamp-mpls-graceful-shutdown-08.txt "Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)", Greg Bernstein, 18-Nov-08, This document describes requirements for, and use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in conjunction with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing mechanism and its companion Link Capacity Adjustment Scheme (LCAS) which can be used for hitless dynamic resizing of the inverse multiplex group. These techniques apply to Optical Transport Network (OTN), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals. "Traffic Engineering Database Management Information Base in support of MPLS-TE/GMPLS", Thomas Nadeau, 4-Aug-08, This memo defines the Management Information Base (MIB) objects in order to manage traffic engineering database (TED) information with extension in support of Multi-Protocol Label Switching (MPLS) with traffic engineering (TE) as well as Generalized MPLS (GMPLS) for use with network management protocols. "draft-ietf-ccamp-pc-and-sc-reqs-06.txt", Diego Caviglia, Dino Bramanti, Dan Li, Dave McDysan, 15-Sep-08, From a Carrier perspective, the possibility of turning a Permanent Connection (PC) into a Soft Permanent Connection (SPC) and vice versa, without actually affecting Data Plane traffic being carried over it, is a valuable option. In other terms, such operation can be seen as a way of transferring the ownership and control of an existing and in-use Data Plane connection between the Management Plane and the Control Plane, leaving its Data Plane state untouched. This memo sets out the requirements for such procedures within a Generalized Multiprotocol Label Switching (GMPLS) network. "OSPF Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering", Mach Chen, Renhai Zhang, 27-Jul-08, This document describes extensions to the OSPF version 2 and 3 protocols to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined for the flooding of TE information about inter-AS links which can be used to perform inter-AS TE path computation. No support for flooding information from within one AS to another AS is proposed or defined in this document. "Description of the RSVP-TE Graceful Restart Procedures", Dan Li, 19-May-08, The Hello message for the Resource Reservation Protocol (RSVP) has been defined to establish and maintain basic signaling node adjacencies for Label Switching Routers (LSRs) participating in a Multiprotocol Label Switching (MPLS) traffic engineered (TE) network. The Hello message has been extended for use in Generalized MPLS (GMPLS) network for state recovery of control channel or nodal faults. "Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)", Dimitri Papadimitriou, Martin Vigoureux, Kohei Shiomoto, Deborah Brungard, Jean-Louis Roux, Eiji Oki, Ichiro Inoue, Emmanuel Dotaro, Gert Grammel, 3-Nov-08, There are requirements for the support of networks comprising LSRs with different data plane switching layers controlled by a single Generalized Multi Protocol Label Switching (GMPLS) control plane instance, referred to as GMPLS Multi-Layer Networks/Multi-Region Networks (MLN/MRN). This document defines extensions to GMPLS routing and signaling protocols so as to support the operation of GMPLS Multi-Layer/Multi- Region Networks. It covers the elements of a single GMPLS control plane instance controlling multiple LSP regions or layers within a single TE domain. "ISIS Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering", Mach Chen, Renhai Zhang, 4-Sep-08, This document describes extensions to the ISIS (ISIS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines ISIS-TE extensions for the flooding of TE information about inter-AS links which can be used to perform inter- AS TE path computation. No support for flooding information from within one AS to another AS is proposed or defined in this document. "GMPLS Ethernet Label Switching Architecture and Framework", Don Fedyk, Lou Berger, Loa Andersson, 27-Oct-08, There has been significant recent work in increasing the capabilities of Ethernet switches and Ethernet forwarding models. As a consequence, the role of Ethernet is rapidly expanding into "transport networks" that previously were the domain of other technologies such as SONET/SDH TDM and ATM. This document defines an architecture and framework for a GMPLS based control plane for Ethernet in this "transport network" capacity. GMPLS has already been specified for similar technologies. Some additional extensions to the GMPLS control plane are needed and this document provides a framework for these extensions.Contents "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE", Adrian Farrel, Dimitri Papadimitriou, JP Vasseur, Arthi Ayyangar, 27-May-08, Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits. This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis. "GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)", Lou Berger, Attila Takacs, Diego Caviglia, Don Fedyk, Julien Meuric, 17-Nov-08, This document defines a method for the support of GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs). The presented approach is applicable to any switching technology and builds on the original RSVP model for the transport of traffic related parameters. The procedures described in this document are experimental. "Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks", Weiqiang Sun, Guoying Zhang, Jianhua Gao, Guowu Xie, Rajiv Papneja, Bin Gu, Xueqing Wei, 24-Jun-08, Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for future data transmission network. GMPLS has been developed to control and operate different kinds of network elements, such as conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add- Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross- connects (OXCs), etc. Dynamic provisioning ability of these physically diverse devices differs from each other drastically. At the same time, the need for Dynamicly provisioned connections is increasing because optical networks are being deployed in metro areas. As different applications have varied requirements in the provisioning performance of optical networks, it is imperative to define standardized metrics and procedures such that the performance of networks and application needs can be mapped to each other. This document provides a series of performance metrics to evaluate the dynamic LSP provisioning performance in GMPLS networks, specifically the Dynamic LSP setup/release performance. These metrics can depict the features of GMPLS networks in LSP dynamic provisioning. They can also be used in operational networks for carriers to monitor the control plane performance in realtime. "Data Channel Status Confirmation Extensions for the Link Management Protocol", Dan Li, Huiying Xu, Fatai Zhang, Snigdho Bardalai, Julien Meuric, Diego Caviglia, 2-Nov-08, This document defines simple additions to the Link Management Protocol (LMP) to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent LSRs to confirm data channel statuses, and provides triggers for notifying the management plane if any discrepancies are found. "RSVP Extensions for Path Key Support", Richard Bradford, JP Vasseur, Adrian Farrel, 1-Nov-08, The paths taken by Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. To preserve confidentiality of topology within each AS, the PCEs support a mechanism to hide the contents of a segment of a path (such as the segment of the path that traverses an AS), called the Confidential Path Segment (CPS), by encoding the contents as a Path Key Subobject (PKS) and embedding this subobject within the result of its path computation. This document describes how to carry Path Key Subobjects in the Resource Reservation Protocol (RSVP) Explicit Route Objects (EROs) and Record Route Object (RROs) so as to facilitate confidentiality in the signaling of inter-domain TE LSPs. "draft-ietf-ccamp-pc-spc-rsvpte-ext-02.txt", Diego Caviglia, Daniele Ceccarelli, Dino Bramanti, Dan Li, Snigdho Bardalai, 31-Oct-08, 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. See draft "draft-ietf-ccamp-pc-and-reqs-04.txt [1]. This memo provides a minor extension to RSVP-TE [RFC2205], [RFC3471], [RFC3473], [RFC4872] signaling protocol, within GMPLS architecture, to enable such connection ownership transfer and describes the proposed procedures. Failure conductions and subsequent roll back are also illustrated taking into account that an handover failure must not impact the already established data plane connections. "GMPLS control of Ethernet PBB-TE", Don Fedyk, David Allan, Himanshu Shah, Nabil Bitar, Attila Takacs, Diego Caviglia, Alan McGuire, Nurit Sprecher, Lou Berger, 13-Jul-08, This specification is complementary to the GMPLS controlled Ethernet architecture document [ARCH] and describes the technology specific aspects of GMPLS control for Provider Backbone Bridging Traffic Engineering (PBB-TE) [IEEE 802.1Qay]. The necessary GMPLS extensions and mechanisms are described to establish Ethernet PBB-TE point to point (P2P) and point to multipoint (P2MP) connections. This document supports, but does not modify, the standard IEEE data plane. "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching", Lou Berger, Don Fedyk, 8-Aug-08, This document describes a method for controlling two specific types of Ethernet switching via Generalized Multi-Protocol Label Switching (GMPLS). This document supports the types of switching implied by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. Specifically, switching in support of Ethernet private line service and Ethernet virtual private line service. Support for MEF and ITU defined parameters are also covered. Some of the extensions defined in this document are generic in nature and not specific to Ethernet. "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI)", Lou Berger, Don Fedyk, 8-Aug-08, This document describes a method for controlling two specific types of Ethernet switching via a Generalized Multi-Protocol Label Switching (GMPLS) based User-Network Interface (UNI). This document supports the types of switching required to implied by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. This document is the UNI companion to "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching". This document does not define or limit the underlying intra-domain or Internal NNI (I-NNI) technology used to support the UNI. "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON)", Greg Bernstein, 31-Oct-08, This memo provides a framework for applying Generalized Multi- Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of wavelength switched optical networks (WSON). In particular we provide control plane models for key wavelength switched optical network subsystems and processes. The subsystems include wavelength division multiplexed links, tunable laser transmitters, reconfigurable optical add/drop multiplexers (ROADM) and wavelength converters. Lightpath provisioning, in general, requires the routing and wavelength assignment (RWA) process. This process is reviewed and the information requirements, both static and dynamic for this process are presented, along with alternative implementation scenarios that could be realized via GMPLS/PCE and/or extended GMPLS/PCE protocols. This memo does NOT address optical impairments in any depth and focuses on topological elements and path selection constraints that are common across different WSON environments. It is expected that a variety of different techniques will be applied to optical impairments depending on the type of WSON, such as access, metro or long haul. "Generalized Labels for G.694 Lambda-Switching Capable Label Switching Routers", Tomohiro Otani, Hongxiang Guo, Keiji Miyazaki, Diego Caviglia, 14-Jul-08, 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. "Service Provider Requirements for Ethernet control with GMPLS", Wataru Imajuku, Yoshiaki Sone, Muneyoshi Suzuki, Kazuhiro Matsuda, Nabil Bitar, 11-Jun-08, Generalized Multi-Protocol Label Switching (GMPLS) is applicable to Ethernet switches supporting Provider Backbone Bridge Traffic Engineering (PBB-TE) networks. The GMPLS controlled Ethernet label switch network not only automates creation of Ethernet Label Switched Paths(Eth-LSPs), it also provides sophisticated Eth-LSP recovery Mechanisms such as protection and restoration of an Eth-LSP. This document describes the requirements for the set of solutions of GMPLS controlled Ethernet label switch networks. "Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions", Lou Berger, Don Fedyk, 8-Aug-08, This document describes two technology independent extensions to Generalized Multi-Protocol Label Switching. The first extension defines the new switching type Data Channel Switching Capable. Data Channel Switching Capable interfaces are able to support switching of the whole digital channel presented on single channel interfaces. The second extension defines a new type of generalized label and updates related objects. The new label is called the Generalized Channel_Set Label and allows more than one data plane label to be controlled as part of an LSP. "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks", Greg Bernstein, 3-Nov-08, This document provides a model of information needed by the routing and wavelength assignment (RWA) process in wavelength switched optical networks (WSONs). The purpose of the information described in this model is to facilitate constrained lightpath computation in WSONs, particularly in cases where there are no or a limited number of wavelength converters available. This model currently does not include optical impairments. Cga & Send maIntenance (csi) ---------------------------- "SeND Hash Threat Analysis", Ana Kukec, Suresh Krishnan, Sheng Jiang, 3-Nov-08, 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. The purpose of the document is to provide analysis of possible hash threats and to decide how to encode the hash agility support in SeND. "Securing Neighbor Discovery Proxy Problem Statement", Greg Daley, Jean-Michel Combes, Suresh Krishnan, 20-Oct-08, Neighbor Discovery Proxy is used to provide an address presence on a link from nodes which are no themselves present. It allows a node to receive packets directed at its address by allowing another device to Neighbor advertise on its behalf. Neighbor Discovery Proxy is used in Mobile IPv6 and related protocols to provide reachability from nodes on the home network when a Mobile Node is not at home, by allowing the Home Agent to act as proxy. It is also used as a mechanism to allow a global prefix to span multiple links, where proxies act as relays for Neighbor discovery messages. Neighbor Discovery Proxy currently cannot be secured using SEND. Today, SEND assumes that a node advertising an address is the address owner and in possession of appropriate public and private keys for that node. This document describes how existing practice for proxy Neighbor Discovery relates to Secured Neighbor Discovery. "Secure Proxy ND Support for SEND", Suresh Krishnan, Julien Laganier, Marco Bonola, 4-Nov-08, Secure Neighbor Discovery (SEND) specifies a method for securing Neighbor Discovery (ND) signaling against specific threats. As specified today, SEND assumes that the node advertising an address is the owner of the address and is in possession of the private key used to generate the digital signature on the message. This means that the Proxy ND signaling initiated by nodes that do not possess knowledge of the address owner's private key cannot be secured using SEND. This document extends the current SEND specification with support for Proxy ND, the Secure Proxy ND Support for SEND. Datagram Congestion Control Protocol (dccp) ------------------------------------------- "Faster Restart for TCP Friendly Rate Control (TFRC)", Eddie Kohler, Sally Floyd, Arjuna Sathiaseelan, Intellectual Property, 14-Jul-08, TCP-Friendly Rate Control (TFRC) is a congestion control mechanism for unicast flows operating in a best-effort Internet environment. This document introduces Faster Restart, an optional mechanism for safely improving the behavior of interactive flows that use TFRC. Faster Restart is proposed for use with TFRC and with TFRC-SP, the Small Packet variant of TFRC. We present Faster Restart in general terms as a congestion control mechanism, and further discuss Faster Restart for Datagram Congestion Control Protocol (DCCP) Congestion Control IDs 3 and 4. "RTP and the Datagram Congestion Control Protocol (DCCP)", Colin Perkins, 22-Jun-07, The Real-time Transport Protocol (RTP) is a widely used transport for real-time multimedia on IP networks. The Datagram Congestion Control Protocol (DCCP) is a newly defined transport protocol that provides desirable services for real-time applications. This memo specifies a mapping of RTP onto DCCP, along with associated signalling, such that real-time applications can make use of the services provided by DCCP. "The DCCP Service Code", Gorry Fairhurst, 29-Sep-08, This document describes the usage of Service Codes by the Datagram Congestion Control Protocol, RFC 4340. It motivates the setting of a Service Code by applications. Service Codes provide a method to identify the intended service/application to process a DCCP connection request. This provides improved flexibility in the use and assignment of port numbers for connection multiplexing. The use of a DCCP Service Code can also enable more explicit coordination of services with middleboxes (e.g. network address translators and firewalls). This document updates the specification provided in RFC 4340. "DCCP Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal", Gorry Fairhurst, 8-Oct-08, This document specifies an update to the Datagram Congestion Control Protocol (DCCP), a connection-oriented and datagram-based transport protocol. The update adds support for the DCCP-Listen packet. This assists DCCP applications to communicate through middleboxes (e.g. a DCCP server behind a firewall, or a Network Address Port Translator), where peering endpoints need to initiate communication in a near- simultaneous manner to establish necessary middlebox state. "Quick-Start for Datagram Congestion Control Protocol (DCCP)", Gorry Fairhurst, 5-Sep-08, This document specifies the use of the Quick-Start mechanism by the Datagram Congestion Control Protocol (DCCP). DCCP is a transport protocol that allows the transmission of congestion-controlled, unreliable datagrams. DCCP is intended for applications such as streaming media, Internet telephony, and on-line games. In DCCP, an application has a choice of congestion control mechanisms, each specified by a Congestion Control Identifier (CCID). This document specifies general procedures applicable to all DCCP CCIDs and specific procedures for the use of Quick-Start with DCCP CCID-2 and CCID-3. Quick-Start enables a DCCP sender to cooperate with any Quick-Start routers along the end-to-end path to determine an allowed sending rate at the start and, at times, in the middle of a DCCP connection (e.g., after an idle or application-limited period). The present specification is provided for use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet. Dynamic Host Configuration (dhc) -------------------------------- "Virtual Subnet Selection Options for DHCPv4 and DHCPv6", Kim Kinnear, Richard Johnson, Mark Stapp, Jay Kumarasamy, 8-Jul-08, 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]. "Subnet Allocation Option", Richard Johnson, 8-Jul-08, This document defines a new DHCP option which is passed between the DHCP Client and the DHCP Server to request dynamic allocation of a subnet, give specifications of subnet(s) allocated, and report usage statistics. This memo documents the current usage of the option in agreement with [RFC3942], which declares that any pre-existing usages of option numbers in the range 128 - 223 should be documented and the working group will try to officially assign those numbers to those options. "Rebind Capability in DHCPv6 Reconfigure Messages", D Evans, Ralph Droms, 17-Nov-08, This document updates RFC 3315 to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message, which extends the Reconfigure message to allow a DHCPv6 server to cause a DHCPv6 client to send a Rebind message. The document also clarifies how a DHCPv6 client responds to a received Reconfigure message. "Guidelines for Creating New DHCP Options", David Hankins, 14-Oct-08, This document seeks to provide guidance to prospective DHCP Option authors, to help them in producing option formats that are easily adoptable. "Container Option for Server Configuration", Ralph Droms, 28-Nov-08, In some DHCP service deployments, it is desirable for a DHCP server in one administrative domain to pass configuration options to a DHCP server in a different administrative domain. This DHCP option carries a set of DHCP options that can be used by another DHCP server. "Layer 2 Relay Agent Information", Bharat Joshi, Pavan Kurapati, 1-Oct-08, In some networks, DHCP servers rely on Relay Agent Information option appended by Relay Agents for IP address and other parameter assignment policies. This works fine when end hosts are directly connected to Relay Agents. In some network configurations, one or more Layer 2 devices may reside between DHCP clients and Relay agent. In these network scenarios, it is difficult to use the Relay Agent Information option for IP address and other parameter assignment policies effectively. So there is a need for the device that is closest to the end hosts to append Relay Agent Information option in DHCP messages. These devices are typically known as Layer 2 Relay Agents. This document aims to describe the network scenarios where Layer 2 Relay Agent is in use and also how it handles DHCP messages. "DHCPv6 Bulk Leasequery", Mark Stapp, 25-Nov-08, The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a client to request information about DHCPv6 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 DHCPv6 binding data via TCP. "Extensions to Layer 2 Relay Agent", Bharat Joshi, Pavan Kurapati, Mukund Kamath, Stefaan De Cnodder, 14-Jun-08, As per industry trends, Access Networks have been migrating from traditional ATM based networks to Ethernet networks. In Ethernet based access networks, Access Concentrators are typically configured to act as a transparent bridge in Layer 2 mode. These Access Concentrators also act as Layer 2 relay agents. Layer 2 Relay Agent functionality does not provide means to avoid flooding of DHCP messages and also needs to be extended to support DHCP LeaseQuery This draft discusses these issues and provides solutions for the same. "The DHCPv4 Relay Agent Identifier Suboption", Mark Stapp, 30-Sep-08, This memo defines a new Relay Agent Identifier suboption for the Dynamic Host Configuration Protocol's (DHCP) Relay Agent Information option. The suboption carries a value that uniquely identifies the relay agent device. The value may be administratively-configured or may be generated by the relay agent. The suboption allows a DHCP relay agent to include the identifier in the DHCP messages it sends. "DHCPv6 option for network boot", Thomas Huth, Jens Freimann, 18-Nov-08, The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a framework for passing configuration information to nodes on a network. This document describes a new option for DHCPv6 to convey information, required for network booting, to the nodes. "DHCPv4 Leasequery by relay agent remote ID", Pavan Kurapati, D.T.V. Ramakrishna Rao, Bharat Joshi, 20-Oct-08, Some Relay Agents extract lease information from the DHCP message exchanged between the client and DHCP server. This lease information is used by relay agents for various purposes like antispoofing, prevention of flooding. RFC 4388 defines a mechanism for relay agents to retrieve the lease information from the DHCP server as and when this information is lost. Existing leasequery mechanism is data driven which means that a relay agent can initiate the leasequery only when it starts receiving data from/to the clients. In certain scenarios, this model is not scalable. This document first looks at issues in existing mechanism and then proposes a new query type, query by remote ID, to address these issues. Diameter Maintenance and Extensions (dime) ------------------------------------------ "The Diameter API", Pat Calhoun, David Frascone, 28-Jul-08, The Diameter authentication, authorization, and accounting (AAA) protocol provides support for peering AAA transactions across the Internet. This document describes an API for the Diameter protocol. The API is defined for the C language. The intent of the API is to foster source code portability across multiple programming platforms. "Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction", Jouni Korhonen, Hannes Tschofenig, Julien Bournelle, Gerardo Giaretta, Madjid Nakhjiri, 27-Oct-08, Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the Home Agent and the Diameter server of the Mobile Service Provider (MSP). This document specifies the interaction between a Mobile IP Home Agent and that Diameter server. Several different mechanisms for authenticating a Mobile Node are supported. The usage of the Internet Key Exchange v2 (IKEv2) protocol allows different mechanisms, such as the Extensible Authentication Protocol (EAP), certificates and pre-shared secrets to be used. Furthermore, another method makes use of the Mobile IPv6 Authentication Protocol. In addition to authentication and authorization, the configuration of Mobile IPv6 specific parameters and accounting is specified in this document. "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction", Jouni Korhonen, Julien Bournelle, Hannes Tschofenig, Charles Perkins, Kuntal Chowdhury, 19-Nov-08, A Mobile IPv6 node requires a home agent address, a home address, and a security association with its home agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters are statically configured. Mobile IPv6 bootstrapping work aims to make this information dynamically available to the Mobile Node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document describes MIPv6 bootstrapping using the Diameter Network Access Server (NAS) to home Authentication, Authorization and Accounting server (HAAA) interface. "Diameter Base Protocol", Victor Fajardo, Jari Arkko, John Loughney, Glen Zorn, 24-Nov-08, The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations. "Diameter Quality of Service Application", Dong Sun, Peter McCann, Hannes Tschofenig, Tina Tsou, Avri Doria, Glen Zorn, 13-Jul-08, This document describes the framework, messages and procedures for the Diameter Quality of Service (QoS) application. The Diameter QoS application allows network elements to interact with Diameter servers when allocating QoS resources in the network. In particular, two modes of operation -- Pull and Push -- are defined. "Diameter Applications Design Guidelines", Victor Fajardo, Tolga Asveren, Hannes Tschofenig, Glenn McGregor, John Loughney, 24-Nov-08, The Diameter Base protocol provides updated rules on how to extend Diameter by modifying and/or deriving from existing applications or creating entirely new applications. This is a companion document to the Diameter Base protocol that further explains and clarifies these rules. It is meant as a guidelines document and therefore it does not add, remove or change existing rules. "Quality of Service Parameters for Usage with the AAA Framework", Jouni Korhonen, Hannes Tschofenig, 3-Nov-08, This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within RADIUS and Diameter. The payloads used to carry these QoS parameters are opaque for the AAA client and the AAA server itself and interpreted by the respective Resource Management Function. "Quality of Service Attributes for Diameter", Jouni Korhonen, Hannes Tschofenig, Mayutan Arumaithurai, Mark Jones, Avi Lior, 28-Oct-08, This document extends the IPFilterRule AVP functionality of the Diameter Base protocol and the functionality of the QoS-Filter-Rule AVP defined in RFC 4005. The ability to convey Quality of Service information using the AVPs defined in this document is available to existing and future Diameter applications where permitted by the command ABNF. Domain Keys Identified Mail (dkim) ---------------------------------- "DomainKeys Identified Mail (DKIM) Service Overview", Tony Hansen, Dave Crocker, Phillip Hallam-Baker, 11-Jul-08, This document provides an overview of the DomainKeys Identified Mail (DKIM) service and describes how it can fit into a messaging service. It also describes how DKIM relates to other IETF message signature technologies. It is intended for those who are adopting, developing, or deploying DKIM. DKIM allows an organization to take responsibility for transmitting a message, in a way that can be validated by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures, from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public- key cryptography, using the domain name service as its key server technology [RFC4871]. This permits verification of a responsible organization, as well as the integrity of the message contents. DKIM will also provide a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages. DKIM's authentication of email identity can assist in the global control of "spam" and "phishing. "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", agent Local-part, Author Domain, return error, Eric Allman, Jim Fenton, Mark Delany, John Levine, 22-Nov-08, 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 a domain signs its outgoing mail, and how other hosts can access that record. "DomainKeys Identified Mail (DKIM) Development, Deployment and Operations", Tony Hansen, Phillip Hallam-Baker, Dave Crocker, Ellen Siegel, 3-Nov-08, DomainKeys Identified Mail (DKIM) allows an organization to take responsibility for transmitting a message, in a way that can be validated by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures, from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public key cryptography, using the domain name service as its key server technology [RFC4871]. This permits verification of a responsible organization, as well as the integrity of the message contents. DKIM will also provide a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages. DKIM's authentication of email identity can assist in the global control of "spam" and "phishing. This document provides implementation, deployment, operational and migration considerations for DKIM. Detecting Network Attachment (dna) ---------------------------------- "Design document for Detecting Network Attachment in IPv6 Networks (DNAv6 Design)", Sathya Narayanan, James Kempf, Erik Nordmark, Brett Pentland, JinHyeock Choi, Greg Daley, Nicolas Montavont, 11-Jul-08, Efficient detection of network attachment in IPv6 needs the following three components: a method for hosts to detect link change in the presence of unmodified (non-DNAv6) routers, a method for the host to query routers on the link to identify the link (Link Identification) and a method for the routers on the link to consistently respond to such a query with minimal delay (Fast RA). Solving the link identification based strictly on RFC 2461 is difficult because of the flexibility offered to routers in terms of prefixes advertised in a router advertisement (RA) message. Similarly, the random delay in responding to router solicitation messages imposed by RFC 2461 makes it difficult to receive an RA quickly. In this memo, a mechanism that was developed for detection of network attachement is documented for future reference. This memo is an informational document and thus does not define a new standard. The mechanism proposed in this informational RFC requires the hosts to monitor all the prefixes advertised on the link and use it for link identification in the presence of non-DNAv6 routers is presented. A more efficient link- identification mechanism requiring the DNAv6 routers to monitor the link for advertised prefixes to assist the hosts in link identification combined with a fast router advertisement mechanism that selects the order of response for the router deterministically is also presented. "Tentative Options for Link-Layer Addresses in IPv6 Neighbour Discovery", Greg Daley, Erik Nordmark, 13-Jul-08, The proposed IPv6 Duplicate Address Detection (DAD) Optimization "Optimistic DAD" defines a set of recoverable procedures which allow a node to make use of an address before DAD completes. Essentially, Optimistic DAD forbids usage of certain Neighbour Discovery options which could pollute active neighbour cache entries, while an address is tentative. This document defines a new option and procedures to replace cache polluting options, in a way which is useful to tentative nodes. These procedures are designed to be to backward compatible with existing devices which support IPv6 Neighbour Discovery. "Simple procedures for Detecting Network Attachment in IPv6", Suresh Krishnan, Greg Daley, 3-Nov-08, 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. DNS Extensions (dnsext) ----------------------- "DNS Zone Transfer Protocol (AXFR)", Edward Lewis, 14-Jul-08, The Domain Name System standard mechanisms for maintaining coherent servers for a zone consist of three elements. One mechanism is the Authoritative Transfer (AXFR) is defined in RFC 1034 and RFC 1035. The definition of AXFR, has proven insufficient in detail, forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of the AXFR, new in the sense that is it recording an accurate definition of an interoperable AXFR mechanism. "Evaluating DNSSEC Transition Mechanisms", Roy Arends, Peter Koch, Jakob Schlyter, 14-Jul-08, This document collects and summarizes different proposals for alternative and additional strategies for authenticated denial in DNS responses, evaluates these proposals and gives a recommendation for a way forward. It is a snapshot of the DNSEXT working group discussion of June 2004. "Clarifications and Implementation Notes for DNSSECbis", Samuel Weiler, David Blacka, 14-Jul-08, This document is a collection of minor technical clarifications to the DNSSECbis document set. It is meant to serve as a resource to implementors as well as an interim repository of DNSSECbis errata. "Domain Name System (DNS) IANA Considerations", Donald Eastlake 3rd, 14-Jul-08, Internet Assigned Number Authority (IANA) parameter assignment considerations are specified for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes "Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", Jelte Jansen, 23-Oct-08, This document describes how to produce RSA/SHA-256 and RSA/SHA-512 DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). "Update to DNAME Redirection in the DNS", Scott Rose, Wouter Wijngaards, 16-Jul-08, The DNAME record provides redirection for a sub-tree of the domain name tree in the DNS system. That is, all names that end with a particular suffix are redirected to another part of the DNS. This is a revision of the original specification in RFC 2672, also aligning RFC 3363 and RFC 4294 with this revision. "Measures for making DNS more resilient against forged answers", Bert Hubert, Remco Mook, 17-Nov-08, The current Internet climate poses serious threats to the Domain Name System. In the interim period before the DNS protocol can be secured more fully, measures can already be taken to harden the DNS to make 'spoofing' a recursing nameserver many orders of magnitude harder. Even a cryptographically secured DNS benefits from having the ability to discard bogus responses quickly, as this potentially saves large amounts of computation. By describing certain behaviour that has previously not been standardised, this document sets out how to make the DNS more resilient against accepting incorrect responses. This document updates RFC 2181. "Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records", Francis Dupont, 19-Nov-08, The main goal of this document is to deprecate the use of HMAC-MD5 as an algorithm for the TSIG (secret key transaction authentication) resource record in the DNS (domain name system). "DNS Proxy Implementation Guidelines", Ray Bellis, 27-Nov-08, This document provides guidelines for the implementation of DNS proxies, as found in broadband routers and other similar network devices. Domain Name System Operations (dnsop) ------------------------------------- "DNS Referral Response Size Issues", Paul Vixie, Akira Kato, 14-Jul-08, With a mandated default minimum maximum UDP message size of 512 octets, the DNS protocol presents some special problems for zones wishing to expose a moderate or high number of authority servers (NS RRs). This document explains the operational issues caused by, or related to this response size limit, and suggests ways to optimize the use of this limited space. Guidance is offered to DNS server implementors and to DNS zone operators. "Locally-served DNS Zones", Mark Andrews, 10-Jul-08, Experience has shown that there are a number of DNS zones all iterative resolvers and recursive nameservers should, unless configured otherwise, automatically serve. RFC 4193 specifies that this should occur for D.F.IP6.ARPA. This document extends the practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space and other well known zones with similar characteristics. "Initializing a DNS Resolver with Priming Queries", Peter Koch, Matt Larson, 14-Jul-08, This document describes the initial queries a DNS resolver is supposed to emit to initialize its cache with a current NS RRSet for the root zone as well as the necessary address information. "DNSSEC Trust Anchor Configuration and Maintenance", Matt Larson, Olafur Gudmundsson, 14-Jul-08, This document recommends a preferred format for specifying trust anchors in DNSSEC validating security-aware resolvers and describes how such a resolver should initialize trust anchors for use. This document also describes different mechanisms for keeping trust anchors up to date over time. "Requirements for Management of Name Servers for the DNS", Wesley Hardaker, 3-Sep-08, Management of name servers for the Domain Name Service (DNS) has traditionally been done using vendor-specific monitoring, configuration and control methods. Although some service monitoring platforms can test the functionality of the DNS itself there is not a interoperable way to manage (monitor, control and configure) the internal aspects of a name server itself. This document discusses the requirements of a management system for DNS name servers. A management solution that is designed to manage the DNS can use this document as a shopping list of needed features. Data for Reachability of Inter/tra-NetworK SIP (drinks) ------------------------------------------------------- "Consolidated Provisioning Problem Statement", David Schwartz, Rohan Mahy, Alan Duric, Edward Lewis, 7-Jul-08, This document describes the type of data provisioned among Voice Service Providers and underscores the need for clearly defined structures and interfaces to facilitate this provisioning. This work is in support of the service provider peering as defined by the SPEERMINT WG. Email Address Internationalization (eai) ---------------------------------------- "Downgrading mechanism for Email Address Internationalization", Kazunori Fujiwara, Yoshiro Yoneya, 16-Sep-08, Traditional mail systems handle only ASCII characters in SMTP envelope and mail header fields. The Email Address Internationalization (UTF8SMTP) extension allows UTF-8 characters in SMTP envelope and mail header fields. To avoid rejecting internationalized Email messages when a server in the delivery path does not support the UTF8SMTP extension, some sort of converting mechanism is required. This document describes a downgrading mechanism for Email Address Internationalization. Note that this is a way to downgrade, not tunnel. There is no associated up-conversion mechanism, although internationalized email clients might use original internationalized addresses or other data when displaying or replying to downgraded messages. "IMAP Support for UTF-8", Pete Resnick, Chris Newman, 3-Nov-08, This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support unencoded international characters in user names, mail addresses and message headers. This is an early draft and intended as a framework for discussion. Please do not deploy implementations of this draft. "Mailing Lists and Internationalized Email Addresses", Randall Gellens, 20-Nov-08, This document describes considerations for mailing lists with the introduction of internationalized email addresses. This document makes some specific recommendations on how mailing lists should act in various situations. "POP3 Support for UTF-8", Chris Newman, Randall Gellens, 20-Nov-08, This specification extends the Post Office Protocol version 3 (POP3) to support un-encoded international characters in user names, passwords, mail addresses, message headers, and protocol-level textual error strings. "Displaying Downgraded Messages for Email Address Internationalization", Kazunori Fujiwara, 16-Oct-08, This document describes how to display downgraded messages which originally contain internationalized E-mail addresses or internationalized header fields. Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- "Location-to-URL Mapping Architecture and Framework", Henning Schulzrinne, 29-Sep-07, This document describes an architecture for a global, scalable, resilient and administratively distributed system for mapping geographic location information to URLs, using the Location-to- Service (LoST) protocol. The architecture generalizes well-known approaches found in hierarchical lookup systems such as DNS. "Best Current Practice for Communications Services in support of Emergency Calling", Brian Rosen, James Polk, 3-Nov-08, The IETF and other standards organization have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks and services should use such standards to make emergency calls. "Framework for Emergency Calling using Internet Multimedia", Brian Rosen, Henning Schulzrinne, James Polk, Andrew Newton, 10-Jul-08, The IETF has several efforts targeted at standardizing various aspects of placing emergency calls. This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities. "Location Hiding: Problem Statement and Requirements", Henning Schulzrinne, Laura Liess, Hannes Tschofenig, Barbara Stark, Andres Kuett, 12-Oct-08, The emergency services architecture developed in the IETF Emergency Context Resolution with Internet Technology (ECRIT) working group describes an architecture where location information is provided by access networks to end points or VoIP service providers in order to determine the correct dial string and information to route the call to a Public Safety Answering Point (PSAP). For determining the PSAP Uniform Resource Identifier (URI) the usage of the Location-to- Service Translation (LoST) Protocol is envisioned. This document explores the architectural impact for the IETF emergency services architecture for situations where the Internet Access Provider (IAP) and/or the Internet Service Provider (ISP) are only willing to disclose limited or no location information. This document provides a problem statement and lists requirements. "Specifying Holes in LoST Service Boundaries", James Winterbottom, Martin Thomson, 12-Oct-08, This document describes how holes can be specified in geodetic service boundaries. One means of implementing a search solution in a service database, such as one might provide with a LoST server, is described. "Synchronizing Location-to-Service Translation (LoST) Servers", Henning Schulzrinne, Hannes Tschofenig, 3-Nov-08, The LoST (Location-to-Service Translation) protocol is used to map locations to service URLs. This document defines a set of LoST extensions that allow LoST servers to synchronize their lists of mappings. "IANA Registering a SIP Resource Priority Header Namespace for Local Emergency Communications", James Polk, 27-Oct-08, This document creates and IANA registers the new Session Initiation Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for local emergency usage to a public safety answering point (PSAP), between PSAPs, and between a PSAP and first responders and their organizations. EAP Method Update (emu) ----------------------- "EAP Generalized Pre-Shared Key (EAP-GPSK) Method", Charles Clancy, Hannes Tschofenig, 19-Nov-08, This Internet Draft defines an Extensible Authentication Protocol (EAP) method called EAP Generalized Pre-Shared Key (EAP-GPSK). This method is a lightweight shared-key authentication protocol supporting mutual authentication and key derivation. "Requirements for an Tunnel Based EAP Method", Katrin Hoeper, Stephen Hanna, Hao Zhou, Joseph Salowey, 31-Oct-08, This memo defines the requirements for a tunnel-based Extensible Authentication Protocol (EAP) Method. This method will use Transport Layer Security (TLS) to establish a secure tunnel. The tunnel will provide support for password authentication, EAP authentication and the transport of additional data for other purposes. Telephone Number Mapping (enum) ------------------------------- "ENUM Implementation Issues and Experiences", Lawrence Conroy, Kazunori Fujiwara, 20-Nov-08, This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it clarifies the ENUM and Dynamic Delegation Discovery System standards. Its aim is to help others by reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. It does not revise the standards, but it is intended to provide technical input to future revisions of those documents. "IANA Registration for IAX Enumservice", Ed Guy, 17-Jun-08, This document registers the IAX Enumservice using the URI scheme 'iax:' as per the IANA registration process defined in the ENUM specification RFC3761. "IANA Registration of Enumservices: Guide, Template and IANA Considerations", Hoeneisen Bernie, Alexander Mayrhofer, Jason Livingood, 21-Nov-08, This document specifies a revision of the IANA Registration Guidelines for Enumservices, describes corresponding registration procedures, and provides a guideline for creating Enumservice Specifications. "A Telephone Number Mapping (ENUM) Service Registration for Internet Calendaring Services", Rohan Mahy, 10-Mar-08, This document registers a Telephone Number Mapping (ENUM) service for Internet Calendaring Services. Specifically, this document focuses on provisioning 'mailto:' (iMIP) and 'http:' (CalDAV) URIs in ENUM. "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM", Jason Livingood, 3-Dec-07, This document defines the use case for Infrastructure ENUM and proposes its implementation as a parallel namespace to "e164.arpa" as defined in RFC3761, as the long-term solution to the problem of allowing carriers to provision DNS records for telephone numbers independently of those provisioned by end users (number assignees). "IANA Registration for an Enumservice Calling Name Delivery (CNAM) Information and IANA Registration for URI type 'pstndata'", Richard Shockey, 29-Sep-08, This document registers the Enumservice 'pstndata' and subtype 'cnam' using the URI scheme 'pstndata:' as per the IANA registration process defined in the ENUM specification, RFC 3761 and registers a new URI type 'pstndata:'. This data is used to facilitate the transfer of Calling Name Delivery (CNAM) data for calls that originate on the Public Switched Telephone Network (PSTN) that may be displayed on VoIP or other Real-time Client User Agents (CUA). The pstndata URI is created to facilitate this transfer, however this URI may be used to transport other PSTN data in the future. "Combined User and Infrastructure ENUM in the e164.arpa tree", Michael Haberler, Otmar Lendl, Richard Stastny, 22-Oct-07, This memo defines an interim solution for Infrastructure ENUM to allow a combined User and Infrastructure ENUM implementation in e164.arpa as a national choice. This interim solution will be deprecated after approval and implementation of the long-term solution. "ENUM Requirement for EDNS0 Support", Jim Reid, Lawrence Conroy, 6-Sep-06, Support for EDNS0 (Extension Mechanisms for DNS) is mandated in this document for DNS entities querying for or serving NAPTR records. In general those entities will be supporting ENUM resolution. This requirement is needed because DNS responses to ENUM-related queries generally return large RRSets. Without EDNS0 support these lookups would result in truncated responses and repeated queries over TCP transport. That has a severe impact on DNS server load and on the latency of those queries. This document adds an operational requirement to use of the protocol standardised in RFC 3761. "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", Scott Bradner, Lawrence Conroy, Kazunori Fujiwara, 31-Mar-08, This document discusses the use of the Domain Name System (DNS) for the storage of E.164 numbers, and for resolving them into URIs that can be used for (for example) telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document obsoletes RFC 3761. "IANA Registration for Enumservice UNUSED", Richard Stastny, Lawrence Conroy, Jim Reid, 29-Mar-08, This document registers the Enumservice "unused" using the URI scheme "http:" as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice may be used to indicate that the E.164 number (or E.164 number range) tied to the domain in which the enclosing NAPTR is published is not allocated or assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early". "IANA Registration for an Enumservice Trunkgroup", Richard Shockey, Tom Creighton, 7-Jul-08, This document registers the Enumservice 'trunk' and subtypes 'sip' and 'tel' using the URI schemes 'sip:' and 'tel:' as per the IANA registration process defined in the ENUM specification RFC 3761 [RFC7761]. RFC 4904 [RFC4904] defines a technique for the conveyance of carrying trunking information in SIP [RFC3261] and or TEL [RFC3966] URI's. This Enumservice provides a mechanism for ENUM databases residing in service provider networks a mechanism to query for that data. FEC Framework (fecframe) ------------------------ "Forward Error Correction (FEC) Framework", Mark Watson, 24-Oct-08, This document describes for a framework for using forward error correction (FEC) codes with applications in public and private IP networks to provide protection against packet loss. The framework supports applying Forward Error Correction to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. This framework can be used to define Content Delivery Protocols that provide Forward Error Correction for streaming media delivery or other packet flows. Content Delivery Protocols defined using this framework can support any FEC Scheme (and associated FEC codes) which is compliant with various requirements defined in this document. Thus, Content Delivery Protocols can be defined which are not specific to a particular FEC Scheme and FEC Schemes can be defined which are not specific to a particular Content Delivery Protocol. "SDP Elements for FEC Framework", Ali Begen, 3-Nov-08, This document specifies the use of Session Description Protocol (SDP) to describe the parameters required to signal the Forward Error Correction (FEC) Framework Configuration Information between the sender(s) and receiver(s). This document also provides examples that show the semantics for grouping multiple source and repair flows together for the applications that simultaneously use multiple instances of the FEC Framework. "Methods to convey FEC Framework Configuration Information", Rajiv Asati, 3-Nov-08, FEC Framework document [FECARCH] defines the FEC Framework Configuration Information necessary for the FEC framework operation. This document describes how to use existing signaling protocols to determine and dynamically communicate the Configuration information between sender(s) and receiver(s). Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. "RTP Payload Format for 1-D Interleaved Parity FEC", Ali Begen, 27-Oct-08, This document defines a new RTP payload format for the Forward Error Correction (FEC) that is generated by the 1-D interleaved parity code from a source media encapsulated in RTP. The 1-D interleaved parity code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The 1-D interleaved parity code offers a good protection against bursty packet losses at a cost of decent complexity. The new payload format defined in this document is used as a part of the DVB Application- layer FEC Specification. "DVB Application-Layer Hybrid FEC Protection", Ali Begen, Thomas Stockhammer, 29-Aug-08, This document describes the Application-layer Forward Error Correction (FEC) protocol that was developed by the Digital Video Broadcasting (DVB) consortium for the protection of media streams over IP networks. The DVB 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 AL-FEC offers a good protection against both bursty and random packet losses at a cost of decent complexity. The 1-D interleaved parity code and Raptor code have already been specified in separate documents and the current document normatively references these specifications. "Raptor FEC Schemes for FECFRAME", Mark Watson, 24-Oct-08, This document describes Fully-Specified