One document matched: draft-perkins-mext-gtpdata-01.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="no"?>
<!-- rfc ipr="pre5378Trust200902" docName='draft-perkins-mip4-authreq-01.txt'-->
<rfc ipr="trust200811" docName='draft-perkins-mext-gtpdata-01.txt' >
<?rfc symrefs="no"?>
<front>

<title abbrev="GTP Tunnel Request for Mobile IPv6">
	GTP Tunnel Request for Mobile IPv6 </title>

    <author initials="C." surname="Perkins" fullname="Charles E. Perkins">
       <organization>Tellabs Inc.</organization>
      <address>
        <postal>
          <street>4555 Great America Parkway</street>
          <city>Santa Clara</city>
          <region>CA 95054</region>
          <country>USA</country>
        </postal>
        <email>charliep@computer.org</email>
      </address>
    </author>



<date month="August" year="2011" />

  <area>Internet</area>
  <workgroup>Mobility Extensions for IPv6 [mext]</workgroup>
<keyword>Mobility</keyword>
<keyword>IPv6</keyword>
<keyword>Proxy MIP</keyword>
<keyword>Tunneling</keyword>


<abstract>

<t>
	Widely deployed mobility management systems for wireless
	communications use GTP for transmitting packets to mobility
	agents serving the mobile node.  In order to enable use of
	Proxy Mobile IPv6 in such telecommunication systems, GTP
	should be allowed as a tunneling choice for packets between
	the LMA and the MAG.  This specification allocates a new
	bit (the 'G' bit) in the Proxy Binding Update for the purpose
	of enabling GTP tunneling.
</t>
</abstract>

</front>

<middle>
<section anchor='intro' title='Introduction'>

<t>
	Widely deployed mobility management systems for wireless
	communications use GTP <xref target="TS_29-060"/>
	for transmitting packets to mobility
	agents serving the mobile node.  In order to enable use of
	Proxy Mobile IPv6 in such telecommunication systems, GTP
	<xref target="RFC5213"/>
	should be allowed as a tunneling choice for packets between
	the LMA and the MAG.  This specification allocates a new
	bit (the 'G' bit) in the Proxy Binding Update for the purpose
	of enabling GTP tunneling.

	This specification does not introduce any modifications to GTP.
	Considerations about the use of GTP-C for establishing binding
	updates is outside the scope of this specification.
</t>

</section>

<section anchor='bu_gtp'
	title='GTP tunneling bit in Binding Update'>

<t>
	In order to request GTP tunneling, the 'G' bit is set
	in the Binding Update.  This is also useful when the 'P'
	bit is set, so that the MAG can indicate that the LMA
	should use GTP as the tunneling protocol for proxy packet
	delivery.
</t>

<figure><artwork>
	                            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	                            |          Sequence #           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |A|H|L|K|M|R|P|G|    Reserved   |           Lifetime            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                        Mobility options                       .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>

<t>
<list style='hanging'>

<t hangText='G'> <vspace blankLines='1' />

	The 'G' bit is allocated from the previously
	reserved bits in the Binding Update header.
</t>

</list>
</t>

</section>

<section anchor='new_status'
	title='New Status Code for GTP tunneling rejection'>

<t hangText='Status'>
	<vspace blankLines='1' />
	The Status is an 8-bit unsigned integer field in a Binding
	Acknowledgement message, indicating the disposition of the
	Binding Update.  Values of the Status field less than 128
	indicate that the Binding Update was accepted by the receiving
	node.
	Values greater than or equal to 128
	indicate that the Binding Update was rejected by the receiving
	node. The following new Status value is specified for use when
	the receiving node cannot provide GTP as a tunneling option.
</t>
<t>
<list style='hanging'>


<t hangText='TBD'>
 Invalid Tunnel Format
</t>

</list>
</t>
</section>

<section anchor='sec' title='Security Considerations'>

<t>

	This document does not introduce any security mechanisms,
	and does not have any impact on existing security mechanisms.
	Tunneling of data via GTP does not introduce any
	known security vulnerabilities.

</t>

</section>

<section anchor='iana' title='IANA Considerations'>

<t>
	This document allocates a new bit from the reserved field of
	the Binding Update message header.  The new bit is
	denoted the 'G' bit.

	This document also creates a new "Status Code" for the Status field
	in the Binding Acknowledgement message. The new status code,
	"Invalid Tunnel Format",
	indicates rejection of the requested tunneling mode in the
	Binding Update, and is needed if the receiver of the Binding
	Update does not offer GTP encapsulation.  The new Status Code
	is required to be allocated from the values larger than 128
	in order to indicate that the Binding Update was rejected.
</t>

</section>

</middle>

<back>


<references title='Normative References'>
<?rfc include='reference.RFC.2373.xml'?>
<?rfc include='reference.RFC.5213.xml'?>
<reference anchor="TS_29-060">
  <front>
	<title>
	3GPP Technical Specification 23.060: General Packet Radio
	Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn
	and Gp interface (Release 8)
	</title>
    <author surname="3rd Generation Partnership Project">
    <organization>
    </organization>
    </author>
    <date month="March" year="2007"/>
  </front>
</reference>
</references>

</back>

</rfc>