This document describes various models for endpoint control of media policy for centralized conferencing services. The models include detailed mixer control, as in H.248, individual end-point negotiation, and participant roles, as in MSCML. This memo presents a proposal for an efficient and simple way of forming email addresses. The goal is to achieve easier, more productive communication between email users, in particular by aking addresses intuitive and thus easy to remember, or guess-enabled on material-world data about the correspondent, as well as independent from technical or organizational specifics of email services. IPv6 rapid deployment (6rd) builds upon mechanisms of 6to4 (RFC3056) to enable a service provider to rapidly deploy IPv6 unicast service to its existing IPv4 sites. Like 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to transit IPv4-only network infrastructure. Unlike 6to4, 6rd requires a service provider to use one of its own IP prefixes rather than the fixed 6to4 prefix. A service provider has used this mechanism for its own "rapid deployment" of IPv6 (five weeks from first exposure to "opt-in" deployment for 1,500,000 residential sites). This document describes a SIP-based method for network initiated partial session transfers that works together with terminal initiated partial session transfers. It uses the Mobile Node Control Mode for terminal initiated partial session transfers and it extends this method to support network initiated partial session transfers. The IETF is specifying a protocol for network-based localized mobility management, which takes basic operation for registration, tunnel management and de-registration into account. This document specifies a protocol for route optimization in networks, which support network-based mobility management. The specified protocol focuses on efficient set up and maintenance of a route optimized path between two mobile nodes and suits complex mobility scenarios as well as networks with multiple mobility anchors. This document describes the Namespace Identifier (NID) for Uniform Resource Namespace (URN) resources published by the Near-Field Communication Forum (NFC Forum). The NFC Forum defines and manages resources that utilize this URN identification model. Management activities for these and other resource types are provided by the NFC Forum Technical Committee. The virtual broadband access server (VBAS) protocol looks BAS and IP-DSLAM as a whole and provides an applicable method for communicating between BAS and IP-DSLAM. This document describes a communication process, which is added in the existing access control modes. It also describes how to encapsulate VBAS packets over Ethernet. The unused fields in TCP/IP can be used to establish malicious communication channel[1][2][3]. This draft presents the fieldsin TCP/IP and ICMP messages and the values which must be enforced before the packets are streamed to the network so as to prevent the malicious communication channel. EAP is used to establish secure communication channel in IKEv2 and in Wireless Security. EAP-TLS, EAP-TTLS, EAP-MD5, EAP-SIM uses radius protocol for communication bewteen radius server and the client. These protocols are used in both Wireless network authentication and in IKEV2 authentication to establish VPN tunnel. +----------+ +----------+ +----------+ | | EAPOL | EAP | RADIUS | | | EAP |<------>| Server |<------>| RADIUS | | Client | EAPOW | | (EAP) | Server | | | | | | | +----------+ +----------+ +----------+ This draft presents the security protocol which can be used to establish the secure communication channel between the radius server and pass through server. Pass through server is access point in the case of wireless communication and it is gateway in case of IKEV2 authnetication. In a public WLAN hotspot, we need to have an easy and secure way to authenticate users. We have to find also mobility solutions, given by providers, to perform well the roaming. A roaming mobile terminal MT may be within radio range of more than one access point AP. Therefore, we need to make an intelligent network selection decision after receiving some roaming information. Currently, the information is typically provisioned on the MTs as static roaming tables. But, this approach is not scalable when there is a large number of access points. In this draft, we propose our solution called OSFR, Optimized Network Selection for Fast Roaming to improve association speed and scalability. This draft introduces the Certified PN Formation Protocol (CPFP) based on the personal public key infrastructure (personal PKI) concept. CPFP employs Elliptic Curve Cryptography (ECC) techniques by using ECDH, ECDSA and STS protocols and provides feasible solutions for key revocation and transitive imprinting. Since the mid 1990s, IEEE 802 and IETF have cooperated in the development of SNMP MIBs and AAA applications. This document describes the history of that cooperation, and the policies and procedures that have developed in order to coordinate between the two organizations. This document describes principles of Internet host configuration. It covers issues relating to configuration of Internet layer parameters, as well as parameters affecting higher layer protocols. This document describes common issues seen in RADIUS implementations and suggests some fixes. Where applicable, ambiguities and errors in previous RADIUS specifications are clarified. RFC 3580 provides guidelines for the use of the Remote Authentication Dialin User Service (RADIUS) within IEEE 802 local area networks (LANs). This document proposes additional attributes for use within IEEE 802 networks. The attributes defined in this document are usable both within RADIUS and Diameter. This document describes an RFC 3933 experiment in the Working Group formation process, known as the Exploratory Group. Exploratory Groups may be created as the first step toward Working Group formation, or as an intermediate step between a Birds of a Feather (BOF) session and Working Group creation. Exploratory Groups are focused on completion of prerequisites for Working Group formation, and as a result they have a short life-time, with limited opportunities for milestone extension. This document defines a resource reservation protocol Hierarchical Proxy Mobile Resource Reservation Protocol (HPMRSVP). This protocol is based on the hierarchical architecture HMIPv6 and used a modified version of FHMIPv6 to handle the handover. During a session, the resource reservation between two mobile nodes is limited to the access network. Furthermore, when a handover occurs, resources are uniquely reserved to the target access point before the handover is completed. The proposed protocol allows to reduce delays and packet loss. In addition, management of refresh messages is moved to the access router, which holds the refresh reservation state for the duration of the session on behalf of the mobile unit. The access network thereby becomes responsible for upholding the session, which optimizes the utilization of the radio link. Session Initiation Protocol (SIP) is passed on point-to-point protocol. This document describes a Multipoint Session Initiation Protocol. This protocol is an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. The protocol is based on distributed network entities architecture, and the use of the server is mandatory. The Link Management Protocol (LMP) has been developed as part of the Generalized MPLS (GMPLS) protocol suite to manage Traffic Engineering (TE) links. The GMPLS control plane (routing and signaling) uses TE links for establishing Label Switched Paths (LSPs). This memo describes the relationship of the LMP procedures to 'discovery' as defined in the International Telecommunication Union (ITU), and on-going ITU-T work. This document provides an overview of LMP in the context of the ITU-T Automatically Switched Optical Networks (ASON) and transport network terminology and relates it to the ITU-T discovery work to promote a common understanding for progressing the work of IETF and ITU-T. This document describes a two rate three color marker that has been in use for data services including Frame Relay services. This marker can be used for metering per-flow traffic in the emerging IP and L2 VPN services. The marker defined here is different from previously defined markers in the handling of the in-profile traffic. Furthermore this marker doesn’t impose peak rate shaping requirements on customer edge (CE) devices. This document describes an extension to Mobile IPv4 Registration Revocation (as described in RFC 3543) for a home or foreign agent to revoke mobile IP services for multiple bindings or visitors with a single registration revocation exchange. OSPFv3 includes a mechanism for supporting multiple instances on the same link. OSPFv2 could benefit from such a mechanism in order to support multiple routing domains on the same subnet. The OSPFv2 instance ID is reserved for support of separate OSPFv2 protocol instances. This is different from OSPFv3 where it could be used for other purposes such as putting the same link in multiple areas. OSPFv2 supports this capability using a separate subnet or the OSPF multi-area adjacency capability. OSPFv2 and OSPFv3 include a reliable flooding mechanism to disseminate routing topology and Traffic Engineering (TE) information within a routing domain. Given the effectiveness of these mechanisms, it is convenient to envision using the same mechanism for dissemination of other types of information within the domain. However, burdening OSPF with this additional information will impact intra-domain routing convergence and possibly jeopardize the stability of the OSPF routing domain. This document presents mechanism to relegate this ancillary information to a separate OSPF instance and minimize the impact. This document defines a DHCP option that contains Radio specific Parameters for Mobile Access Points, Like Transmit Power, Country code, reserved RF channels. The PKIX (Public-Key Infrastructure (X.509)) Working Group of the IETF (The Internet Engineering Task Force) has defined a number of certificate management protocols. These protocols are primarily focused on X.509v3 public-key certificates. However, it is sometimes desirable to manage certificates in alternative formats as well. This document specifies how such certificates may be requested using the CRMF (Certificate Request Message Format) syntax that is used by several different protocols. It also explains how alternative certificate formats may be incorporated into such popular protocols as PKIX-CMP (PKIX Certificate Management Protocol) and CMC (Certificate Management Messages over CMS). This document describes the work in progress on Flow State Aware standards activity in the ITU and proposes a new type of control packet to be identified that can alert downstream or upstream nodes on data related to an individual flow. This memorandum describes a method whereby one can use GSS-API [RFC2078] to supply a secure channel between a user on a client and a server, authenticating both the user and server with public key certificates [RFC3280], without the need for an external Public Key Infrastructure for certificate verification. The method leverages the existing Simple Public Key Mechanism Version 3 (SPKM-3) [RFC2847]. In addition to describing the use of SPKM-3 for mutual authentication, this memorandum updates RFC2847, reflecting implementation experience. This memorandum describes a method whereby one can use GSS-API [RFC2078] to supply a public-key based secure channel between a client and a server without the need for an external Public Key Infrastructure for certificate verification. The method leverages the existing Simple Public Key Mechanism (SPKM), and is specified as two separate GSS-API mechanisms, SPKM-3 and LIPKEY, with LIPKEY layered above SPKM-3. SPKM-3 describes a method for creation of the secure channel using mutual authentication where both a user and server authenticate with public-key certificates [RFC3280]. SPKM-3 also describes a method for creation of the secure channel where only the server authenticates with a public-key certificate, and the user is anonymous. LIPKEY then uses the SPKM-3 anonymous secure channel to authenticate a user with a password, completing the mutual authentication. This document describes some security risks of the Reliable Multicast Transport (RMT) Working Group set of building blocks and protocols. An emphasis is placed on risks that might be resolved in the scope of transport protocol design. However, relevant security issues related to IP Multicast control-plane and other concerns not strictly within the scope of reliable transport protocol design are also discussed. The document also begins an exploration of approaches that could be embraced to mitigate these risks. The purpose of this document is to provide a consolidated security discussion and provide a basis for further discussion and potential resolution of any significant security issues that may exist in the current set of RMT standards. In this paper we propose a new hierarchical method to enhance the current routing and forwarding paradigm for the Internet called Tunneled Inter-Domain Routing (TIDR). We will present the way in which TIDR permits to establish tunnels to the edge of the network, and how they will be used to forward traffic to stub networks. These tunnels will be explicitly signaled by using a new transitive BGP attribute called LOCATOR. This new routing and forwarding paradigm provides, among others, the following benefits: global routing table reduction, inter-domain routing infrastructure protection, improved multi-homing of edge networks, numerous forwarding decisions for a particular address prefix, it stops the AS number consumption, and it can be smoothly deployed. Several wireless ad-hoc routing protocols have been and are being developped for MANET. However, autoconfiguration of MANET networks is still an unsettled area, and several methods have been proposed to perform such a task. One of the mecanisms that may be required for address autoconfiguration, is the detection of address conflicts. This is specially true for one of scenarios for MANET autoconf, the This document specifies a general protocol for the detecting address conflicts in a MANET network, and hence addresses a subset of the requirements of a full MANET address autoconfiguration solution. It is specified as an independent protocol from the MANET routing protocol, and the address configuration method, and may be used with any of them. It aims at conceptual simplicity: essentially, a tree of the nodes is built, from which all the information from all the existing nodes is known. Conflicts are detected by the node at root of the tree, or as inconsistent information on the root of the tree. This document describes a Uniform Resource Name (URN) namespace for the Digital Video Broadcasting Project (DVB) for naming persistent resources defined within DVB standards. Example resources include technical documents and specifications, eXtensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by DVB. This document proposes a solution for Service Network discovery and selection that could be implemented within the existing EAP specification framework. The purpose of Service Network discovery and selection here is to help a WLAN client using EAP for authentication to decide whether or not to connect to a WLAN Access Network, and help it select the most appropriate Mediating Network as a next hop for routing AAA packets in roaming situations where the WLAN Access Network has agreements with more than one Mediating Network affiliated with the client’s Home Service Network. The proposed solution has 3 components: a delivery mechanism for conveying Access Network and Service Network Information to a WLAN client, a data model/syntax for structuring the information in a generic manner, and a method by which the WLAN client can indicate its selection to the WLAN Access Network. The Extensible Authentication Protocol (EAP) is defined in [RFC3748]. This document defines a mechanism that allows an access network to provide identity selection hints to an EAP peer - the end of the link that responds to the authenticator. The purpose is to assist the EAP peer in selecting an appropriate Network Access Identifier (NAI). This is useful in situations where the peer does not receive a lower layer indication of what network it is connecting to, or when there is no direct roaming relationship between the access network and the peer's home network. In the latter case, authentication is typically accomplished via a mediating network such as a roaming consortium or broker. The mechanism defined in this document is limited in its scalability. It is intended for access networks that have a small to moderate number of direct roaming partners. This document describes additional Remote Authentication Dial In User Service (RADIUS) [1] attributes for use of RADIUS AAA (Authentication, Authorization, Accounting) in both Wireless and wired networks. It contains an IPv4 address type control mechanism, mobile IPv4 home agent discovery mechanism, and a RADIUS capabilities discovery mechanism. This document describes bandwidth profile parameters and a protocol framework that enables an AAA server to specify the parameters that should be allocated by the access network for duration of an authorized user session. This document describes a new RADIUS attribute used by a home RADIUS to indicate Chargeable User Identity to all parties involved in the roaming transaction outside the home network. This document describes RADIUS Authentication, Authorization, Accounting (AAA) attributes that are used to convey the Access Network?s operational ownership and Location Information to a Home Service Network. This document describes RADIUS Authentication, Authorization, Accounting (AAA) attributes that are used to convey the Access Network’s operational ownership and Location Information to a Home Service Network. The NetConf protocol needs a way to represent the managed data on a device. This document provides a data model representation along with concrete realizations of system and interface managed objects. This memo defines XML Schema for reporting information about the NetConf system. This document provides motivation for enhancing the NFSv4 protocol to enable checksumming of data and describes extensions to NFSv4 in order to enable such a capability. Discussion and suggestions for improvements are requested. This document advocates the usage of small, mostly constant payloads in the SYN+ACK frame of the 3-way TCP [RFC0793] handshake. We show how this can have immediate benefits for some protocols. Additionally, we describe a new TCP option that enables a wider range of protocols to gain from it. This document describes the requirements for the logical entity known as the Session Initiation Protocol (SIP)-H.323 Interworking Function (SIP-H.323 IWF) that will allow the interworking between SIP and H.323. The objective of this document is to begin a discussion that will determine the level of interest at the IETF in documenting how multiple recovery techniques can successfully be combined to protect a set of network resources and the various interactions between these recovery techniques. Potential outcome of this work could be to define new MIBs and/or OAM techniques devoted to such interactions. This document is an addendum to RFC xxxx, which specifies the real-time transport protocol for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. This document contains the information related to the new operating mode of VMR-WB. All provisions, restrictions, use cases, features, etc. that are specified in RFC xxxx are applicable to the new operating mode without any exception. No new media type registration is included in this document as the new VMR-WB mode, defined in this document, will use the same media type specified in RFC xxxx (i.e., audio/VMR-WB). Note that the RFC xxxx was developed with sufficient flexibility for future extensions and thereby it allows the addition of new operating modes without any impacts on the interoperability of terminals supporting different versions of the VMR-WB standard. This document specifies a real-time transport protocol (RTP) payload format to be used for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. The payload format is designed to be able to interoperate with existing VMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of VMR-WB speech data in storage mode applications such as email. A MIME type registration is included, for VMR-WB, specifying use of both the RTP payload and the storage formats that has a number of operating modes, one of which is interoperable with AMR-WB (i.e., RFC 3267) audio codec at certain rates. Therefore, provisions have been made in this draft to facilitate and simplify data packet exchange between VMR-WB and AMR-WB in the interoperable mode with no transcoding function involved. Stream Control Transmission Protocol (SCTP) RFC2960 [SXM00] specifications utilize the possible multiple paths between the sender and receiver for retransmission of lost data chunks and as a backup for the primary path, in case of primary path failure. Other than that, all the data chunks are being sent on the primary path chosen by the SCTP user during the association initiation. This memo describes an extension to SCTP that allows endpoints to use the multiple available paths for simultaneous data transmission. The extension maintains SCTP congestion control on each path, so as to ensure fair integration with other traffic in the network. In MANET, nodes wishing to communicate with nodes in the wired Internet, the global Internet connectivity is required and this functionality can be achieved with the help of the Internet gateway (IGW). For the support of reliability and flexibility, multiple IGWs can be provisioned for a MANET. In this case, load-balancing becomes one of the important issues since the network performance such as the network throughput can be improved if the load of the IGW is well-balanced. In this draft, we categorize the load-balancing mechanisms for the IPv6-based MANET with multiple IGWs and define a new load-balancing metric computed from the hop distance and the number of routing table entries. This document specifies a common interface for using HIP with a Distributed Hash Table service to provide a HIT-to-address lookup service and an unmanaged name-to-HIT lookup service. This draft proposes OAM procedures for the Ethernet interworking, IP interworking and FR-ATM interworking Virtual Private Wire Service (VPWS). This document specifies the IPFIX protocol that serves for transmitting IP traffic flow information over the network. In order Aitken, Claise Standard Track [page 1] New Information Elements for the IPFIX Information Model March 2008 to transmit IP traffic flow information from an exporting process to an information collecting process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX data and templates records are carried over a number of transport protocols from an IPFIX exporting process to an IPFIX collecting process. While using SIGComp [4] based compression in SIP/SDP [5] [6], it is imperative to have access to a static dictionary to be used on the first SIP message that the compressor sends out. The session set up time can be reduced significantly if the compression rate of the first SIP message is considerably high. The existing static dictionary for SIP and SDP [2], however, does not include some wireless specific data elements. This document introduces these new data elements that are specific to various wireless access technologies. These new data elements are part of the first SIP message (i.e., originating SIP Invite) used to initiate a session. Current SIP messages are text based and inherently large, especially when these messages are to be transmitted over the bandwidth-strained wireless access technologies (a typical orginiating SIP Invite is about 1200 bytes). For most wireless technologies, transmitting the session initiation messages (such as SIP Invite) over the signaling channel can reduce the call setup time substantially. The size limitation of these wireless signaling channels are typically very small (~210 bytes in the uplink and ~110 bytes in the downlink). To address this problem, a new function called Encoding Assitant (EA) has been introduced in the User Agent (UA) and in the SIP Proxy server within the network. Additionally, the method provided in this document defines new SIP option tags and headers. These new option tags and headers allow the UA and a SIP Proxy server within the network (such as the P-CSCF), to exchange information using the signaling channels supported by most wireless access networks. The purpose of this draft is to describe a methodology specific to the benchmarking of MPLS forwarding devices. The scope of this benchmarking will be 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. Providing a Standard method for Addition of regional Advertisements in the IP Multicast Video Streaming is very important , because the equipment deployed would most likely be from different vendors across a multicast network. The idea is to introduce a special kind of Enhanced IGMP Ad-Insert control packet, which is passed from the multicast source to intermediate routers and which indicates that the source is going to stop sending multicast traffic for a particular group for specified time and the Regional center can utilize this time to insert its regional advertisement. This document specifies enhancement to the Internet Group Management Protocol, IGMPv3. IGMP is the protocol used by IPv4 systems to report their IP Multicast group memberships to neighboring Multicast routers. This enhancement for IGMP adds support for "specifying day, time and duration with Multicast reports", that is, the ability for a system to report interest in receiving traffic for a particular Multicast address at a particular day, time and for a specific duration. This information may be used by intermediate routers and switches to ensure providing better Quality of Service. Also specifying such information in a consolidated packet may help reduce signaling load on the multicast routers. This document specifies a network-based protocol which allows mobile nodes to remain reachable while moving around a certain administrative network called Edge Mobility Domain. This protocol also allows mobile nodes to keep their IP address when the mobile nodes move from one access router to another within the Edge Mobility Domain. The Presence Information Data Format (PIDF) defines a basic XML format for presence information. The contact element in PIDF is understood as a URI. However, some existing Internet services do not identify users (presentities) natively with a URI. Mapping non-URIs to contact element in Presence Information Data Format (Map2PIDF) specifies the mapping of addresses to a URI in the case of such currently existing services. The Presence Information Data Format (PIDF) defines a basic XML format for presence information. The optional contact element in PIDF contains a URI that ultimately resolves to a network interface on some device. Currently, the ways of expressing features related to that interface are limited. PIDFConn defines an extension to PIDF for describing features of connectivities and the cost of using services. This document addresses the problem of providing a bi-directional multicast protocol in an Intranet environment. A protocol named Switched Bi-directional Multicast Protocol (XMP) is proposed. Participants(Sender, S, or Receivers, Rs)signal their will to join the group sending a START(G) packet toward a Focal Point Router(FP). To take control of transmission a receiver application receives permission from the master application (the master transmitter)and sends a START(G) packet re-labeling the involved routers interfaces from R to S. The master Sender resumes transmission by means of his application commanding the receiver's application to go back to the receiver mode and emitting a START(G)packet to FP. ns-2 has been used to simulate it. The Real Time Network Service (RTNS) is a process of data transfer (with real time characteristics) between two end systems. It is part of the OSI model of the Network layer, the Internet layer ot the DoD model respectively. It is not a separate protocol, but rather an additional service, of which applications, exchanging data in real time, can take advantage. In the current document this service is defined as an option of the Internet Protocol. The Real Time Network Service (RTNS) is a process of data transfer (with real time characteristics) between two end systems. It is part of the OSI model of the Network layer. It is not a separate protocol, but rather an additional service, of which applications, exchanging data in real time, can take advantage. In the current document this service is defined as an option of the Internet Protocol. This draft presents a framework document for modeling network elements (NE), facilities, lines, protocols and services for substantially easing development and operation of element manager systems (EMS), network management systems (NMS) and operations support systems (OSS). The framework is independent of the access method used, including SNMP, CLI, Netconf, Corba, CMIP, XML-RPC, etc.) It covers configuration, alarms, current-historical performance, accounting management and security. The frameworks builds on and reuses the existing base of MIBs. The documents presents a light-weight, structured and very simplified framework and method to data modeling for defining and maintaining meta models, device etc. models, and device etc. descriptors. This document provides a framework and methodology for performing performance test and benchmarking of wireless LAN (WLAN) switches and controllers, including systems comprising groups of controllers and WTPs. This document defines and discusses a number of tests and associated test conditions that may be used to characterize the performance of such systems, and also supplies the methods used to calculate the expected results of these tests. Specific formats for reporting the results of the tests are also provided, where applicable. The tests described in this document extend the methodology defined for benchmarking network interconnect devices in RFC 2544, and LAN switches in RFC 2889, to WLAN switch controller systems. The methodology herein is to be used together with the companion terminology document. This document provides a terminology to be used when performing performance test and benchmarking of wireless LAN (WLAN) switches and controllers, including systems comprising groups of controllers and Access Points. The various wireless-specific device nomenclature, as well as the definitions of configuration parameters and test conditions that may be used to characterize the performance of these devices, are provided. The document also defines some of the metrics used during WLAN switch benchmarking. This terminology is to be used in conjunction with the companion methodology document. This document defines the Congestion Status precondition for SIP, utilizing the framework defined in RFC 3312 and updated in RFC 4032. The Congestion Status precondition requires that the participant verify that congestion thresholds along the network path for the session media have not been exceeded before continuing with session establishment or modification. This verification is performed via an RTP probe utilizing draft "Congestion Notification Process for Real- Time Traffic" and draft "RTP Payload Format for ECN Probing". This document describes Admission Control as a use case for the mechanisms described in "Congestion Notification Process for Real-Time Traffic" [1] and the RTP payload format defined in "RTP Payload Format for ECN Probing" [2]. This document describes use cases for the mechanisms described in draft "Congestion Notification Process for Real-Time Traffic" and the RTP payload format defined in draft "RTP Payload Format for ECN Probing". Specifically, it describes admission control and preemption use cases. This memo defines a Real Time Transport Protocol (RTP) payload format for use when probing for congestion using Explicit Congestion Detection (ECN). This payload format is intended for use with the probing mechanisms described in draft "Real-time ECN Use Cases". While defined in terms of the specific application of admission control, it is desirable to overlay this format with other probing mechanisms so as to reduce the number of probing packet formats. This document provides a framework and methodology for performing stress testing and benchmarking of wireless LAN (WLAN) devices, including clients (i.e., host interfaces) and Access Points. The document defines and discusses a number of tests and associated test conditions that may be used to characterize the performance of such devices, and also supplies the methods used to calculate the results of these tests. This document also describes specific formats for reporting the results of the tests. It extends the methodology defined for benchmarking network interconnecting devices in RFC 2544 and LAN switches in RFC 2889 to IEEE 802.11 WLAN devices. This document describes a Diameter application that performs Authentication, Authorization, and Accounting for Quality of Service (QoS) reservations. This protocol is used by elements along the path of a given application flow to authenticate a reservation request, ensure that the reservation is authorized, and to account for resources consumed during the lifetime of the application flow. Clients that implement the Diameter QoS application contact an authorizing entity/application server that is located somewhere in the network, allowing for a wide variety of flexible deployment models. This document outlines some interoperability issues observed with the use of ARP over GMPLS controlled Ethernet router-to- router (PSC) interfaces transiting from a non-Ethernet core, e.g., FSC or LSC core. The document also recommends some procedures to address these issues. The aim of this document is to facilitate and ensure better interworking of GMPLS- capable Label Switching Routers (LSRs), based on experience gained in interoperability testing. One of the biggest challenges faced by GMPLS technology is “how it can be deployed” in a manner least impacting to existing IP/ MPLS networks. GMPLS architecture document lists [RFC3945] three different scenarios in which GMPLS technology can be deployed: overlay, augmented and integrated. Reference [GMPLS-mig] addresses the problem of migration from MPLS to GMPLS networks using the integrated model. This draft addresses the same problem space for augmented model and illustrates the applicability of augmented model in deploying GMPLS technology in existing IP/ MPLS networks. Z. Ali, et Al. Expires August 2008 [page 1] Internet-Draft draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07 [RFC4379] describes procedures for ping and tracerouting for LSPs with PSC (packet switch capable) transit switching capability. An important implication of using transparent (non-PSC) nodes in GMPLS network is that LSP Ping solution described in [RFC4379] are not applicable to LSP with non-PSC switching capability. Another important difference between PSC and non-PSC switching technologies is the data and control plan separation in the latter case. An implication of the separation of data and control planes in GMPLS networks is that LSP traceroute procedures described in [RFC4379] are not directly applicable to GMPLS networks with separation of data and control planes. The scope of this draft is cases where data plane does not provide the OAM functions addressed by this draft. This document is assumed that OAM mechanisms provided by the underlying data plan technology MUST be used, whenever possible. E.g., G.709 addresses the problem of trace routing in DWDM network. However, G.709 OAM mechanisms are only applicable to OEO (Optical-Electrical-Optical) capable node. This document fills in such gaps; in particular it addresses GMPLS OAM functionality in optical networks with wavelength routers, ROADMs nodes, etc. with no OEO conversion capability. For this purpose, the draft relies on control plan mechanism to provide required OAM functions. Specifically the proposed solutions are based on Link Management Protocol (LMP) [RFC4204] and RSVP-TE [RFC3209], [RFC3473] and do not require any extension to the data plan. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. GMPLS-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. GMPLS-TE graceful shutdown mechanisms are tailored towards addressing the planned outage in the network. This document provides requirements and protocol mechanisms so as to reduce/eliminate traffic disruption in the event of a planned shutdown of a network resource. These operations are equally applicable for both MPLS and its GMPLS extensions. Ability to administratively shutdown RSVP Hellos and Graceful Restart (GR) procedure without impacting the traffic is a desirable network operation. Furthermore, there are applications that run RSVP Hellos with intervals on the order of milliseconds. This poses a requirement to reduce the number of RSVP messages to a minimal required count. Fortunately RSVP Hellos are not mandatory and are only required to run when needed. This allows applications to remove an RSVP Hello session, when it is not needed. This ID proposes a procedure to remove RSVP Hello and/ or GR sessions for administrative or optimization purposes. Use of node-id based RSVP Hello messages is implied in a number of cases, e.g., when data and control plan are separated, when TE links are unnumbered. Furthermore, when link level failure detection is performed by some means other than RSVP Hellos, use of node-id based Hellos is optimal for detecting signaling adjacency failure for RSVP- TE. Nonetheless, this implied behavior is unclear and this document formalizes use of node-id based RSVP Hello sessions as a best current practice (BCP) in some scenarios. The problem of quality analysis and advanced fault detection of a pure light-path in a Dense Wavelength Division Multiplexing (DWDM) optical network requires the transmission of optical evidence related parameters along the provisioned route. In this draft we propose an RSVP-TE based mechanism to collect and evaluate optical evidence measured over optical nodes along the light-path. Point-to-MultiPoint (P2MP) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques described in [RFC4875]. However, [RFC4875] does not Expires August 2007 [page 1] draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-00.txt address many issues that comes when a P2MP-TE LSP is signaled in a multi-domain networks. Specifically, one of the issues in multi-domain networks is how to allow computation of a loosely routed P2MP-TE LSP such that it is remerge free. This document provides a framework and required protocol extensions needed for establishing and controlling P2MP MPLS and GMPLS TE LSPs in multi-domain networks. This document borrows inter-domain TE terminology from [RFC4726], e.g., for the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes). Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. There are many deployment scenarios which require Egress LSR to receive binding of the RSVP-TE LSP to an application, and payload identification, using some "out-of-band" (OOB) mechanism. This document proposes protocol mechanisms to address this requirement. The procedures described in this document are equally applicable for point-to-point (P2P) and point-to- multipoint (P2MP) LSPs. One of the management requirements for point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks is the ability to identify source-to-leaf (S2L) sub-lsp by name. This document provides a minor extension to RSVP-TE for P2MP TE LSPs [RSVP-TE- P2MP] to signal name for S2L sub-lsp. There are many deployment scenarios where an RSVP-TE LSP carries multiple payloads. In these cases, it gets ambiguous on what should value should be carried as L3PID in the Label Request Object [RFC3209] or G-PID in the Generalized Label Request Object Expires January 2009 [page 1] draft-ali-mpls-sig-pid-multiplexing-case-00.txt [RFC3471], [RFC3473]. The document propose use of some dedicated PID values to cover some typical cases of multiple payload carried by the LSP, including that indicates to the egress node to ignore signaling to learn payload carried by the LSP. This document describes how MAC filtering programmed by the IEEE multiple MAC registration protocol (MMRP or 802.1ak) can be employed by VPLS-PE devices as the exclusive mechanism for interworking with 802.1ah PBBNs. No new protocol standardization is required to do this, however there are small procedural changes associated with the interworking of protocols. RFC 3031 permits MPLS load balancing while making no specific representations as to implementation requirements. This has subsequently become an issue with respect to the reliability of path test mechanisms. Load balancing algorithms may separate path test probes from the path of interest. This document proposes guidelines for implementation of load balancing such that path test mechanisms are not impacted. This document is a framework for how data plane OAM functions can be applied to operations and maintenance procedures. The document is structured to outline how OAM functionality can be used to assist in fault management, configuration, accounting, performance management and security, commonly known by the acronym FCAPS. Provider Backbone Transport (PBT, known as well as PBB-TE and progressed in IEEE as 802.1Qay [802.1Qay]) provides a mechanism where native Ethernet point-to-point tunnels can be configured or signaled across a provider-based Ethernet network [FEDYK]. PWE3 architecture defines a mechanism, called pseudowires, that emulates the essential attributes of a layer-2 and layer-1 service over a Packet Switched Network (PSN). This draft describes the architecture and procedures where Pseudowires are carried across PBT tunnels. In this proposal PBT tunnels are used as the PSN. This document defines the architecture of Netnews systems and specifies the correct manipulation and interpretation of Netnews articles by software which originates, distributes, stores, and displays them. It also specifies the requirements that must be met by any protocol used to transport and serve Netnews articles. This document describes the registration of the Multipurpose Internet Mail Extensions (MIME) sub-types to be used by the international astronomical community for the interchange of FITS files. The encoding is defined by the published FITS standard documents. The FITS format has been in use since 1979, and almost all data from astronomical observations are interchanged using FITS. This document describes a private Session Initiation Protocol(SIP) header (P-header) used by the Open Mobile Alliance (OMA), for Push- to-talk over Cellular (PoC) along with its applicability, which is limited to the OMA PoC application. The P-Answer-State header is used for indicating the answering mode of the handset which is particular to the PoC application. This document describes a set of private Session Initiation Protocol(SIP) headers (P-headers) used by the Open Mobile Alliance (OMA),For Push to talk over Cellular (PoC) along with their applicability, which is limited to the OMA PoC application. The P-headers are used for requesting and indicating the alerting mode of the handset which is particular to the PoC application. DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transfer Agents (MTAs) or Mail User Agents (MUAs). The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus proving and protecting message sender identity and the integrity of the messages they convey while retaining the functionality of Internet email as it is known today. Proof and protection of email identity, including repudiation and non-repudiation, may assist in the global control of "spam" and "phishing". DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transport Agents (MTAs) or Mail User Agents (MUAs). The primary DKIM protocol is described in This document describes the records that senders may use to advertise how they sign their outgoing mail, and how verifiers should access and interpret those results. This document sketches a potential quality control mechanism for the IETF in the form of working group review committees. The idea is to form a small committee per working group that will provide document review and advice throughout the working group's lifetime. This document describes a method for usin