cellular

The Third Generation Partnership Project (3GPP) has identified cases where different SIP private header extensions referred to as "P-" header fields, and defined in RFC 7315, need to be included in SIP requests and responses where they were not allowed according to RFC 7315. This document updates RFC 7315, in order to allow inclusion of the affected "P-" header fields in such requests and responses. This document obsoletes RFC 7976. The changes related to RFC 7976 involve the inclusion of the P-Visited-Network-ID header field in SIP responses.

This document also makes updates to RFC 7315 in order to fix misalignments that occurred when RFC 3455 was obsoleted by RFC 7315.

Network slicing is a feature that was introduced by the 3rd Generation Partnership Project (3GPP) in Mobile Networks. Realization of 5G slicing implies requirements for all mobile domains, including the Radio Access Network (RAN), Core Network (CN), and Transport Network (TN).

This document describes a network slice realization model for IP/MPLS networks with a focus on the Transport Network fulfilling the service objectives for 5G slicing connectivity. The realization model reuses many building blocks commonly used in service provider networks at the current time.

The document specifies a common attachment circuits (ACs) YANG data

model, which is designed to be reusable by other models. This design

is meant to ensure consistent AC structures among models that

manipulate ACs. For example, this common model can be reused by

service models to expose ACs as a service, service models that

require binding a service to a set of ACs, network and device models

to provision ACs, etc.

Delivery of network services assumes that appropriate setup is

provisioned over the links that connect customer termination points

and a provider network. The required setup to allow successful data

exchange over these links is referred to as an attachment circuit

(AC), while the underlying link is referred to as a "bearer".

This document specifies a YANG service data model for ACs. This model

can be used for the provisioning of ACs before or during service

provisioning (e.g., RFC 9543 Network Slice Service).

The document also specifies a YANG service data model for managing

bearers over which ACs are established.

This document specifies a network model for attachment circuits. The model can be used for the provisioning of attachment circuits prior or during service provisioning (e.g., VPN, Network Slice Service). A companion service model is specified in the YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) (I-D.ietf- opsawg-teas-attachment-circuit).

The module augments the base network ('ietf-network') and the Service Attachment Point (SAP) models with the detailed information for the provisioning of attachment circuits in Provider Edges (PEs).

This document defines a YANG data model, referred to as the "AC Glue"

model, to augment the LxVPN Service Model (LxSM) and LxVPN Network

Model (LxNM) with references to attachment circuits (ACs). The AC

Glue model enables a provider to associate Layer 2/3 VPN (LxVPN)

services with the underlying AC infrastructure, thereby facilitating

consistent provisioning and management of new or existing ACs in

conjunction with LxVPN services. Specifically, by introducing an

integrated approach to AC and LxVPN management, this model supports

Attachment Circuit as a Service (ACaaS) and provides a standardized

mechanism for aligning AC/VPN requests with the network

configurations required to deliver them.

This document updates RFC 9048, "Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')", and its predecessor RFC 5448 with an optional extension providing ephemeral key exchange. The extension EAP-AKA' Forward Secrecy (EAP-AKA' FS), when negotiated, provides forward secrecy for the session keys generated as a part of the authentication run in EAP-AKA'. This prevents an attacker who has gained access to the long-term key from obtaining session keys established in the past. In addition, EAP-AKA' FS mitigates passive attacks (e.g., large-scale pervasive monitoring) against future sessions. This forces attackers to use active attacks instead.

RFC 5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates. This document defines encrypting JSON objects in HTTP messages, using JSON Web Tokens (JWTs), and signing the OAuth 2.0 access tokens KeyPurposeIds for inclusion in the Extended Key Usage (EKU) extension of X.509 v3 public key certificates used by Network Functions (NFs) for the 5G System.

This document discusses the applicability of Segment Routing over IPv6 (SRv6) to the user plane of mobile networks. The network programming nature of SRv6 accomplishes mobile user-plane functions in a simple manner. The statelessness of SRv6 and its ability to control both service layer path and underlying transport can be beneficial to the mobile user plane, providing flexibility, end-to-end network slicing, and Service Level Agreement (SLA) control for various applications.

This document discusses how SRv6 could be used as the user plane of mobile networks. This document also specifies the SRv6 Endpoint Behaviors required for mobility use cases.

This document describes Static Context Header Compression and fragmentation (SCHC) specifications, RFCs 8724 and 8824, in combination with the 3rd Generation Partnership Project (3GPP) and the Narrowband Internet of Things (NB-IoT).

This document has two parts: one normative part that specifies the use of SCHC over NB-IoT and one informational part that recommends some values if 3GPP wants to use SCHC inside their architectures.

This document specifies the certificate extension for including Network Function Types (NFTypes) for the 5G System in X.509 v3 public key certificates as profiled in RFC 5280.

A 4G mobile network uses IP-based transport for the control plane to establish the data session at the user plane for the actual data delivery. In the existing architecture, IP-based unicast is used for the delivery of multimedia content to a mobile terminal, where each user is receiving a separate stream from the server. From a bandwidth and routing perspective, this approach is inefficient. Evolved multimedia broadcast and multicast service (eMBMS) provides capabilities for delivering contents to multiple users simultaneously, but its deployment is very limited or at an experimental stage due to numerous challenges. The focus of this document is to list the options for using Information-Centric Networking (ICN) in 4G mobile networks and elaborate the experimental setups for its further evaluation. The experimental setups discussed provide guidance for using ICN either natively or with an existing mobility protocol stack. With further investigations based on the listed experiments, ICN with its inherent capabilities such as network-layer multicast, anchorless mobility, security, and optimized data delivery using local caching at the edge may provide a viable alternative to IP transport in 4G mobile networks.

This memo discusses the use of the Constrained Application Protocol (CoAP) in building sensors and other devices that employ cellular networks as a communications medium. Building communicating devices that employ these networks is obviously well known, but this memo focuses specifically on techniques necessary to minimize power consumption.

The 3GPP mobile network Authentication and Key Agreement (AKA) is an authentication mechanism for devices wishing to access mobile networks. RFC 4187 (EAP-AKA) made the use of this mechanism possible within the Extensible Authentication Protocol (EAP) framework. RFC 5448 (EAP-AKA') was an improved version of EAP-AKA.

This document is the most recent specification of EAP-AKA', including, for instance, details about and references related to operating EAP-AKA' in 5G networks.

EAP-AKA' differs from EAP-AKA by providing a key derivation function that binds the keys derived within the method to the name of the access network. The key derivation function has been defined in the 3rd Generation Partnership Project (3GPP). EAP-AKA' allows its use in EAP in an interoperable manner. EAP-AKA' also updates the algorithm used in hash functions, as it employs SHA-256 / HMAC-SHA-256 instead of SHA-1 / HMAC-SHA-1, which is used in EAP-AKA.

This version of the EAP-AKA' specification defines the protocol behavior for both 4G and 5G deployments, whereas the previous version defined protocol behavior for 4G deployments only. While EAP-AKA' as defined in RFC 5448 is not obsolete, this document defines the most recent and fully backwards-compatible specification of EAP-AKA'. This document updates both RFCs 4187 and 5448.

As part of providing wireline access to the 5G Core (5GC), deployed wireline networks carry user data between 5G residential gateways and the 5G Access Gateway Function (AGF). The encapsulation method specified in this document supports the multiplexing of traffic for multiple PDU sessions within a VLAN-delineated access circuit, permits legacy equipment in the data path to inspect certain packet fields, carries 5G QoS information associated with the packet data, and provides efficient encoding. It achieves this by specific points of similarity with the Point-to-Point Protocol over Ethernet (PPPoE) data packet encapsulation (RFC 2516).

This document specifies new Internet Key Exchange Protocol Version 2 (IKEv2) notification status types to better manage IPv4 and IPv6 coexistence by allowing the responder to signal to the initiator which address families are allowed.

This document updates RFC 7296.

This document defines the Subscriber and Performance Policy Identifier Context Headers. These Variable-Length Context Headers can be carried in the Network Service Header (NSH) and are used to inform Service Functions (SFs) of subscriber- and performance-related information for the sake of policy enforcement and appropriate Service Function Chaining (SFC) operations. The structure of each Context Header and their use and processing by NSH-aware nodes are described.

The Real-time Transport Protocol (RTP) is a common transport choice for interactive multimedia communication applications. The performance of these applications typically depends on a well-functioning congestion control algorithm. To ensure a seamless and robust user experience, a well-designed RTP-based congestion control algorithm should work well across all access network types. This document describes test cases for evaluating performances of candidate congestion control algorithms over cellular and Wi-Fi networks.

In multiconnectivity scenarios, the clients can simultaneously connect to multiple networks based on different access technologies and network architectures like Wi-Fi, LTE, and DSL. Both the quality of experience of the users and the overall network utilization and efficiency may be improved through the smart selection and combination of access and core network paths that can dynamically adapt to changing network conditions.

This document presents a unified problem statement and introduces a solution for managing multiconnectivity. The solution has been developed by the authors based on their experiences in multiple standards bodies, including the IETF and the 3GPP. However, this document is not an Internet Standards Track specification, and it does not represent the consensus opinion of the IETF.

This document describes requirements, solution principles, and the architecture of the Multi-Access Management Services (MAMS) framework. The MAMS framework aims to provide best performance while being easy to implement in a wide variety of multiconnectivity deployments. It specifies the protocol for (1) flexibly selecting the best combination of access and core network paths for the uplink and downlink, and (2) determining the user-plane treatment (e.g., tunneling, encryption) and traffic distribution over the selected links, to ensure network efficiency and the best possible application performance.

Adoption of cloud and fog technology allows operators to deploy a single "Service Function" (SF) to multiple "execution locations". The decision to steer traffic to a specific location may change frequently based on load, proximity, etc. Under the current Service Function Chaining (SFC) framework, steering traffic dynamically to the different execution endpoints requires a specific "rechaining", i.e., a change in the service function path reflecting the different IP endpoints to be used for the new execution points. This procedure may be complex and take time. In order to simplify rechaining and reduce the time to complete the procedure, we discuss separating the logical Service Function Path (SFP) from the specific execution endpoints. This can be done by identifying the SFs using a name rather than a routable IP endpoint (or Layer 2 address). This document describes the necessary extensions, additional functions, and protocol details in the Service Function Forwarder (SFF) to handle name-based relationships.

This document presents InterDigital's approach to name-based SFC. It does not represent IETF consensus and is presented here so that the SFC community may benefit from considering this mechanism and the possibility of its use in the edge data centers.

The P-Served-User header field was defined based on a requirement from the 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) in order to convey the identity of the served user, his/ her registration state, and the session case that applies to that particular communication session and application invocation. A session case is metadata that captures the status of the session of a served user regardless of whether or not the served user is registered or the session originates or terminates with the served user. This document updates RFC 5502 by defining a new P-Served-User header field parameter, "orig-cdiv". The parameter conveys the session case used by a proxy when handling an originating session after Call Diversion (CDIV) services have been invoked for the served user. This document also fixes the ABNF in RFC 5502 and provides more guidance for using the P-Served-User header field in IP networks.

This memo describes a rate adaptation algorithm for conversational media services such as interactive video. The solution conforms to the packet conservation principle and uses a hybrid loss-and-delay- based congestion control algorithm. The algorithm is evaluated over both simulated Internet bottleneck scenarios as well as in a Long Term Evolution (LTE) system simulator and is shown to achieve both low latency and high video throughput in these scenarios.

This document creates additional Session Initiation Protocol (SIP) Resource-Priority namespaces to meet the requirements of the 3GPP-defined Mission Critical Push To Talk (MCPTT) and places these namespaces in the corresponding IANA registry.

This document discusses both use cases and operational experience with Multipath TCP (MPTCP) in real networks. It lists several prominent use cases where Multipath TCP has been considered and is being used. It also gives insight to some heuristics and decisions that have helped to realize these use cases and suggests possible improvements.

This document updates RFC 7315, by modifying the extension-access- info part of the P-Access-Network-Info header field Augmented Backus- Naur Form (ABNF), and by adding the following 'access-info' header field parameter values to the list of 'access-info' header field parameter values in the ABNF: 'operator-specific-GI' and 'utran-sai-3gpp'. The values are defined in the ABNF but are not included in the list.

This document defines a profile that is a superset of the connection to IPv6 cellular networks defined in the IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts document. This document defines a profile that is a superset of the connections to IPv6 cellular networks defined in "IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts" (RFC 7066).

Both mobile hosts and mobile devices with the capability to share their 3GPP mobile connectivity are in scope.

This document defines two new configuration attributes for the Internet Key Exchange Protocol version 2 (IKEv2). These attributes can be used for carrying the IPv4 address and IPv6 address of the Proxy-Call Session Control Function (P-CSCF). When an IPsec gateway delivers these attributes to an IPsec client, the IPsec client can obtain the IPv4 and/or IPv6 address of the P-CSCF server located in the 3GPP network.

In 3GPP networks, the signaling path between a calling user and a called user can be partitioned into segments, referred to as traffic legs. Each traffic leg may span networks belonging to different operators and will have its own characteristics that can be different from other traffic legs in the same call. A traffic leg might be associated with multiple SIP dialogs, e.g., in case a Back-to-Back User Agent (B2BUA) that modifies the SIP dialog identifier is located within the traffic leg.

This document defines a new SIP URI parameter, 'iotl' (an abbreviation for Inter-Operator Traffic Leg). The parameter can be used in a SIP URI to indicate that the entity associated with the address, or an entity responsible for the host part of the address, represents the end of a specific traffic leg (or multiple traffic legs).

With Wi-Fi emerging as a crucial access network for mobile service providers, it has become important to provide functions commonly available in 3G and 4G networks in Wi-Fi access networks as well. Such functions include Access Point Name (APN) Selection, multiple Packet Data Network (PDN) connections, and seamless mobility between Wi-Fi and 3G/4G networks.

The EAP Authentication and Key Agreement (EAP-AKA), and EAP-AKA', protocol is required for mobile devices to access the mobile Evolved Packet Core (EPC) via Wi-Fi networks. This document defines a few new EAP attributes to enable the above-mentioned functions in such networks. The attributes are exchanged between a client (such as a Mobile Node (MN)) and its network counterpart (such as an Authentication, Authorization, and Accounting (AAA) server) in the service provider's infrastructure.

This document describes a set of private header (P-header) Session Initiation Protocol (SIP) fields used by the 3GPP, along with their applicability, which is limited to particular environments. The P-header fields are used for a variety of purposes within the networks that the partners implement, including charging and information about the networks a call traverses. This document obsoletes RFC 3455.

This document describes requirements for extending an IPv6 /64 prefix from a User Equipment Third Generation Partnership Project (3GPP) radio interface to a LAN link and describes two implementation examples.

This specification defines a new mobility option, the Quality-of- Service (QoS) option, for Proxy Mobile IPv6. This option can be used by the local mobility anchor and the mobile access gateway for negotiating Quality-of-Service parameters for a mobile node's IP flows. The negotiated QoS parameters can be used for QoS policing and marking of packets to enforce QoS differentiation on the path between the local mobility anchor and the mobile access gateway. Furthermore, making QoS parameters available on the mobile access gateway enables mapping of these parameters to QoS rules that are specific to the access technology and allows those rules to be enforced on the access network using access-technology-specific approaches.

As the deployment of third and fourth generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations have made the Internet Protocol version 6 (IPv6) mandatory in their specifications. However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost, and delay put special requirements on how IPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), or Evolved Packet System (EPS) networks (hereafter collectively referred to as Third Generation Partnership Project (3GPP) networks). This document also lists specific IPv6 functionalities that need to be implemented in addition to what is already prescribed in the IPv6 Node Requirements document (RFC 6434). It also discusses some issues related to the use of these components when operating in these networks. This document obsoletes RFC 3316.

As interest in IPv6 deployment in cellular networks increases, several migration issues have been being raised; IPv6 prefix management is the issue addressed in this document. Based on the idea that DHCPv6 servers can manage prefixes, we use DHCPv6 Prefix Delegation to address such prefix management issues as an access router offloading delegation of prefixes and release tasks to a DHCPv6 server. The access router first requests a prefix for an incoming mobile node from the DHCPv6 server. The access router may next do stateless or stateful address allocation to the mobile node, e.g., with a Router Advertisement or using DHCP. We also describe prefix management using Authentication, Authorization, and Accounting (AAA) servers. This document is not an Internet Standards Track specification; it is published for informational purposes.

The use of cellular broadband for accessing the Internet and other data services via smartphones, tablets, and notebook/netbook computers has increased rapidly as a result of high-speed packet data networks such as HSPA, HSPA+, and now Long-Term Evolution (LTE) being deployed. Operators that have deployed networks based on 3rd Generation Partnership Project (3GPP) network architectures are facing IPv4 address shortages at the Internet registries and are feeling pressure to migrate to IPv6. This document describes the support for IPv6 in 3GPP network architectures. This document is not an Internet Standards Track specification; it is published for informational purposes.

Several MIME type/subtype combinations exist that can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it is helpful to know from the Content- Type alone if the content can be rendered.

This document specifies two parameters, 'codecs' and 'profiles', that are used with various MIME types or type/subtype combinations to allow for unambiguous specification of the codecs employed by the media formats contained within, or the profile(s) of the overall container format. This document obsoletes RFC 4281; RFC 4281 defines the 'codecs' parameter, which this document retains in a backwards compatible manner with minor clarifications; the 'profiles' parameter is added by this document.

By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action (such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.).

Similarly, the profiles can provide an overall indication, to the receiver, of the specifications with which the content complies. This is an indication of the compatibility of the container format and its contents to some specification. The receiver may be able to work out the extent to which it can handle and render the content by examining to see which of the declared profiles it supports, and what they mean. [STANDARDS-TRACK]

Large Proxy Mobile IPv6 deployments would benefit from a functionality where a Mobile Access Gateway could dynamically discover a Local Mobility Anchor for a Mobile Node attaching to a Proxy Mobile IPv6 domain. The purpose of the dynamic discovery functionality is to reduce the amount of static configuration in the Mobile Access Gateway. This document describes several possible dynamic Local Mobility Anchor discovery solutions. This document is not an Internet Standards Track specification; it is published for informational purposes.

The Packet-switched Streaming Service (PSS) and the Multimedia Broadcast/Multicast Service (MBMS) defined by 3GPP use the Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) with some extensions. This document provides information about these extensions and registers the RTSP and SDP extensions with IANA. This document is not an Internet Standards Track specification; it is published for informational purposes.

Mobile IPv4 is a standard mobility protocol that enables an IPv4 device to move among networks while maintaining its IP address. The mobile device has the Mobile IPv4 client function to signal its location to the routing anchor, known as the Home Agent. However, there are many IPv4 devices without such capability due to various reasons. This document describes Proxy Mobile IPv4 (PMIPv4), a scheme based on having the Mobile IPv4 client function in a network entity to provide mobility support for an unaltered and mobility-unaware IPv4 device. This document also describes a particular application of PMIPv4 as specified in the WiMAX Forum and another application that is to be adopted in 3GPP2. This document is not an Internet Standards Track specification; it is published for informational purposes.

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 that 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 Media Access Control (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. [STANDARDS-TRACK]

This specification defines a new EAP method, EAP-AKA', which is a small revision of the EAP-AKA (Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement) method. The change is a new key derivation function that binds the keys derived within the method to the name of the access network. The new key derivation mechanism has been defined in the 3rd Generation Partnership Project (3GPP). This specification allows its use in EAP in an interoperable manner. In addition, EAP-AKA' employs SHA-256 instead of SHA-1.

This specification also updates RFC 4187, EAP-AKA, to prevent bidding down attacks from EAP-AKA'. This memo provides information for the Internet community.

This document registers a set of IANA Diameter Command Codes to be used in new vendor-specific Diameter applications defined for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS). These new Diameter applications are defined for Mobile Management Entity (MME)- and Serving GPRS (General Packet Radio Service) Support Node (SGSN)-related interfaces in the architecture for the Evolved 3GPP Packet Switched Domain, which is also known as the Evolved Packet System (EPS). This memo provides information for the Internet community.

This document specifies the SIP P-Served-User P-header. This header field addresses an issue that was found in the 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) between an S-CSCF (Serving Call Session Control Function) and an AS (Application Server) on the ISC (IMS Service Control) interface. This header field conveys the identity of the served user and the session case that applies to this particular communication session and application invocation. This memo provides information for the Internet community.

This document specifies the Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header). This P-Header is used in the Open Mobile Alliance's (OMA) Push to talk over Cellular (PoC) system. It enables URI-list servers to refuse the handling of incoming URI lists that have embedded URI lists. This P-Header also makes it possible for the URI-list server to inform the client about the embedded URI list that caused the rejection and the individual URIs that form such a URI list. This memo provides information for the Internet community.

This document describes the Namespace Identifier (NID) for Uniform Resource Namespace (URN) resources published by the 3rd Generation Partnership Project (3GPP). 3GPP defines and manages resources that utilize this URN name model. Management activities for these and other resource types are provided by the 3GPP Support Team. This memo provides information for the Internet community.

Mobile IPv6 is designed to maintain its connectivity while moving from one network to another. It is adopted in 3G CDMA networks as a way to maintain connectivity when the mobile node (MN) moves between access routers. However, this handover procedure requires not only movement detection by the MN, but also the acquisition of a new Care-of Address and Mobile IPv6 registration with the new care-of address before the traffic can be sent or received in the target network. During this period, packets destined for the mobile node may be lost, which may not be acceptable for a real-time application such as Voice over IP (VoIP) or video telephony. This document specifies fast handover methods in the 3G CDMA networks in order to reduce latency and packet loss during handover. This memo provides information for the Internet community.

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 memo provides information for the Internet community.

This document specifies the SIP P-Profile-Key P-header. This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) to provide SIP registrars and SIP proxy servers with the key of the profile corresponding to the destination SIP URI of a particular SIP request. This memo provides information for the Internet community.

This document specifies the Session Initiation Protocol (SIP) P-User-Database Private-Header (P-header). This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) to provide SIP registrars and SIP proxy servers with the address of the database that contains the user profile of the user that generated a particular request. This memo provides information for the Internet community.

This document serves to register and document the standard MIME types associated with the 3GPP2 multimedia file format, which is part of the family based on the ISO Media File Format. [STANDARDS-TRACK]

This document is a history capturing the background, motivation and thinking during the LEMONADE definition and design process.

The LEMONADE Working Group -- Internet email to support diverse service environments -- is chartered to provide enhancements to Internet mail to facilitate its use by more diverse clients. In particular, by clients on hosts not only operating in environments with high latency/bandwidth-limited unreliable links but also constrained to limited resources. The enhanced mail must be backwards compatible with existing Internet mail.

The primary motivation for this effort is -- by making Internet mail protocols richer and more adaptable to varied media and environments -- to allow mobile handheld devices tetherless access to Internet mail using only IETF mail protocols.

The requirements for these devices drive a discussion of the possible protocol enhancements needed to support multimedia messaging on limited-capability hosts in diverse service environments. A list of general principles to guide the design of the enhanced messaging protocols is documented. Finally, additional issues of providing seamless service between enhanced Internet mail and the existing separate mobile messaging infrastructure are briefly listed. This memo provides information for the Internet community.

This document specifies an RTP payload format for the transmission of 3GPP (3rd Generation Partnership Project) timed text. 3GPP timed text is a time-lined, decorated text media format with defined storage in a 3GP file. Timed Text can be synchronized with audio/video contents and used in applications such as captioning, titling, and multimedia presentations. In the following sections, the problems of streaming timed text are addressed, and a payload format for streaming 3GPP timed text over RTP is specified. [STANDARDS-TRACK]

The Open Mobile Alliance (OMA) is defining the Push-to-talk over Cellular (PoC) service where SIP is the protocol used to establish half-duplex media sessions across different participants, to send instant messages, etc. This document defines a SIP event package to support publication, subscription, and notification of additional capabilities required by the PoC service. This SIP event package is applicable to the PoC service and may not be applicable to the general Internet. This memo provides information for the Internet community.

This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution that uses the Authentication and Key Agreement (AKA) mechanism. AKA is used in the 3rd generation mobile networks Universal Mobile Telecommunications System (UMTS) and CDMA2000. AKA is based on symmetric keys, and typically runs in a Subscriber Identity Module, which is a UMTS Subscriber Identity Module, USIM, or a (Removable) User Identity Module, (R)UIM, similar to a smart card.

EAP-AKA includes optional identity privacy support, optional result indications, and an optional fast re-authentication procedure. This memo provides information for the Internet community.

The cellular telephone industry has defined a service known as the Multimedia Messaging Service (MMS). This service uses formats and protocols that are similar to, but differ in key ways from, those used in Internet mail.

One important difference between MMS and Internet Mail is that MMS uses headers that start with "X-Mms-" to carry a variety of user agent- and server-related information elements.

This document specifies how to exchange messages between these two services, including mapping information elements as used in MMS X-Mms-* headers as well as delivery and disposition reports, to and from that used in SMTP and Internet message headers. [STANDARDS-TRACK]

This document defines new options to discover the Broadcast and Multicast Service (BCMCS) controller in an IP network. BCMCS is being developed for Third generation (3G) cellular telephone networks. Users of the service interact with a controller in the network via the Mobile Node (MN) to derive information required to receive Broadcast and Multicast Service. Dynamic Host Configuration Protocol can be used to configure the MN to access a particular controller. This document defines the related options and option codes. [STANDARDS-TRACK]

The 3rd-Generation Partnership Project (3GPP) has selected Session Initiation Protocol (SIP) as the session establishment protocol for the 3GPP IP Multimedia Core Network Subsystem (IMS). IMS is part of Release 5 of the 3GPP specifications. Although SIP is a protocol that fulfills most of the requirements for establishing a session in an IP network, SIP has never been evaluated against the specific 3GPP requirements for operation in a cellular network. In this document, we express the requirements identified by 3GPP to support SIP for Release 5 of the 3GPP IMS in cellular networks. This memo provides information for the Internet community.

This document serves to register and document the standard MIME types associated with the 3GPP multimedia file format, which is part of the family based on the ISO Media File Format. [STANDARDS-TRACK]

This document describes the IANA's allocation of a block of Diameter Command Codes for the Third Generation Partnership Project (3GPP) Release 5. This document does not pass judgment on the usage of these command codes. Further more, these command codes are for use for Release 5. For future releases, these codes cannot be reused, but must be allocated according to the Diameter Base specification. This memo provides information for the Internet community.

This memo describes the full set of notations needed to represent a text string in a Dial Sequence. A Dial Sequence is normally composed of Dual Tone Multi Frequency (DTMF) elements, plus separators and additional "actions" (such as "wait for dialtone", "pause for N secs", etc.) which could be needed to successfully establish the connection with the target service: this includes the cases where subaddresses or DTMF menu navigation apply.

This document describes different scenarios in Third Generation Partnership Project (3GPP) defined packet network, i.e., General Packet Radio Service (GPRS) that would need IP version 6 and IP version 4 transition. The focus of this document is on the scenarios where the User Equipment (UE) connects to nodes in other networks, e.g., in the Internet. GPRS network internal transition scenarios, i.e., between different GPRS elements in the network, are out of scope. The purpose of the document is to list the scenarios for further discussion and study. This memo provides information for the Internet community.

This document describes a profile for optimizing TCP to adapt so that it handles paths including second (2.5G) and third (3G) generation wireless networks. It describes the relevant characteristics of 2.5G and 3G networks, and specific features of example deployments of such networks. It then recommends TCP algorithm choices for nodes known to be starting or ending on such paths, and it also discusses open issues. The configuration options recommended in this document are commonly found in modern TCP stacks, and are widely available standards-track mechanisms that the community considers safe for use on the general Internet. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

In wireless environments and especially in cellular systems, e.g. GSM

(Global System for Mobile communications) and UMTS (Universal Mobile

Telecommunications System), there is a need to maximize the transport

efficiency for data over the radio interface. With the introduction

of SIP/SDP (Session Initiation Protocol/Session Description Protocol)

to cellular devices, compression of the signaling messages should be

considered in order to improve both service availability and quality,

mainly by reducing the user idle time, e.g. at call setup. The

purpose of this document is to outline requirements and motivations

for development of a scheme for compression and decompression of

messages from signaling protocols.

The REGISTER function is used in a SIP system primarily to associate

a temporary contact address with an address-of-record. This contact

is generally in the form of a URI, such as Contact:

<sip:alice@pc33.atlanta.com> and is generally dynamic and associated

with the IP address or hostname of the SIP UA. The problem is that

network topology may have one or more SIP proxies between the UA and

the registrar, such that any request travelling from the user's home

network to the registered UA must traverse these proxies. The

REGISTER method does not give us a mechanism to discover and record

this sequence of proxies in the registrar for future use. This

document defines an extension header field, 'Path' which provides

such a mechanism

The Hypertext Transfer Protocol (HTTP) Authentication Framework

includes two authentication schemes: Basic and Digest. Both schemes

employ a shared secret based mechanism for access authentication.

The Authentication and Key Agreement (AKA) mechanism performs user

authentication and session key distribution in Universal Mobile

Telecommunications System (UMTS) networks. AKA is a challenge-

response based mechanism that uses symmetric cryptography. This memo

specifies an AKA based one-time password generation mechanism for

HTTP Digest access authentication.

This document contains recommendations from the Internet

Engineering Task Force (IETF) IPv6 Working Group to the Third

Generation Partnership Project (3GPP) community regarding the use

of IPv6 in the 3GPP standards. Specifically, this document

recommends that the 3GPP:

1. Specify that multiple prefixes may be assigned to each

primary PDP context,

2. Require that a given prefix must not be assigned to more

than one primary PDP context, and

3. Allow 3GPP nodes to use multiple identifiers within those

prefixes, including randomly generated identifiers.

The IPv6 Working Group supports the use of IPv6 within 3GPP and

offers these recommendations in a spirit of open cooperation

between the IPv6 Working Group and the 3GPP community. Since the

original publication of this document as an Internet-Draft, the

3GPP has adopted the primary recommendations of this document.

This document describes the standardization collaboration between 3GPP and IETF. This memo provides information for the Internet community.

This document describes the standardization collaboration between 3GPP2 and IETF. This memo provides information for the Internet community.

This is a draft of the requirements for IPng as envisioned by representatives of the Cellular Digital Packet Data (CDPD) consortium of service providers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.