name: PAP
full_form: Password Authentication Protocol
context: Figure 23 describes the RADIUS message flows between a GGSN and an Authentication, Authorization and Accounting (AAA) server for the case where PPP is terminated at the GGSN. The case where PPP is relayed to an LNS is beyond the scope of the present document. NOTE 1: Separate accounting and Authentication servers may be used. NOTE 2: Actual messages depend on the used authentication protocol (e.g. PAP, CHAP). NOTE 3: If some external applications require RADIUS Accounting request (Start) information before they can process user packets, then the selected APN (GGSN) may be configured in such a way that the GGSN drops user data until the Accounting Response (START) is received from the AAA server. The GGSN may delete the PDP context if the Accounting Response (START) is not received. NOTE 4: An LCP termination procedure may be performed. Either the MS or the GGSN may initiate the context deactivation. NOTE 5: The Access-Request message shall be used for primary PDP context only. NOTE 6: Network Initiated deactivation. NOTE 7: User Initiated deactivation. Figure 23: RADIUS message flow for PDP type PPP (successful user authentication case) When a GGSN receives a Create PDP Context Request message for a given APN, the GGSN shall immediately send a Create PDP context response back to the SGSN. After PPP link setup, the authentication phase may take place. During Authentication phase, the GGSN sends a RADIUS Access-Request to an AAA server. The AAA server authenticates and authorizes the user. If RADIUS is also responsible for IP address allocation the AAA server shall return the allocated IP address or IPv6 prefix in the Access-Accept message (if the user was authenticated). If the user is not authenticated, the GGSN shall send a Delete PDP context request to the SGSN. Even if the GGSN was not involved in user authentication (e.g. for PPP no authentication may be selected), it may send a RADIUS Accounting-Request START message to an AAA server. This message contains parameters, e.g. a tuple which includes the user-id and IP address or IPv6 prefix, to be used by application servers (e.g. WAP gateway) in order to identify the user. This message also indicates to the AAA server that the user session has started, and the QoS parameters associated to the session. If some external applications require RADIUS Accounting request (Start) information before they can process user packets, then the selected APN (GGSN) may be configured in such a way that the GGSN drops user data until the Accounting Response (START) is received from the AAA server. The GGSN may delete the PDP context if the Accounting Response (START) is not received. The Authentication and Accounting servers may be separately configured for each APN. When the GGSN receives a Delete PDP Context Request message and providing a RADIUS Accounting-Request START message was sent previously, the GGSN shall send a RADIUS Accounting-Request STOP message to the AAA server, which indicates the termination of this particular user session. The GGSN shall immediately send a Delete PDP context response, without waiting for an Accounting-Response STOP message from the AAA server. The AAA server shall deallocate the IP address or IPv6 prefix (if any) initially allocated to the subscriber. Accounting-Request ON and Accounting-Request OFF messages may be sent from the GGSN to the AAA server to ensure the correct synchronization of the session information in the GGSN and the AAA server. The GGSN may send an Accounting-Request ON message to the AAA server to indicate that a restart has occurred. The AAA server may then release the associated resources. Prior to a scheduled restart, the GGSN may send Accounting-Request OFF message to the AAA server, the AAA server may then release the associated resources. If an Access-Challenge is sent to the GGSN when using PPP PDP type, the GGSN shall handle it by PPP CHAP providing PPP CHAP was the selected Authentication protocol. If CHAP authentication was not selected, authentication shall fail RFC 2865 [38].
description: The Password Authentication Protocol (PAP) is a simple authentication protocol used in various telecommunications contexts, including Point-to-Point Protocol (PPP) connections. It involves the client sending a username and password to the server for verification. In the context of RADIUS message flows between a GGSN and an AAA server, PAP may be used as one of the authentication protocols, alongside others like CHAP.
explanation: PAP is classified under the Protocol category because it defines a set of rules for data transmission and authentication in telecommunications networks. Specifically, within the context provided, PAP plays a role in the authentication phase of PPP link setup, where the GGSN sends a RADIUS Access-Request to an AAA server using protocols like PAP or CHAP.
section_title: 16.3.2 PPP PDP type
biotag_Context: O,O,O,O,B-Protocol,O,O,O,O,B-Network Function,O,O,B-Service,I-Service,I-Service,I-Service,O,O,O,O,O,O,B-Protocol,O,O,O,O,O,O,O,O,B-Protocol,O,O,O,O,B-Network Function,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,B-Protocol,O,O,O,O,O,O,O,O,O,O,O,O,O,B-Network,O,O,O,O,O,O,O,O,O,O,B-Network Function,O,O,O,O,O,O,O,O,O,O,O,O,B-Service,O,O,B-Network Function,O,O,O,B-Protocol,O,O,O,O,O,O,O,O,O,O,O,O,B-Procedure,O,O,O,O,O,O,O,B-Parameter,O,O,B-Network Function,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,B-Protocol,O,O,O,O,B-Network,O,O,O,O,O,O,O,O,O,B-Protocol,O,O,O,B-Protocol,O,B-Protocol,O,O,O,O,O,O,B-Network Function,O,O,O,B-Protocol,O,O,O,O,O,O,O,O,B-Network Function,O,O,O,O,O,B-Protocol,O,O,O,O,O,O,O,B-Protocol,O,O,O,O,O,O,O,O,O,O,O,O,B-Network Function,O,O,B-Protocol,O,O,O,B-Service,O,O,B-Protocol,I-Protocol,O,O,O,O,O,O,B-Protocol,O,O,O,O,B-Protocol,O,O,O,B-Protocol,I-Protocol,O,O,O,O,B-Protocol,O,O,B-Protocol,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,B-Network Function,O,O,O,O,B-Protocol,O,O,O,O,O,O,O,O,B-Network Function,O,O,O,O,O,O,O,O,B-Protocol,O,O,O,O,O,O,O,O,O,B-Protocol,O,O,O,O,O,B-Service,O,O,O,O,O,O,O,O,O,O,O,O,O,B-Protocol,O,O,B-Protocol,O,O,O,O,O,O,O,O,B-Protocol,O,O,O,O,O,O,O,O,O,O,O,O,O,B-Protocol,I-Protocol,O,O,O,O,O,O,O,O,B-Measurement,O,O,O,O,O,O,O,O,O,O,B-Protocol,O,O,O,O,O,O,O,O,O,O,O,O,O,B-Network,O,O,O,O,O,O,O,O,O,O,B-Network Function,O,O,O,O,O,O,O,O,O,O,O,O,B-Service,O,O,B-Network Function,O,O,O,B-Protocol,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,B-Network Function,O,O,O,B-Protocol,O,O,O,O,O,O,B-Protocol,O,O,O,O,O,O,O,B-Network Function,O,O,O,B-Protocol,O,O,O,O,O,B-Service,O,O,O,O,O,O,O,O,O,O,O,B-Network Function,O,O,O,O,O,B-Protocol,O,O,O,O,O,O,O,O,O,O,O,B-Service,O,O,B-Protocol,I-Protocol,O,O,O,B-Protocol,O,O,B-Protocol,O,O,O,O,O,O,O,O,O,B-Miscellaneous,O,O,O,O,O,O,O,O,O,B-Network Function,O,O,B-Protocol,I-Protocol,O,O,O,O,O,O,O,O,O,O,O,B-Network Function,O,O,B-Service,O,O,B-Network Function,O,O,O,O,B-Miscellaneous,O,O,O,B-Protocol,I-Protocol,O,O,O,O,O,O,O,O,B-Protocol,I-Protocol,O,O,O,O,O,O,O,O,O,O,O,O,B-Network Function,O,O,O,O,O,O,O,B-Service,O,O,B-Protocol,I-Protocol,O,O,O,O,O,O,O,O,O,O,O,O,O,B-Network Function,O,O,B-Protocol,B-Protocol,O,O,B-Network Function,O,O,O,O,B-Protocol,B-Protocol,O,B-Protocol,B-Protocol,O,O,O,O,O,O,B-Protocol,O,O,O,O,O,O,O,B-Specification,O,O
biotag_Description: O,B-Protocol,I-Protocol,I-Protocol,O,O,O,O,O,O,O,O,O,O,O,O,B-Protocol,I-Protocol,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,B-Protocol,O,O,O,O,B-Network Function,O,O,B-Service,O,B-Protocol,O,O,O,O,O,O,O,O,O,O,O,O,O