WO2009018774A1

WO2009018774A1 - A session connection method,apparatus and system in communication system

Info

Publication number: WO2009018774A1
Application number: PCT/CN2008/071900
Authority: WO
Inventors: Ruobin Zheng
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2007-08-06
Filing date: 2008-08-06
Publication date: 2009-02-12
Also published as: CN101365238A; CN101365238B

Abstract

The invention discloses a session connection method, apparatus and system in communication system. The method, which is used for building the session connection from the communication terminal of point-to-point protocol PPP session to the communication terminal of internet protocol IP session, includes the following steps: communicating with the PPP session communication terminal through PPP session; communicating with the IP session communication terminal through IP session; transmitting the information of PPP session which should be handled by the IP session communication terminal to the IP session communication terminal in the form of IP session; and transmitting the information of IP session which should be handled by the PPP session communication terminal to the PPP session communication terminal in the form of PPP session. By the session relaying, the embodiment of the invention realizes the transformation especially the authentication transformation between the PPP session and the IP session, which achieves the data transmission between UE and network side which apply different protocols. And when UE roams among networks, which apply different protocols, the service of UE would not be interrupted. Thus the user experience is improved.

Description

A communication system session connection method, device and system The present application claims priority to a Chinese patent application filed on August 6, 2007 by the Chinese Patent Office, application number 200710143897.3, and the invention titled "a method and device for session conversion" The entire contents of which are incorporated herein by reference. Technical field

The present invention relates to the field of computers and communications, and more particularly to communication system session connection methods, apparatus and systems. Background technique

The current network system only supports Point to Point Protocol (PPP) sessions. User Equipment (UE) accesses the Internet based on PPP at the data link layer and carries the point-to-point protocol over Ethernet. PPP over Ethernet, PPPoE) connects multiple devices on a shared Ethernet. The industry has proposed an Internet Protocol (IP) session, which is used for network access management, port accounting, and state management. An IP session is a session connection established between a UE and an IP Edge device. The IP edge device includes multiple devices, such as a Broadband Network Gateway (BNG) and a Broadband Remote Access Server (BRAS).

With the popularity of wireless access networks and portable UEs (such as laptops and mobile phones), the home network that the UE initially belongs to is different from the protocol session supported by the visited home network after roaming, for example, as shown in FIG. The dotted line indicates the IP session, the dotted line indicates the PPP session, the solid line indicates the connection relationship of the device, the home network only supports the IP session, and the visited network only supports the PPP session. When the UE does not roam to the visited network, it and the home network During the interaction of a device (such as a Service Provider (SP)), the IP session ends on an IP edge device (such as a BNG that only supports IP sessions) in the home network. After roaming, the UE must IP edge devices (such as BRASs that only support PPP sessions) in the visited network perform PPP sessions, and through IP edge devices in the visited network and IP edge devices in the home network and a device in the home network Interact. Or, for example, as shown in FIG. 2, the dotted line indicates the IP session, the dotted line indicates the PPP session, the solid line indicates the connection relationship of the device, the home network only supports the PPP session, and the visited network only supports the IP session. Before roaming, the UE Based on the PPP session interacting with the SP in the home network, the PPP session will terminate on the BRAS in the home network. After roaming, the UE must perform an IP session with the BNG in the visited network, and interact with the SP in the home network through the BNG in the visited network and the BRAS in the home network.

Since the IP session is a kind of session that has just been proposed recently, the update speed of the network side device and the UE may be inconsistent. For example, as shown in FIG. 3, a PPP-based UE needs to pass through a Residential Gateway (RG) in a Customer Premises Network (CPN) and an Access Network that supports only IP sessions. connection. Or, for example, as shown in FIG. 4, the IP-based UE needs to log in only the visited network of the PPP session through the RG in the CPN in which it is located.

In the process of implementing the present invention, the inventors have found that at least the following problems exist in the prior art: In the above different scenarios, the mutual conversion between the PPP session and the IP session needs to be implemented, and an effective solution has not been proposed in the prior art, especially It is an issue of authentication conversion between a PPP session and an IP session that needs to be resolved. Summary of the invention

Embodiments of the present invention provide a communication system session connection method, apparatus, and system, which are used to implement conversion between a PPP session and an IP session.

An embodiment of the present invention provides a communication system session connection method, which is used to establish a session connection of a point-to-point protocol PPP session communication peer to an Internet Protocol IP session communication peer, and the method includes the following steps:

Performing session communication with the PPP session communication peer through the PPP session; Communicate with the IP session communication peer through the IP session; and forward the information that needs to be processed by the IP session communication peer in the PPP session to the IP session communication peer in the form of an IP session, and the IP session needs to be communicated by the PPP session. The information processed by the terminal is forwarded to the PPP session communication peer in the form of a PPP session. An embodiment of the present invention further provides a relay device, including:

Point-to-point protocol PPP session interface unit, used to communicate with the PPP session peer-to-peer point-to-point protocol PPP session;

The Internet Protocol IP session interface unit is configured to exchange IP sessions with the IP session communication peer; the session conversion unit is configured to send the information that needs to be processed by the IP session communication peer in the ppp session to the IP session communication peer in the form of an IP session. The information that needs to be processed by the PPP session communication peer in the IP session is sent to the PPP session communication peer in the form of a PPP session.

An embodiment of the present invention further provides a communication system, where the communication system includes a relay device, and the relay device includes:

Embodiments of the present invention also provide a computer readable medium having computer executable instructions for performing the following steps:

Performing session communication with the PPP session communication peer through the PPP session;

Session communication with the IP session communication peer through the IP session;

The information that needs to be processed by the IP session communication peer in the PPP session is forwarded to the IP session communication peer in the form of an IP session, and the information that needs to be processed by the PPP session communication peer in the IP session is forwarded to the PPP session communication pair in the form of a PPP session. end. It is an authentication conversion, which enables data transmission between the UE and the network side that apply different protocols, and the UE does not interrupt the service during the roaming process of the network using different protocols, which can enhance the user experience. DRAWINGS

1 and 2 are network structure diagrams in the case of UE roaming in the prior art;

3 and FIG. 4 are network structure diagrams in the case where the UE is not roaming in the prior art; FIG. 5A is a structural diagram of the system in the embodiment of the present invention;

5B is a structural diagram of session relay in an embodiment of the present invention;

FIG. 6 is a flowchart of a main method for converting a PPP session to an IP session according to an embodiment of the present invention; FIG. 7 is a PPP session to an IP when a PPP session does not include an authentication process and an IP session includes using Option 82 for DHCP authentication according to an embodiment of the present invention; FIG. 8 is a flowchart of a method for converting a PPP session to an IP session when a PPP session includes CHAP authentication and an IP session includes DHCP authentication supporting CHAP authentication according to an embodiment of the present invention; FIG. 9 is a flowchart of the present invention; In the example, the PPP session includes an authentication process and a flow chart of a method for converting a PPP session to an IP session when the IP session includes EAP authentication;

9B is a flowchart of a method for converting a PPP session to an IP session when a PPP session includes CHAP authentication and an IP session includes EAP authentication on PAN A according to an embodiment of the present invention;

10 is a flowchart of a method for converting a PPP session to an IP session when a PPP session includes EAP authentication and an IP session includes EAP authentication carried on PAN A according to an embodiment of the present invention;

11 is a flowchart of a method for converting a PPP session to an IP session when a PPP session includes EAP authentication and an IP session includes DHCP authentication supporting EAP authentication according to an embodiment of the present invention;

FIG. 12 is a flowchart of a method for converting an IP session to a PPP session according to an embodiment of the present invention; FIG. 14 is a flowchart of a method for converting an IP session to a PPP session when the DHCP is configured by the Option 82; FIG. 14 is a PPP session including a CHAP in the embodiment of the present invention; A flowchart of a method for converting an IP session to a PPP session when the authentication and IP session include DHCP authentication supporting CHAP authentication; 15A is a flowchart of a method for converting an IP session to a PPP session when a PPP session includes an authentication process and an IP session includes an EAP authentication according to an embodiment of the present invention; a method for converting an IP session to a PPP session during EAP authentication on the EAPoL Figure

16 is a PPP session including EAP authentication and an IP session, including the bearer in the embodiment of the present invention;

Flowchart of the method of IP session to PPP session conversion when E AP authentication on E APoL. In the process of converting the IP session, the information in the PPP session network is sent to the device in the IP session network to create an IP session, and the data is transmitted between the PPP session network and the IP session network. Or, in the process of converting the IP session to the PPP session, the information in the IP session network is sent to the device in the PPP session network to create a PPP session, and the data is transmitted between the PPP session network and the IP session network.

The PPP session in this embodiment is a generalized PPP session, which includes a PPPoE session and a PPP over ATM (PPPoA) session. This embodiment uses a PPPoE session as an example for detailed description.

The basic conversion process of the PPPoE session to the IP session includes: (1) session establishment phase: conversion from the PPPoE session establishment process to the IP session establishment process; wherein the PPPoE session establishment process includes a PPPoE discovery process, a link establishment process, a PPP authentication process, and an NCP Negotiation (mainly refers to address allocation) process; IP session establishment process includes DHCP authentication and address allocation. (2) Session data transfer phase: Conversion of PPPoE session data transfer to IP session data transfer. (3) Session termination phase: The transition from the PPPoE session termination process to the IP session termination process; wherein the PPPoE session termination process includes a link termination process and a PPPoE termination process.

The basic conversion process from IP session to PPPoE session includes: (1) session establishment phase: conversion from IP session establishment process to PPPoE session establishment process; wherein PPPoE session establishment process includes PPPoE discovery process, link establishment process, PPP authentication process, and NCP Negotiation Refers to the address assignment process; the IP session establishment process includes DHCP authentication and address assignment. (2) Session data transfer phase: Conversion of IP session data transfer to PPPoE session data transfer. (3) Session termination phase: transition from the IP session termination process to the PPPoE session termination process; wherein the PPPoE session termination process includes a link termination process and a PPPoE termination process.

The intermediate module in the embodiment of the present invention is specifically a session relay, and the session relay may be a physical device entity or a logical device and exists in other devices.

In this embodiment, the PPPoE session process may not include an authentication process, or includes a Password Authentication Protocol (PAP) authentication, a Challenge-Handshake Authentication Protocol (CHAP) authentication, or an Extensible Authentication Protocol (Extensible Authentication). Protocol, EAP) authentication, etc. The IP session process may not include EAP authentication or EAP authentication. When the IP session does not include EAP authentication, the IP session process includes the Option 82 option or the Dynamic Host Configuration Protocol (DHCP) authentication that supports the PAP/CHAP mode. When an IP session includes EAP authentication, the EAP authentication includes EAP authentication carried on the Network Access Authentication Bearer Protocol (PANA), EAP authentication on the EAP over LAN (EAPoL) carried over the EAP, or EAP mode. DHCP authentication, etc. In summary, the PPPoE session includes four authentication modes, and the IP session includes five authentication modes. The four authentication modes of the PPPoE session can be mutually converted with the five authentication modes of the IP session.

Referring to FIG. 5A, the system in this embodiment includes a session communication peer (or Applicant) on the user side, a session relay, a session communication peer on the network side, an authenticator, an authentication server, and a DHCP server.

The session communication peer end on the user side or the network side may be a PPP session communication peer end or an IP session communication peer end.

The session communication peer end on the network side is used to communicate with the user side through the session relay to communicate with the peer end session.

The session communication peer end of the user side may be located on the UE or the RG, and the session communication peer end as the user side is used to interact with the session relay to implement the PPPoE session (or IP session), For the authenticated applicant, it interacts with the session relay to implement access authentication. In this embodiment,

Suppliant is located on the UE as an example.

Session relay, used to interact with Suppliant to implement a PPPoE session (or IP session), and interact with the network side session communication peer according to the Suppliant MAC address to implement an IP session (or PPPoE session) and perform a PPPoE session The conversion between the IP session and the PPPoE session is obtained from the PPPoE session and sent to the connected device in the IP session, and the information about the PPPoE session needs to be obtained from the IP session and sent to the PPPoE session. Connected device. The session relay replaces the Suppliant to obtain the first IP address sent by the peer of the session communication on the network side, and the session relay can send the first IP address to the Suppliant. Alternatively, the session relay allocates a second IP address to the Suppliant, and establishes a correspondence between the second IP address and the first IP address. When receiving the packet sent by the Suppliant, the second IP address in the packet is converted into a corresponding The first IP address is sent to the session communication peer on the network side, and the first IP address in the packet sent by the session communication peer on the network side is converted into a corresponding second IP address and sent to the Suppliant.

The authenticator uses the authentication process of the session, interacts with the session relay through the session communication peer on the network side, and performs authentication interaction with the authentication server. The session communication peers and the authenticators on the network side may both be located on physical entities such as ANs or IP edge devices, or the session communication peers on the network side and the authenticators are located on different physical entities. At this time, session communication on the network side The opposite end is closer to the Suppliant than the certifier. In this embodiment, the session communication peer end and the authenticator on the network side are all located on the IP edge device as an example. In DHCP authentication, the authenticator is a DHCP authenticator; in the EAP authentication carried in PANA, the authenticator is a PAN A authentication proxy (PAA). The authentication server is used to authenticate Suppliant based on the authentication information sent by the authenticator. The DHCP server is used to assign an IP address. The DHCP server is selected and interacted with by the session communication peer on the network side. The interaction process between the session communication peer, the authenticator, the authentication server, and the DHCP server on the network side is prior art and will not be described in detail herein.

The session relay can be a logical entity and exists in other devices. There can be multiple other devices, such as an RG, an access node (AN), an IP edge device, and the like. System Which device is the turning point of the IP session and the PPPoE session, and which device the session relay is on. If the Suppliant to RG applies the PPPoE session, the RG to the AN and the above device apply the IP session, then the session relay is located on the RG; if the Suppliant to the AN applies the PPPoE session, the AN to the IP edge device and the above device applies the IP session, the session relay On the AN; if the Suppliant to the IP edge device applies the PPPoE session, the IP edge device applies the IP session to the SP or other IP edge device, the session relay is located on the IP edge device, and the interaction between the session relay and the IP edge device is the session. The interaction between the trunk and other modules inside the IP edge device.

The session relay can also be a physical entity that exists independently at any location between the UE and the IP edge device. Which two devices in the system are the turning point of the IP session and the PPPoE session, and the session is in front of which device. If the Suppliant to RG applies the PPPoE session, the AN to the IP edge device and the above device apply the IP session, the session relay is between the RG and the AN; if the Suppliant to the AN applies the PPPoE session, the IP edge device to the SP applies the IP session, then the session The trunk is between the AN and the IP edge device.

Referring to FIG. 5B, the session relay in the embodiment of the present invention includes a PPP session interface unit 11, an IP session interface unit 12, and a session conversion unit 13.

The PPP session interface unit 11 is configured to exchange a point-to-point protocol PPPoE session with the PPP session communication peer. When interacting with Suppliant in a PPPoE session, Suppliant is the PPP session communication peer; when interacting with the network side PPPoE session, the network side includes the PPP session communication peer.

The IP session interface unit 12 is configured to exchange an IP session with the IP session communication peer. When interacting with Suppliant IP session, Suppliant is the IP session communication peer; when interacting with the network side IP session, the network side includes the IP session communication peer.

The session conversion unit 13 is configured to send the information that needs to be processed by the IP session communication peer in the PPPoE session to the IP session communication peer in the form of an IP session, and the PPPoE session is used in the IP session to be processed by the PPP session communication peer. The form is sent to the PPP session communication peer.

The session relay includes an authentication relay (AR). The AR is used to perform authentication and conversion on the PPPoE session and the IP session in the session authentication phase. The AR proxy Suppliant can use the IP address of the Suppliant to identify the IP session with the authenticator. (or PPP will Then, the user authentication or the device authentication is finally completed. Generally, the authentication relay is located in the session relay, and the authentication relay is also separated from the session relay. In this embodiment, the authentication relay is located in the session relay as an example.

When the session relay exists in other device entities, the PPP session interface unit 11 and the IP session interface unit 12 are interface units in other device entities.

The conversion process between the PPPoE session and the IP session includes the conversion of the PPPoE session to the IP session and the conversion of the IP session to the PPPoE session. Referring to Figure 6, the main method of PPPoE session to IP session conversion is as follows:

Step 601: The Suppliant initiates a PPPoE session creation process and interacts with the session relay to implement and complete the PPPoE discovery phase, that is, to create a PPPoE session.

Step 602: Implement and complete the link establishment phase, and establish a standard PPP session. Suppliant negotiates with the Session Relay for Link Control Protocol (LCP).

Step 603: The session relay interacts with the IP edge device to enter the IP session creation process. Step 604: Suppliant initiates an address allocation process, and the session relay replaces Suppliant to request the DHCP server to obtain the IP address of the Suppliant through the IP edge device, and the session relay obtains the IP address assigned by the DHCP server through the IP edge device, and allocates the DHCP server. The first IP address is sent to Suppliant. Alternatively, the session relay assigns a second IP address to the Suppliant, the second IP address corresponding to the first IP address assigned by the DHCP server.

Step 605: Enter the data transmission phase. The data in the form of PPPoE is transmitted between the Suppliant and the session relay, and the data in the form of IP over Ethernet (IPoE) is transmitted between the session relay and the IP edge device. Two forms of data are converted by session relay.

Step 606: After the data transmission is completed, the PPPoE session termination phase is entered, and the first is the link termination phase. Suppliant initiates the termination of the PPPoE session and interacts with the session relay to terminate the standard PPP session.

Step 607: Suppliant or Session Relay Send PPPoE Activation Discovery Termination (PPPoE

Active Discovery Terminate (PADT) is used to terminate the PPPoE session.

Step 608: The session relay sends a DHCP release to the DHCP server through the IP edge device. (DHCP Release) message to request the DHCP server to release the IP address of the Suppliant, and the IP session is terminated.

Step 602 and step 603 are two independent operations, and there is no strict sequence.

Several typical examples of the PPPoE session to IP session conversion process are described in detail below.

Referring to Figure 7, the PPPoE session does not include the authentication process and the IP session includes the Option 82 for DHCP authentication. The PPPoE session to IP session conversion method is as follows:

Step 701: The first step of the PPPoE discovery phase, that is, the PPPoE Active Discovery Initiation (PADI), initiates a PPPoE session creation process, and creates a PPPoE session. Suppliant broadcasts PADI messages in a broadcast, where the session identifier (ID) uses the default session ID such as 0x0000. If the session relay is behind the AN, the AN adds the access loop identifier (such as the receiving port number) to the received PADI packet in the form of a TAG (tag) and sends it. If the session relay is located on the AN, the access loop identifier is sent to the session relay by the other module except the session relay in the AN. The session relay obtains the Suppliant MAC address at least in this step.

Step 702: Enter an IP session creation process, including a DHCP authentication and address allocation process. The session relay that receives the PADI packet sends a DHCP Discover message to the IP edge device, or the session relay sends a DHCP Discover message to an IP edge device. The IP edge device sends the DHCP Discover message to the IP edge device. Send DHCP Discover messages to other IP edge devices. The access loop identifier obtained by the session relay is inserted into the DHCP Discover message in the format of Option 82. If the session relay is located after the AN, the access loop identifier is obtained from the PADI TAG. If the session relay is located on the AN, the access loop identifier is obtained from the AN. The session relay sends a DHCP Discover message to the IP edge device by using the obtained Suppliant MAC address.

Step 703: The IP edge device forwards the DHCP Discover message to multiple DHCP servers to select a DHCP server, and the IP edge device performs authentication according to the obtained access loop identifier. After the authentication succeeds, the IP edge device returns a dynamic host configuration protocol (DHCP Offer) message to the session relay, indicating that the authentication succeeds and agrees to perform subsequent operations on address allocation. There are several ways to select an IP edge device and a DHCP server. For example, the first DHCP server that returns a DHCP Offer message is determined to be the object of the subsequent IP session of the IP edge device, and the IP edge of the first DHCP Offer message is returned. The device is determined to be the object of a subsequent IP session for the session relay.

Step 704: Enter the second step of the PPPoE discovery phase, that is, the PPPoE Active Discovery Offer (PADO) phase. The session relay responds to the PADI message sent by Suppliant, that is, sends a PADO message to Suppliant. In the PADO message, the source address in the Ethernet frame is filled with the MAC address of the session relay, and the session ID is still filled with 0x0000.

Step 705: Enter the third step of the PPPoE discovery phase, that is, the PPPoE Active Discovery Request (PADR) phase. After receiving the PADO message, Suppliant receives a PADO message from multiple session relays, and selects a session relay from multiple session relays according to the content of the PADO message or the time sequence of receiving the PADO message. The object of the subsequent session, and sends a unicast request message (that is, the PADR message) to the selected session relay (where the session ID is still 0x0000).

Step 706: Enter the final step of the PPPoE discovery phase, that is, the PPPoE Active Discovery Session-Confirmation (PADS) phase. After receiving the PADR packet, the session relay assigns a unique session process ID (referred to as a specific session ID in this embodiment) to the PPPoE session, and sends a PADS4 message carrying the specific session ID to Suppliant.

Step 707: Enter the link establishment phase, that is, create a standard PPP session. Suppliant and the session relay perform LCP negotiation.

Step 708: Enter the address allocation phase. Suppliant sends a configuration request (Config-Request) message to the session relay, requesting the assignment of an IP address (which can be expressed as IP@).

The Config-Request packet is in the form of (0.0.0.0), indicating that an IP address needs to be configured.

Step 709: The session relay sends a DHCP Request message to the selected DHCP server through the IP edge device, and requests to obtain the first IP address of the Suppliant. Step 710: The DHCP server sends a DHCP Reply (DHCP Ack) message to the session relay through the IP edge device, where the DHCP Ack message carries the first IP address assigned to the Suppliant.

Step 711: The session relay sends a configuration response (Config-Nak) message to the Suppliant, and sends the first IP address assigned by the DHCP server to the Suppliant. Alternatively, the session relay assigns a second IP address to the Suppliant, and the session relay establishes a correspondence between the second IP address and the first IP address assigned by the DHCP server.

The session relay sends a DHCP Request message and the session relay allocates a second IP address to the Suppliant. The two IP addresses are two independent operations, which can be performed simultaneously.

Suppliant and session relay can further perform operations other than address allocation in NCP negotiation, such as negotiation of configuration parameters of user services. Helps reduce user operations.

Step 712: Enter the data transmission phase. The data in the form of PPPoE is transmitted between the Suppliant and the session relay, and the data in the form of IPoE is transmitted between the session relay and the IP edge device, and the data format is converted by the session relay. The session relay only needs to change the datagram according to PPPoE or IPoE. The header and trailer of the text, the payload part does not need to be changed. For example, when you need to convert from PPPoE to IPoE, remove the PPPoE header and trailer from the data packet. For example, when you need to convert from IPoE to PPPoE, add PPPoE header and trailer to the data.

Step 713: The Suppliant and the session relay terminate the request ( Termination-Request) and the Termination-Ack message to terminate the link (ie, terminate the standard PPP session). For example, when the user shuts down, Suppliant sends a Termination-Request message, and the session relay sends a Termination-Ack message. When the user owes a fee, the session relay sends a Termination-Request message, and Suppliant sends the Termination-Ack message.

Step 714: The Termination-Ack message triggers the Suppliant or the session relay to send a PPPoE Active Discovery Terminate (PADT) message to terminate the PPPoE session. That is, the device that receives the Termination-Ack message sends a PADT message.

Step 715: The session relay sends a DHCP Release (DHCP Release) message to the DHCP server through the IP edge device to request to release the IP address of the Suppliant, and terminate the IP session. Among them, step 702 and step 703 must be completed between steps 701 and 709.

Between step 707 and step 708, an authentication phase may be added to perform PAP authentication or CHAP authentication. The PAP authentication is a two-way handshake authentication, and the password is plain text. The PAP authentication process is as follows: The authenticated party sends the username and password to the authenticator, and the authenticator checks to see if the user has the password, and then sends the corresponding response. CHAP authentication is three-way handshake authentication, and the password is ciphertext (key). CHAP authentication is performed by the authenticator to send some randomly generated packets to the authenticated party. The authenticated party encrypts with its own password through the Message-Digest Algorithm 5 (MD5) algorithm and authenticates to the authenticator. Returning the ciphertext; the authenticator encrypts the password and the random message saved by itself with the MD5 algorithm, compares the ciphertext of the two, and returns the corresponding response according to the comparison result. In this embodiment, Suppliant uses any username and password, and session relays default to Suppliant authentication.

This embodiment describes a process of converting a PPPoE session that does not include an authentication process to an IP session that includes DHCP authentication. The process of converting a PPPoE session that does not include the authentication process to an IP session that includes other authentication modes is similar to the process of this embodiment. Refer to the implementation, and will not repeat them here.

For DHCP authentication, the method for converting a PPPoE session to an IP session is shown in Figure 8. The specific process is as follows:

Step 801: The Suppliant interacts with the session relay to perform the PPPoE discovery phase processing process. For details, refer to steps 701, 704, 705, and 706.

Step 802: Enter the link establishment phase, that is, Suppliant and the session relay perform LCP negotiation. Step 803: Enter the IP session creation phase. The session relay that receives the PADI packet sends a DHCP Discover message to the IP edge device and the DHCP server. The authentication option ( auth-proto Option ) carried in the DHCP Discover message indicates that Chap authentication is used.

Step 804: The IP edge device returns a DHCP Offer message to the session relay, in DHCP.

The authentication option of the Offer message carries the Chap Challenge message (Chap-Challenge) authentication information. The first DHCP server and IP edge device that reply to the DHCP Offer message are selected follow-up sessions. Word object.

Step 805: The session relay carries the Chap-Challenge in the received DHCP Offer in the PPP LCP message and sends it to Suppliant.

Step 806: After Suppliant processes the Chap-Challenge, the PPP LCP responds with a Chap response (Chap-Response) to the session relay.

Step 807: The session relay sends a DHCP Request message to the IP edge device, and requests the IP address of the Suppliant from the DHCP server. The authentication option of the DHCP Request message carries the Chap-Response authentication information.

Step 808: The IP edge device authenticates the Suppliant according to the Chap-Response in the received DHCP Request message, and after the authentication succeeds, the DHCP server returns a DHCP response (DHCP Ack) message to the session relay through the IP edge device. The DHCP Reply (DHCP Ack) message carries the first IP address assigned to the Suppliant, and the session relay records the IP address assigned to the Suppliant.

Step 809: The session relay notifies Suppliant through the PPP LCP message, and the Chap authentication succeeds. Step 810: After the authentication is successful, enter the address allocation phase. Sent by Suppliant

The Config-Request packet is sent to the session relay to request the configuration of an IP address.

Step 811: The session relay returns a Config-Nak message to the Suppliant, and carries the first IP address assigned by the recorded DHCP server to the Suppliant. Alternatively, the session relay assigns a second IP address to the Suppliant and carries it in the Config-Nak4 message, the second IP address corresponding to the first IP address assigned by the DHCP server.

Suppliant and session relay can further perform NCP negotiation on user services. Step 812: Enter the data transmission phase. The data in the form of PPPoE is transmitted between the Suppliant and the session relay, and the data in the form of IPoE is transmitted between the session relay and the IP edge device, and the data format is converted by the session relay. The session relay only needs to change the datagram according to PPPoE or IPoE. The head and tail of the text, the payload part does not need to be changed. The session relay converts the second IP address in the data from the Suppliant to the corresponding first IP address, sends the IP address to the IP edge device, and converts the first IP address in the data packet from the IP edge device. For the corresponding number The second IP address is sent to Suppliant.

Step 813: Suppliant and Session Relay Interrupt Request ( Termination-Request) and Termination-Ack messages are terminated to terminate the standard PPP session.

Step 814: When the standard PPP session is terminated, the Termination-Ack message triggers the Suppliant or the session relay to send a PADT message to terminate the PPPoE session.

Step 815: The session relay sends a DHCP Release (DHCP Release) message to the DHCP server through the IP edge device to request to release the IP address of the Suppliant, and terminate the IP session.

Wherein step 803 occurs after the beginning of step 801 and step 805 occurs after step 802.

Referring to FIG. 9A, the PPPoE session includes an authentication process and the IP session includes EAP authentication.

The process of converting a PPPoE session to an IP session is as follows:

Step 900 A: Suppliant interacts with the session relay to perform the PPPoE discovery phase.

Step 900B: Enter the link establishment phase, that is, Suppliant and session relay perform LCP negotiation.

Step 900C: Enter the EAP authentication startup phase. The session relay interacts with the IP edge device based on the obtained Suppliant's MAC address to complete the EAP authentication.

Step 900D: Enter the authentication phase of the PPPoE session and the EAP authentication phase of the IP session.

Suppliant interacts with the IP edge device through session relay, which will come from the session relay

The PPP-based packet of Suppliant is converted into an IP-based packet and sent to the IP edge device, and the IP-based packet from the IP edge device is converted into a PPP-based packet and sent to the packet.

Suppliant, the IP edge device authenticates Suppliant based on received messages and locally saved information.

Step 900E: After the authentication succeeds, enter the address allocation phase of the PPPoE session and the DHCP address allocation phase of the IP session. Suppliant interacts with the DHCP server through the session relay and the IP edge device. The DHCP server assigns an IP address to the Suppliant and sends it to the session relay. The session relay sends the first IP address assigned by the DHCP server to the Suppliant. Alternatively, the session relay assigns a second IP address to the Suppliant, the second IP address and DHCP. The first IP address assigned by the server - corresponding.

Step 900F: Enter the data transmission phase. The data packet in the form of a PPPoE session is transmitted between the Suppliant and the session relay, and the data packet in the form of an IPoE session is transmitted between the session relay and the IP edge device. The session relay converts the data packet form, and the session relay only The header and trailer of the data message need to be changed according to PPPoE or IPoE. The payload part does not need to be changed.

Step 900G: Enter the link termination phase. Suppliant interacts with the session relay to terminate the standard PPP session.

Step 900H: Enter the PPPoE session termination phase. The Suppliant or Session Relay sends a PADT message to terminate the PPPoE session.

Step 9001: Enter the IP session termination phase. The session relay interacts with the DHCP server through the IP edge device to terminate the IP session.

The following is a detailed description of several session conversion procedures for common authentication methods for PPPoE sessions and IP sessions.

Referring to FIG. 9B, when the PPPoE session includes the CHAP authentication and the IP session includes the EAP authentication carried on the PAN A, the process of converting the PPPoE session to the IP session is as follows:

Step 901: The Suppliant interacts with the session relay to perform the PPPoE discovery phase. For the specific process, refer to steps 701, 704, 705, and 706.

Step 902: Enter the link establishment phase, that is, the Suppliant and the session relay perform LCP negotiation. Step 903: Enter the EAP authentication startup phase. The session relay sends a PANA Client Initiation message (PANA-Client-Initiation) to the IP edge device to select a PAN Authentication Agent (PAA) that provides the authentication and authorization service, and indicates that the EAP carried on the PAN A is adopted. Authentication, where the PAA is located on the IP edge device.

Step 904: The selected PAA interacts with the session relay to complete the EAP authentication startup phase. The specific operations include: The PAA sends a PANA-Auth-Request message to the session relay, indicating that the local authentication service can be provided, and sends the locally used local part to the session relay through the PANA-Auth-Request message. IP address; session relay sends PANA authentication reply (PANA- Auth- Answer) PAA. Among them, the S position is 1.

Step 905: Enter the EAP authentication phase. The PAA sends an EAP-Request/Identity message to the session relay to inform the EAP identity. The EAP-Request/Identity message is sent by the PANA-Auth-Request packet.

Step 906: Session Relaying Suppliant Media Access Control (Media Access

Control, MAC) address is bound to EAP Identity. Since one session uses EAP authentication and the other session does not use EAP authentication, the MAC address needs to be bound to EAP Identity. Among them, the session relay has obtained the Suppliant's MAC address when establishing the initial connection with Suppliant.

Step 907: The bearer sends an EAP identity reply to the PAA in the session.

( EAP -Response/Identity ) is the PAN A- Auth- Answer of the text.

Step 908: The PAA sends a PANA-Auth-Request message carrying the EAP MD5 Challenge Request (EAP-Request/MD5 Challenge) to the session relay.

Step 909: The session relay converts the EAP-Request/MD5 Challenge into a Chap-Challenge, and converts the PANA-Auth-Request packet into a PPP LCP packet, and sends the PPP LCP carrying the Chap-Challenge to the message. Suppliant.

Step 910: After Suppliant processes the Chap-Challenge, the PPP LCP replies to Chap-Response to relay the session.

Step 911: The session relay converts the Chap-Response into an EAP-MD5 challenge response (EAP-Response/MD5 Challenge), and converts the PPP LCP message into a PANA-Auth-Answer message, and carries the EAP-Response/MD5 The PANA-Auth-Answer message from Challenge is sent to the PAA.

Step 912: The PAA authenticates the Suppliant according to the received PANA-Auth-Answer message, and after the authentication succeeds, the EAP success is successfully replied to the session relay (the EAP derivative key may be further replied). The reply information is carried in the PANA-Auth-Request 4 message and sent to the session relay. The session relay sends a PANA-Auth-Answer message in response to the PAA. Where the C position is 1, indicating the authentication knot Bunch.

Step 913: The session relay notifies Suppliant through the PPP LCP message, and the Chap authentication succeeds. Step 914: Enter the address allocation phase. Suppliant sends a Config-Request message to the session relay, requesting the configuration of an IP address.

Step 915: The session relay initiates a standard DHCP process, and interacts with the DHCP server to obtain an IP address assigned by the DHCP server to the Suppliant. For details, see Step 803.

804, 807 and 808.

Step 916: The session relay returns a Config-Nak message to Suppliant, and carries the IP address assigned by the recorded DHCP server to Suppliant. Alternatively, the session relay assigns a second IP address to the Suppliant and carries it in the Config-Nak4 message, the second IP address corresponding to the IP address assigned by the DHCP server.

Suppliant and Session Relay can further make an NCP negotiation process for service configuration.

Step 917: Enter the data transfer phase. The data packet in the form of a PPPoE session is transmitted between the Suppliant and the session relay, and the data packet in the form of an IPoE session is transmitted between the session relay and the IP edge device. The session relay converts the data packet form, and the session relay only The header and trailer of the data message need to be changed according to PPPoE or IPoE. The payload part does not need to be changed.

Step 918: Suppliant interacts with the session relay Termination-Request and Termination-Ack to terminate the standard PPP session.

Step 919: When the standard PPP session is terminated, the Termination-Ack message triggers the Suppliant or the session relay to send the PADT4 message to terminate the PPPoE session.

Step 920: In the session, the PANA-Termination-Request (PANA-Termination-Request) message is sent to the PAA, and the PAA returns a PANA-Termination-Answer message to terminate the PAN A session.

Step 921: The session relay sends DHCP to the DHCP server through the IP edge device.

Release will request the release of Suppliant's IP address.

Step 906 and step 907 are two independent operations, and there is no strict execution sequence. The foregoing three embodiments describe that the process of converting a PPPoE session including a Chap authentication to a PPPoE session including a DHCP authentication to an IP session including other authentication modes is similar to the process of the foregoing three embodiments, and may be referred to for execution, and details are not described herein again. .

The difference between the PAP authentication and the Chap authentication is that the PAP authentication is a two-way handshake authentication, and the Chap authentication is a three-way handshake authentication, including a PAP-authenticated PPPoE session to a IP session including various authentications, and a PPPoE session including Chap authentication. The conversion process of the authenticated IP session is similar, and can be referred to for execution, and details are not described herein again.

Referring to FIG. 10, when the PPPoE session includes the EAP authentication and the IP session includes the EAP authentication carried on the PAN A, the PPPoE session to the IP session conversion method is as follows:

Step 1001: The Suppliant interacts with the session relay to perform the PPPoE discovery phase. For details, refer to steps 701, 704, 705, and 706.

Step 1002: Enter the link establishment phase, that is, Suppliant and session relay perform LCP negotiation.

Step 1003: Enter the authentication phase. Session relay sends to IP edge device

The PAN A-Client-Initiation message is used to select the PA A that provides the authentication and authorization service. The PAA is located on the IP edge device.

Step 1004: The selected PAA interacts with the session relay to enter the EAP authentication startup phase. The specific operations include: The PAA sends a PANA-Auth-Request packet to the session relay, indicating that the local authentication and authorization service can be provided, and the locally used local IP address is sent to the session relay through the PANA-Auth-Request packet; Send P ANA- Auth- Answer to respond to P AA.

Step 1005: The PAA sends an EAP Identity Request (EAP-Request/Identity) to the session relay to notify the EAP Identity, and the EAP-Request/Identity text is carried on the PANA-Auth-Request packet.

Step 1006: The session relay converts the PAN A-Auth-Request packet into a PPP LCP packet, and sends the PPP LCP packet carrying the EAP-Request/Identity to the Suppliant. Step 1007: Suppliant sends a PPP LCP carrying EAP-Response/Identity to the session relay.

Step 1008: The session relay converts the PPP LCP message into a PANA-Auth-Answer message, and sends the PANA-Auth-Answer message carrying the EAP-Response/Identity to the PAA.

Step 1009: Perform an EAP Method negotiation and an authentication method interaction process. The specific process includes: The PPP LCP is used to carry the EAP interaction between the Suppliant and the session relay. The PANA packet is used to carry the EAP interaction between the session relay and the PAA until the EAP authentication process ends. When both the PPP session and the IP session adopt the EAP authentication mode, there are multiple authentication methods, such as authentication through the MD5 algorithm.

Step 1010: The PAA authenticates the Suppliant according to the received PAN A-Auth- Answer message, and when the authentication succeeds, returns the EAP success (EAP success) and the corresponding EAP derived key to the session relay. The bearer is sent to the session relay in the PANA-Auth-Request message. The session relay sends a PANA-Auth-Answer message in response to the PAA.

Step 1011: The session relay encapsulates the EAP authentication (EAP success) in the PPP.

The LCP message is sent to Suppliant.

Step 1012: Enter the address allocation phase. Suppliant sends a Config-Request message to the session relay, requesting the configuration of an IP address.

Step 1013: The session relay initiates a standard DHCP process, and interacts with the DHCP server to obtain an IP address assigned by the DHCP server to the Suppliant. For details, refer to steps 803, 804, 807, and 808.

Step 1012 and step 1013 are two independent processes, and there is no strict execution sequence. Step 1014: The session relay returns a Config-Nak message to Suppliant, and carries the IP address assigned by the recorded DHCP server to Suppliant. Alternatively, the session relay assigns a second IP address to the Suppliant, which corresponds to the IP address assigned by the DHCP server.

Suppliant and session relay can further perform NCP negotiation on user services. Step 1015: Enter the data transmission phase. The data packet in the form of a PPPoE session is transmitted between the Suppliant and the session relay, and the data packet in the form of an IPoE session is transmitted between the session relay and the IP edge device. The session relay converts the data packet form, and the session relay only The header and trailer of the data message need to be changed according to PPPoE or IPoE. The payload part does not need to be changed.

Step 1016: Suppliant interacts with the session relay Termination-Re quest

Termination-Ack is used to terminate the standard PPP session.

Step 1017: When the standard PPP session is terminated, the Termination-Ack triggers the Suppliant or the session relay to send the PADT packet to terminate the PPPoE session.

Step 1018: The session relay sends a PANA-Termination-Request message to the PAA, and the PAA returns a PANA-Termination-Answer message to complete the termination of the PAN A session.

Step 1019: The session relay sends a DHCP Release message to the DHCP server through the IP edge device to request to release the IP address of the Suppliant.

During DHCP authentication, the process of converting a PPPoE session to an IP session is as follows:

Step 1101: The Suppliant interacts with the session relay to perform the PPPoE discovery phase. For details, refer to steps 701, 704, 705, and 706.

Step 1102: Enter the link establishment phase, that is, Suppliant and the session relay perform LCP negotiation.

Step 1103: The session relay sends a DHCP Discover message to the DHCP authenticator (located on the IP edge device) and the DHCP server to select a DHCP authenticator and a DHCP server that provide the authentication and authorization service, and indicates the session relay support through the authentication option. Authentication mode. Among them, the session relay interacts with the DHCP authenticator through the obtained Suppliant MAC address.

Step 1104: The DHCP server returns a DHCP Offer message. After receiving the DHCP Offer message, the DHCP Authenticator adds the authentication option to indicate the locally supported authentication mode, records the untenant IP address provided by the DHCP server for the session relay, and replaces it with a local part for Suppliant. The IP address is then forwarded to the session to forward the DHCP Offer message carrying the local IP address. Step 1105: The session relay sends a DHCP Request message to respond to the DHCP Offeror's DHCP Offer, which includes the authentication mode supported by the DHCP authenticator and the IP address provided by the DHCP authenticator, indicating that the DHCP authenticator that can support the corresponding authentication mode has been selected. And accepted the IP address provided by the DHCP Authenticator.

Step 1106: After receiving the DHCP Request message, the DHCP Authenticator sends a DHCP Ack message carrying the EAP-Request/Identity 4 message to the session relay.

Step 1107: The session relay converts the DHCP packet into a PPP LCP packet, and sends the PPP LCP packet carrying the EAP-Request/Identity to the Suppliant.

Step 1108: Suppliant sends a PPP LCP carrying EAP-Response/Identit to the session relay.

Step 1109: The session relay converts the PPP LCP packet into a DHCP Request message, and sends the DHCP Request message carrying the EAP-Response/Identity to the DHCP authenticator.

Step 1110: Perform EAP Method negotiation and the process of authenticating the method. The specific process includes: The PPP LCP packet is used to carry the EAP between the Suppliant and the session relay. The session relay and the DHCP Authenticator use the DHCP packet to carry the EAP to communicate with each other until the EAP authentication process ends.

Step 1111: The DHCP authenticator authenticates the Suppliant according to the received DHCP Request message, and when the authentication succeeds, replies to the session relay with EAP success (or EAP success and corresponding EAP derived key), and carries it in DHCP. In the Ack message, and carrying the DHCP server in the DHCP Ack4 message, the first IP address is assigned to the Suppliant and sent to the session relay.

Step 1112: The session relay encapsulates the EAP success packet in the PPP LCP packet and sends it to the Suppliant.

Step 1113: Enter the address allocation phase. Suppliant sends a Config-Request message to the session relay, requesting the configuration of an IP address.

Step 1114: The session relay returns a Config-Nak message to the Suppliant, which will be recorded. The IP address assigned by the DHCP server is carried to Suppliant. Alternatively, the session relay assigns a second IP address to the Suppliant, the second IP address corresponding to the IP address assigned by the DHCP server.

Suppliant and Session Relay can further perform NCP negotiation on user services. Step 1115: Enter the data transmission phase. The data in the form of a PPPoE session is transmitted between the Suppliant and the session relay, and the data message in the form of an IPoE session is transmitted between the session relay and the DHCP authenticator, and the data relay is converted by the session relay, and the session is relayed. Simply change the header and trailer of the data message according to PPPoE or IPoE. The payload does not need to be changed.

Step 1116: Suppliant interacts with the session relay Termination-Request and Termination-Ack to terminate the standard PPP session.

Step 1117: When the standard PPP session is terminated, the Termination-Ack triggers the Suppliant or the session relay to send the PADT packet to terminate the PPPoE session.

The Release message terminates the IP session by requesting to release the IP address of Suppliant.

The above two embodiments describe a PPPoE session including EAP authentication to include

PANA's EAP-authenticated IP session conversion process, and the conversion process from PPPoE session including EAP authentication to IP session including DHCP authentication supporting EAP authentication, including EAP-authenticated PPPoE session to IP session including other authentication methods The conversion process is similar to the process of the above two embodiments, and can be referred to for execution, and details are not described herein again.

The above embodiment describes the process of converting a PPPoE session to an IP session. Correspondingly, the conversion process of the IP session to the PPPoE session is shown in Figure 12. The main method flow is as follows:

Step 1201: Suppliant initiates an IP session creation process, and initiates an IP session authentication and address allocation process.

Step 1202: The session relay initiates a PPPoE session creation process, and interacts with the IP edge device according to the obtained Suppliant MAC address to implement and complete the PPPoE discovery phase, that is, create a PPPoE session.

Step 1203: Enter a link establishment phase of the PPPoE session, and create a standard PPP session. That is, the session relay and the IP edge device perform LCP negotiation.

Step 1204: The session relay responds to the initiation operation of Suppliant to complete the authentication process of the IP session.

Step 1205: Enter the address allocation phase. Suppliant initiates the address allocation process, in which the session relay replaces Suppliant to request the IP edge device (or DHCP server) to obtain the Suppliant IP address. The session relay sends the first IP address assigned by the IP edge device (or DHCP server) to Suppliant. Alternatively, the session relay assigns a second IP address to the Suppliant, the second IP address corresponding to the first IP address assigned by the IP edge device (or DHCP server).

Step 1206: Enter the data transfer phase. The data packet in the form of an IPoE session is transmitted between the Suppliant and the session relay, and the data packet in the form of a PPPoE session is transmitted between the session relay and the IP edge device.

Step 1207: After the data transmission is completed, Suppliant sends a DHCP Release message to the session relay to request to release the local IP address, and the IP session is terminated. Among them, Suppliant determines the session relay as a DHCP server.

Step 1208: Enter a link termination phase of the PPP session. The session relay interacts with the IP edge device to terminate the standard PPP session.

Step 1209: The IP edge device or the session relay sends a PADT packet to terminate the PPPoE session.

Step 1202 and step 1203 are two independent operations, and there is no strict sequence.

Several typical examples of the conversion process from IP session to PPPoE session are described in detail below.

Referring to Figure 13, the PPPoE session does not include the authentication process and the IP session includes the Option 82 for DHCP authentication. The process of converting the IP session to the PPPoE session is as follows:

Step 1301: Suppliant sends a DHCP Discover message to the session relay to start

DHCP authentication and address allocation process. If the session relay is located after the AN, the AN adds the access loop identifier (such as the receiving port number) to the received PADI packet in the form of TAG, and concurrently give away. If the session relay is located on the AN, the access loop identifier is sent to the session relay by the other module except the session relay in the AN.

Step 1302: The DHCP Discover message triggers the session relay to broadcast the PADI message (the session ID is 0x0000). The access loop identifier of the IP session establishment process packet obtained by the session relay is inserted into the PADI packet in the format of the TAG. If the session relay is located after the AN, the access loop identifier is obtained from Option 82. If the session relay is located on the AN, the access loop identifier is obtained from the AN.

Step 1303: The IP edge device checks the legality of the Suppliant according to the access loop identifier in the received PADI packet. After the validity check is performed, the IP edge device sends a PADO packet to the session relay, and the PADO packet is Ethernet. The source address in the net frame is filled with the MAC address of the IP edge device.

Step 1304: After receiving the PAD04 message, the session relay receives a PADO message from multiple IP edge devices, and selects one of the multiple IP edge devices according to the content of the PADO message or the order of receiving the PADO message. The IP edge device is the object of the subsequent session and sends a unicast P ADR message to the selected IP edge device (where the session ID is still 0x0000).

Step 1305: The IP edge device allocates a unique session process ID (that is, a specific session ID) to the PPPoE session, and carries a specific session ID in the PADS4 message replied to the session relay.

Step 1306: The session relay sends a DHCP Offe message to Suppliant, and replaces the address of the DHCP server with the IP address of the node where the session relay is located in the DHCP Offer message.

Step 1307: Enter the link establishment phase, that is, the session relay and the IP edge device perform LCP negotiation.

Step 1308: Suppliant sends a DHCP Request message to the session relay to request an IP address.

Step 1309: The session relay sends a Config-Request message to the IP edge device to request an IP address for the Suppliant.

Step 1310: The IP edge device returns a Config-Nak packet to the session relay, and carries the first IP address allocated by the PPP process. The session relay and IP edge device can further perform NCP negotiation on user services. Step 1311: The session relay returns a DHCP Ack message carrying the first IP address assigned to the Suppliant to the Suppliant. Alternatively, the session relay assigns a second IP address to the Suppliant and carries it in the DHCP Ack4 message, the second IP address corresponding to the IP address assigned by the PPP process.

Step 1312: After the authentication and address assignment are successful, the data transmission phase is entered. The data packet in the form of an IPoE session is transmitted between the Suppliant and the session relay, and the data packet in the form of a PPPoE session is transmitted between the session relay and the IP edge device. The session relay performs the conversion between the data packet in the form of the IPoE session and the data packet in the PPPoE session format. The session relay only needs to change the header and the tail of the data packet according to the PPP or the IP, and the payload portion does not need to be changed.

Step 1313: When the data transmission phase needs to be ended, Suppliant sends a DHCP Release message to the session relay to request the release of the Suppliant IP address.

Step 1314: The session relay and the IP edge device exchange Termination-Request messages and Termination-Ack messages to terminate the standard PPP session.

Step 1315: When the standard PPP session is terminated, the Termination-Ack message triggers the IP edge device or the session relay to send the PADT4 message to terminate the PPPoE session.

In step 1307 and step 1308, a PPP authentication phase between the session relay and the IP edge device may be performed. The session relay uses the legal user name and password set in advance on the session relay to obtain the authentication success through the IP edge device. .

Wherein step 1306 occurs after step 1301 and ends before step 1309. The process of converting the IP session to the PPPoE session is as follows:

Step 1401: Suppliant sends a DHCP Discover message to the session relay to start

DHCP authentication and address allocation process. The authentication option ( auth-proto Option ) carried in the DHCP Discover message indicates that Chap authentication is used.

Step 1402: The session relay and the IP edge device perform the interaction in the PPPoE discovery phase. For the specific process, refer to step 1302 - step 1305. Step 1403: Entering the link establishment phase, the session relay and the IP edge device perform LCP negotiation.

Step 1404: The IP edge device sends a PPP LCP packet carrying the Chap-Challenge authentication information to the session relay.

Step 1405: The session relay obtains Chap-Challenge from the PPP LCP message, and

The Chap-Challenge is sent to Suppliant in a DHCP Offer message.

Step 1406: Suppliant sends a DHCP Request message carrying the Chap-Response through the authentication option to the session relay to request the local IP address from the session relay.

Step 1407: The session relay obtains Chap-Response from the DHCP Request, and

The Chap-Response is sent to the IP edge device in the PPP LCP packet.

Step 1408: The IP edge device authenticates the Suppliant according to the PPP LCP4 text, and when the authentication succeeds, the PPP LCP packet is sent to notify the session relay, and the Chap authentication succeeds.

Step 1409: The session relay sends a Config-Request message to the IP edge device to request an IP address for the Suppliant.

Step 1410: The IP edge device returns a Config-Nak packet to the session relay, and carries the first IP address allocated by the PPP process, and the session relay relays the first IP address allocated by the PPP process to the Suppliant. Alternatively, the session relay assigns a second IP address to the Suppliant, the second IP address corresponding to the first IP address assigned by the PPP process.

Session relay and IP edge devices can further perform NCP negotiation on user services. Step 1411: The session relay returns a DHCP Ack message to the Suppliant, which carries the IP address assigned to the Suppliant, indicating that the Chap authentication succeeds.

Step 1412: After the authentication and address assignment are successful, the data transmission phase is entered. The data packet in the form of an IPoE session is transmitted between the Suppliant and the session relay, and the data in the form of a PPPoE session is transmitted between the session relay and the IP edge device. The session relay performs the conversion between the data in the form of IPoE session and the data in the form of PPPoE. The session relay only needs to change the header and the tail of the data according to PPP or IP, and the payload portion does not need to be Variety. Step 1413: When the data transmission phase needs to be ended, Suppliant sends a DHCP Release message to the session relay to request to release the IP address of the Suppliant.

Step 1414: The session relay and the IP edge device exchange the Termination-Request message and the Termination-Ack message to terminate the standard PPP session.

Step 1415: When the standard PPP session is terminated, the Termination-Ack message triggers the IP edge device or the session relay to send the PADT4 message to terminate the PPPoE session.

The above two embodiments describe a conversion process from an IP session including DHCP authentication to a PPPoE session not including an authentication process, and a conversion process describing an IP session including DHCP authentication to a PPPoE session including a Chap authentication process, including DHCP authentication. The process of converting the IP session to the PPPoE session including the other authentication process is similar to the process of the foregoing two embodiments, and may be referred to for execution, and details are not described herein again.

Referring to Figure 15A, the PPPoE session includes the authentication process and the IP session includes EAP authentication. The process of converting the IP session to the PPPoE session is as follows:

Step 1500 A: Enter the EAP authentication startup phase. Suppliant initiates the creation of an IP session and initiates the authentication and address assignment process for the IP session.

Step 1500B: Enter the PPPoE discovery phase, that is, create a PPPoE session and a PPPoE session. The session relay initiates the PPPoE session creation process, and interacts with the IP edge device according to the obtained Suppliant MAC address to implement and complete the PPPoE discovery phase.

Step 1500C: Enter the link establishment phase of the PPPoE session, that is, the session relay and the IP edge device perform LCP negotiation.

Step 1500D: Enter the authentication phase of the PPPoE session and the EAP authentication phase of the IP session. Suppliant interacts with IP edge devices through session relays, which converts IP-based packets from Suppliant into PPP-based messages and sends them to IP edge devices, as well as PPP-based packets from IP edge devices. The text is converted to an IP-based message and sent to Suppliant, which authenticates the Suppliant by the IP edge device based on the received message and the locally saved information.

Step 1500E: After the authentication is successful, enter the address allocation phase. Suppliant In the address allocation process, the session relay replaces the Suppliant to request the IP edge device (or DHCP server) to obtain the IP address of the Suppliant. The session relay sends the first IP address assigned by the IP edge device (or DHCP server) to the Suppliant. Alternatively, the session relay assigns a second IP address to the Suppliant, the second IP address corresponding to the IP address assigned by the IP edge device (or DHCP server).

Step 1500F: Enter the data transmission phase. The data packet in the form of an IPoE session is transmitted between the Suppliant and the session relay, and the data packet in the form of a PPPoE session is transmitted between the session relay and the IP edge device.

Step 1500G: After the data transmission is completed, Suppliant sends a DHCP Release message to the session relay to request to release the local IP address, and the IP session is terminated.

Step 1500H: Enter the link termination phase. The session relay interacts with the IP edge device to terminate the PPPoE session.

Step 15001: The IP edge device or session relay sends a PADT4 message to terminate the PPPoE session.

Referring to FIG. 15B, when the PPPoE session includes the CHAP authentication and the IP session includes the EAP authentication carried on the EAPoL, the process of converting the IP session to the PPPoE session is as follows:

Step 1501: Suppliant sends an EAPoL start (EAPoL-St session relay t) message to the session relay to start EAP authentication. The EAPoL-St session relay t message indicates that the EAP authentication carried on the EAPoL is adopted.

Step 1502: The session relay and the IP edge device perform the PPPoE discovery phase interaction. For the specific process, refer to step 1302 - step 1305.

Step 1503: Enter the link establishment phase, and the session relay and the IP edge device perform LCP negotiation.

Step 1504: Enter the authentication phase. The IP edge device sends the PPP LCP4 message carrying the Chap-Challenge authentication information to the session relay. Step 1505: The session relay sends an EAP Request/Identity message to the Suppliant, and the Suppliant returns an EAP-Response/Identity message, where the EAP Request/Identity message and the EAP-Response/Identity message are both carried in the EAPol. On the text.

Step 1506: The session relay binds the PPPoE session ID to the EAP Identity.

Step 1507: Session Relay converts Chap-Challenge to EAP-Request/MD5

Challenge, and convert the PPP LCP essay into EAPoL essay, and send the EAPol essay containing EAP-Request/MD5 Challenge to Suppliant.

Step 1508: Suppliant returns the processed EAP-Response/MD5 Challenge to the session relay through the EAPoL 4 message.

Step 1509: Session Relay converts the EAP-Response/MD5 Challenge to

Chap-Response, and convert the EAPoL packet into a PPP LCP packet, and send the PPP LCP4 packet carrying the Chap-Response to the IP edge device.

Step 1510: The IP edge device performs authentication according to the received PPP LCP packet, and when the authentication succeeds, the PPP LCP packet is used to notify the session relay, and the Chap authentication succeeds.

Step 1511: The session relay generates an EAP success and sends the EAP success to the Suppliant via the EAPoL message.

Step 1512: Enter the address allocation phase. Suppliant sends a DHCP Discover message to the session relay to initiate the DHCP address allocation process.

Step 1513: The DHCP Discover message triggers the session relay to send a Config-Request message to the IP edge device to request an IP address.

Step 1514: The session relay returns a DHCP Offer message to the Suppliant in response to the DHCP Discover message.

The session relay sends a Config-Request message and the session relay returns a DHCP Offer message to Suppliant, which is two independent operations, which can be performed simultaneously.

Step 1515: Suppliant sends a DHCP Request message to the session relay to request an IP address.

Step 1516: The IP edge device returns a Config-Nak packet to the session relay, and the PPP process is performed. The assigned first IP address is brought to the session relay.

Step 1517: The session relay sends the IP address assigned by the PPP process to the Suppliant through the DHCP ACK message. Alternatively, the session relay assigns a second IP address to the Suppliant and carries it in the DHCP ACK4 message, the second IP address corresponding to the IP address assigned by the PPP process.

IP edge devices and session relays can further make NCP negotiation for services. Step 1518: After the authentication and address assignment are successful, the data transmission phase is entered. The data packet in the form of an IPoE session is transmitted between the Suppliant and the session relay, and the data packet in the form of a PPPoE session is transmitted between the session relay and the IP edge device. The session relay performs the conversion between the data packet in the form of the IPoE session and the data packet in the PPPoE session format. The session relay only needs to change the header and the tail of the data according to the PPP or the IP, and the payload portion does not need to be changed. .

Step 1519: When the data transmission phase needs to be ended, Suppliant sends a DHCP Release message to the session relay to request the release of the Suppliant IP address.

Step 1520: The session relay and the IP edge device exchange Termination-Request packets and Termination-Ack messages to terminate the standard PPP session.

Step 1521: When the standard PPP session is terminated, the Termination-Ack message triggers the IP edge device or the session relay to send the PADT4 message to terminate the PPPoE session.

Referring to Figure 16, when the PPPoE session includes the EAP authentication and the IP session includes the EAP authentication carried on the EAPoL, the process of converting the IP session to the PPPoE session is as follows:

Step 1601: Suppliant sends an EAPoL-St session relay t message to the session relay to start EAP authentication.

Step 1602: The session relay and the IP edge device perform the PPPoE discovery phase interaction. For the specific process, refer to step 1302 - step 1305.

Step 1603: Enter the link establishment phase, and the session relay and the IP edge device perform LCP negotiation.

Step 1604: Enter the authentication phase. The IP edge device sends the PPP LCP carrying the EAP-Request/Identity to the session relay. Step 1605: The session relay converts the PPP LCP packet into an EAPoL packet, and carries the EAP-Request/Identity in the EAPoL packet and sends it to the Suppliant.

Step 1606: Suppliant sends an EAPol message carrying EAP-Response/Identity to the session relay.

Step 1607: The session relay converts the EAPoL packet into a PPP LCP packet, and in the PPP

The LCP carries the EAP-Response/Identity and sends it to the IP edge device.

Step 1608: Perform EAP Method negotiation and the process of authentication method exchange. The method includes: Between the Suppliant and the session relay, the EAPoL packet is used to carry the EAP, and the PPP LCP packet is used to carry the EAP interaction between the session relay and the IP edge device until the EAP authentication process ends.

Step 1609: The IP edge device performs authentication according to the received PPP LCP packet, and when the authentication succeeds, the EAP success is encapsulated in the PPP LCP packet and sent to the session relay, and the session relay authentication is notified.

Step 1610: The session relay converts the PPP LCP packet into an EAPoL packet, and sends the EAP success to the Suppliant in the 802. lx message.

Step 1611: Enter the address allocation phase. Suppliant sends a DHCP Discover message to the session relay to initiate the DHCP address allocation process.

Step 1612: The DHCP Discover message triggers the session relay to send a Config-Request message to the IP edge device to request an IP address.

Step 1613: The session relay returns a DHCP Offer message to Suppliant in response to DHCP.

Discover message.

Step 1614: Suppliant sends a DHCP Request message to the session relay to request an IP address.

Step 1615: The IP edge device returns a Config-Nak packet to the session relay, and brings the IP address assigned by the PPP process to the session relay.

Step 1616: The session relay sends the IP address assigned by the PPP process to the Suppliant through the DHCP ACK message. Or, the session relay assigns a second IP address to the Suppliant and carries In the DHCP ACK4 message, the second IP address corresponds to the IP address assigned by the PPP process.

The IP edge device and the session relay can further perform other operations of NCP negotiation.

Step 1617: After the authentication and address assignment are successful, the data transmission phase is entered. The data packet in the form of an IPoE session is transmitted between the Suppliant and the session relay, and the data packet in the form of a PPPoE session is transmitted between the session relay and the IP edge device. The session relay performs the conversion between the data packet in the form of the IPoE session and the data packet in the PPPoE session format. The session relay only needs to change the header and the tail of the data according to the PPP or the IP, and the payload portion does not need to be changed. .

Step 1618: When the data transmission phase needs to be ended, Suppliant sends a DHCP Release message to the session relay to request the release of the Suppliant IP address.

Step 1619: The session relay and the IP edge device exchange the Termination-Request message and the Termination-Ack message to terminate the standard PPP session.

Step 1620: When the standard PPP session is terminated, the Termination-Ack message triggers the IP edge device or the session relay to send a PADT4 message to terminate the PPPoE session.

The above two embodiments describe a conversion process including an EAP-authenticated IP session carried on the EAPoL to a PPPoE session including a Chap authentication process, and an IP session including EAP authentication carried on the EAPoL to include an EAP authentication process. The conversion process of the PPPoE session, including the EAP-authenticated IP session to the PPPoE session, is similar to the process of the foregoing two embodiments, and can be referred to for execution.

The above embodiment describes the conversion process between the PPPoE session and the IP session. The conversion process between the PPPoA session and the IP session can be referred to for execution, and details are not described herein again. It is an authentication conversion, which enables data transmission between the UE and the network side that apply different protocols, and the UE does not interrupt the service during the roaming process of the network using different protocols, which can enhance the user experience. Moreover, the embodiment of the present invention clearly describes a PPP session including four authentication modes and a conversion method of an IP session including five authentication modes, so that PPP sessions and IP sessions in various situations can be mutually converted, and data is maintained. transmission. Through the description of the above embodiments, those skilled in the art can clearly understand that the present invention can be implemented by hardware, or can be implemented by means of software plus necessary general hardware platform, and the technical solution of the present invention. It can be embodied in the form of a software product that can be stored in a non-volatile storage medium (may be

A CD-ROM, a USB flash drive, a removable hard disk, etc., includes instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform the methods described in various embodiments of the present invention.

In summary, the above description is only the preferred embodiment of the present invention and is not intended to limit the scope of the present invention. Any modifications, equivalents, improvements, etc. made within the spirit and scope of the present invention are intended to be included within the scope of the present invention.

Claims

Rights request

A communication system session connection method, characterized in that the method is used for establishing a session connection of a PPP session communication peer to an Internet Protocol IP session communication peer, the method comprising the following steps:

The information that needs to be processed by the IP session communication peer in the PPP session is forwarded to the IP session communication peer in the form of an IP session, and the information that needs to be processed by the PPP session communication peer in the IP session is forwarded to the PPP session communication pair in the form of a PPP session. end.

2. The method of claim 1 wherein:

The session communication between the peers and the peers of the PPP session includes the PPP session authentication phase in the PPP session creation process. The PPP session authentication phase includes the password authentication protocol PAP authentication mode, the challenge handshake protocol Chap authentication mode, or the scalable authentication protocol EAP authentication mode. ; and / or

Session communication with the IP session communication peer includes IP session during IP session creation

3. The method of claim 2, wherein in the IP session authentication phase,

The DHCP authentication mode includes the DHCP authentication mode using the 82 option.

DHCP authentication mode in PAP/Chap mode;

The EAP authentication mode includes an EAP mode DHCP authentication mode, an EAP authentication mode carried on the PANA, or an EAP authentication mode carried on the local area network;

The conversion method according to claim 3, wherein in the DHCP authentication mode, the authentication mode supported by the DHCP authentication option in the Discover message is detected by the peer of the IP session communication; When the DHCP Discover message does not include the authentication option, it indicates that the DHCP authentication mode is adopted. If the DHCP Discover message includes the authentication option and the authentication option is Chap or PAP mode, it indicates that the DHCP authentication mode is in Chap mode or PAP mode. When the DHCP Discover message includes the authentication option and the authentication option is EAP mode, it indicates that the DHCP authentication mode is adopted in EAP mode.

The conversion method according to claim 2, wherein if the authentication mode adopted in the PPP session creation phase does not match the authentication mode adopted in the IP session creation phase, the authentication mode used in the PPP session creation is converted. The authentication mode used in the IP session creation phase and the authentication mode adopted in the IP session creation phase are converted to the authentication mode used in the PPP session creation phase.

The method according to any one of claims 2 to 4, wherein, if only one of the session creation phases of the IP session creation phase and the PPP session creation phase includes an EAP authentication mode, the authentication mode is performed. Before the conversion, the peer communication session with the peer-only session creation phase interacts with the EAP identity, and binds the MAC address of the other party's session communication peer to the EAP identity.

The method according to any one of claims 2 to 4, wherein, if the IP session creation phase and the PPP session creation phase only include an authentication phase, instead of a PPP session communication peer Communicate with the IP session communication peer to complete the authentication phase.

The method according to any one of claims 2 to 4, wherein when the IP conference communication peer is located on the network side,

If the IP session creation phase adopts the DHCP authentication mode of the 82 option, the PPP session packet carrying the access loop identifier and the IP session carrying the access loop identifier in the format of the 82 option are converted. The authentication server in the network side authenticates the PPP session communication peer according to the access loop identifier.

If the IP session creation phase adopts the PAP/Chap mode for DHCP authentication, the Chap challenge word sent by the authentication server in the network side is processed, and the Chap response is returned, so that the authentication server performs authentication according to the authentication information in the Chap response. If the EAP authentication mode is adopted in the IP session creation phase, the EAP response is returned according to the EAP request sent by the authentication server in the network side, so that the authentication server performs authentication according to the authentication information in the EAP response.

The method according to any one of claims 2 to 4, wherein the session creation phase comprises an address allocation phase, wherein: instead of the user-side session communication peer to the network side

The DHCP server requests and obtains the first IP address; assigns a second IP address to the session communication peer end on the user side, and establishes a correspondence between the second IP address and the first IP address;

After the second IP address is assigned to the session communication peer of the user side, the second IP address of the session communication peer end of the user side is converted into the corresponding first IP address, and then forwarded to the session communication peer end of the network side. And converting the first IP address in the packet from the session communication peer end of the network side to the corresponding second IP address, and then forwarding the message to the session communication peer end of the user side.

10. The method of claim 2, wherein the session creation phase of the PPP comprises:

Ethernet bears the point-to-point protocol PPPoE discovery phase: establishes a connection with the PPP session communication peer, and obtains the PPP session identifier;

Link establishment phase: Perform link control protocol LCP negotiation with the PPP session communication peer; wherein the PPPoE discovery phase includes the following steps:

The initial PADI message and the PPPoE activation discovery are confirmed by the PPPoE activation. The PADO session establishes a connection with the PPP session communication peer and determines each other as a subsequent session object, wherein the source address of the PADO packet is filled with the local MAC address.

The peer with the PPP session communicates with the PPPoE to discover the request. The PADR packet and the PADS packet exchange PPP session identifier.

11. A relay device, comprising:

An internet protocol IP session interface unit, configured to exchange an IP session with an IP session communication peer; a session conversion unit, configured to process a letter in the ppp session that needs to be processed by the IP session communication peer The information is sent to the IP session communication peer in the form of an IP session, and the information that needs to be processed by the PPP session communication peer in the IP session is sent to the PPP session communication peer in the form of a PPP session.

The apparatus according to claim 11, wherein the session conversion unit includes an authentication relay AR, and the AR is used for conversion of an authentication phase in a PPP session and an IP session, where the conversion of the authentication phase includes the following Any one:

If the authentication mode adopted in the PPP session creation phase does not match the authentication mode used in the IP session creation phase, the authentication mode used in the PPP session creation is converted to the authentication mode adopted in the IP session creation phase, and the IP session creation phase is adopted. The adopted authentication mode is converted to the authentication mode adopted in the PPP session creation phase;

If the IP session creation phase and the PPP session creation phase include the authentication phase, the PPP session communication peer and the IP session communication peer interaction are performed to complete the authentication phase;

If only one of the session creation phases of the IP session creation phase and the PPP session creation phase includes the EAP authentication mode, the session communication peer interacts with the EAP identity only before the authentication mode is changed, and Bind the MAC address of the other party's session communication peer to the EAP identity.

The relay device according to claim 11, wherein the relay device is a logical device and exists in a home gateway, an access node AN, or an IP edge device; or

The relay device is a physical entity located between the user equipment and the IP edge device.

A communication system, characterized in that the communication system comprises the relay device according to any one of claims 11 to 13.

A computer readable medium having computer executable instructions for performing the steps of any one of claims 1 to 10.