No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

NE40E-M2 V800R010C10SPC500 Feature Description - User Access 01

This is NE40E-M2 V800R010C10SPC500 Feature Description - User Access
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
L2TP Packets

L2TP Packets

Figure 8-2 L2TP protocol structure

Figure 8-2 depicts the relationship of PPP frames and control messages over the L2TP control and data channels. PPP frames are passed through an unreliable data channel; control messages are sent over a reliable L2TP control channel.

Both L2TP data and control messages are transmitted in UDP packets. Data messages are not retransmitted in the case of transmission failures and therefore the transmission is unreliable; the transmission of control messages, however, is controlled by the traffic control and retransmission mechanisms and therefore is reliable. L2TP uses the registered UDP port 1701 and this port is used only during the initial establishment of an L2TP tunnel. The initiator of an L2TP tunnel picks a free source UDP port (which may or may not be 1701), and sends packets to port 1701 of the receiver. Upon receiving the packets, the receiver also picks a free port on its own system (which may or may not be 1701), and sends a reply to the initiator's UDP port. Once the source and destination ports and addresses are specified, they must remain unchanged as long as the tunnel is connective.

L2TP Header

Headers of L2TP control messages and L2TP data messages are the same.

Figure 8-3 Format of an L2TP message header

In the L2TP message header, "opt" following a field indicates that the field is optional in a data message but is mandatory in a control message.

Figure 8-3 describes the fields in an L2TP message header.

Table 8-1 Description of fields in an L2TP message header

Field

Meaning

Remarks

T

Indicates the type of a message:
  • 0: indicates a data message.
  • 1: indicates a control message.

The value must be 1 in a control message.

L

Indicates the Length bit. The value 1 indicates that a message header contains the Length field.

The value must be 1 in a control message.

x

Indicates a reserved bit.

-

S

Indicates the Sequence bit. The value 1 indicates that a message header contains the Ns field and the Nr field.

The value must be 1 in a control message.

O

Indicates the Offset size bit. The value 1 indicates that a message header contains the Offset size field.

The value must be 0 in a control message.

P

Indicates the priority. This field exists only in a data message.

The value must be 0 in a control message.

Ver

Indicates the version number of the L2TP protocol.

The value is 2 if L2TPv2 is enabled.

Length

Indicates the total length of a message, in bytes.

-

Tunnel ID

Indicates the tunnel ID, which is only locally valid.

The value must be 0 in a Hello control message because the Hello control message is globally valid.

Session ID

Indicates the session ID, which is only locally valid.

-

Ns

Indicates the sequence number of the current message.

-

Nr

Indicates the sequence number of the next message expected to be received.

It is a reserved field in data messages.

offset size

Indicates the origin position of the payload.

-

offset padding

Indicates the padding bit.

-

The tunnel ID and session ID contained in an L2TP message header are allocated by the peer along an L2TP tunnel to identify a tunnel and a session, respectively. Messages with the same tunnel ID and different session IDs are multiplexed on one L2TP tunnel.

Structure of an L2TP Data Message

A user PPP packet (already encapsulated with a source IP header and a PPP header) is encapsulated with the following protocol headers when being transmitted as an IP packet over a public network:

  • A 16-byte L2TP header

  • An 8-byte UDP header

  • A 20-byte new IP header, indicating the source and destination addresses of an L2TP tunnel

Figure 8-4 shows the format of an L2TP data message.

Figure 8-4 Format of an L2TP data message

The LAC encapsulates a PPP packet as follows:

  1. Encapsulates the packet with an L2TP header.

  2. Encapsulates the packet with a UDP header.

  3. Encapsulates the packet with a new IP header and then sends the packet through a public network interface. The destination address in the new IP header is the IP address of the destination of the L2TP tunnel.

NOTE:

L2TP has no data fragmentation function. After an L2TP message is encapsulated with an IP header, the IP packet can be fragmented as required. To ensure that no packet needs to be fragmented, the size of the encapsulated IP packet cannot be greater than the value of the MTU of the physical interface.

After receiving the packet on the interface connected to the public network, the LNS handles the packet as follows:

  1. Decapsulates the IP header and the UDP header and then sends the packet to the L2TP module.

  2. Decapsulates the L2TP header and the PPP header to restore the original user IP packet, and then sends the IP packet to the server inside the private network.

Download
Updated: 2019-01-02

Document ID: EDOC1100058415

Views: 14586

Downloads: 9

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next