TSG-A WG4 TITLE: GRE L2TPv3 Comparison SOURCE: A40-20070514-xxx SS_GRE_L2TPv3 Comparison TSG-A WG4 TITLE: GRE L2TPv3 Comparison SOURCE: Samsung : Kyungjoo Grace Suh, Bill Semper, B.S. Bae, ABSTRACT: This contribution compares the use of GRE versus L2TPv3 for the inter-AN interface in the Evolved Network Architecture. DATE: May 14, 2007 RECOMMENDATION: Note. Notice Samsung Electronics grant a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner's name any Organizational Partner's standards publication even though it may include all or portions of this contribution; and at the Organizational Partner's sole discretion to permit others to reproduce in whole or in part such contribution or the resulting Organizational Partner's standards publication. Samsung Electronics are also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partner’s standard which incorporates this contribution. This document has been prepared by Samsung Electronics to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on Samsung Electronics . Samsung Electronics specifically reserves the right to amend or modify the material contained herein and to any intellectual property of Samsung Electronics other than provided in the copyright statement above.

Samsung’s Position L2TPv3 has been proposed as a protocol for the inter-AN interface (IP packet tunneling as well as Layer tunneling) In this contribution, we closely analyze the header overhead from these two protocols We also look at the mechanisms needed to establish the tunnels Based on our analysis, we conclude the GRE is the better solution for the inter-AN tunneling protocol

GRE Header 1 2 3 4 5 6 7 8 9 C r K S Reserved Ver Protocol Type Key 1 2 3 4 5 6 7 8 9 C r K S Reserved Ver Protocol Type Key Sequence number (Optional) Attributes (Optional) User Traffic (Optional)

GRE Header (cont.) C (Checksum Present) ‘0’ r (reserved) ‘0’ K (Key Present) ‘1’ S (Sequence Number Present) ‘0 or 1’ Reserved ‘000000000’ Ver (Version Number) ‘000’ Protocol Type: Hex ‘88 81H’ for “Unstructured Byte Stream”, or hex ‘88 D2H’ for “3GPP2 Packet”. The protocol type shall be set to “3GPP2 Packet” only if the packet contains attributes. Key The Key field contains a four-octet number Sequence number: If the link layer/network layer protocol requires that the GRE packets be delivered in sequence (e.g. if a state-full compression mechanism is in use) over the connection, the S indicator shall be set to ‘1’ and the sequence number field shall be included in each GRE packet sent over the connection. Attributes: If the Protocol Type field is set to ’88 D2H’ for “3GPP2 Packet”, one or more attributes are included

L2TPv3 Header 7 6 5 4 3 2 1 Octet (MSB) Session ID = 55 4D 42 01H ...   7 6 5 4 3 2 1 Octet (MSB) Session ID = 55 4D 42 01H ... (LSB) Version Direction AGW IP Addr. Ver. Sequence Included TTL Reserved CRC

L2TPv3 Header (cont.) Session ID: This is a 32-bit field set to 55 4D 42 01H Version : 3 bit field which gives the version of the header Direction : 1 bit field which is set to ‘0’ or ‘1’ to indicate direction AGW IP Address Version This is a 1-bit field which is set to ‘0’ if the AGW address field contains an IPv4 address or ‘1’ if the AGW address field contains an IPv6 address Sequence Included This is a 1-bit field which is set to ‘1’ if the AGW Sequence Number field is present. Otherwise this field is set to ‘0’. The AGW Sequence Number may be used to provide in-order packet delivery TTL : 3 bit field for the time to live for the packets CRC : 16 bit CRC covering the L2TPv3 header computed using the polynomial x0 + x1 + x2 + x4 + x5 + x7 + x8 + x10 + x11 + x12 + x16 + x22 + x23 + x26 + x32 . Other attribute fields for AGW Address, Mobile Key, and Sequence Number

L2TPv3 Header vs. GRE Header Scenario: AGW, MIPv4 address is sent, Sequence number is included. To be fair, assume Checksum included in GRE (to match CRC in L2TPv3). L2TPv3: Session_ID: 4 bytes Parameters/CRC: 4 bytes AGW MIPv4 IP Address: 4 bytes Key: 4 bytes Sequence Number: 4 bytes TOTAL: 20 bytes of overhead per packet

L2TPv3 Header vs. GRE Header (cont.) Define new Attribute for ‘3GPP2’ protocol to carry AGW MIPv4 IP Address. 2 byte subheader, 4 bytes for address: 6 bytes total These are already defined in IOS for other purposes Parameters: 4 bytes Key: 4 bytes Sequence Number: 4 bytes AGW MIPv4 Attribute: 6 bytes Checksum: 2 bytes TOTAL: 20 bytes of overhead per packet. CONCLUSION: There is no advantage in terms of header overhead in using L2TPv3 for inter-RAN bearer tunneling

L2TPv3 vs. GRE: Tunnel Setup GRE Keys can be assigned during AGW-BS bearer setup No reason separate keys can not be used for forward and reverse directions If PMIP is used and supports carrying GRE keys, this should be possible Keys for AT are then known at the AN as part of the network context passed when added to the Route Set Extra overhead of passing extra keys for separate direction is minimal – number of ANs is not very large GRE does not need explicit tunnel setup signaling; the same method used for L2TPv3 will work CONCLUSION: L2TPv3 does not have an advantage over GRE in tunnel establishment

GRE Preference L2TPv3 does not appear to offer any distinct advantages over GRE GRE is already widely used in today’s RANs GRE is being proposed for the AGW-eBS bearer We recommend keeping GRE for the eBS-eBS interface as well